[FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input
michael at niedermayer.cc
Thu May 17 16:38:55 EEST 2018
On Thu, May 17, 2018 at 12:22:01PM +0200, Hendrik Leppkes wrote:
> On Thu, May 17, 2018 at 11:49 AM, Michael Niedermayer
> <michael at 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.leppkes at 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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel