libquicktime-devel — Discussion about development

[Libquicktime-devel] Issue with stps-atom and packetindex

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

Hello,

I was provided with a sample file which contains all open-GOP MPEG2
essence. The structure of the file is IBBPBB... where the first two
B-frames reference a non existing keyframe. These two broken frames
are ignored thanks to an edts entry. The stss atom is empty as there
are only partial sync samples.

The problem I found is that packet_index_create_video() marks all
frames as keyframes when there are not stss entries. Trivial fix:

-    else if(!stss)
+    else if(!stss && !stps)

Patch attached

Thanks,
Erik

[Libquicktime-devel] 8-byte long

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

Hello,

I have a build environment where 'long' are stored in eight bytes.
Found the following issue while looking at supporting empty edit
entries:

Media time
A 32-bit integer containing the starting time within the media of this
edit segment (in media timescale units). If this field is set to –1,
it is an empty edit.

(lldb) p edts.elst.table[0].time
(long) $1 = 4294967295

Hmm...

long quicktime_read_int32(quicktime_t *file)
{
unsigned long result;
unsigned long a, b, c, d;
uint8_t data[4];

quicktime_read_data(file, data, 4);
a = data[0];
b = data[1];
c = data[2];
d = data[3];

result = (a << 24) | (b << 16) | (c << 8) | d;
return (long)result;
}

(lldb) p sizeof(long)
(unsigned long) $3 = 8

Attaching a patch to change quicktime_read_int32,
quicktime_read_int32_le & quicktime_read_uint32 to use  int32_t and
uint32_t instead of long.

Thanks,
Erik

Re: [Libquicktime-devel] Integer overflow + tmcd atom issue

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

Hi,

Am 09.10.2015 um 14:21 schrieb Erik Johansson:
> Hi,
[...]
> Attaching proposed patch.

Applied

Burkhard

[Libquicktime-devel] Integer overflow + tmcd atom issue

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

Hi,

Two minor bugs encountered in the last few days:

Integer over flow in stts.c: quicktime_time_to_sample() around line 151.

(lldb) p stts->table[0].sample_duration * stts->table[0].sample_count
(int) $27 = 1027032704
(lldb) p (int64_t)stts->table[0].sample_duration *
(int64_t)stts->table[0].sample_count
(long long) $29 = 5322000000

The problematic file had a sample_duration of 400000, and 13000+ frames.


The second issue is in stsdtable.c, in the function
quicktime_stsdtable_read_timecode(). I was provided with a file,
allegedly created by ffmpeg, which had two extra bytes corresponding
to the two commented out lines:
  //  table->tmcd.reserved3[1] = quicktime_read_char(file);
  //  table->tmcd.reserved3[2] = quicktime_read_char(file);

The code then proceeds to try to interpret those two bytes as an atom
header without checking
  while(quicktime_position(file) < parent_atom->end)
    {
    quicktime_atom_read_header(file, &leaf_atom);

(In this particular case, the size value of leaf_atom got set to a
large negative value, making it loop for quite some time)

Attaching proposed patch.

-- 
Erik Johansson

Re: [Libquicktime-devel] Count image description extension crash in QT

[Balázs O. <oro...@gm...>]

Hi,

I understand, I have only recently been forced to develop for the
insanity which is called QuickTime, for which I honestly see NO reason
why is it considered "professional", neither from a programmer, nor
from a user perspective. This would lead to a long rant, so I don't
even start...

As for the terminating bytes, there is some vague hint here:
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-61112
Maybe you can decipher some info about the reason for it's existence
(I couldn't).

Greets,
Balázs



2015-03-20 11:10 GMT+01:00 Burkhard Plaum
<bur...@ig...>:
> Hi,
>
> Am 19.03.2015 um 20:58 schrieb Balázs Oroszi:
> [...]
>>
>> I've attached a trivial patch to add the padding also when any user
>> atom is present, and I've verified with my own QuickTime components,
>> that MOV files generated this way no longer crash when using the
>> CountImageDescriptionExtensionType() function.
>
> Applied. Now Apple needs to fix the QuickTime components so they don't crash
> on broken files :)
>
> And as I said several times already: These termination bytes are unnecessary,
> because the total size of the parent atom is always known. The more such
> redundancies a fileformat has, the more potential security holes you'll have
> in the parser.
>
> Burkhard

Re: [Libquicktime-devel] Count image description extension crash in QT

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

Hi,

Am 19.03.2015 um 20:58 schrieb Balázs Oroszi:
[...]
>
> I've attached a trivial patch to add the padding also when any user
> atom is present, and I've verified with my own QuickTime components,
> that MOV files generated this way no longer crash when using the
> CountImageDescriptionExtensionType() function.

Applied. Now Apple needs to fix the QuickTime components so they don't crash
on broken files :)

And as I said several times already: These termination bytes are unnecessary,
because the total size of the parent atom is always known. The more such
redundancies a fileformat has, the more potential security holes you'll have
in the parser.

Burkhard

[Libquicktime-devel] Count image description extension crash in QT

[Balázs O. <oro...@gm...>]

Hi,

There was a bug in libquicktime-generated MOVs, which makes the
QuickTime API function CountImageDescriptionExtensionType() and/or
GetNextImageDescriptionExtensionType() crash.
This was discussed and eventually fixed here:
http://sourceforge.net/p/libquicktime/mailman/libquicktime-devel/thread/44736.91.22.94.234.1239326393.squirrel%40ipfmv1.e-technik.uni-stuttgart.de/

The behaviour was also discussed in the following places (among others):
http://trac.perian.org/ticket/103
http://lists.apple.com/archives/quicktime-api/2009/Jan/msg00128.html

I've noticed however, that if any user atom is present, but none of
the ones mentioned in the fix (pasp, clap, colr, fiel, gama), the
written MOV won't have the mentioned padding and will make programs
trying to use the QT function CountImageDescriptionExtensionType()
crash.
An example of this situation for example is when only a 'glbl' user
atom is present (created by ffmpeg for various codec headers).

I've attached a trivial patch to add the padding also when any user
atom is present, and I've verified with my own QuickTime components,
that MOV files generated this way no longer crash when using the
CountImageDescriptionExtensionType() function.

Greets,
Balázs

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

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

Hi,

Am 06.03.2015 um 15:45 schrieb Steven Schultz:
> In a 5.1 system the surround speakers are almost parallel to the listening
> position but slight behind.   It's in a 7.1 system that the rear surrounds
> are directly in back of the listening position.
>
> I'll include a picture from my AV Receiver's manual showing the speaker
> positions for up to  an 11.1 system

Very good, thanks a lot. You can "fix" the channel definitions, but it would be
great to have some documentation for the channel labels in the header file
e.g. "Left Rear channel in a 5.1 system/Side channel in a 7.1 System" or whatever
you think is correct.

Also IIRC ffmpeg also defines channel locations now. Would be great if lqt
wouldn't be completely incompatible with other APIs.

> But the extreme low limit of message size on the mailing list might delay
> things until the message is manually approved.

That's the reason people use image hosters and/or pastebin for larger data :)
In some parts of the world (I've been there), people have slow internet and/or
small inbox quotas.

Burkhard

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Steven S. <sch...@gm...>]

On Fri, Mar 6, 2015 at 3:40 AM, Burkhard Plaum <
bur...@ig...> wrote:

> Hi,
>
> To my understanding (and in other audio systems), "Surround" channels
> always mean
> rear channels.


It's true that is  how many people set their systems up.  And it was the
usual layout for the quadraphonic systems in the 1970s.- ahead of its time
- the format failed then but today is back with more channels than ever.

I remember that this stuff was extremely poorly documented, it wasn't
> even a Quicktime documentation. It was a documentation of the Apple
> "Core audio format" and by accident I found out that the multichannel
> definiton is the
> same as the chan atom in Quicktime files. So it can well be that I guessed
> the
> meanings of the channels somewhat wrong.


Seems that accidents are how much of Apple's formats are discovered.  It
was by accident that I stumbled into this "problem" - I was assigning, in
the Quicktime 7 application, the channel layout of a Quicktime file's audio
track and selected the wrong choice.  Both 'surround left/right' and
'surround rear left/right' were offered.  I picked the 'rear' and then
qtinfo was saying unknown but the AV receiver played the file fine.  So off
to the mailing list and here we are :-)

>
> Can be. But I still wonder if there is a system with "Surround" plus "Rear
> Surround"
> speakers, where would they exactly be located? Are the channel positions
> better
> documented by now?


In a 5.1 system the surround speakers are almost parallel to the listening
position but slight behind.   It's in a 7.1 system that the rear surrounds
are directly in back of the listening position.

I'll include a picture from my AV Receiver's manual showing the speaker
positions for up to  an 11.1 system

But the extreme low limit of message size on the mailing list might delay
things until the message is manually approved.

> ALSO needed is a 'Mono' mapping (id #42 as I recall) which is easy enough
> > to add.
>
> Go ahead :)


will do - that's today's project


>
> > Is there nothing that could be done to clean 'em up and perhaps remove
> some
> > of the redundancy?
>
> Yes, if you are an Apple Engineer with enough influence to make an
> incompatible
> change to the Quicktime format....
>
>
I'll see what I can do :)

Cheers,
Steven

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

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

Hi,

Am 05.03.2015 um 18:12 schrieb Steven Schultz:

[...]
>>
> OK - that's the piece of the puzzle that I overlooked or didn't realize the
> significance of.  Thanks!
>
>
>> Channels 3 and 4 of your file have the fields
>> CHANNEL_LABEL_RearSurroundLeft
>> CHANNEL_LABEL_RearSurroundRight for which no LQT_* equivalent exists. So
>> they
>> are labeled as "Unknown" by qtinfo.
>>
>> Maybe the most pragmatic solution would be to map
>> CHANNEL_LABEL_RearSurroundLeft and
>> CHANNEL_LABEL_RearSurroundRight to LQT_CHANNEL_BACK_LEFT and
>> LQT_CHANNEL_BACK_RIGHT
>> respectively.
>>
>
> Hmmm, the idea of calling 'surround' and 'rear surround'  the same thing
> bothers me.  They have different ID numbers and there are systems (not mine
> -   Yet :) that have surround and rear surround channels.

To my understanding (and in other audio systems), "Surround" channels always mean
rear channels. I remember that this stuff was extremely poorly documented, it wasn't
even a Quicktime documentation. It was a documentation of the Apple
"Core audio format" and by accident I found out that the multichannel definiton is the
same as the chan atom in Quicktime files. So it can well be that I guessed the
meanings of the channels somewhat wrong.

> Would it be OK if I added "LQT_CHANNEL_Rs" and "LQT_CHANNEL_Ls" (or similar
> if you have a  better idea for the name) for the Right and Left and mapped
> them to CHANNEL_LABEL_RearSurroundRight and CHANNEL_LABEL_RearSurroundLeft
> respectively?

Can be. But I still wonder if there is a system with "Surround" plus "Rear Surround"
speakers, where would they exactly be located? Are the channel positions better
documented by now?

> ALSO needed is a 'Mono' mapping (id #42 as I recall) which is easy enough
> to add.

Go ahead :)

> Another possibility would be to make the chan atom visible in the public
>> API, but I
>> don't know it it worth the effort.
>
>
> Would be nice - but only if someone else does the work <grin>
>
>
>> The defitions are so messy and redundant that it's
>> better to keep them private.
>>
>
> Is there nothing that could be done to clean 'em up and perhaps remove some
> of the redundancy?

Yes, if you are an Apple Engineer with enough influence to make an incompatible
change to the Quicktime format....

chan.c (like most other files) is nothing but a Quicktime atom implemented
in a C file. Thus, the C-definitions are as messy/redundant/crappy as the original
Quicktime atom.

> Feels like a waste to have all that work/effort just
> sitting there not publicly available.

Well that's a common symptom in the whole Quicktime format. Internally there is
*lots* of stuff defined, but only a tiny subset is actually used.

Burkhard

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Steven S. <sch...@gm...>]

On Thu, Mar 5, 2015 at 8:59 AM, Burkhard Plaum <
bur...@ig...> wrote:

> Hi,
>
> You are the first who reports about a wrongly labeled file more 8 years
> after I programmed that, so it can't be that bad :)
>

no, not bad at all.  took that long for multi-channel audio to catch my
interest in earnest.


> The problem is that chan.c defines an insane number of channel labels. So
> I decided to
> simplify things a bit


hmmm - the duplication made the situation seem more complex and harder to
see what was going on.   somewhat like the adage  "any problem in computer
science can be solved by another layer of indirection" :)


> and define the LQT_CHANNEL_* enum, which is defined according to
>  real-life files and codecs like AC3, DTS or AAC.
>

LPCM is a codec and predates all of those  <g>


> static struct
>    {
>    lqt_channel_t lqt_channel;
>    channel_label_t channel_label;
>    }
> lqt_channels[] =
>    {
>      { LQT_CHANNEL_UNKNOWN,            CHANNEL_LABEL_Unknown },
>      { LQT_CHANNEL_FRONT_LEFT,         CHANNEL_LABEL_Left },
>      { LQT_CHANNEL_FRONT_RIGHT,        CHANNEL_LABEL_Right },
>      { LQT_CHANNEL_FRONT_CENTER,       CHANNEL_LABEL_Center },
>      { LQT_CHANNEL_FRONT_CENTER_LEFT,  CHANNEL_LABEL_LeftCenter },
>      { LQT_CHANNEL_FRONT_CENTER_RIGHT, CHANNEL_LABEL_RightCenter },
>      { LQT_CHANNEL_BACK_CENTER,        CHANNEL_LABEL_CenterSurround },
>      { LQT_CHANNEL_BACK_LEFT,          CHANNEL_LABEL_LeftSurround },
>      { LQT_CHANNEL_BACK_RIGHT,         CHANNEL_LABEL_RightSurround },
>      { LQT_CHANNEL_SIDE_LEFT,          CHANNEL_LABEL_LeftSurroundDirect },
>      { LQT_CHANNEL_SIDE_RIGHT,         CHANNEL_LABEL_RightSurroundDirect },
>      { LQT_CHANNEL_LFE,                CHANNEL_LABEL_LFEScreen },
>    };
>
>
OK - that's the piece of the puzzle that I overlooked or didn't realize the
significance of.  Thanks!


> Channels 3 and 4 of your file have the fields
> CHANNEL_LABEL_RearSurroundLeft
> CHANNEL_LABEL_RearSurroundRight for which no LQT_* equivalent exists. So
> they
> are labeled as "Unknown" by qtinfo.
>
> Maybe the most pragmatic solution would be to map
> CHANNEL_LABEL_RearSurroundLeft and
> CHANNEL_LABEL_RearSurroundRight to LQT_CHANNEL_BACK_LEFT and
> LQT_CHANNEL_BACK_RIGHT
> respectively.
>

Hmmm, the idea of calling 'surround' and 'rear surround'  the same thing
bothers me.  They have different ID numbers and there are systems (not mine
-   Yet :) that have surround and rear surround channels.

Would it be OK if I added "LQT_CHANNEL_Rs" and "LQT_CHANNEL_Ls" (or similar
if you have a  better idea for the name) for the Right and Left and mapped
them to CHANNEL_LABEL_RearSurroundRight and CHANNEL_LABEL_RearSurroundLeft
respectively?

ALSO needed is a 'Mono' mapping (id #42 as I recall) which is easy enough
to add.

Another possibility would be to make the chan atom visible in the public
> API, but I
> don't know it it worth the effort.


Would be nice - but only if someone else does the work <grin>


> The defitions are so messy and redundant that it's
> better to keep them private.
>

Is there nothing that could be done to clean 'em up and perhaps remove some
of the redundancy?  Feels like a waste to have all that work/effort just
sitting there not publicly available.

Thanks for the hint!

Cheers,
Steven

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

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

Hi,

Am 04.03.2015 um 18:13 schrieb Steven Schultz:
> Hi —
>
> It appears that qtinfo’s multichannel audio handing is simplistic and isn’t looking in the correct place for information.
>
> A 4 channel audio file (produced with Quicktime Player)  produces this output from qtinfo:
>
[...]

> Ah ha - so the quicktime file is correct and qtinfo is wrong.

You are the first who reports about a wrongly labeled file more 8 years after I programmed that,
so it can't be that bad :)

> Seems that qtinfo uses the multichannel.c module rather than the quicktime_chan_dump logic of chan.c.

The problem is that chan.c defines an insane number of channel labels. So I decided to
simplify things a bit and define the LQT_CHANNEL_* enum, which is defined according to
real-life files and codecs like AC3, DTS or AAC.

> is there a reason multichannel.c is around instead of using the logic in chan.c?
The channel locations (as shown by qtinfo) are *always* taken from the chan atom (shown by qtinfo),
if that exists.

The mapping from chan atom channels to LQT channels happens in chan.c:

static struct
   {
   lqt_channel_t lqt_channel;
   channel_label_t channel_label;
   }
lqt_channels[] =
   {
     { LQT_CHANNEL_UNKNOWN,            CHANNEL_LABEL_Unknown },
     { LQT_CHANNEL_FRONT_LEFT,         CHANNEL_LABEL_Left },
     { LQT_CHANNEL_FRONT_RIGHT,        CHANNEL_LABEL_Right },
     { LQT_CHANNEL_FRONT_CENTER,       CHANNEL_LABEL_Center },
     { LQT_CHANNEL_FRONT_CENTER_LEFT,  CHANNEL_LABEL_LeftCenter },
     { LQT_CHANNEL_FRONT_CENTER_RIGHT, CHANNEL_LABEL_RightCenter },
     { LQT_CHANNEL_BACK_CENTER,        CHANNEL_LABEL_CenterSurround },
     { LQT_CHANNEL_BACK_LEFT,          CHANNEL_LABEL_LeftSurround },
     { LQT_CHANNEL_BACK_RIGHT,         CHANNEL_LABEL_RightSurround },
     { LQT_CHANNEL_SIDE_LEFT,          CHANNEL_LABEL_LeftSurroundDirect },
     { LQT_CHANNEL_SIDE_RIGHT,         CHANNEL_LABEL_RightSurroundDirect },
     { LQT_CHANNEL_LFE,                CHANNEL_LABEL_LFEScreen },
   };

Channels 3 and 4 of your file have the fields CHANNEL_LABEL_RearSurroundLeft
CHANNEL_LABEL_RearSurroundRight for which no LQT_* equivalent exists. So they
are labeled as "Unknown" by qtinfo.

Maybe the most pragmatic solution would be to map CHANNEL_LABEL_RearSurroundLeft and
CHANNEL_LABEL_RearSurroundRight to LQT_CHANNEL_BACK_LEFT and LQT_CHANNEL_BACK_RIGHT
respectively.

Another possibility would be to make the chan atom visible in the public API, but I
don't know it it worth the effort. The defitions are so messy and redundant that it's
better to keep them private.

Burkhard

[Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Steven S. <sch...@gm...>]

Hi —

It appears that qtinfo’s multichannel audio handing is simplistic and isn’t looking in the correct place for information.

A 4 channel audio file (produced with Quicktime Player)  produces this output from qtinfo:

[mini:x/QuadroPopParty] sms% qtinfo 4.mov
in quicktime_get_chan
Type: Quicktime
  1 audio tracks.
    4 channels, 24 bits, sample rate 48000, length 99918240 samples, compressor lpcm.
    Sample format: 32 bit signed.
    Channel setup: [1]Front Left, [2]Front Right, [0]Unknown, [0]Unknown
    Language: eng
    supported.
  0 video tracks.
  0 text tracks.
[mini:x/QuadroPopParty] sms% qtinfo 4.mov
Type: Quicktime
  1 audio tracks.
    4 channels, 24 bits, sample rate 48000, length 99918240 samples, compressor lpcm.
    Sample format: 32 bit signed.
    Channel setup: Front Left, Front Right, Unknown, Unknown
    Language: eng
    supported.
  0 video tracks.
  0 text tracks.
[mini:x/QuadroPopParty] sms% qtinfo 4.mov
Type: Quicktime
  1 audio tracks.
    4 channels, 24 bits, sample rate 48000, length 99918240 samples, compressor lpcm.
    Sample format: 32 bit signed.
    Channel setup: Front Left, Front Right, Unknown, Unknown
    Language: eng
    supported.
  0 video tracks.
  0 text tracks.

After a morning of puzzling over this and seeing only that multichannel.c is an incomplete subset of chan.c I remembered that qtdump might help.

qtdump says about the stsd atom:

    sample table
     sample description (stsd)
      version 0
      flags 0
      total_entries 1
       format lpcm
       reserved 00 00 00 00 00 00 
       data_reference 1
       version 2
       revision 0
       vendor xxxxx
       channels 4
       sample_size 24
       samplerate                     48000.000000
       formatSpecificFlags:           0000000e
       constBytesPerAudioPacket:      12
       constLPCMFramesPerAudioPacket: 1
       channel description
        version                     0
        flags                       0
        mChannelLayoutTag:          0x00000000 [Use channel decriptions]
        mChannelBitmap:             0x00000000
        mNumberChannelDescriptions: 4
         mChannelLabel[0]: 0x00000001 [Left]
         mChannelFlags[0]: 0x00000000
         mCoordinates[0]: [0.000000 0.000000 0.000000]
         mChannelLabel[1]: 0x00000002 [Right]
         mChannelFlags[1]: 0x00000000
         mCoordinates[1]: [0.000000 0.000000 0.000000]
         mChannelLabel[2]: 0x00000021 [Rear Surround Left]
         mChannelFlags[2]: 0x00000000
         mCoordinates[2]: [0.000000 0.000000 0.000000]
         mChannelLabel[3]: 0x00000022 [Rear Surround Right]
         mChannelFlags[3]: 0x00000000
         mCoordinates[3]: [0.000000 0.000000 0.000000]

Ah ha - so the quicktime file is correct and qtinfo is wrong.

Seems that qtinfo uses the multichannel.c module rather than the quicktime_chan_dump logic of chan.c.

is there a reason multichannel.c is around instead of using the logic in chan.c?

Re: [Libquicktime-devel] Small fix: read gmin's reserved 16-bits

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

Hi,

Am 26.01.2015 um 18:45 schrieb Derek Chow:
> Otherwise consequent read for next atom size etc in a loop is
> misinterpreted.
>
> Patch attached.

Applied

Burkhard

[Libquicktime-devel] Small fix: read gmin's reserved 16-bits

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

Index: src/gmin.c
===================================================================
RCS file: /cvsroot/libquicktime/libquicktime/src/gmin.c,v
retrieving revision 1.8
diff -u -r1.8 gmin.c
--- src/gmin.c	7 Jan 2011 14:40:46 -0000	1.8
+++ src/gmin.c	26 Jan 2015 17:28:05 -0000
@@ -56,6 +56,7 @@
        for(i = 0; i < 3; i++)
                gmin->opcolor[i] = quicktime_read_int16(file);
        gmin->balance = quicktime_read_int16(file);
+       gmin->reserved = quicktime_read_int16(file);
 }
 
 void quicktime_write_gmin(quicktime_t *file, quicktime_gmin_t *gmin)

Re: [Libquicktime-devel] Multiple moov atoms

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

> I don't think there's any need. I worked around it by treating a bad
> tref to timecode as the same as a missing tref - I just use the first
> timecode track.

Something like this [attached patch]?

-- 



Derek Chow / C++ Developer

der...@mi... / +44(0)7825373230

Office +44 (0)207 884 2530
21 Broadwall, London, SE1 9PL, United Kingdom
http://www.mirriad.com

Re: [Libquicktime-devel] libquicktime created files have 0 frame count

[Steven S. <sch...@gm...>]

On Thu, Oct 30, 2014 at 11:37 AM, Burkhard Plaum <
pl...@ig...> wrote:

> Hi,
>
> Am 24.10.2014 um 20:58 schrieb Steven Schultz:
>
> > The problem was that let_ensure_stream_cmodel_decode  exits/returns early
> > if !file->vtracks[track].codec->decode_video and all the
> > uncompressed codecs still returned 0 if called with row_pointers of 0.
>
> So it was another bug :)
>

and as usual "two wrongs did not make a right" :) :)


> > My solution was to modify the videocodec/ uncompressed codecs
>
> Ahh, and you committed that already, very good.
>

Welcome! ;)

Steven

Re: [Libquicktime-devel] libquicktime created files have 0 frame count

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

Hi,

Am 24.10.2014 um 20:58 schrieb Steven Schultz:

> The problem was that let_ensure_stream_cmodel_decode  exits/returns early
> if !file->vtracks[track].codec->decode_video and all the
> uncompressed codecs still returned 0 if called with row_pointers of 0.

So it was another bug :)

> My solution was to modify the videocodec/ uncompressed codecs to return
> 1 instead of 0 when called with rows_pointers of 0.
>
> Seems to be working OK so far.

Ahh, and you committed that already, very good.

Burkhard

Re: [Libquicktime-devel] libquicktime created files have 0 frame count

[Steven S. <sch...@gm...>]

Hi --

On Fri, Oct 24, 2014 at 10:58 AM, Burkhard Plaum <
pl...@ig...> wrote:

> Hi,
>
> Am 23.10.2014 um 17:57 schrieb Steven Schultz:
>
> > I am still puzzled why the Native color model still shows as Undefined.
> > My memory (possibly faulty) is that it used to say something like "YUV
> > 4:2:2 planar"
>
> Right. The decoding colormodel is now determined just when it's actually
> used,
> because it can involve decoding a first image (not in your case of
> uncompressed
> video of course)
>

Ah, ok.  So my memory of a different behavior was correct.


> Of course qtinfo should not show "Undefined".
>

That is just the symptom of the problem.   Programs that called lqt_get_cmodel
followed by lqt_colormodel_is_yuv immediately after quicktime_open failed
because the color model hadn't been updated.

A possible solution would be to modify quicktime_print_info() such that it
> calls
> lqt_ensure_stream_cmodel_decode() for each video track first. Any
> volunteers?
>

The problem was that let_ensure_stream_cmodel_decode  exits/returns early
if !file->vtracks[track].codec->decode_video and all the
uncompressed codecs still returned 0 if called with row_pointers of 0.

My solution was to modify the videocodec/ uncompressed codecs to return
1 instead of 0 when called with rows_pointers of 0.

Seems to be working OK so far.

Steven

Re: [Libquicktime-devel] libquicktime created files have 0 frame count

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

Hi,

Am 23.10.2014 um 17:57 schrieb Steven Schultz:

> I am still puzzled why the Native color model still shows as Undefined.
> My memory (possibly faulty) is that it used to say something like "YUV
> 4:2:2 planar"

Right. The decoding colormodel is now determined just when it's actually used,
because it can involve decoding a first image (not in your case of uncompressed
video of course)

Of course qtinfo should not show "Undefined".

A possible solution would be to modify quicktime_print_info() such that it calls
lqt_ensure_stream_cmodel_decode() for each video track first. Any volunteers?

Burkhard

Re: [Libquicktime-devel] libquicktime created files have 0 frame count

[Steven S. <sch...@gm...>]

On Thu, Oct 23, 2014 at 10:13 AM, Burkhard Plaum <
pl...@ig...> wrote:

> Hi,
>
> Am 22.10.2014 um 20:47 schrieb Steven Schultz:
> > I've finally narrowed the problem down to the 'stts' atom having a
> > 'sample_count' value of 0.
>
> Fixed. That *encoding* bug creeped in during the last update of the
> *decoding* API :)
>

qtinfo testing.mov

Type: Quicktime

  0 audio tracks.

  1 video tracks.

    704x480, depth 24

    rate 23.976025 [24000:1001] constant

    length 10 frames

    compressor 2vuy.

    Native colormodel:  Undefined

    Interlace mode:     None (Progressive)

    Pixel aspect ratio: 10:11

    No timecodes available

    supported.

  0 text tracks.

Much better :)

I am still puzzled why the Native color model still shows as Undefined.
My memory (possibly faulty) is that it used to say something like "YUV
4:2:2 planar"

Steven

Re: [Libquicktime-devel] libquicktime created files have 0 frame count

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

Hi,

Am 22.10.2014 um 20:47 schrieb Steven Schultz:
> I tried posting this a few days ago but with a screenshot of the atom
> layout the mail item was too large and is waiting for moderator approval.
>
> It's been a little while since I needed to create a 4:2:2 uncompressed
> Quicktime file but now when I run the program that did this task in the
> past the file shows up as having 0 frames which makes many applications
> unhappy.
>
> I've finally narrowed the problem down to the 'stts' atom having a
> 'sample_count' value of 0.

Fixed. That *encoding* bug creeped in during the last update of the *decoding* API :)

Burkhard

[Libquicktime-devel] libquicktime produced files have 0 frame count

[Steven S. <sch...@gm...>]

It's been a little while since I needed to create a 4:2:2 uncompressed
Quicktime file but now when I run the program that did this task in the
past the file shows up as having 0 frames which makes many applications
unhappy.

I've finally narrowed the problem down to the 'stts' atom having a
'sample_count' value of 0.

Included  is a simple test case that produces a 10 frame Quicktime file
named testing.mov.  Compilation was done with cc -I/usr/local/include/lqt
testqt.c -lquicktime but if you've libquicktime installed elsewhere change
the -I and / or add -L.

Running the program as ./a.out results in the file

[larry:~] sms% ls -l testing.mov
-rw-r--r--  1 sms  staff  6759228 Oct 17 16:56 testing.mov

qtinfo says the file has 0 frames

qtinfo testing.mov

Type: Quicktime
  0 audio tracks.
  1 video tracks.
    704x480, depth 24
    rate 23.976025 [24000:0] constant
    length 0 frames
    compressor 2vuy.
    Native colormodel:  Undefined
    Interlace mode:     None (Progressive)
    Pixel aspect ratio: 10:11
    No timecodes available
    supported.
  0 text tracks.

and the frame rate doesn't look right either, I'd expect [24000:1001].   I
thought too that the Native colormodel should be 422.

Looking at the file using an Apple utility I se  the 'stts' atom has a 0
for the 'sampCnt' (sample_count) field.  If I change that to 10 the qtinfo
output is  correct.

The test program is based on the y4mtoqt program from mjpegtools.  Y4mtoqt
was working for years and hasn't changed, so something in libquicktime's
been broken in the last few months or
so.
I've tried attaching what I thought were small enough screenshots showing
the atoms of the broken file but a 64KB limit on mail times is causing the
mail to be held pending moderator approval.

here's the  test program that produces a file with 10 junk frames.

#include <stdio.h>

#include <stdlib.h>

#include <stdint.h>

#include <quicktime.h>

#include <lqt.h>

#include <colormodels.h>


int

main(int argc, char **argv)

{

char *outfilename = "testing.mov";

uint8_t *yuv[3];

int y_len, u_len, v_len, nfields = 1, dominance = 0;

int imodel = 0;

int err, i, c, y4mchroma;

char *qtchroma = NULL;

quicktime_t *qtf;

quicktime_pasp_t pasp;


 qtchroma = QUICKTIME_2VUY;

imodel = BC_YUV422P;    /* Input is planar */


 y_len = 704 * 480;

u_len = 352 * 480 ;

v_len = 352 * 480 ;

yuv[0] = malloc(y_len);

yuv[1] = malloc(u_len);

yuv[2] = malloc(v_len);


 qtf = quicktime_open(outfilename, 0, 1);

if (!qtf)

fprintf(stderr,"quicktime_open(%s,0,1) failed", outfilename);


 quicktime_set_video(qtf, 1,

704,

480,

(double) 24000 / 1001,

qtchroma);

lqt_set_cmodel(qtf, 0, imodel);


 dominance = 0;

nfields = 1;

lqt_set_fiel(qtf, 0, nfields, dominance);


 pasp.hSpacing = 10;

pasp.vSpacing = 11;

lqt_set_pasp(qtf, 0, &pasp);


 for (i = 0; i < 10; i++)

{

err = quicktime_encode_video(qtf, yuv, 0);

if (err != 0)

fprintf(stderr, "quicktime_encode_video failed.");

}

quicktime_close(qtf);

exit(0);

}

[Libquicktime-devel] libquicktime created files have 0 frame count

[Steven S. <sch...@gm...>]

I tried posting this a few days ago but with a screenshot of the atom
layout the mail item was too large and is waiting for moderator approval.

It's been a little while since I needed to create a 4:2:2 uncompressed
Quicktime file but now when I run the program that did this task in the
past the file shows up as having 0 frames which makes many applications
unhappy.

I've finally narrowed the problem down to the 'stts' atom having a
'sample_count' value of 0.

Attached is a simple test case that produces a 10 frame Quicktime file
named testing.mov.  Compilation was done with cc -I/usr/local/include/lqt
testqt.c -lquicktime but if you've libquicktime installed elsewhere change
the -I and / or add -L.

Running the program as ./a.out results in the file

[larry:~] sms% ls -l testing.mov
-rw-r--r--  1 sms  staff  6759228 Oct 17 16:56 testing.mov

qtinfo says the file has 0 frames

qtinfo testing.mov

Type: Quicktime
  0 audio tracks.
  1 video tracks.
    704x480, depth 24
    rate 23.976025 [24000:0] constant
    length 0 frames
    compressor 2vuy.
    Native colormodel:  Undefined
    Interlace mode:     None (Progressive)
    Pixel aspect ratio: 10:11
    No timecodes available
    supported.
  0 text tracks.

and the frame rate doesn't look right either, I'd expect [24000:1001].   I
thought too that the Native colormodel should be 422.

Also attached is a small extract  of 'dumpster' (an Apple utility that is
very useful for exploring Quicktime files and can also edit/modify them)

Note the 'stts' atom has a 0 for the 'sampCnt' (sample_count) field.  If I
change that to 10 the qtinfo output is  correct.

The test program is based on the y4mtoqt program from mjpegtools.  Y4mtoqt
was working for years and hasn't changed, so something in libquicktime's
been broken in the last few months.

decoding existing files created earlier or imported from a video capture
works but at the moment libquicktime can't be used to create new files that
other applications are happy with.

Steven Schultz

Re: [Libquicktime-devel] FFmpeg plugin resync DNW for out-of-order B-frames after full sync keyframes

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

Hi,

Am 27.09.2014 um 13:57 schrieb Derek Chow:
> Okay, I'll keep in mind that this should also support MP4.
>
>> The code for calculating the pts does this right for both cases because the first ctts value is
>> alaways zero for quicktime and max_decoding_delay for mp4. I don't see how the PTS can get
>> negative here.
>
> In the beginning of this thread, as with the "quicktime_is_bframe()
> breaking for wobbly GOP pattern" thread, I describe an XDCAM quicktime
> file with initial non-zero ctts value... The qtdump output looks like:
>
> ...
>       composition time to sample (ctts)
>        version 0
>        flags 0
>        total_entries 46437
>         count 1 duration 2
>         count 2 duration -1
>         count 1 duration 2
> ...
>
> Hence the PTS gets negative!

Ahh ok, I think I know what this is:

PTS = DTS + CTS. Assuming your DTS is 0, 1, 2, 3.... you get (with the current code):

PTS1: 0 + 2 - 2 = 0  (First I-Frame)
PTS2: 1 - 1 - 2 = -2 (Obsolete B-Frame, should be skipped)
PTS3: 2 - 1 - 2 = -1 (Obsolete B-Frame, should be skipped)
PTS4: 3 + 2 - 2 = 3  (First P-Frame)

The problem is not, that PTS gets negative, in fact negative PTS are completely correct here.

The problem is that the stream contains some undecodable B-Frames (from before the first I-frame)
at the beginning. Hardware encoders like cameras like to do that. On the decoding side, such frames
should be skipped (i.e. not even passed to the decoder).

Burkhard