[vlc-devel] Re: live.com and the RTP-header marker bit

[Ross Finlayson]

Sigmund,

Thanks for looking into this.

The current "H261VideoRTPSource" implementation is, as you discovered, 
rather dumb.  It currently works by skipping (and ignoring) the 4-byte 
"H.261 header" (as defined in RFC 2032).  It then uses the marker bit to 
figure out whether a complete video frame has arrived, and does not deliver 
data to the caller until it has received a complete video frame.  If any of 
the packets that make up the complete video frame get lost, then the data 
for the entire frame gets discarded.

As you noted, however, this doesn't work well for a decoder that (i) wants 
to use the information that's in each "H.261 header", and/or (ii) can make 
good use of partial frame data (if packets get lost).

So, I'll change the implementation to:
	(i) Deliver each packet payload (after the 4-byte "H.261 header") to the 
caller, even if it does not constitute a complete frame, and
	(ii) Make the value of the 4-byte "H.261 header" (for the most 
recently-delivered packet data) available to the caller, using a special 
member function.

I'll let you know when a new version of the LIVE.COM is available that 
includes this fix (probably sometime within a few hours).

	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>