libquicktime-devel — Discussion about development

Re: [Libquicktime-devel] libquicktime on windows

[Burkhard P. <bur...@ig...>]

Hi,

Am 15.11.2013 16:20, schrieb Derek Chow:
> Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS.
> ________________________________________

Applied.

Do I understand it right that libquicktime CVS now compiles in mingw in 32- and 64 bit,
provided all dependencies are installed?

Burkhard

Re: [Libquicktime-devel] libquicktime on windows

[Derek C. <der...@mi...>]

Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS.
________________________________________
From: Burkhard Plaum [bur...@ig...]
Sent: 08 October 2013 10:11
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows

Hi,

Am 07.10.2013 17:00, schrieb Christian Ebert:
> * Burkhard Plaum on Monday, October 07, 2013 at 16:39:12 +0200
>> Am 03.10.2013 17:07, schrieb Derek Chow:
>>> cool,
>>>
>>>> Applied 004_localtime_s.patch with a tiny fix
>>>> _localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S
>>>
>>> Looking back at that patch, I reckon the check for defined(_WIN64) is also probably unnecessary.
>>> How about a further change to just see if these msvcrt methods are available when we resort to
>>> them (see attached win_localtime.diff)?
>>
>> Agree, applied.
>>
>>>> So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
>>>> and testing 005_libtool_dll_fix.patch on some other systems.
>>>
>>> FYI I've used 005_libtool_dll_fix.patch for builds on linux with no apparent issues.
>>
>> Applied
>
> The above, or one of the above causes build to fail on Mac OS
> 10.8.5:

[...]

Oops.

Ok, I introduced a variable MODULE_LDFLAGS, which is set by configure and used in
plugins/*/Makefile.am

Currently it's set to "-no-undefined" just for Linux. It can easily be tweaked for other
systems depending on the variable $host_os, but I don't know what values $host_os has on
Win32 and Win64. Maybe Derek can find this out and make a patch for configure.ac.

Burkhard


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Libquicktime-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libquicktime-devel

Re: [Libquicktime-devel] Patch Two bugs found with 1.2.4

[Burkhard P. <bur...@ig...>]

Hi,

Am 28.10.2013 19:53, schrieb Paul J. Taggart:
>
> Sorry, I left "lqt_" off the module names. Patches are attached.

Applied.
Burkhard

Re: [Libquicktime-devel] Patch Two bugs found with 1.2.4

[Paul J. T. <pta...@ci...>]

Sorry, I left "lqt_" off the module names. Patches are attached.
On Mon, 2013-10-28 at 10:56 -0400, Paul J. Taggart wrote:
> I've run into two bugs. The first causes Segmentation Faults when
> reading video frames with the native color model after reading frames
> from the same file with a different color model.
> 
> lines 372 & 373 of codecs.c should be:
> file->vtracks[track].io_row_span =
> file->vtracks[track].stream_row_span;
> file->vtracks[track].io_row_span_uv =
> file->vtracks[track].stream_row_span_uv;
> The current version has those assignments reversed and changes the
> rowspan for the native color model to the last color model used.
> 
> The other bug miscalculates the space needed for the uv planes: Line
> 495 of color.c should be: 
> uv_size = rowspan_uv * ((height + sub_v - 1)/sub_v);
> not: 
> uv_size = (rowspan_uv * ((height + sub_v - 1))/sub_v;
> 
> Doing the integer division after the multiplication makes the uv_size
> a
> half a line too large. The addition of sub_v - 1 to the height is to
> force rounding up if the height of the frame is an odd number and
> sub_v
> = 2. By multiplying the (height +1) by the rowspan_uv before dividing
> by 2, integer truncation does not work.
> 
> I can provide this in patch format if needed. 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Libquicktime-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libquicktime-devel

[Libquicktime-devel] Two bugs found with 1.2.4

[Paul J. T. <pta...@ci...>]

I've run into two bugs. The first causes Segmentation Faults when
reading video frames with the native color model after reading frames
from the same file with a different color model.

lines 372 & 373 of codecs.c should be:
file->vtracks[track].io_row_span = file->vtracks[track].stream_row_span;
file->vtracks[track].io_row_span_uv =
file->vtracks[track].stream_row_span_uv;
The current version has those assignments reversed and changes the
rowspan for the native color model to the last color model used.

The other bug miscalculates the space needed for the uv planes: Line
495 of color.c should be: 
uv_size = rowspan_uv * ((height + sub_v - 1)/sub_v);
not: 
uv_size = (rowspan_uv * ((height + sub_v - 1))/sub_v;

Doing the integer division after the multiplication makes the uv_size a
half a line too large. The addition of sub_v - 1 to the height is to
force rounding up if the height of the frame is an odd number and sub_v
= 2. By multiplying the (height +1) by the rowspan_uv before dividing
by 2, integer truncation does not work.

I can provide this in patch format if needed.

Re: [Libquicktime-devel] AAC audio

[Burkhard P. <bur...@ig...>]

Hi,

Am 07.10.2013 21:48, schrieb Erik Johansson:
> Hi,
[...]
>> AVCodecContext provides a field for audio sample format as follows:
>>      /**
>>       * audio sample format
>>       * - encoding: Set by user.
>>       * - decoding: Set by libavcodec.
>>       */
>>      enum AVSampleFormat sample_fmt;  ///< sample format
>> The audio decoder in libquicktimes ffmpeg plugin sets sample_fmt to 16bit signed, and
>> then relies on that being the case throughout the code. Only the latest ffmpeg resets
>> sample_fmt to float as per the documentation.

This was written at a time when all ffmpeg audio codecs used 16 bit samples. Nowadays it's
different. The behaviour of the core is to call the decode() function with output = NULL at
the beginning. During this initialization call, the member atrack->sample_format can be set
(according to what's in ffmpeg). In most codecs it's hardwired, but in audiocodec/pcm.c
you'll find a function init_decode_lpcm(), which does runtime detection of the sample format.

Making proper sample format detection and supporting planar audio in ffmpeg would be a very
patch to start with.

Burkhard

Re: [Libquicktime-devel] libquicktime on windows

[Burkhard P. <bur...@ig...>]

Hi,

Am 07.10.2013 17:00, schrieb Christian Ebert:
> * Burkhard Plaum on Monday, October 07, 2013 at 16:39:12 +0200
>> Am 03.10.2013 17:07, schrieb Derek Chow:
>>> cool,
>>>
>>>> Applied 004_localtime_s.patch with a tiny fix
>>>> _localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S
>>>
>>> Looking back at that patch, I reckon the check for defined(_WIN64) is also probably unnecessary.
>>> How about a further change to just see if these msvcrt methods are available when we resort to
>>> them (see attached win_localtime.diff)?
>>
>> Agree, applied.
>>
>>>> So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
>>>> and testing 005_libtool_dll_fix.patch on some other systems.
>>>
>>> FYI I've used 005_libtool_dll_fix.patch for builds on linux with no apparent issues.
>>
>> Applied
>
> The above, or one of the above causes build to fail on Mac OS
> 10.8.5:

[...]

Oops.

Ok, I introduced a variable MODULE_LDFLAGS, which is set by configure and used in
plugins/*/Makefile.am

Currently it's set to "-no-undefined" just for Linux. It can easily be tweaked for other
systems depending on the variable $host_os, but I don't know what values $host_os has on
Win32 and Win64. Maybe Derek can find this out and make a patch for configure.ac.

Burkhard

Re: [Libquicktime-devel] AAC audio

[Erik J. <eri...@gm...>]

Hi,

On Mon, Oct 7, 2013 at 2:02 PM, Burkhard Plaum
<bur...@ig...> wrote:
> - If an ffmpeg decoder outputs floating point samples, they should be
>    passed through and not converted to 16 bit int.
>
> - The prime samples are completely ignored by the faad2 based decoder so ignoring them
>    for the ffmpeg decoder would mean no feature regression.
>
> - The proper method for getting the prime samples can be a separate patch. If the data
>    is available in an itunes atom this can be used of course, but we shouln't write any
>    itunes specific stuff unless the file type is LQT_FILE_M4A.

I'll just add a few additional comments. As Phil wrote, we had an
internal discussion about whether to send our existing solution as a
patch to libquicktime. My comments at that time were:

> 1) The support for reading the iTunes atom is very limited, as we only read iTunSMPB.
> It appears most of the other supported atoms can be both read and written.
>
> 2) The parsing of the payload of the iTunSMPB is assumes the data is correctly
> formatted.

A little later, we switched to a newer version of ffmpeg, which is
where the horrible float to 16-bit audio hack enters the picture. My
unredacted notes with regards to that are as follows:

> AVCodecContext provides a field for audio sample format as follows:
>     /**
>      * audio sample format
>      * - encoding: Set by user.
>      * - decoding: Set by libavcodec.
>      */
>     enum AVSampleFormat sample_fmt;  ///< sample format
> The audio decoder in libquicktimes ffmpeg plugin sets sample_fmt to 16bit signed, and
> then relies on that being the case throughout the code. Only the latest ffmpeg resets
> sample_fmt to float as per the documentation. In addition, it appears memory
> allocated for audio decoded using avcodec_decode_audio4() is never free'd.

and

> Fixed memory leak and implemented horrible hack to get by for now. Opened bug
> 24574 for fixing properly ("broken gets fixed, shoddy lasts forever").

I realise I'm probably mixing issues on the same thread, but hopefully
it'll provide some context that may prove helpful to Derek :-)

Thanks,
Erik

Re: [Libquicktime-devel] libquicktime on windows

[Christian E. <bla...@gm...>]

* Burkhard Plaum on Monday, October 07, 2013 at 16:39:12 +0200
> Am 03.10.2013 17:07, schrieb Derek Chow:
>> cool,
>> 
>>> Applied 004_localtime_s.patch with a tiny fix
>>> _localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S
>> 
>> Looking back at that patch, I reckon the check for defined(_WIN64) is also probably unnecessary.
>> How about a further change to just see if these msvcrt methods are available when we resort to
>> them (see attached win_localtime.diff)?
> 
> Agree, applied.
> 
>>> So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
>>> and testing 005_libtool_dll_fix.patch on some other systems.
>> 
>> FYI I've used 005_libtool_dll_fix.patch for builds on linux with no apparent issues.
> 
> Applied

The above, or one of the above causes build to fail on Mac OS
10.8.5:

libtool: link: gcc  -o .libs/lqt_vorbis.so -bundle  .libs/vorbis.o .libs/lqt_vorbis.o   -L/usr/local/lib -L/sw/lib ../../src/.libs/libquicktime.dylib /sw/lib/libiconv.dylib /sw/lib/libintl.dylib /sw/lib/libvorbisenc.dylib /sw/lib/libvorbis.dylib /sw/lib/libvorbisfile.dylib -lm -lz -ldl  -O3
Undefined symbols for architecture x86_64:
  "_ogg_page_eos", referenced from:
      _flush_data in vorbis.o
  "_ogg_page_serialno", referenced from:
      _next_page in vorbis.o
  "_ogg_stream_clear", referenced from:
      _delete_codec in vorbis.o
      _decode in vorbis.o
  "_ogg_stream_flush", referenced from:
      _encode in vorbis.o
      _flush_data in vorbis.o
  "_ogg_stream_init", referenced from:
      _encode in vorbis.o
      _next_page in vorbis.o
  "_ogg_stream_packetin", referenced from:
      _encode in vorbis.o
      _flush_data in vorbis.o
  "_ogg_stream_packetout", referenced from:
      _decode in vorbis.o
      _decode_frame in vorbis.o
  "_ogg_stream_pagein", referenced from:
      _next_page in vorbis.o
  "_ogg_sync_buffer", referenced from:
      _next_page in vorbis.o
  "_ogg_sync_init", referenced from:
      _decode in vorbis.o
  "_ogg_sync_pageout", referenced from:
      _next_page in vorbis.o
  "_ogg_sync_reset", referenced from:
      _decode in vorbis.o
  "_ogg_sync_wrote", referenced from:
      _next_page in vorbis.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [lqt_vorbis.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


-- 
  Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
free movies       --->>> http://www.blacktrash.org/underdogma
http://itunes.apple.com/podcast/underdogma-movies/id363423596

Re: [Libquicktime-devel] libquicktime on windows

[Burkhard P. <bur...@ig...>]

Hi,

Am 03.10.2013 17:07, schrieb Derek Chow:
> cool,
>
>> Applied 004_localtime_s.patch with a tiny fix
>> _localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S
>
> Looking back at that patch, I reckon the check for defined(_WIN64) is also probably unnecessary.
 > How about a further change to just see if these msvcrt methods are available when we resort to
 > them (see attached win_localtime.diff)?

Agree, applied.

>> So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
>> and testing 005_libtool_dll_fix.patch on some other systems.
>
> FYI I've used 005_libtool_dll_fix.patch for builds on linux with no apparent issues.

Applied

Burkhard

Re: [Libquicktime-devel] AAC audio

[Burkhard P. <bur...@ig...>]

Hi,

Am 04.10.2013 17:28, schrieb Phil Barrett:
> Hi Derek
>
> Try attached patch against current CVS tip - it's probably not quite right but it's mostly there.
>

I took a quick look and noticed the following (for the case it should go into cvs):

- If an ffmpeg decoder outputs floating point samples, they should be
   passed through and not converted to 16 bit int.

- The prime samples are completely ignored by the faad2 based decoder so ignoring them
   for the ffmpeg decoder would mean no feature regression.

- The proper method for getting the prime samples can be a separate patch. If the data
   is available in an itunes atom this can be used of course, but we shouln't write any
   itunes specific stuff unless the file type is LQT_FILE_M4A.

Burkhard

Re: [Libquicktime-devel] AAC audio

[Derek C. <der...@mi...>]

Oh yes please, if possible I'd like to have a look.

(PS, say hi to Mark for me! :P)

________________________________
From: Phil Barrett [ph...@fi...]
Sent: 04 October 2013 15:31
To: Derek Chow
Cc: lib...@li...
Subject: Re: [Libquicktime-devel] AAC audio

Hi Derek

I was just starting to have a go at adding an AAC decoder to the lqt_ffmpeg plugin as an LPGL alternative to using the GPL lqt_faad2 plugin and when I decided to do a search on the mailing list I saw this thread start by you - proposing to do exactly the same thing!

Don't suppose you got anywhere with a patch?  Any remarks to make on getting this working?

My colleague Erik Johansson implemented AAC decoding support via the FFMPEG plugin.

He doesn't think the patch would be considered appropriate for merging as it stands currently, largely because it's implemented by reading one part of the iTunes data atom (iTunSMPB) without any support for writing this, or for reading or writing other parts of the atom. But it works for us.

We could put together a patch for you to develop further if you liked.

Phil
--
Phil Barrett
FilmLight Ltd

Re: [Libquicktime-devel] AAC audio

[Phil B. <ph...@fi...>]

Hi Derek

> I was just starting to have a go at adding an AAC decoder to the  
> lqt_ffmpeg plugin as an LPGL >alternative to using the GPL lqt_faad2  
> plugin and when I decided to do a search on the mailing list I >saw this  
> thread start by you - proposing to do exactly the same thing!
>
> Don't suppose you got anywhere with a patch?  Any remarks to make on  
> getting this working?

My colleague Erik Johansson implemented AAC decoding support via the  
FFMPEG plugin.

He doesn't think the patch would be considered appropriate for merging as  
it stands currently, largely because it's implemented by reading one part  
of the iTunes data atom (iTunSMPB) without any support for writing this,  
or for reading or writing other parts of the atom. But it works for us.

We could put together a patch for you to develop further if you liked.

Phil
-- 
Phil Barrett
FilmLight Ltd

Re: [Libquicktime-devel] AAC audio

[Derek C. <der...@mi...>]

Hi Phil,

I was just starting to have a go at adding an AAC decoder to the lqt_ffmpeg plugin as an LPGL alternative to using the GPL lqt_faad2 plugin and when I decided to do a search on the mailing list I saw this thread start by you - proposing to do exactly the same thing!

Don't suppose you got anywhere with a patch?  Any remarks to make on getting this working?

Thanks,
Derek

Re: [Libquicktime-devel] libquicktime on windows

[Derek C. <der...@mi...>]

cool,

> Applied 004_localtime_s.patch with a tiny fix
> _localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S

Looking back at that patch, I reckon the check for defined(_WIN64) is also probably unnecessary.  How about a further change to just see if these msvcrt methods are available when we resort to them (see attached win_localtime.diff)?

> So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
> and testing 005_libtool_dll_fix.patch on some other systems.

FYI I've used 005_libtool_dll_fix.patch for builds on linux with no apparent issues.

________________________________________
From: Burkhard Plaum [bur...@ig...]
Sent: 27 September 2013 14:48
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows

Hi,

sorry for the delay....

I applied:
002_bzero_bcopy_to_memset_memcpy.patch


Am 12.09.2013 19:19, schrieb Derek Chow:
> Hi Burkhard,
>
>> This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
>> by the configure script, but these checks are missing in
>> configure.ac.
>
> I've been relying on the implicit check that AC_FUNC_MMAP does - I've tried using
 > AC_CHECK_FUNCS_ONCE on getpagesize to explicitly ensure it's checked but it still bloats
 > the configure script with duplicate checks because the implicit check uses AC_CHECK_FUNCS.
 > Shall we just stick it on the AC_CHECK_FUNCS call in configure.ac anyway (if it's cached I
 > suppose it's not that slow)?

I'd not rely on implicit checks, because AC_FUNC_MMAP might be changed in the future.
The autotools cause enough headaches with version compatibilities already....

> I've attached a new 004_localtime_s.patch that works around the missing localtime_s export from
 > msvcrt in MinGW - instead use the _localtime{32,64}_s functions (which localtime_s basically
 > inlines depending on the target arch).  Also replaced the perror with a comment when falling back
 > to the non-reentrant localtime.

Applied 004_localtime_s.patch with a tiny fix
_localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S

> I compiled libquicktime as a dll and linked to it in an MSVC built application with the
 > generated libquicktime.dll.a import library - it would appear that the use of -fvisibility=hidden
 > is externing the functions correctly.

Ahh now I got it. The problem was a non-gcc compiler stumbling on the *header* file when compiling
an application (not libquicktime istelf).

Applied 006_pragma_gcc_fix.patch


> I've attached a new unified diff for 007_LQT_CODEC_FILE_win_default.patch that #ifdef's the usage of USERPROFILE only for Windows.

Ok, applied 007_LQT_CODEC_FILE_win_default.patch

So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
and testing 005_libtool_dll_fix.patch on some other systems.

Burkhard

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Libquicktime-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libquicktime-devel

Re: [Libquicktime-devel] libquicktime on windows

[Burkhard P. <bur...@ig...>]

Hi,

sorry for the delay....

I applied:
002_bzero_bcopy_to_memset_memcpy.patch


Am 12.09.2013 19:19, schrieb Derek Chow:
> Hi Burkhard,
>
>> This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
>> by the configure script, but these checks are missing in
>> configure.ac.
>
> I've been relying on the implicit check that AC_FUNC_MMAP does - I've tried using
 > AC_CHECK_FUNCS_ONCE on getpagesize to explicitly ensure it's checked but it still bloats
 > the configure script with duplicate checks because the implicit check uses AC_CHECK_FUNCS.
 > Shall we just stick it on the AC_CHECK_FUNCS call in configure.ac anyway (if it's cached I
 > suppose it's not that slow)?

I'd not rely on implicit checks, because AC_FUNC_MMAP might be changed in the future.
The autotools cause enough headaches with version compatibilities already....

> I've attached a new 004_localtime_s.patch that works around the missing localtime_s export from
 > msvcrt in MinGW - instead use the _localtime{32,64}_s functions (which localtime_s basically
 > inlines depending on the target arch).  Also replaced the perror with a comment when falling back
 > to the non-reentrant localtime.

Applied 004_localtime_s.patch with a tiny fix
_localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S

> I compiled libquicktime as a dll and linked to it in an MSVC built application with the
 > generated libquicktime.dll.a import library - it would appear that the use of -fvisibility=hidden
 > is externing the functions correctly.

Ahh now I got it. The problem was a non-gcc compiler stumbling on the *header* file when compiling
an application (not libquicktime istelf).

Applied 006_pragma_gcc_fix.patch


> I've attached a new unified diff for 007_LQT_CODEC_FILE_win_default.patch that #ifdef's the usage of USERPROFILE only for Windows.

Ok, applied 007_LQT_CODEC_FILE_win_default.patch

So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
and testing 005_libtool_dll_fix.patch on some other systems.

Burkhard

Re: [Libquicktime-devel] libquicktime on windows

[Derek C. <der...@mi...>]

Hi Burkhard,

> This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
> by the configure script, but these checks are missing in
> configure.ac.

I've been relying on the implicit check that AC_FUNC_MMAP does - I've tried using AC_CHECK_FUNCS_ONCE on getpagesize to explicitly ensure it's checked but it still bloats the configure script with duplicate checks because the implicit check uses AC_CHECK_FUNCS.  Shall we just stick it on the AC_CHECK_FUNCS call in configure.ac anyway (if it's cached I suppose it's not that slow)?

> > # localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
> > # FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
> > $ patch -p0 004_localtime_s.patch

> Not sure which systems are affected, but printing repeated error
> messages for missing OS festures is no good idea.

I've attached a new 004_localtime_s.patch that works around the missing localtime_s export from msvcrt in MinGW - instead use the _localtime{32,64}_s functions (which localtime_s basically inlines depending on the target arch).  Also replaced the perror with a comment when falling back to the non-reentrant localtime.

> Looks ok if it doesn't break on Linux or OSX (please verify).

I'll hopefully get back with some tests on Linux soon (but don't have an mac machine handy at the moment to test OSX).

> Ok but how is the symbol visibility handled on Windows? Did you compile libquicktime
> as a DLL?

I compiled libquicktime as a dll and linked to it in an MSVC built application with the generated libquicktime.dll.a import library - it would appear that the use of -fvisibility=hidden is externing the functions correctly.

> Please make a unified diff so I can look at it. Trying to check for $USERPROFILE should
> happen on Windows only. On Posix systems, this always fails and just wastes time. Or (even worse)
> $USERPROFILE could be set and used for something completely unrelated.

I've attached a new unified diff for 007_LQT_CODEC_FILE_win_default.patch that #ifdef's the usage of USERPROFILE only for Windows.

________________________________________
From: Burkhard Plaum [bur...@ig...]
Sent: 12 September 2013 14:07
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows

Hi,

Am 12.09.2013 13:09, schrieb Derek Chow:
> Ok, I've got a base win32 build of libquicktime including ffmpeg plugin support!

Very good.

 > I've attached some
 > patches I've used - mind I have yet to verify whether they break the linux build.  See below for
 > some remarks.

[...]

> ########################
> ### Building libquicktime ###
> ########################
>
> # NOTE: It's important to do the CVS checkout in the msys shell rather than in a Windows environment to avoid Windows line-endings getting in the way of building.
> $ cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login
> $ cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -D2013-05-13 -P libquicktime
>
> # (Sorry, I'm currently not so up-to-date checkout of libquicktime due to the project I'm working with - so I hope the patches still work when I update)
> $ cd libquicktime

You should always patch against cvs.

> # replace usage of bzero and bcopy with memset and memcpy:
> $ patch -p0 002_bzero_bcopy_to_memset_memcpy.patch

Patch looks ok.

> # replace usage of sysconf with getpagesize:
> $ patch -p0 003_getpagesize.patch

This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
by the configure script, but these checks are missing in
configure.ac.

> # localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
> # FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
> $ patch -p0 004_localtime_s.patch

+ #else
+   perror("Using thread-unsafe localtime");
+   memcpy(&tm, localtime(&ti), sizeof(tm));
+ #endif

Not sure which systems are affected, but printing repeated error
messages for missing OS festures is no good idea.

> # add -no-undefined to the libtool calls for making shared libraries:
> $ patch -p0 005_libtool_dll_fix.patch

Looks ok if it doesn't break on Linux or OSX (please verify).

> # tweak the ABI headers to avoid warnings in case I want to use the libquicktime library with other compilers (which I have successfully tried with MSVC 9.0):
> $ patch -p0 006_pragma_gcc_fix.patch

+ #ifdef __GNUC__
   #pragma GCC visibility push(default)
+ #endif

Ok but how is the symbol visibility handled on Windows? Did you compile libquicktime
as a DLL?

In another library, which was ported to Windows, we have something like:

#ifdef DLLEXPORT
#define GAVL_PUBLIC __declspec(dllexport) // Windows
#else
#define GAVL_PUBLIC __attribute__ ((visibility("default"))) // gcc
#endif

And prefix every public functions by GAVL_PUBLIC (for lqt it would be LQT_PUBLIC).
IIRC this was the only clean way to build a shared library on both systems, but I
might be wrong since I didn't do the porting myself.

The code is compliled with -fvisibility=hidden (if supported by the compiler)
In this case, the pragmas are no longer necessary.

> # fix LQT_CODEC_FILE default to work for windows environments that don't define HOME - using USERPROFILE instead (e.g. "C:\Users\<username>").
> # this isn't necessary if you only intend to run programs in the msys environment
> $ patch -p0 007_LQT_CODEC_FILE_win_default.patch

Please make a unified diff so I can look at it. Trying to check for $USERPROFILE should
happen on Windows only. On Posix systems, this always fails and just wastes time. Or (even worse)
$USERPROFILE could be set and used for something completely unrelated.

[...]

> # NOTE: Running libquicktime applications outside of msys environment:
> As the path that libquicktime searches for it's plugins is currently hardcoded based on a #define
 > setup by the configure script (http://libquicktime.sourceforge.net/doc/codecs.html), you need
 > to setup an environment variable to correctly point to it's location as the msys path
 > e.g. '/c/dev/libquicktime/lib/libquicktime' won't make much sense to Windows natively...

Currently we use $LIBQUICKTIME_PLUGIN_DIR if that exists, and fall back to the hardcoded
default if it doesn't. If you want, you can propose and alternative method on Windows.

> Comments are welcome!

See above. I didn't apply anything yet though. As already said, patch against CVS and
consider my comments.

Burkhard

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Libquicktime-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libquicktime-devel

Re: [Libquicktime-devel] libquicktime on windows

[Burkhard P. <bur...@ig...>]

Hi,

Am 12.09.2013 13:09, schrieb Derek Chow:
> Ok, I've got a base win32 build of libquicktime including ffmpeg plugin support!

Very good.

 > I've attached some
 > patches I've used - mind I have yet to verify whether they break the linux build.  See below for
 > some remarks.

[...]

> ########################
> ### Building libquicktime ###
> ########################
>
> # NOTE: It's important to do the CVS checkout in the msys shell rather than in a Windows environment to avoid Windows line-endings getting in the way of building.
> $ cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login
> $ cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -D2013-05-13 -P libquicktime
>
> # (Sorry, I'm currently not so up-to-date checkout of libquicktime due to the project I'm working with - so I hope the patches still work when I update)
> $ cd libquicktime

You should always patch against cvs.

> # replace usage of bzero and bcopy with memset and memcpy:
> $ patch -p0 002_bzero_bcopy_to_memset_memcpy.patch

Patch looks ok.

> # replace usage of sysconf with getpagesize:
> $ patch -p0 003_getpagesize.patch

This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
by the configure script, but these checks are missing in
configure.ac.

> # localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
> # FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
> $ patch -p0 004_localtime_s.patch

+ #else
+   perror("Using thread-unsafe localtime");
+   memcpy(&tm, localtime(&ti), sizeof(tm));
+ #endif

Not sure which systems are affected, but printing repeated error
messages for missing OS festures is no good idea.

> # add -no-undefined to the libtool calls for making shared libraries:
> $ patch -p0 005_libtool_dll_fix.patch

Looks ok if it doesn't break on Linux or OSX (please verify).

> # tweak the ABI headers to avoid warnings in case I want to use the libquicktime library with other compilers (which I have successfully tried with MSVC 9.0):
> $ patch -p0 006_pragma_gcc_fix.patch

+ #ifdef __GNUC__
   #pragma GCC visibility push(default)
+ #endif

Ok but how is the symbol visibility handled on Windows? Did you compile libquicktime
as a DLL?

In another library, which was ported to Windows, we have something like:

#ifdef DLLEXPORT
#define GAVL_PUBLIC __declspec(dllexport) // Windows
#else
#define GAVL_PUBLIC __attribute__ ((visibility("default"))) // gcc
#endif

And prefix every public functions by GAVL_PUBLIC (for lqt it would be LQT_PUBLIC).
IIRC this was the only clean way to build a shared library on both systems, but I
might be wrong since I didn't do the porting myself.

The code is compliled with -fvisibility=hidden (if supported by the compiler)
In this case, the pragmas are no longer necessary.

> # fix LQT_CODEC_FILE default to work for windows environments that don't define HOME - using USERPROFILE instead (e.g. "C:\Users\<username>").
> # this isn't necessary if you only intend to run programs in the msys environment
> $ patch -p0 007_LQT_CODEC_FILE_win_default.patch

Please make a unified diff so I can look at it. Trying to check for $USERPROFILE should
happen on Windows only. On Posix systems, this always fails and just wastes time. Or (even worse)
$USERPROFILE could be set and used for something completely unrelated.

[...]

> # NOTE: Running libquicktime applications outside of msys environment:
> As the path that libquicktime searches for it's plugins is currently hardcoded based on a #define
 > setup by the configure script (http://libquicktime.sourceforge.net/doc/codecs.html), you need
 > to setup an environment variable to correctly point to it's location as the msys path
 > e.g. '/c/dev/libquicktime/lib/libquicktime' won't make much sense to Windows natively...

Currently we use $LIBQUICKTIME_PLUGIN_DIR if that exists, and fall back to the hardcoded
default if it doesn't. If you want, you can propose and alternative method on Windows.

> Comments are welcome!

See above. I didn't apply anything yet though. As already said, patch against CVS and
consider my comments.

Burkhard

Re: [Libquicktime-devel] libquicktime on windows

[Derek C. <der...@mi...>]

Ok, I've got a base win32 build of libquicktime including ffmpeg plugin support!  I've attached some patches I've used - mind I have yet to verify whether they break the linux build.  See below for some remarks.

########################
### prerequisites ###
########################
I used the following MinGW-w64 toolchain (to cross compile 32-bit binaries to link with my 32-bit application with a view to later move to 64-bit) + msys builds:

    http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/threads-posix/dwarf/x32-4.8.0-release-posix-dwarf-rev2.7z/download
    http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z/download

Using the MinGW-w64 cross-compiler, I've had to add some extra configure parameters to generate appropriate make files.

The following commands with a "$" prompt are ran inside the installed msys shell, with the mingw-w64 toolchain mounted as /mingw...

########################
### building dependencies ###
########################

=== ffmpeg ===
# FFMpeg already has quite a bit of documentation out there how to build Windows libraries so I won't go into any detail.  Some links worth looking at:

#    https://trac.ffmpeg.org/wiki/MingwCompilationGuide
#    http://ffmpeg.zeranoe.com/
#    https://github.com/rdp/ffmpeg-windows-build-helpers

=== dlfcn-win32 to wrap dlfcn ===
# https://code.google.com/p/dlfcn-win32/
# (Compiling from source as I couldn't tell what architecture/exception handling the pre-built files were using - besides it's really small and quick to build)
$ tar xvf dlfcn-win32-r19.tar.bz2
$ cd dlfcn-win32-r19
$ ./configure --cross-prefix=i686-w64-mingw32- --prefix=/mingw/i686-w64-mingw32 --libdir=/mingw/i686-w64-mingw32/lib --incdir=/mingw/i686-w64-mingw32/include --enable-shared
$ make
$ make install
$ cd ..

=== GNU libiconv ===
# http://ftpmirror.gnu.org/libiconv
$ tar xvf libiconv-1.14.tar.gz
$ cd libiconv-1.14
$ ./configure --host=i686-w64-mingw32 --prefix=/mingw/i686-w64-mingw32
$ make
$ make install-strip
$ cd ..

NOTE: could've installed elsewhere and used --with-libiconv-prefix option with libquicktime's configure.

=== GNU libintl (can be found as part of gettext) ===
# http://ftpmirror.gnu.org/gettext
$ tar xvf gettext-0.18.3.1.tar.gz
$ cd gettext-0.18.3.1
$ ./configure --host=i686-w64-mingw32 --prefix=/mingw/i686-w64-mingw32
# (If /mingw/bin/i686-w64-mingw32-ar.exe doesn't exist already in your toolchain...)
$ cp /mingw/bin/ar.exe to /mingw/bin/i686-w64-mingw32-ar.exe
$ make
# (If /mingw/bin/i686-w64-mingw32-ranlib.exe doesn't exist already in your toolchain...)
$ cp /mingw/bin/ranlib.exe to /mingw/bin/i686-w64-mingw32-ranlib.exe
$ make install-strip
$ cd ..

########################
### Building libquicktime ###
########################

# NOTE: It's important to do the CVS checkout in the msys shell rather than in a Windows environment to avoid Windows line-endings getting in the way of building.
$ cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login
$ cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -D2013-05-13 -P libquicktime

# (Sorry, I'm currently not so up-to-date checkout of libquicktime due to the project I'm working with - so I hope the patches still work when I update)
$ cd libquicktime

# replace usage of bzero and bcopy with memset and memcpy:
$ patch -p0 002_bzero_bcopy_to_memset_memcpy.patch

# replace usage of sysconf with getpagesize:
$ patch -p0 003_getpagesize.patch

# localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
# FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
$ patch -p0 004_localtime_s.patch

# add -no-undefined to the libtool calls for making shared libraries:
$ patch -p0 005_libtool_dll_fix.patch

# tweak the ABI headers to avoid warnings in case I want to use the libquicktime library with other compilers (which I have successfully tried with MSVC 9.0):
$ patch -p0 006_pragma_gcc_fix.patch

# fix LQT_CODEC_FILE default to work for windows environments that don't define HOME - using USERPROFILE instead (e.g. "C:\Users\<username>").
# this isn't necessary if you only intend to run programs in the msys environment
$ patch -p0 007_LQT_CODEC_FILE_win_default.patch

# generate the configure script:
$ ./autogen.sh

# fix ffmpeg plugin to link libavutil (Linux doesn't need this so should we bother properly adding the dependency into configure.ac?):
vim plugins/ffmpeg/Makefile
# (add ' -lavutil' to lqt_ffmpeg_la_LIBADD definition)

# configure and build! (You may need to add "PKG_CONFIG_PATH=<path to ffmpeg install prefix>/lib/pkgconfig" to the configure call if you installed ffmpeg somewhere particular.
$ ./configure --host=i686-w64-mingw32 --without-doxygen
$ make
$ make install

# NOTE: Running libquicktime applications outside of msys environment:
As the path that libquicktime searches for it's plugins is currently hardcoded based on a #define setup by the configure script (http://libquicktime.sourceforge.net/doc/codecs.html), you need to setup an environment variable to correctly point to it's location as the msys path e.g. '/c/dev/libquicktime/lib/libquicktime' won't make much sense to Windows natively...

Comments are welcome!

________________________________________
From: Derek Chow [der...@mi...]
Sent: 20 August 2013 15:14
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows

Hi Tim et al,

I'm looking at giving this a go with the long term view of replacing the
use of the Windows QuickTime API to unify Linux + Windows platform code
for reading and writing.

It's been a while since the last post on this thread, though - any
updates on this issue?  I'll take Burkhard's advice on MinGW as a
starting point.

Cheers,
Derek

Re: [Libquicktime-devel] libquicktime question

[Burkhard P. <bur...@ig...>]

Hi,

Am 26.08.2013 07:50, schrieb Anthony Cuozzo:
> All,
>
> Just wondering: Does libquicktime have a maximum file size limitation?

libquicktime uses the 64 bit file API, which allows file sizes up to
9223372036854775808 bytes.

Burkhard

[Libquicktime-devel] libquicktime question

[Anthony C. <ac...@ru...>]

All,

Just wondering: Does libquicktime have a maximum file size limitation?

Thanks!
Anthony

Re: [Libquicktime-devel] FFMpeg thread safety

[Burkhard P. <bur...@ig...>]

Hi,

Am 20.08.2013 15:58, schrieb Derek Chow:
> Hi,
>
> FFMpeg usage should use register a lock manager with av_lockmgr_register() so that
 > multithreaded use of libavcodec can mutex critical sections and avoid errors such as
 > "Insufficient thread locking around avcodec_open/close()" in the FFMpeg plugin.
>
> See attached patch for a suggestion (based on http://code.opencv.org/issues/1369) on
 > how this could be addressed.

Good that you address this, but your approach is somewhat dangerous.

Imagine an application, which uses ffmpeg through libquicktime and additionally through
some other library. If you set a global callback from a dynamically loaded module, your
application crashes when avcodec_open() is called from somewhere else *after* the lqt
module was unloaded.

AFAIK the global locking is needed because libavcodec uses some global variables, mostly
tables, which are runtime generated. The cleanest way to solve this would be a global mutex
inside libavcodec. This way, the application programmer wouldn't have to care at all.

Another (less clean) solution could be a global mutex within libquicktime, accessible e.g.
via functions like lqt_ffmpeg_[un]lock(). If you make sure that on every call to
avcodec_open*() and avcodec_close*() the global mutex is locked, concurrent calls to
avcodec_open() from within libquicktime are save. Concurrent calls from lqt and another library
can IMO only be protected with a mutex inside libavcodec as said above, especially when
applications make heavy use of dynamic modules.

Burkhard

[Libquicktime-devel] FFMpeg thread safety

[Derek C. <der...@mi...>]

Hi,

FFMpeg usage should use register a lock manager with 
av_lockmgr_register() so that multithreaded use of libavcodec can mutex 
critical sections and avoid errors such as "Insufficient thread locking 
around avcodec_open/close()" in the FFMpeg plugin.

See attached patch for a suggestion (based on 
http://code.opencv.org/issues/1369) on how this could be addressed.

Cheers,
Derek

Re: [Libquicktime-devel] libquicktime on windows

[Derek C. <der...@mi...>]

Hi Tim et al,

I'm looking at giving this a go with the long term view of replacing the 
use of the Windows QuickTime API to unify Linux + Windows platform code 
for reading and writing.

It's been a while since the last post on this thread, though - any 
updates on this issue?  I'll take Burkhard's advice on MinGW as a 
starting point.

Cheers,
Derek

Re: [Libquicktime-devel] [PATCH] ProRes encoder name change

[Burkhard P. <bur...@ig...>]

Hi,

Am 05.06.2013 11:45, schrieb Boris Maksalov:
> Hi,
>
> As you may know, FFMpeg has two implementations of ProRes encoder, only one of them supporting interlaced encoding. Recently they renamed that one from "prores_kostya" to "prores_ks". The attached patch will first look for the new name, then for the old one, and finally will revert to codec-id based lookup.

Applied

Burkhard