[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:39:44 EEST 2019


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.

- Hendrik


More information about the ffmpeg-devel mailing list