[FFmpeg-devel] Bugreport: mpegts-demuxer gives wrong pts/dts with avchd files
Fri Feb 29 13:50:48 CET 2008
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
decoding, the timestamp calculation is needed or some frames will not have
timestamps at all. And thats fatal for variable framerate material.
> 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
Also about complexity, code has to be shared between decoder and the parser
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel