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

Michael Niedermayer michaelni
Thu Feb 28 21:37:22 CET 2008

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:
> >>>
> >>>> Hello,
> >>>>
> >>>> i just stumbled over misbehvaiour of the mpegts-demuxer of ffmpeg. I
> >>> [...]
> > 
> > more details after more debugging:
> > 
> [...]
> > 
> > So it seems that if parsers give fields instead of frames, here is
> > something fundamentally broken in libavformat/utils.c/av_read_frame.
> > 
> > This should be a problem for mpeg2 too (and maybe other formats).
> checking SVN it seems revision 12156 brought a solution for mpeg2, but
> it was reverted. There the parser context was extended to remember field
> parity. The h264 parser would have to be extended in a similar way, that
> means it would need to parse h264 slice headers together with all the
> golomb stuff etc.
> And of course rev. 12156 would have to be kept, if it works. These two
> changes should fix the AVCHD parsing.
> 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
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.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080228/82f3ce6f/attachment.pgp>

More information about the ffmpeg-devel mailing list