[FFmpeg-devel] [PATCH 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

Hendrik Leppkes h.leppkes at gmail.com
Tue May 7 02:42:50 EEST 2019


On Tue, May 7, 2019 at 1:39 AM Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>
> On Tue, May 7, 2019 at 12:34 AM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> >
> > On Sun, May 05, 2019 at 08:51:08PM +0200, Marton Balint wrote:
> > > This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
> > >
> > > I don't think it is a good idea to drop frames from CFR input just because they
> > > are duplicated, that can cause issues for API users expecting CFR input. Also
> > > it can cause issues at the end of file, if the last frame is a duplicated
> > > frame.
> > >
> > > Fixes ticket #7880.
> > >
> > > Signed-off-by: Marton Balint <cus at passwd.hu>
> > > ---
> > >  libavcodec/qtrle.c        |  12 ++---
> > >  tests/ref/fate/qtrle-8bit | 109 ++++++++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 115 insertions(+), 6 deletions(-)
> >
> > This change would make the decoder quite a bit slower. It also would make
> > encoding the output harder.
> > For example motion estimation would be run over unchanged frames even when
> > no cfr is wanted.
>
> This is simple:
> There is X input packets, any other decoder outputs X output frames.
> FFmpeg outputs Y output frames (where Y < X). How can this be correct
> decoding?
>
> If you want to lesten the burden of static frames, a filter to detect
> duplicates and make a stream VFR is what you should suggest, not
> making decoders act "unexpectedly".
>
> >
> > Also if one for consistency wants every decoder to not drop duplicated things
> > that will cause some major problems in other decoders.
> > Iam thinking of MPEG2 here, where the duplication is at a field level
> > perfectly progressive material would be turned into some mess with field
> > repetition in that case. Again undoing that in a subsequent stage would be
> > quite a bit harder and wastefull
> >
>
> There is quite a fundamental difference between CFR codecs where we
> end up not generating output for an input packet just because we feel
> like it, and the thought of somehow interpreting field repeat
> metadata. That just smells like deflection, lets not go there.
>

Also since you talk about making a "mess", this class of changes makes
quite a mess out of perfectly CFR material, to use your own
formulation. :)

- Hendrik


More information about the ffmpeg-devel mailing list