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

[Thorsten Jordan]

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.
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.

-- 
Greetings, Thorsten