[FFmpeg-devel] [PATCH] rtpenc: packetizer for VP9 RTP payload format (draft v2)

[Ronald S. Bultje]

Hi,

On Thu, Jun 2, 2016 at 12:33 PM, Thomas Volkert <silvo at gmx.net> wrote:

> Hi,
>
> On 30.05.2016 17:43, Ronald S. Bultje wrote:
>
>> Hi,
>>
>> On Mon, May 30, 2016 at 10:41 AM, Thomas Volkert <silvo at gmx.net> wrote:
>>
>> From: Thomas Volkert <thomas at netzeal.de>
>>>
>>> ---
>>>   libavformat/Makefile     |  1 +
>>>   libavformat/rtpenc.c     | 14 +++++++++++++
>>>   libavformat/rtpenc.h     |  1 +
>>>   libavformat/rtpenc_vp9.c | 54
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>   libavformat/sdp.c        |  4 ++++
>>>   5 files changed, 74 insertions(+)
>>>   create mode 100644 libavformat/rtpenc_vp9.c
>>>
>> No opinion on the patch itself yet, but I'm wondering if you've tested
>> this
>> under real conditions with the built-in and libvpx-based decoders? I'm
>>
> Yes.
>
> asking because IIRC the built-in ffvp9 decoder doesn't deal with missing
>> references well at all (it just bails out), so it might be that under real
>>
> My tests showed this behavior, too.
> Is it possible to improve the decoder with acceptable effort to overcome
> this limitation?


Yes, absolutely, just use a different reference should help about half of
it, see h264/mpeg/hevc decoders for more general info on error
resilience/recovery.

network conditions, it doesn't work all that well...
>>
>> (That doesn't disqualify the patch in any way, but it would be good to
>> document somewhere for people trying to use this.)
>>
> I think the sender part is not the right position.
> Where should we place such a hint?


That's a great question, I'm not entirely sure. The point is not so much to
serve as a TODO list (in which case it should go into vp9.c), but to
document a limitation and suggest a workaround (use libvpx-vp9), so I would
suggest to put it in rtpenc_vp9.c anyway, but it does feel iffy.

Ronald