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

[Michael Niedermayer]

On Tue, May 07, 2019 at 01:39:44AM +0200, Hendrik Leppkes 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.

in ISO/IEC 13818-2: 1995 (E), repeat_first_field is part of the picture coding extension,
if its removed it will no longer decode. Iam not sure calling this metadata
is accurate.

also the description of the field is:
    [...]If progressive_sequence is equal to 0 and progressive_frame is equal to 1:
    If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame
    consists of two fields. The first field (top or bottom field as identified by top_field_first) is followed by the
    other field.
    If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of
    three fields. The first field (top or bottom field as identified by top_field_first) is followed by the other
    field, then the first field is repeated. [...]

if you dont return 3 fields you break the normative specification. This speaks
about the "output of the decoding process" not how to interpret the output.

I bring MPEG2 up here because we dont do what the normative spec says
because it doesnt make sense for us. It does make sense if you output on a
analoge interlaced PAL/NTSC screen. It is fundamentally the same as the
CFR case, on one side a interlaced display as factor on the other a output
only capable to handle fixed duration (CFR) frames.

About CFR codecs, the cases this is about are generally input packets that
code the equivalent of "nothing changed". In frameworks that allow only CFR
an implementation would produce a duplicated frame. In frameworks that allow
VFR an implementation can omit the duplicated frame.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190509/6ea1105e/attachment.sig>