[Libquicktime-devel] quicktime_is_bframe() breaking for wobbly GOP pattern

[Derek Chow]

Hi,

I've come across an XDCAM file with an unusual GOP pattern that breaks the
current logic of quicktime_is_bframe() (see related notes in
http://sourceforge.net/p/libquicktime/mailman/message/29389235/) , meaning
seeking to certain frames 'resync's badly for the FFmpeg plugin:

composition time to sample (ctts)
version 0
flags 0
total_entries 46437
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 0 <--- flagged as a B-frame however bitstream flag
reveals this is an I-frame
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 1
count 1 duration -1
count 1 duration 0 <--- flagged as a B-frame however bitstream flag
reveals this is an I-frame
...

Any ideas what to do about this?

Thanks,

[Derek Chow]

One idea I have is to assume the previous to simply compare the previous
ctts entry (see attached patch).

Post by Derek Chow
Hi,
I've come across an XDCAM file with an unusual GOP pattern that breaks the
current logic of quicktime_is_bframe() (see related notes in
http://sourceforge.net/p/libquicktime/mailman/message/29389235/) ,
composition time to sample (ctts)
version 0
flags 0
total_entries 46437
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 0 <--- flagged as a B-frame however bitstream
flag reveals this is an I-frame
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 2
count 2 duration -1
count 1 duration 1
count 1 duration -1
count 1 duration 0 <--- flagged as a B-frame however bitstream
flag reveals this is an I-frame
...
Any ideas what to do about this?
Thanks,
--
Derek Chow / C++ Developer
Office [phone]
21 Broadwall, London, SE1 9PL, United Kingdom
http://www.mirriad.com

[Derek Chow]

(Sorry I'm using a new email client and forgot to send as plain text,
message below):

One idea I have is to assume the previous to simply compare the
previous ctts entry (see attached patch).

[Burkhard Plaum]

Hi,

the more I look at the code, the more I get the feeling that
it's too messy to get fixed. The next file with a probably
even weirder GOP pattern might break the code again.
The logic behind seeking and resyncing in a file with
B-frames actually quite straightforward, but our code, which
grew over the years from patches by different submitters, doesn't
resemble this.

Also, from what I see our current resync/skip mechanism will
produce garbled output for H.264 streams with B-pyramids
(where B-frames can also be reference frames).

I'll think about how we can enhance lqt_read_video_packet()
and use it from within the codecs. One generic routine, which
outputs the PTS, DTS and frame type along with the compressed data
would probably help a lot.

Burkhard