thanks, I will submit a new patch with the requested changes On Wed, Jun 12, 2019 at 3:00 PM Marton Balint <c...@passwd.hu> wrote:
> > > On Wed, 12 Jun 2019, Michael Niedermayer wrote: > > > On Wed, Jun 12, 2019 at 10:09:08AM +0200, Marton Balint wrote: > >> > >> > >> On Wed, 12 Jun 2019, Michael Niedermayer wrote: > >> > >>> On Tue, Jun 11, 2019 at 03:21:41PM -0500, Amir Z wrote: > >>>> Thanks Michael Niedermayer for looking into this > >>>> > >>>> What I am trying to solve is having a way to detect concealed decoding > >>>> errors by the caller to avcodec_receive_frame. > >>>> > >>>> Should I add a general value e.g. #define > >>>> FF_DECODE_ERROR_DECODE_ERROR_OCCURRED 4 ? > >>> > >>> I suggest > >>> FF_DECODE_ERROR_CONCEALMENT_ACTIVE or something similar and then always > >>> set this for all cases of error concealment > >>> Its more informative than just knowing there was an error > >> > >> Concealment is a consequence. Error_flags should refer to the cause. A > >> generic UNKNOWN error seems much better to me if it is not feasible to > >> determine the cause. > > > > Concealment is the consequence generally, still the error in the frames > > differs between concealment or no concealment. A user application may > > want to treat these differently. > > concealemnt is not supported by all codecs currently and also not by > > all variants, for example interlaced material tends to be less supported > > in concealment. A user app might choose to discard a frame that > > contains errors but no concealemnt if the following frame is fine. > > > > Also in a very pedantic view, concealemnt itself is an error too. > > Its rarly known exactly where the damage starts so concealment often > needs > > to cover more and by doing so adds errors in a minority of locations > > that is if you just want a formal argument why this would fit in here. > > Not an argument against the principle that concealemnt differs here in > what > > it is, you are certainly correct about that. > > OK, FF_DECODE_ERROR_CONCEALMENT_ACTIVE is fine then. > > Thanks, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
