[FFmpeg-devel] [PATCH] rtpenc: packetizer for VP9 RTP payload format (draft v2)
Ronald S. Bultje
rsbultje at gmail.com
Thu Jun 2 19:13:51 CEST 2016
On Thu, Jun 2, 2016 at 12:33 PM, Thomas Volkert <silvo at gmx.net> wrote:
> On 30.05.2016 17:43, Ronald S. Bultje wrote:
>> 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
>> under real conditions with the built-in and libvpx-based decoders? I'm
> 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
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.
More information about the ffmpeg-devel