[vlc-devel] Re: live.com and the RTP-header marker bit
finlayson at live.com
Fri Mar 26 19:01:15 CET 2004
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
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).
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>
More information about the vlc-devel