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

Sigmund Augdal sigmunau at stud.ntnu.no
Fri Mar 26 15:51:37 CET 2004


On Thu, Mar 25, 2004 at 03:10:13PM -0800, Ross Finlayson wrote:
> 
> >> Because the LIVE.COM code passes complete frames to the decoder, I don't
> >> think you need this information at all.  Once you've gotten data from the
> >> "livedotcom" demux, it should already be a complete frame.
> >Seem like you're right, but it also seems like the frame is completly 
> >messed
> >up, and my decoder library doesn't like it. Is there any way to disable 
> >this
> >"feature", if only just for debugging?
> 
> No, you can't 'disable' this (at least, not easily), but one thing you 
> could do is add debugging commands to
I changed H261VideoRTPSource into inherit from SimpleRTPSource, and
instansiated SimpleRTPSource with doNormalMBitRule as false. And commented
out everything that didn't compile after this. This makes h261
decoding work perfectly for me. Let me explain why. H261 uses a 4 byte
header in front of each RTP packet. This header _does_ change from packet to
packet. LiveMedia (as far as I understand) keeps the first header in a frame
and drops all the others while rebuilding a frame. As this header does
change from packet to packet, this is obviously bad. I have discovered two
things that happens because of this:
1. the header contains info about where in the frame the macroblocks in this
packet is to be placed. In perfect conditions this is not a big problem, but
when there is packet loss dropping the header causes large parts of the
video to be displaced and rendered in a completly wrong place.
2. the header contains quantizer information. When this changes inside a
frame it causes  macroblocks to go bright green or pink and just entirly
wrong.

I don't know what the proper way to handle this is, just that the current
way is bad.

Sigmund Augdal

-- 
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 mailing list