[Live-devel] RTSP H264 frame inversion

[Ross Finlayson]

>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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110201/6e7c4940/attachment-0001.html>