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?
--
Regards, Thorsten