Yes, your input device object should be setting the "fPresentationTime" field in its implementation of "doGetNextFrame()", when it delivers each NAL unit.Concerning this point, I've a misunderstanding about how set this value. I'll explain : my frames are coming in a decoding order, that means that for an IDR period like "IBBP", I've "IPBB". So, if each time I proceed a "doGetNextFrame()" I set the fPresentationTime to the value given by gettimeofday(), I see clearly that my video is displayed in decoding order. So, do I've to adapt my fPresentationTime to give a later timestamp for PFrames that dependent BFrames?
The last "Informative Note" in section 5.1 of RFC 3984 suggests that yes, you should do this - i.e., if you have "B" frames, the presentation times should not be monotonically increasing.
In my mind, this will be do with a picture timing value given in SEI, but if I check the Live555 code, I just see an "empty" analyze_sei_data() function with the comment "Later, perhaps adjust "fPresentationTime" if we saw a "pic_timing" SEI payload??? #####"
That's because - when I coded "H264VideoStreamFramer" - I had yet to see a stream that had any "pic_timing" SEI payloads. However, once you've generated such a stream, as a ".264" (and verified that VLC plays it properly, when renamed as ".h264"), please send me a copy, and I'll update our framer implementation accordingly.
-- Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
