<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] RTSP H264 frame
inversion</title></head><body>
<blockquote type="cite" cite>
<blockquote>Yes, your input device object should be setting the
"fPresentationTime" field in its implementation of
"doGetNextFrame()", when it delivers each NAL unit.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
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?</blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>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???
#####"</blockquote>
<div><br></div>
<div>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.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>