libquicktime-devel — Discussion about development

Re: [Libquicktime-devel] [PATCH] Yet another patch for the latest FFMpeg

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

Hi,

Am 04.06.2013 18:03, schrieb Erik Johansson:
> Some codecs in the latest ffmpeg requires that size and format
> information is set in the AVFrame passed to avcodec_encode_video2.
> Without this information, trying to encode e.g. 'ffv1' will segfault.
> Fix attached.
>
> Regards
> // Erik
>

Applied

Burkhard

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

[Boris M. <bor...@ya...>]

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.

[Libquicktime-devel] [PATCH] Yet another patch for the latest FFMpeg

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

Some codecs in the latest ffmpeg requires that size and format
information is set in the AVFrame passed to avcodec_encode_video2.
Without this information, trying to encode e.g. 'ffv1' will segfault.
Fix attached.

Regards
// Erik

Re: [Libquicktime-devel] [PATCH] Another compatibility fix for the latest FFMpeg

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

Hi,

Am 13.05.2013 18:09, schrieb Joseph Artsimovich:
> This time it's a runtime issue. When avcodec_encode_video2() is called, we pass it an AVPacket with pkt.data pointing to a buffer we've allocated ourselves. Now, an AVPacket can be a managed one (requiring a call to av_free_packet()) or an unmanaged one (backed by some external buffer AVPacket
> doesn't own). Since very recently, some codecs (in this case it was ProRes, with multithreading enabled) started converting an unmanaged AVPacket we pass to avcodec_encode_video2() to a managed one. As a result, the "data" member get overwritten and a call to av_packet_free() is now required. BTW,
> calling av_packet_free() on an unmanaged AVPacket is still fine. The fix is attached.
>

Applied

Burkhard

Re: [Libquicktime-devel] [PATCH] chunk_to_offset and PCM 'sowt' fixes

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

Hi,

Am 07.05.2013 11:47, schrieb Erik Johansson:
> Hello,
>
> On Tue, May 7, 2013 at 11:33 AM, Burkhard Plaum
> <bur...@ig...> wrote:
>> How sure you about that? Do you have any sample files?
>>
>> I can remember double-checking the sample formats a while ago, and it turned
>> out that 8 bit PCM seems *always* unsigned, even if the name sowt (twos backwards)
>> suggests something else.
>
> I came across this on movie files created by a Panasonic FX35 compact
> camera. There's a sample file at http://goo.gl/2RtVy (link to google
> drive document, use File->Download to get a non-streamed version). I
> used google to try and find out what the right thing to do here was
> and ended up at http://wiki.multimedia.cx/index.php?title=ADPCM, so I
> may well be wrong. I wouldn't be surprised if some encoders do the
> wrong thing here.

Of course there are always encoders who do the wrong thing. This way
hacking on multimedia libraries at least doesn't become boring.

I didn't find any reference regarding 8 bit sowt so I changed the
sample format to signed as you suggested. Maybe the camera you mentioned
is the only encoder which writes 8 bit sowt anyway :)

Burkhard

[Libquicktime-devel] [PATCH] Another compatibility fix for the latest FFMpeg

[Joseph A. <jo...@mi...>]

This time it's a runtime issue. When avcodec_encode_video2() is called, 
we pass it an AVPacket with pkt.data pointing to a buffer we've 
allocated ourselves. Now, an AVPacket can be a managed one (requiring a 
call to av_free_packet()) or an unmanaged one (backed by some external 
buffer AVPacket doesn't own). Since very recently, some codecs (in this 
case it was ProRes, with multithreading enabled) started converting an 
unmanaged AVPacket we pass to avcodec_encode_video2() to a managed one. 
As a result, the "data" member get overwritten and a call to 
av_packet_free() is now required. BTW, calling av_packet_free() on an 
unmanaged AVPacket is still fine. The fix is attached.


-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

Re: [Libquicktime-devel] [PATCH] Make it build against the latest ffmpeg

[Joseph A. <jo...@mi...>]

On 07/05/13 10:20, Burkhard Plaum wrote:>
 >
 > Applied, but wasn't there a problem in audio.c also?

The one with AVCODEC_MAX_AUDIO_FRAME_SIZE being missing?
I thought you fixed that one yourself, at least it seems
fixed. That was the only problem with audio.c


Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

Re: [Libquicktime-devel] [PATCH] chunk_to_offset and PCM 'sowt' fixes

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

Hello,

On Tue, May 7, 2013 at 11:33 AM, Burkhard Plaum
<bur...@ig...> wrote:
> How sure you about that? Do you have any sample files?
>
> I can remember double-checking the sample formats a while ago, and it turned
> out that 8 bit PCM seems *always* unsigned, even if the name sowt (twos backwards)
> suggests something else.

I came across this on movie files created by a Panasonic FX35 compact
camera. There's a sample file at http://goo.gl/2RtVy (link to google
drive document, use File->Download to get a non-streamed version). I
used google to try and find out what the right thing to do here was
and ended up at http://wiki.multimedia.cx/index.php?title=ADPCM, so I
may well be wrong. I wouldn't be surprised if some encoders do the
wrong thing here.

Regards
// Erik

Re: [Libquicktime-devel] [PATCH] Make it build against the latest ffmpeg

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

Hi,


Am 01.05.2013 16:50, schrieb Joseph Artsimovich:
> The patch is attached.
>

Applied, but wasn't there a problem in audio.c also?

Burkhard

Re: [Libquicktime-devel] [PATCH] chunk_to_offset and PCM 'sowt' fixes

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

Hi,

Am 01.05.2013 22:09, schrieb Erik Johansson:
> Two minor bugfixes:
> 1) In quicktime_chunk_to_offset there is a read past the end of the
> stco table when chunk == total_entries.

Applied.

> 2) in plugins/audiocodec/pcm, the sample_format of signed linear PCM
> (sowt) is incorrectly set to unsigned.

How sure you about that? Do you have any sample files?

I can remember double-checking the sample formats a while ago, and it turned
out that 8 bit PCM seems *always* unsigned, even if the name sowt (twos backwards)
suggests something else.

Buurkhard

[Libquicktime-devel] [PATCH] chunk_to_offset and PCM 'sowt' fixes

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

Two minor bugfixes:
1) In quicktime_chunk_to_offset there is a read past the end of the
stco table when chunk == total_entries.

2) in plugins/audiocodec/pcm, the sample_format of signed linear PCM
(sowt) is incorrectly set to unsigned.

Patch for these two attached.

I couldn't help but notice that the sample_format for unsigned linear
PCM (raw) looks suspect as well. Haven't had the time to verify and
fix though.

Regards
// Erik

[Libquicktime-devel] [PATCH] Make it build against the latest ffmpeg

[Joseph A. <jo...@mi...>]

The patch is attached.

-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

Re: [Libquicktime-devel] faac plugin fixes

[Burkhard P. <pl...@ip...>]

Hi,

Am 26.04.2013 15:53, schrieb Erik Johansson:
> My last mail came through horribly garbled - sorry about that!
> Original text included below.
>
> Regards
> // Erik
>
>> Hello,
>>
>> I came across two bugs in the faac plugin.
>>
>> Faac adds one frame of priming delay, i.e. 1024 samples. The bug in the faac
>> plugin is that it only writes the provided number of encoded samples to the
>> output, meaning that since the first 1024 will be priming, the last 1024
>> samples will be lost. I solved this by adding a new configuration parameter:
>>
>>      {
>>        .name =        "faac_priming_delay",
>>        .real_name =   TRS("Priming delay (samples)"),
>>        .type =        LQT_PARAMETER_INT,
>>        .val_min =     { .val_int = FAAC_PRIMING_DELAY },
>>        .val_default = { .val_int = 2112 },
>>      },
>>
>> I choose 2112 samples as the default, since that is the value Apple seems to
>> use when encoding AAC.  (There is a pretty good discussion on priming in
>> this thread:
>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-July/127839.html)
>>
>> The second bug was more trivial; configuration parameter names in lqt_faac.c
>> didn't match those expected by the set_parameter function in faac.c. Solved
>> by adding 'faac_' prefixes to the affected parameter names.
>>

Applied. The prime samples thing is a good catch by the way. They are often
ignored.

Burkhard

Re: [Libquicktime-devel] faac plugin fixes

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

My last mail came through horribly garbled - sorry about that!
Original text included below.

Regards
// Erik

> Hello,
>
> I came across two bugs in the faac plugin.
>
> Faac adds one frame of priming delay, i.e. 1024 samples. The bug in the faac
> plugin is that it only writes the provided number of encoded samples to the
> output, meaning that since the first 1024 will be priming, the last 1024
> samples will be lost. I solved this by adding a new configuration parameter:
>
>     {
>       .name =        "faac_priming_delay",
>       .real_name =   TRS("Priming delay (samples)"),
>       .type =        LQT_PARAMETER_INT,
>       .val_min =     { .val_int = FAAC_PRIMING_DELAY },
>       .val_default = { .val_int = 2112 },
>     },
>
> I choose 2112 samples as the default, since that is the value Apple seems to
> use when encoding AAC.  (There is a pretty good discussion on priming in
> this thread:
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-July/127839.html)
>
> The second bug was more trivial; configuration parameter names in lqt_faac.c
> didn't match those expected by the set_parameter function in faac.c. Solved
> by adding 'faac_' prefixes to the affected parameter names.
>
> Regards
> // Erik
>

Re: [Libquicktime-devel] [PATCH] Add another IMX fourcc

[Burkhard P. <pl...@ip...>]

Hi,

Am 23.04.2013 15:36, schrieb Joseph Artsimovich:
> Hi,
>
> Here is another patch for (read only) Avid IMX support. Being an Avid format, it uses Avid's proprietary atoms to switch between different YUV range mappings. That's now supported. Another thing I changed is stopping taking the height from tkhd and instead take it from stsd.
> I came across a file that had:
> 720x480 in tkhd
> 720x486 in stsd
> 720x512 (including the VBI area) coming out of ffmpeg.
> The file was made with Avid Media Composer 6. It was crashing the current version of libquicktime.

Applied

> BTW, I found more incompatibilities with the latest ffmpeg from git. Looks like they've done a big spring cleanup in their interfaces.
> I haven't done anything to address those yet.

A good idea would be to make a spring cleanup in libquicktime and remove all legacy API stuff in our
libavcodec frontends (and require a more recent ffmpeg version).
Theoretically we still support hopelessly old ffmpeg versions, which probably noone uses anymore and
which mess up our code with lots of #ifdefs.

As alwayws, patches are welcome (I can't work on lqt a the moment).

Burkhard

Re: [Libquicktime-devel] build failure on Mac OS 10.5.8

[Burkhard P. <pl...@ip...>]

Hi,

Am 20.04.2013 14:24, schrieb Christian Ebert:
> Hi,
>
> Recently CVS HEAD stopped building like so:
>
> /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include  -O3 -I/usr/local/include -I/sw/include -I/usr/local/include -I/usr/local/include   -DLOCALE_DIR=\"/usr/local/share/locale\" -O3 -I/usr/local/include -I/sw/include  -finline-functions -Wall -Winline -Wmissing-declarations -Wdeclaration-after-statement -fvisibility=hidden -MT audio.lo -MD -MP -MF .deps/audio.Tpo -c -o audio.lo audio.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -O3 -I/usr/local/include -I/sw/include -I/usr/local/include -I/usr/local/include -DLOCALE_DIR=\"/usr/local/share/locale\" -O3 -I/usr/local/include -I/sw/include -finline-functions -Wall -Winline -Wmissing-declarations -Wdeclaration-after-statement -fvisibility=hidden -MT audio.lo -MD -MP -MF .deps/audio.Tpo -c audio.c  -fno-common -DPIC -o .libs/audio.o
> audio.c: In function ‘decode_chunk_vbr’:
> audio.c:518: error: ‘AVCODEC_MAX_AUDIO_FRAME_SIZE’ undeclared (first use in this function)
> audio.c:518: error: (Each undeclared identifier is reported only once
> audio.c:518: error: for each function it appears in.)
> audio.c: In function ‘decode_chunk’:
> audio.c:674: error: ‘AVCODEC_MAX_AUDIO_FRAME_SIZE’ undeclared (first use in this function)
> make[3]: *** [audio.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> $ uname -mprsv
> Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386
>
> ffmpeg the usual suspect?

Yes. I've outlined a possible solution here:
http://thread.gmane.org/gmane.comp.video.libquicktime.devel/1841/focus=1842

Any patch is welcome.

> Probably because of the autoconf version I have, I also have to
> do:

[...]

> -AM_CONFIG_HEADER(config.h)
> +AC_CONFIG_HEADERS(config.h)

Applied. Hope it doesn't break compilation on other systems.

Burkhard

Re: [Libquicktime-devel] [PATCH] Add another IMX fourcc

[Joseph A. <jo...@mi...>]

Hi,

Here is another patch for (read only) Avid IMX support. Being an Avid 
format, it uses Avid's proprietary atoms to switch between different YUV 
range mappings. That's now supported. Another thing I changed is 
stopping taking the height from tkhd and instead take it from stsd.
I came across a file that had:
720x480 in tkhd
720x486 in stsd
720x512 (including the VBI area) coming out of ffmpeg.
The file was made with Avid Media Composer 6. It was crashing the 
current version of libquicktime.

BTW, I found more incompatibilities with the latest ffmpeg from git. 
Looks like they've done a big spring cleanup in their interfaces.
I haven't done anything to address those yet.


Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

[Libquicktime-devel] build failure on Mac OS 10.5.8

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

Hi,

Recently CVS HEAD stopped building like so:

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include  -O3 -I/usr/local/include -I/sw/include -I/usr/local/include -I/usr/local/include   -DLOCALE_DIR=\"/usr/local/share/locale\" -O3 -I/usr/local/include -I/sw/include  -finline-functions -Wall -Winline -Wmissing-declarations -Wdeclaration-after-statement -fvisibility=hidden -MT audio.lo -MD -MP -MF .deps/audio.Tpo -c -o audio.lo audio.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -O3 -I/usr/local/include -I/sw/include -I/usr/local/include -I/usr/local/include -DLOCALE_DIR=\"/usr/local/share/locale\" -O3 -I/usr/local/include -I/sw/include -finline-functions -Wall -Winline -Wmissing-declarations -Wdeclaration-after-statement -fvisibility=hidden -MT audio.lo -MD -MP -MF .deps/audio.Tpo -c audio.c  -fno-common -DPIC -o .libs/audio.o
audio.c: In function ‘decode_chunk_vbr’:
audio.c:518: error: ‘AVCODEC_MAX_AUDIO_FRAME_SIZE’ undeclared (first use in this function)
audio.c:518: error: (Each undeclared identifier is reported only once
audio.c:518: error: for each function it appears in.)
audio.c: In function ‘decode_chunk’:
audio.c:674: error: ‘AVCODEC_MAX_AUDIO_FRAME_SIZE’ undeclared (first use in this function)
make[3]: *** [audio.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

$ uname -mprsv
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386

ffmpeg the usual suspect?

Probably because of the autoconf version I have, I also have to
do:

Index: configure.ac
===================================================================
RCS file: /cvsroot/libquicktime/libquicktime/configure.ac,v
retrieving revision 1.176
diff -u -r1.176 configure.ac
--- configure.ac        8 Jun 2012 13:56:13 -0000       1.176
+++ configure.ac        20 Apr 2013 12:19:49 -0000
@@ -9,7 +9,7 @@

 USER_CFLAGS=$CFLAGS

-AM_CONFIG_HEADER(config.h)
+AC_CONFIG_HEADERS(config.h)

 AC_CANONICAL_HOST
 AM_MAINTAINER_MODE


c

-- 
\black\trash movie           _COWBOY  CANOE  COMA_
            Ein deutscher Western/A German Western

--->> http://www.blacktrash.org/underdogma/ccc.php

Re: [Libquicktime-devel] [PATCH] Add another IMX fourcc

[Burkhard P. <pl...@ip...>]

Hi,

Am 18.04.2013 18:11, schrieb Joseph Artsimovich:
> Hi,
>
> The attached patch adds 'AVmp' to the list of IMX fourcc's. From what I understand, it's
 > more or less equivalent to 'mx5p', with the only difference being the vendor (Avid vs Sony).

applied.

> On a side note, libquicktime no longer builds with the latest ffmpeg from git. They removed the
 > AVCODEC_MAX_AUDIO_FRAME_SIZE define from a public header. I am not sure how to fix that.

 From what I see, it is used only in the decoding part in 2 lines like:
new_samples = num_samples + AVCODEC_MAX_AUDIO_FRAME_SIZE / (2 * track_map->channels);

which look like some safety margin so we don't crash on broken files.
Maybe setting

new_samples = num_samples + 8192;

would be a completely perfect "fix". The number is only used for allocating the buffer for
decoded samples.

Also from what I see the code assumes, that audio samples are always 16 bit (which was true in
earlier ffmpeg versions), but now we can also have 32 bit floating point output.

Burkhard

[Libquicktime-devel] [PATCH] Add another IMX fourcc

[Joseph A. <jo...@mi...>]

Hi,

The attached patch adds 'AVmp' to the list of IMX fourcc's. From what I 
understand, it's more or less equivalent to 'mx5p', with the only 
difference being the vendor (Avid vs Sony).

On a side note, libquicktime no longer builds with the latest ffmpeg 
from git. They removed the AVCODEC_MAX_AUDIO_FRAME_SIZE define from a 
public header. I am not sure how to fix that.


-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

Re: [Libquicktime-devel] [PATCH] Fix incorrect qmax value for IMX30

[Burkhard P. <pl...@ip...>]

Hi,

Am 12.02.2013 12:26, schrieb Joseph Artsimovich:
> Just a quick one-liner fix.

Applied.

>
> P.S:
> Still waiting for response on my previous patch.

Oops, thanks for reminding me. Also applied.

Burkhard

[Libquicktime-devel] [PATCH] Fix incorrect qmax value for IMX30

[Joseph A. <jo...@mi...>]

Just a quick one-liner fix.

P.S:
Still waiting for response on my previous patch.


-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

[Libquicktime-devel] [PATCH] Better handling of broken frames

[Joseph A. <jo...@mi...>]

Hi,

The current behaviour of lqt_decode_video() when encountering a broken 
frame is to log an error but then proceed to decoding the next frame, 
and then the next one, till it succeeds. At least ffmpeg plugin does it 
like that. That's obviously undesirable, as client code does not receive 
an error status and is additionally mislead about which frame it has 
just received.

So, I made a patch that makes lqt_decode_video() return error on a 
broken frame, giving client code the opportunity to either abort or try 
to continue from the next frame by calling lqt_decode_video() again.

While at it, I also documented the return value of lqt_decode_video().
The ugly thing is it contradicts the general convention in libquicktime 
of having 1 mean success and zero mean failure. I didn't dare to change 
every plugin to make it consistent with the rest of libquicktime, so I 
just documented that 0 means a success and non-zero means failure.
I also fixed one instance of 0 being returned to indicate an error.


-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd

Re: [Libquicktime-devel] Timescales in QTVR files

[Burkhard P. <pl...@ip...>]

Hi,

Am 04.01.2013 22:56, schrieb Stefan Scheffler:
>
> Hi,
>
> it looks like the last change to mvhd.c ("Prefer higher movie
> timescales...") broke QTVR playback in Quicktime player. My best guess
> is that it doesn't like it when track timescales and movie timescale
> differ.
>
> The attached patch sets the movie timescale to the one of the image
> track when creating a QTVR file. I can commit it if that's ok.

If that works for you, you can apply it. Seems there are no conflicts
with non-qtvr files possible.

Burkhard

[Libquicktime-devel] Timescales in QTVR files

[Stefan S. <ste...@gm...>]

Hi,

it looks like the last change to mvhd.c ("Prefer higher movie
timescales...") broke QTVR playback in Quicktime player. My best guess
is that it doesn't like it when track timescales and movie timescale
differ.

The attached patch sets the movie timescale to the one of the image
track when creating a QTVR file. I can commit it if that's ok.

stefan