[FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
nfxjfg at googlemail.com
Wed Mar 15 21:08:16 EET 2017
On Wed, 15 Mar 2017 15:02:08 -0400
"Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> On Wed, Mar 15, 2017 at 2:51 PM, Michael Niedermayer <michael at niedermayer.cc
> > wrote:
> > On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote:
> > > I'm actually starting to believe that the error concealment code in this
> > > decoder (vp56) is fuzz-specific code also. Is there a real-world input
> > > where the user experience is improved by this code?
> > I have no real world damaged vp56 files iam aware of, in fact i dont
> > think i remember seeing vp56 in the wild, what i have are just our
> > samples or at least thats what iam concioulsy aware of
> > Damaged data is inevitable though from packet loss, damaged sectors
> > and other, so damaged data is real it occurs with anything eventually
> > that is stored or transmitted. The only way it can never occur is if
> > a codec is never used more or less
> > and error concealment can provide better quality than lack of EC.
> > when fixing fuzz issues iam trying to do something usefull when theres
> > a related feature like implementing the very basic EC code in vp56.
> > Working error concealment code would be nice for every codec IMO
> I agree in general, but we need a way of verifying that it actually works,
> which in this case means "leads to an improvement in decoded stream
> quality". I don't think that has been verified here.
> No benefit (..) for a very quickly escalation in code complexity related to
> this feature makes me wonder whether that's the right approach.
> but if people dont want EC code in vp56 then we can drop this code of
> > course, makes no difference to me.
> I would personally probably vote to remove EC from vp56. I'd like to hear
> other people's opinions also, don't remove it just because I said so ;-).
I think the right question is: are vp56 streams usually broken?
For example, for mpeg2 or h264, the answer can be "yes" because those
are used in DVB (i.e. very unreliable transport).
More information about the ffmpeg-devel