[FFmpeg-devel] [PATCH] rtpenc: Change the warning text about VP8

Josh Allmann joshua.allmann
Sun Dec 5 05:24:42 CET 2010

On 4 December 2010 14:56, Martin Storsj? <martin at martin.st> wrote:
> On Sat, 4 Dec 2010, Luca Barbato wrote:
>> On 12/04/2010 06:43 PM, Martin Storsj? wrote:
>> > The RTP VP8 spec draft has been updated some time ago, and the current
>> > implementation probably is incompatible with the latest drafts, so we
>> > should probably tell users about this until the code is updated to work
>> > according to the latest spec version.
>> >
>> I think it's Ok, do they complicate the spec even more?
> Yes, IIRC it's kinda complicated now, but also makes a bit more sense
> regarding what kind of packet loss VP8 can tolerate and what it can't.
> It's a few weeks since I skimmed through it, but it might require some
> kind of parsing of the VP8 packet in the packetizer/depacketizer. Don't
> remember all of the details, but it felt not dead obvious that I'd try to
> implement it the same day at least :-)

The insane part is figuring out whether a frame is a reference or not
and marking it as such (the N bit in the VP8 RTP spec). Unfortunately
there is no corresponding flag in the bitstream, and according to my
notes, something like 5 things need to be checked before determining
if the frame is a non-reference:

(names taken from the parlance of FFmpeg's VP8 decoder)
- keyframe
- update_last
- update_altref/update_golden
- update_probabilities

If any of these are true, the frame is used as a reference and cannot
be discarded. Getting this information is tricky -- it's deep into the
bitstream and non-sequential, but luckily I've been told it doesn't
seem to require invoking the arithmetic coder. If anyone with more
knowledge of the VP8 bitstream wants to chime in, please do.

I am assuming the FEC and RTCP feedback stuff is optional. Those would
require more changes to the RTP layer.


More information about the ffmpeg-devel mailing list