[FFmpeg-devel] Bugreport: mpegts-demuxer gives wrong pts/dts with avchd files

[Måns Rullgård]

Michael Niedermayer wrote:
> On Fri, Feb 29, 2008 at 09:03:17AM +0100, Thorsten Jordan wrote:
>> Michael Niedermayer schrieb:
>> > On Thu, Feb 28, 2008 at 04:34:02PM +0100, Thorsten Jordan wrote:
>> >> Thorsten Jordan schrieb:
>> >>> Thorsten Jordan schrieb:
>> >>>> M?ns Rullg?rd schrieb:
>> >>>>> Thorsten Jordan <tjordan at macrosystem.de> writes:
>> [...]
>> >> Michael, why did you revert it? Couldn't the current utils.c a problem
>> >> for mpeg2 too?
>> >
>> > For mpeg2 either of the 2 solutions (12156 and svn) solves the problem, for
>> > H.264 neither works.
>> >
>> > The current mpeg2 parser does not return fields, but always merges 2 fields
>> > into frames (and field picture mpeg2 is rare, interlaced frames are more
>> > common). Either way H.264 does not gurantee paired fields, here frames and
>> > fields can be mixed arbitrarily thus no merging will work.
>> >
>> > The second solution depended on mpeg2 sytle IPB reordering. H.264 allows much
>> > more flexible frame orderings (b pyramid for example) the code would not have
>> > been able to handle that at all.
>> >
>> > The h.264 parser will have to parse slice headers and SEI messages as far as
>> > i understand.
>> >
>> > If you are interrested in fixing this, download te H.264 and H.222 specs
>> > and read
>> > 2.14 Carriage of ITU-T Rec. H.264 | ISO/IEC 14496-10 video
>> > and
>> > 2.7 Restrictions on the multiplexed stream semantics
>> >
>> > Also you will likely have to deal with streams being non compliant to the
>> > AVC in mpeg restrictions, i doubt everyone conforms to them strictly.
>
>> well the particular problem arises with AVCHD material that uses a
>> rather simple scheme (very mpeg2-like), 12 frames per GOP, usual IBB/PBB
>> "packs", every frame consists of two fields etc.
>> At least for such material a simple approach would work, extending the
>> h264 parser to decode slice headers etc. I did that for some other
>> project already and know the h264-specs so far, and such code already
>> exists in h264.c already.
>> The question is, if the h264 parser would be extended with that parsing
>> (no fancy B-pyramid stuff) plus bringing back the changes of rev 12156
>> of utils.c or similar code, would that be accepted into ffmpeg? It would
>> solve the AVCHD problems, but maybe not all h264 parsing cases as you noted.
>> I suppose the code in h264.c doing reference frame computing is needed
>> for a fully correct parser and that code is complex.
>
> I am only interrested in spec compliant solutions. Also note IIRC
> Carl Eugen Hoyos wanted to work on the h264 timestamp problem as well, maybe
> you should contact him to avoid duplicate work.
> And if someone (mans?) wants we can add a if(!h264) over the current timestamp
> calculation code so it doesnt return wrong timestamps. But stream copy or

If correct timestamps can't be guaranteed, then IMHO returning no timestamp
is better than an incorrect value.  A player can easily interpolate
missing timestamps, but has a much harder time if none of the timestamps
can be trusted.  A flag indicating computed (and possibly incorrect)
timestamps might be an option too.

> decoding, the timestamp calculation is needed or some frames will not have
> timestamps at all. And thats fatal for variable framerate material.

Variable framerate material would have to have timestamps on every frame
in the container, or nobody will be able to figure out the missing values.

>> Another alternative would be to combine fields to frames as you did in
>> mpeg2-decoder. Me personally wouldn't like that, as i need to use
>> libavformat with a decoder that can't handle two fields at once (ffh264
>> can do it), and i have to use that decoder (my company demands it so).
>> Another question is wether the additional cpu time of parsing the h264
>> slice headers would be accepted for ffmpeg, the decoder does the same
>> afterwards. It's not too costly, but adds a little.
>
> The parsing would only be done when needed (that is if SEI/DTS/PTS were
> insufficient)
> Also about complexity, code has to be shared between decoder and the parser
> where possible.

Agree.

-- 
M?ns Rullg?rd
mans at mansr.com