[FFmpeg-soc] vp8 de/packetizers

[David Conrad]

On Aug 3, 2010, at 10:04 AM, Martin Storsjö <martin at martin.st> wrote:

> On Mon, 2 Aug 2010, Josh Allmann wrote:
>
>> On 2 August 2010 16:51, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>>> Hi Josh,
>>>
>>> On Mon, Aug 2, 2010 at 7:46 PM, Josh Allmann <joshua.allmann at gmail.com 
>>> > wrote:
>>>> Also, I talked to the dev responsible for gstreamer's vp8 RTP.
>>>> Apparently gstreamer's implementation is made up, so we're going  
>>>> to be
>>>> incompatible with them until a more official spec is published.
>>>
>>> No surprise there. OK, feel free to apply whenever people stop  
>>> giving
>>> comments then.
>>>
>>>> +    int            is_keyframe; // this is rather unused
>>>
>>> That's not good, it should set PKT_FLAG_KEY.
>>>
>>
>> Done. This also fixed stream copying on the receiver side; I didn't
>> realize that was a bug.
>>
>> Also added doxy to the depacketizer, and a comment in the packetizer
>> indicating where to locate the spec.
>>
>> Unless I've mis-counted my marker bits yet again, we are in full
>> compliance with the spec, except for the parts that are undefined --
>> the "VP8" encoding name in particular.
>
> One issue in the proposal that I don't think we comply to (and that I
> think should be changed before it is finalized, is this:
>
>> 3.3 Lost VP8 RTP packets
>> If a lost packet is detected in the RTP stream, the transport layer
>> MUST throw out the current partial VP8 frame (if there is one) and
>> all subsequent RTP packets until a VP8 payload descriptor with the
>> key-frame bit is set.
>
> Not returning a single packet up until the next keyframe, if a single
> packet is lost, feels quite horrible to me. Even though it may not  
> look
> good if some data is lost, it's still better than not getting any  
> data at
> all up until the next keyframe.

VP8's probability contexts and segment map aren't reset between  
interframes, so if an entire frame is lost the rest of the GOP will  
likely decode to total junk.

If you want to do better than the proposal, you can read the vp8 frame  
header and ignore the rfc if the first data partition is intact;  
that's the only guarantee that arithmetic probabilities and the  
segment map remain correct.