Hi, On Thu, Jun 2, 2016 at 12:33 PM, Thomas Volkert <si...@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 <si...@gmx.net> wrote: >> >> From: Thomas Volkert <tho...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
