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

[Michael Niedermayer]

On Wed, Mar 19, 2008 at 09:50:18AM +0100, Thorsten Jordan wrote:
> Michael Niedermayer schrieb:
> [...]
> > 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.
> The problem reappeared here, because I need to write a ts-muxer that can
> mux h.264 and for that need a h.264 elementary stream analyzer
> generating PTS, which is very similar to the task needed for the demuxer
> (more advanced h264-parser).
> I researched a bit and it seems that the picture order count (POC) data
> can be used to generate correct timestamps if they are missing (and of
> course current frame rate, and handling resets of the poc numbers).
> That means only parts of the h264-decoder need to be shared with the
> parser, but its hard to extract it without duplicating code and without
> causing speed loss.
> What would be needed for such a parser is SPS parsing (at least
> partially), PPS parsing and slice header parsing, the init_poc()
> function of h264.c and some state variables.
> I see that these computations and init_poc() are done for every slice,
> although they should be equal for every slice of that picture. Can
> slices of two pictures be mixed in the stream (wouldn't make sense, but
> does the standard forbids this)?
> 
> Carl-Eugen, you are working on the h264-parser said Michael? Had you any
> plans how to generate missing PTS?
> 

> Would the POC-value be sufficient, any comments from the h264-experts here?

Without checking the spec id say no, but using POCs would be much better than
the current code.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20080319/c5f5e256/attachment.pgp>