On Tue, May 7, 2019 at 1:39 AM Hendrik Leppkes <h.lepp...@gmail.com> 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. >
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 _______________________________________________ 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".
