On Tue, May 07, 2019 at 02:03:22AM +0200, Marton Balint wrote: > > > On Tue, 7 May 2019, Michael Niedermayer 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. > > I guess that can be easily fixed by only copying the buffer if it really is > a different frame. > > >It also would make encoding the output harder. > >For example motion estimation would be run over unchanged frames even when > >no cfr is wanted. > > The performance penalty is much more acceptable to me than the issue > described in the ticket. Do you see a straightforward way to fix it other > than reverting?
decoders can in general have frames at the end which need to be flushed out. For example IPB mpeg1/2/4/... In the same way the decoder could output a last frame representing the end exactly [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle
signature.asc
Description: PGP signature
_______________________________________________ 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".
