On Thu, May 17, 2018 at 12:22:01PM +0200, Hendrik Leppkes wrote: > On Thu, May 17, 2018 at 11:49 AM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Wed, May 16, 2018 at 12:53:46AM +0200, Carl Eugen Hoyos wrote: > >> 2018-05-16 0:29 GMT+02:00, Hendrik Leppkes <h.lepp...@gmail.com>: > >> > >> > It makes no real difference if its less efficient or whatever - > >> > if a codec specification asks for this behavior, then our > >> > decoders should act accordingly. > >> > >> I wonder where this suddenly comes from? > >> (I was away from my mail client when a similar argument > >> was used a few weeks ago and I forgot later.) > >> Luckily, many of our codecs do smarter things > >> than the specifications asks for... > >> > >> Do we have a specification for qtrle? > > > > Iam only aware of the one "we", that is more correctly mike melanson > > wrote: https://multimedia.cx/qtrle.txt > > > > I think this invalidates the argument, so if i hear no objections then > > ill apply this patch in a few days > > > > How does that invalidate the argument that you take a compressed CRF > stream and suddenly decide to make VFR out of it? > Because it does not.
We have always droped cloned fields and frames even where the specification unquestionably wants something different, when this is inefficient For example mpeg2 has its field and frame duplication information, we update timestamps according to this information but never duplicate fields/frames. If we imagine an alterantive reality where we did clone then the decoder would be 20% slower in cases where it differs maybe, and we would output many progressive videos as interlaced which could not be displayed nicely that way on the majority of display devices. So what we do for mpeg2 makes sense. And this too changes constant field rate mpeg2 into vfr now qtrle, is a niche codec, why should it be handled in a way that is 1. inefficient & slower 2. easier to mount a DOS attack against 3. inconsistent with the other decoders we have ? Maybe i just dont understand your concern Is it that theres some need in some application for something like regular heartbeat frames ? If so this is a issue for most VFR and especially subtitles, changes to qtrle wont really help or hurt this. It would require injecting regular frames or a flag that for every decoder clones frames if nothing occured beyond a threshold [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel