> So my concern and my question was more about recieving/sending frames than
> recieving/sending packets, so that I was asking if inside livemedia there is
> any buffer that stores packets, sorts them and compile them in frames.
Sort of. First, our RTP reception code automatically ensures that incoming
data is delivered in the correct order, even if packets happen to get reordered
on the network. So that's not something that you ever need to worry about.
Our code also deals with the fact that H.264 NAL units may be fragmented over
multiple RTP packets. Our RTP reception code ("H264VideoRTPSource", for H.264
video) always delivers either a complete NAL unit, or (if one of the fragment
packets happened to have been lost) no NAL unit at all. (Note that if a H.264
video 'access unit' has been split into several slices (each one being a NAL
unit), then these slices will be delivered - in order, and completely (or not
at all) - to the recipient.)
Also, the incoming NAL units will be sorted into 'decode order' - because
that's the order (according to the H.264/RTP payload format standard) in which
they were originally transmitted.
Finally, we have a Boolean function "RTPSource::curPacketMarkerBit()" that the
receiving code can call to check whether or not the most recently-received NAL
unit ends an 'access unit'.
The bottom line is that our code automatically deals with the RTP
packetization/depacketization. All you (as a programmer) need to deal with is
'NAL units'.
You can illustrate this by running the "testRTSPClient" demo application on a
H.264 RTSP stream. See also
http://www.live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data
(ps. When responding to an email, please remember to properly trim the text of
the quoted message that you're responding to.)
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
