On Tue, May 07, 2019 at 01:39:44AM +0200, Hendrik Leppkes wrote: > On Tue, May 7, 2019 at 12:34 AM Michael Niedermayer > <mich...@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 <c...@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.
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list email@example.com https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".