Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 6/2/2020 3:45 AM, Paul B Mahol wrote: > On 6/2/20, Michael Niedermayer wrote: >> On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote: >>> On Mon, 1 Jun 2020 at 14:02, Anton Khirnov wrote: >>> Quoting Paul B Mahol (2020-05-29 18:46:18) > I see no aggression at all here. Same here. People have disagreeing opinions and are expressing them. That does not imply aggression or uncivility. >>> >>> There is no aggression here. >> >> So. let me clarify this as it seems several people didnt notice it. >> >> Calling a submitted feature a bug, is aggression. >> >> A bug is unintended behavior. The user would turn this only on >> when its intended >> >> This thread started from me suggesting the change and asking about better >> suggestions >> I suggest to add a AV_CODEC_FLAG2_FAST_UNSAFE and split the current >> uses of the flag up between the 2 >> >> will submit a patch doing that unless i hear objections / a better >> suggestion. >> >> Zero replies >> >> Please, if you see an issue in a patch or suggestion in the future, >> explain that issue, write a clear argument. >> Simply caling a feature a bug or adding your agreement below such >> statement is not helpfull. Its even less helpfull than just saying >> you are against it. >> >> If you say you are against it i can count that, if you say its something >> that it is not what would that tell me ? >> > > Get it a rest and remove this unsafe code at once. He already disabled it, so please don't exacerbate things. ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 6/2/20, Michael Niedermayer wrote: > On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote: >> On Mon, 1 Jun 2020 at 14:02, Anton Khirnov wrote: >> >> > Quoting Paul B Mahol (2020-05-29 18:46:18) >> > > I see no aggression at all here. >> > >> > Same here. People have disagreeing opinions and are expressing them. >> > That does not imply aggression or uncivility. >> > >> >> There is no aggression here. > > So. let me clarify this as it seems several people didnt notice it. > > Calling a submitted feature a bug, is aggression. > > A bug is unintended behavior. The user would turn this only on > when its intended > > This thread started from me suggesting the change and asking about better > suggestions > I suggest to add a AV_CODEC_FLAG2_FAST_UNSAFE and split the current > uses of the flag up between the 2 > > will submit a patch doing that unless i hear objections / a better > suggestion. > > Zero replies > > Please, if you see an issue in a patch or suggestion in the future, > explain that issue, write a clear argument. > Simply caling a feature a bug or adding your agreement below such > statement is not helpfull. Its even less helpfull than just saying > you are against it. > > If you say you are against it i can count that, if you say its something > that it is not what would that tell me ? > Get it a rest and remove this unsafe code at once. > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If a bugfix only changes things apparently unrelated to the bug with no > further explanation, that is a good sign that the bugfix is wrong. > ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote: > On Mon, 1 Jun 2020 at 14:02, Anton Khirnov wrote: > > > Quoting Paul B Mahol (2020-05-29 18:46:18) > > > I see no aggression at all here. > > > > Same here. People have disagreeing opinions and are expressing them. > > That does not imply aggression or uncivility. > > > > There is no aggression here. So. let me clarify this as it seems several people didnt notice it. Calling a submitted feature a bug, is aggression. A bug is unintended behavior. The user would turn this only on when its intended This thread started from me suggesting the change and asking about better suggestions I suggest to add a AV_CODEC_FLAG2_FAST_UNSAFE and split the current uses of the flag up between the 2 will submit a patch doing that unless i hear objections / a better suggestion. Zero replies Please, if you see an issue in a patch or suggestion in the future, explain that issue, write a clear argument. Simply caling a feature a bug or adding your agreement below such statement is not helpfull. Its even less helpfull than just saying you are against it. If you say you are against it i can count that, if you say its something that it is not what would that tell me ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Mon, 1 Jun 2020 at 14:02, Anton Khirnov wrote: > Quoting Paul B Mahol (2020-05-29 18:46:18) > > I see no aggression at all here. > > Same here. People have disagreeing opinions and are expressing them. > That does not imply aggression or uncivility. > There is no aggression here. If anything the long winded text about how anyone who wants this code removed is creating CO2 emissions is passive-aggressive. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
Quoting Paul B Mahol (2020-05-29 18:46:18) > I see no aggression at all here. Same here. People have disagreeing opinions and are expressing them. That does not imply aggression or uncivility. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 28/05/2020 17:26, Lynne wrote: > That's a bug. We should absolutely not have flags to enable bugs. > The fast flag should be removed from h264 until that bug is fixed, > or deprecated altogether. 100% agree. Hard NAK from me for the very little my opinion here is still worth. This is basically AV_CODEC_ENABLE_SECURITY_ISSUES. - Derek ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 5/29/20, Jean-Baptiste Kempf wrote: > > > On Fri, May 29, 2020, at 16:33, Michael Niedermayer wrote: >> > The responses are "aggressive" because many people want "fast" mode >> > gone. >> >> >> This still doesnt explain the aggressive tone we have here. > > 1% agree > > Whatever the technical discussion, there is no reason to be uncivil to each > other. It never works to be uncivil and has never worked... > > This discussion feels a bit silly because I feel there is an easy way to > solve it. > I see no aggression at all here. > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > > > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, May 29, 2020, at 16:33, Michael Niedermayer wrote: > > The responses are "aggressive" because many people want "fast" mode gone. > > > This still doesnt explain the aggressive tone we have here. 1% agree Whatever the technical discussion, there is no reason to be uncivil to each other. It never works to be uncivil and has never worked... This discussion feels a bit silly because I feel there is an easy way to solve it. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, May 29, 2020 at 10:37:59AM -0300, James Almer wrote: > On 5/29/2020 10:10 AM, Michael Niedermayer wrote: > > while, what you quote above was not about h264 at all > > let me provide benchmarks of most fate h264 samples with and without > > flag_unsafe > > the script that made that is after it. a reply to the 2nd part of your mail > > is > > also below > > > > > > h264-444/444_10bit_cabac.h264 > > 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > > 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > > So the fast flag currently prevents ff_h2645_packet_split() from copying > each NAL into a padded buffer (in the situations where there's are no > emulation_prevention_three_byte to filter). Why is such padding needed > to prevent overreads? > > cbs_h264 always calls ff_h2645_packet_split() with the small_padding > argument as 1, and fuzzing has shown that it seemingly generated no > issues whatsoever, so why can't the bitstream reading code in h264dec > handle it safely? > Or it could but it would be costly? yes, it would cause a slowdown > And even if > costly, wouldn't the the speedup gained in a normal run with no flags > set (where most NALs would not be copied anymore to another buffer) > offset the slowdown from the extra sanity checks? When this code was written the copy was faster than the checks IIRC. That said, it is very possible we could do a more inteligent mix of checks and copying. for example check after each MB that there is enough space left and only copy the last few of a slice to a seperate buffer. but then the max size we use is rather large so we need to calculate a tigher bound there first and hope this is smaller than the average slice Or maybe there are even other ways. Now if we do a check per MB and copy, we could do a step beyond this and also skip copy when unescaping is needed as long as we know the MB is completely before or after all escaped points in the bitstream maybe that complexity isnt worth it, maybe it is for some high bitrate files. We could also keep track of allocated sizes of the bitstream and allocate more from where it comes from or have per codec padding bitstream suggestions. Or maybe theres even some other trick like there exist for mpeg1/2/4ASP which avoids the whole need for checks that all said, this is of course not going to make a huge difference in speed, its just 1 copy of the compressed bitstream. but many use h264 ... all just a bunch of random ideas, i hope something of this helps ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, May 29, 2020 at 02:22:03PM +0100, Kieran Kunhya wrote: > On Fri, 29 May 2020 at 14:11, Michael Niedermayer > wrote: > > > On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > > > > > More generally though (outside this unsafe flag case) > > > > i do disagree with your argument a bit, performance does matter. > > > > Iam regularly reminded of that for example, so much software becomes > > > > slower on each upgrade with few if any features added the real users > > > > care about. Just to pick one, the editor i use to write replies in mutt > > > > is slower to close than before i upgraded the OS. > > > > > > > > Also again to stay general here, this does not apply to the unsafe > > flag. > > > > speed / cpu load does add up. Slower code means more CO2 emissions if > > > > the software is used alot. > > > > If you want a real example insetad of this flag where we could improve > > > > IIRC there was some code iterating over options in the iteration over > > > > options resulting in some sort of O(n^3) or so. Thats from memory > > though > > > > would need to check where that was exactly but thats something we > > should > > > > fix. > > > > > > > > > > Please provide evidence that the H.264 Decoder has got slower. > > > > while, what you quote above was not about h264 at all > > let me provide benchmarks of most fate h264 samples with and without > > flag_unsafe > > the script that made that is after it. a reply to the 2nd part of your > > mail is > > also below > > > > Yes, it's no surprise that a "fast" mode that violates the spec to produce > some undefined and unsafe output is going to be faster. this case does not violate the spec. The spec only describes a valid bitstream. for valid bitstreams the h264 fast_unsafe case here is just faster, same output. > The responses are "aggressive" because many people want "fast" mode gone. > > I also would like it gone and I think the consensus is there to remove it. This still doesnt explain the aggressive tone we have here. You know, one problem with this is when people are angry they do not think as clear as when they are calm and there is the risk that this leads to a different choice the same people would have picked had they looked at the problem calmly. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, 29 May 2020 at 14:11, Michael Niedermayer wrote: > On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > > > More generally though (outside this unsafe flag case) > > > i do disagree with your argument a bit, performance does matter. > > > Iam regularly reminded of that for example, so much software becomes > > > slower on each upgrade with few if any features added the real users > > > care about. Just to pick one, the editor i use to write replies in mutt > > > is slower to close than before i upgraded the OS. > > > > > > Also again to stay general here, this does not apply to the unsafe > flag. > > > speed / cpu load does add up. Slower code means more CO2 emissions if > > > the software is used alot. > > > If you want a real example insetad of this flag where we could improve > > > IIRC there was some code iterating over options in the iteration over > > > options resulting in some sort of O(n^3) or so. Thats from memory > though > > > would need to check where that was exactly but thats something we > should > > > fix. > > > > > > > Please provide evidence that the H.264 Decoder has got slower. > > while, what you quote above was not about h264 at all > let me provide benchmarks of most fate h264 samples with and without > flag_unsafe > the script that made that is after it. a reply to the 2nd part of your > mail is > also below > Yes, it's no surprise that a "fast" mode that violates the spec to produce some undefined and unsafe output is going to be faster. The responses are "aggressive" because many people want "fast" mode gone. I also would like it gone and I think the consensus is there to remove it. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 5/29/2020 10:10 AM, Michael Niedermayer wrote: > while, what you quote above was not about h264 at all > let me provide benchmarks of most fate h264 samples with and without > flag_unsafe > the script that made that is after it. a reply to the 2nd part of your mail is > also below > > > h264-444/444_10bit_cabac.h264 > 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips So the fast flag currently prevents ff_h2645_packet_split() from copying each NAL into a padded buffer (in the situations where there's are no emulation_prevention_three_byte to filter). Why is such padding needed to prevent overreads? cbs_h264 always calls ff_h2645_packet_split() with the small_padding argument as 1, and fuzzing has shown that it seemingly generated no issues whatsoever, so why can't the bitstream reading code in h264dec handle it safely? Or it could but it would be costly? And even if costly, wouldn't the the speedup gained in a normal run with no flags set (where most NALs would not be copied anymore to another buffer) offset the slowdown from the extra sanity checks? ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > More generally though (outside this unsafe flag case) > > i do disagree with your argument a bit, performance does matter. > > Iam regularly reminded of that for example, so much software becomes > > slower on each upgrade with few if any features added the real users > > care about. Just to pick one, the editor i use to write replies in mutt > > is slower to close than before i upgraded the OS. > > > > Also again to stay general here, this does not apply to the unsafe flag. > > speed / cpu load does add up. Slower code means more CO2 emissions if > > the software is used alot. > > If you want a real example insetad of this flag where we could improve > > IIRC there was some code iterating over options in the iteration over > > options resulting in some sort of O(n^3) or so. Thats from memory though > > would need to check where that was exactly but thats something we should > > fix. > > > > Please provide evidence that the H.264 Decoder has got slower. while, what you quote above was not about h264 at all let me provide benchmarks of most fate h264 samples with and without flag_unsafe the script that made that is after it. a reply to the 2nd part of your mail is also below h264-444/444_10bit_cabac.h264 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_10bit_cavlc.h264 1928995 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 676244 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_8bit_cabac.h264 1975800 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 01 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_8bit_cavlc.h264 1957577 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 719418 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_9bit_cabac.h264 1957739 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 633440 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_9bit_cavlc.h264 1943795 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 702884 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/i444_hybrid_+i8x8_+pcm.264 1668108 decicycles in ff_h2645_packet_split, 15 runs, 1 skips 399896 decicycles in ff_h2645_packet_split, 15 runs, 1 skips h264-444/old_i444_lossless_+i8x8_+pcm.264 1626002 decicycles in ff_h2645_packet_split, 15 runs, 1 skips 339882 decicycles in ff_h2645_packet_split, 15 runs, 1 skips h264/attachment631-small.mp4 110095 decicycles in ff_h2645_packet_split, 512 runs, 0 skips 39631 decicycles in ff_h2645_packet_split, 509 runs, 3 skips h264/bbc2.sample.h264 1270163 decicycles in ff_h2645_packet_split, 63 runs, 1 skips 696605 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/brokensps.flv 721112 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 218294 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/AUD_MW_E.264 674261 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 61366 decicycles in ff_h2645_packet_split, 48 runs, 16 skips h264-conformance/BA1_FT_C.264 219061 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 85335 decicycles in ff_h2645_packet_split, 255 runs, 1 skips h264-conformance/BA1_Sony_D.jsv 1529117 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 44400 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/BA2_Sony_F.jsv 26672 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 31297 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/BA3_SVA_C.264 1305464 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 19725 decicycles in ff_h2645_packet_split, 16 runs, 16 skips h264-conformance/BAMQ1_JVC_C.264 1519809 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 440427 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/BAMQ2_JVC_C.264 1426419 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 359686 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/BA_MW_D.264 671156 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 126140 decicycles in ff_h2645_packet_split, 63 runs, 1 skips h264-conformance/BANM_MW_D.264 657848 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 24498 decicycles in ff_h2645_packet_split, 47 runs, 17 skips h264-conformance/BASQP1_Sony_C.jsv 2208853 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 875512 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/CABA1_Sony_D.jsv 1312540 decicycles in ff_h2645_p
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
> > More generally though (outside this unsafe flag case) > i do disagree with your argument a bit, performance does matter. > Iam regularly reminded of that for example, so much software becomes > slower on each upgrade with few if any features added the real users > care about. Just to pick one, the editor i use to write replies in mutt > is slower to close than before i upgraded the OS. > > Also again to stay general here, this does not apply to the unsafe flag. > speed / cpu load does add up. Slower code means more CO2 emissions if > the software is used alot. > If you want a real example insetad of this flag where we could improve > IIRC there was some code iterating over options in the iteration over > options resulting in some sort of O(n^3) or so. Thats from memory though > would need to check where that was exactly but thats something we should > fix. > Please provide evidence that the H.264 Decoder has got slower. Surely by your argument all your fuzzing fixes need an #ifdef to turn them off to save CO2? Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
May 28, 2020, 17:20 by mich...@niedermayer.cc: > TODO: Bump > > */ > #define AV_CODEC_FLAG2_FAST (1 << 0) > + > +/** > + * Allow speedups tricks which can read out of array on non compliant > streams. > + */ > +#define AV_CODEC_FLAG2_FAST_UNSAFE(1 << 1) > That's a bug. We should absolutely not have flags to enable bugs. The fast flag should be removed from h264 until that bug is fixed, or deprecated altogether. ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Thu, May 28, 2020 at 08:30:16PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2020-05-28 20:09:15) > > > > h264 is a specific use of this flag, and that might not be the only > > place it could be used in > > > > But about h264 What this is about if i remember it correctly, is > > that the maximum input any crafted bitstream of a block can require is X, > > now you can if the input size is less than X copy that to a larger buffer or > > you can add lots of checks. Both of these slow the code down a bit. > > OTOH, if the stream is known to be valid that can be skipped. > > > > It can also be skiped if the buffer is already big enough to begin with > > OR if the output goes to the parser and not the decoder. > > So even without the user having access to this, the codepath does not > > become unneeded > > the h264 case is more a "even if you cant proof its safe on case 123 > > use it anyway" > > And quite possibly we can add more code detecting more cases where > > it is safe, this should be investigated either way probably. > > It does not seem to me that there is a sufficient use case for "decode > as fast as possible, even at the cost of crashing sometimes". Big > transcoders like youtube have process untrusted input and therefore care > about correctness. End-user playback is either fast enough or > hardware-accelerated (and thus fast enough). > > What kind of users do you believe warrants this extra complexity? The patch really was a response to kieran and jbs comments They asked this to be either fixed or warnings to be added / documented declaring the fast flag as unsafe would make it unusable for many usecases. And the specific feature can be removed / split to a different flag but not really "fixed". So this patch was born which moved it into a clearly documented new flag. Apparently that struck a nerve of some people, even though i asked about it before posting it. We can drop this patch and disable the one case, if thats what people want More generally though (outside this unsafe flag case) i do disagree with your argument a bit, performance does matter. Iam regularly reminded of that for example, so much software becomes slower on each upgrade with few if any features added the real users care about. Just to pick one, the editor i use to write replies in mutt is slower to close than before i upgraded the OS. Also again to stay general here, this does not apply to the unsafe flag. speed / cpu load does add up. Slower code means more CO2 emissions if the software is used alot. If you want a real example insetad of this flag where we could improve IIRC there was some code iterating over options in the iteration over options resulting in some sort of O(n^3) or so. Thats from memory though would need to check where that was exactly but thats something we should fix. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Thu, May 28, 2020 at 08:09:15PM +0200, Michael Niedermayer wrote: > On Thu, May 28, 2020 at 01:43:17PM -0300, James Almer wrote: > > On 5/28/2020 1:20 PM, Michael Niedermayer wrote: > > > TODO: Bump > > > > > > Signed-off-by: Michael Niedermayer > > > --- > > > doc/APIchanges | 3 +++ > > > doc/codecs.texi| 2 ++ > > > libavcodec/avcodec.h | 6 ++ > > > libavcodec/h264dec.c | 2 +- > > > libavcodec/options_table.h | 1 + > > > tools/target_dec_fuzzer.c | 2 +- > > > 6 files changed, 14 insertions(+), 2 deletions(-) > > > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > > index fb5534b5f5..3e20a44379 100644 > > > --- a/doc/APIchanges > > > +++ b/doc/APIchanges > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > > > > > API changes, most recent first: > > > > > > +2020-xx-xx - xx - lavc 58.xx.100 - avcodec.h > > > + Add AV_CODEC_FLAG2_FAST_UNSAFE > > > + > > > 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h > > >Move AVCodec-related public API to new header codec.h. > > > > > > diff --git a/doc/codecs.texi b/doc/codecs.texi > > > index c092aadc0e..46790b66b3 100644 > > > --- a/doc/codecs.texi > > > +++ b/doc/codecs.texi > > > @@ -787,6 +787,8 @@ Possible values: > > > @table @samp > > > @item fast > > > Allow non spec compliant speedup tricks. > > > +@item fast_unsafe > > > +Allow speedup tricks which can lead to out of array reads and crashes on > > > damaged or crafted files. > > > > This will raise more than a couple eyebrows. Having an option to enable > > what people will consider security issues is not a good idea at all. For > > starters, it acknowledges lavc is not secure and has known issues that > > are purposely not being fixed. > > now, thats not what this was intended to do, of course. > the idea is more > > A user can have a stream that is known to be valid, quite possibly > the users own stream, or otherwise "in house" made or already checked > to be valid. > > In that case any code that is only needed for invalid streams becomes > unneeded. > > > > And on top of it, this can't be outright > > disabled/removed at compile time, so something could still call > > ffmpeg/lavc with it enabled. > > well, yes, but thats not the only such case > we have other options to enable unsafe behavior Also if people dont want a "fast_unsafe" flag we surely can just drop this patch, and set the value to 0 where it otherwise would be used thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
Quoting Michael Niedermayer (2020-05-28 20:09:15) > > h264 is a specific use of this flag, and that might not be the only > place it could be used in > > But about h264 What this is about if i remember it correctly, is > that the maximum input any crafted bitstream of a block can require is X, > now you can if the input size is less than X copy that to a larger buffer or > you can add lots of checks. Both of these slow the code down a bit. > OTOH, if the stream is known to be valid that can be skipped. > > It can also be skiped if the buffer is already big enough to begin with > OR if the output goes to the parser and not the decoder. > So even without the user having access to this, the codepath does not > become unneeded > the h264 case is more a "even if you cant proof its safe on case 123 > use it anyway" > And quite possibly we can add more code detecting more cases where > it is safe, this should be investigated either way probably. It does not seem to me that there is a sufficient use case for "decode as fast as possible, even at the cost of crashing sometimes". Big transcoders like youtube have process untrusted input and therefore care about correctness. End-user playback is either fast enough or hardware-accelerated (and thus fast enough). What kind of users do you believe warrants this extra complexity? -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
Quoting Lynne (2020-05-28 18:26:44) > May 28, 2020, 17:20 by mich...@niedermayer.cc: > > > TODO: Bump > > > > */ > > #define AV_CODEC_FLAG2_FAST (1 << 0) > > + > > +/** > > + * Allow speedups tricks which can read out of array on non compliant > > streams. > > + */ > > +#define AV_CODEC_FLAG2_FAST_UNSAFE(1 << 1) > > > > That's a bug. We should absolutely not have flags to enable bugs. > The fast flag should be removed from h264 until that bug is fixed, > or deprecated altogether. +9001 -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Thu, May 28, 2020 at 01:43:17PM -0300, James Almer wrote: > On 5/28/2020 1:20 PM, Michael Niedermayer wrote: > > TODO: Bump > > > > Signed-off-by: Michael Niedermayer > > --- > > doc/APIchanges | 3 +++ > > doc/codecs.texi| 2 ++ > > libavcodec/avcodec.h | 6 ++ > > libavcodec/h264dec.c | 2 +- > > libavcodec/options_table.h | 1 + > > tools/target_dec_fuzzer.c | 2 +- > > 6 files changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index fb5534b5f5..3e20a44379 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > > > API changes, most recent first: > > > > +2020-xx-xx - xx - lavc 58.xx.100 - avcodec.h > > + Add AV_CODEC_FLAG2_FAST_UNSAFE > > + > > 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h > >Move AVCodec-related public API to new header codec.h. > > > > diff --git a/doc/codecs.texi b/doc/codecs.texi > > index c092aadc0e..46790b66b3 100644 > > --- a/doc/codecs.texi > > +++ b/doc/codecs.texi > > @@ -787,6 +787,8 @@ Possible values: > > @table @samp > > @item fast > > Allow non spec compliant speedup tricks. > > +@item fast_unsafe > > +Allow speedup tricks which can lead to out of array reads and crashes on > > damaged or crafted files. > > This will raise more than a couple eyebrows. Having an option to enable > what people will consider security issues is not a good idea at all. For > starters, it acknowledges lavc is not secure and has known issues that > are purposely not being fixed. now, thats not what this was intended to do, of course. the idea is more A user can have a stream that is known to be valid, quite possibly the users own stream, or otherwise "in house" made or already checked to be valid. In that case any code that is only needed for invalid streams becomes unneeded. > And on top of it, this can't be outright > disabled/removed at compile time, so something could still call > ffmpeg/lavc with it enabled. well, yes, but thats not the only such case we have other options to enable unsafe behavior > > The issues should be fixed, or the relevant "fast" codepath in the > decoder removed for being buggy. h264 is a specific use of this flag, and that might not be the only place it could be used in But about h264 What this is about if i remember it correctly, is that the maximum input any crafted bitstream of a block can require is X, now you can if the input size is less than X copy that to a larger buffer or you can add lots of checks. Both of these slow the code down a bit. OTOH, if the stream is known to be valid that can be skipped. It can also be skiped if the buffer is already big enough to begin with OR if the output goes to the parser and not the decoder. So even without the user having access to this, the codepath does not become unneeded the h264 case is more a "even if you cant proof its safe on case 123 use it anyway" And quite possibly we can add more code detecting more cases where it is safe, this should be investigated either way probably. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 5/28/2020 1:20 PM, Michael Niedermayer wrote:
> TODO: Bump
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/APIchanges | 3 +++
> doc/codecs.texi| 2 ++
> libavcodec/avcodec.h | 6 ++
> libavcodec/h264dec.c | 2 +-
> libavcodec/options_table.h | 1 +
> tools/target_dec_fuzzer.c | 2 +-
> 6 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index fb5534b5f5..3e20a44379 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2020-xx-xx - xx - lavc 58.xx.100 - avcodec.h
> + Add AV_CODEC_FLAG2_FAST_UNSAFE
> +
> 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h
>Move AVCodec-related public API to new header codec.h.
>
> diff --git a/doc/codecs.texi b/doc/codecs.texi
> index c092aadc0e..46790b66b3 100644
> --- a/doc/codecs.texi
> +++ b/doc/codecs.texi
> @@ -787,6 +787,8 @@ Possible values:
> @table @samp
> @item fast
> Allow non spec compliant speedup tricks.
> +@item fast_unsafe
> +Allow speedup tricks which can lead to out of array reads and crashes on
> damaged or crafted files.
This will raise more than a couple eyebrows. Having an option to enable
what people will consider security issues is not a good idea at all. For
starters, it acknowledges lavc is not secure and has known issues that
are purposely not being fixed. And on top of it, this can't be outright
disabled/removed at compile time, so something could still call
ffmpeg/lavc with it enabled.
The issues should be fixed, or the relevant "fast" codepath in the
decoder removed for being buggy.
> @item noout
> Skip bitstream encoding.
> @item ignorecrop
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 01099bc8cd..479f219b43 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -346,6 +346,12 @@ typedef struct RcOverride{
> * Allow non spec compliant speedup tricks.
> */
> #define AV_CODEC_FLAG2_FAST (1 << 0)
> +
> +/**
> + * Allow speedups tricks which can read out of array on non compliant
> streams.
> + */
> +#define AV_CODEC_FLAG2_FAST_UNSAFE(1 << 1)
> +
> /**
> * Skip bitstream encoding.
> */
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index e463fde2a5..b764caa942 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -603,7 +603,7 @@ static int decode_nal_units(H264Context *h, const uint8_t
> *buf, int buf_size)
> }
>
> ret = ff_h2645_packet_split(&h->pkt, buf, buf_size, avctx, h->is_avc,
> h->nal_length_size,
> -avctx->codec_id, avctx->flags2 &
> AV_CODEC_FLAG2_FAST, 0);
> +avctx->codec_id, avctx->flags2 &
> AV_CODEC_FLAG2_FAST_UNSAFE, 0);
> if (ret < 0) {
> av_log(avctx, AV_LOG_ERROR,
> "Error splitting the input into NAL units.\n");
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 8ba137f51e..4e26b844f6 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -71,6 +71,7 @@ static const AVOption avcodec_options[] = {
> {"drop_changed", "Drop frames whose parameters differ from first decoded
> frame", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG_DROPCHANGED }, INT_MIN,
> INT_MAX, A|V|D, "flags"},
> {"flags2", NULL, OFFSET(flags2), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT}, 0,
> UINT_MAX, V|A|E|D|S, "flags2"},
> {"fast", "allow non-spec-compliant speedup tricks", 0, AV_OPT_TYPE_CONST,
> {.i64 = AV_CODEC_FLAG2_FAST }, INT_MIN, INT_MAX, V|E, "flags2"},
> +{"fast_unsafe", "allow speedup tricks which can read out of arrays", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_FAST_UNSAFE }, INT_MIN, INT_MAX,
> V|E, "flags2"},
> {"noout", "skip bitstream encoding", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_CODEC_FLAG2_NO_OUTPUT }, INT_MIN, INT_MAX, V|E, "flags2"},
> {"ignorecrop", "ignore cropping information from sps", 0, AV_OPT_TYPE_CONST,
> {.i64 = AV_CODEC_FLAG2_IGNORE_CROP }, INT_MIN, INT_MAX, V|D, "flags2"},
> {"local_header", "place global headers at every keyframe instead of in
> extradata", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_LOCAL_HEADER },
> INT_MIN, INT_MAX, V|E, "flags2"},
> diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> index d01deaf8d5..414cdab593 100644
> --- a/tools/target_dec_fuzzer.c
> +++ b/tools/target_dec_fuzzer.c
> @@ -208,7 +208,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
> size) {
> if (flags & 8)
> ctx->err_recognition |= AV_EF_EXPLODE;
> }
> -if ((flags & 0x10) && c->id != AV_CODEC_ID_H264)
> +if (flags & 0x10)
> ctx->flags2 |= AV_CODEC_FLAG2_FAST;
>
> if (flags & 0x40)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
[FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
TODO: Bump
Signed-off-by: Michael Niedermayer
---
doc/APIchanges | 3 +++
doc/codecs.texi| 2 ++
libavcodec/avcodec.h | 6 ++
libavcodec/h264dec.c | 2 +-
libavcodec/options_table.h | 1 +
tools/target_dec_fuzzer.c | 2 +-
6 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index fb5534b5f5..3e20a44379 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-xx-xx - xx - lavc 58.xx.100 - avcodec.h
+ Add AV_CODEC_FLAG2_FAST_UNSAFE
+
2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h
Move AVCodec-related public API to new header codec.h.
diff --git a/doc/codecs.texi b/doc/codecs.texi
index c092aadc0e..46790b66b3 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -787,6 +787,8 @@ Possible values:
@table @samp
@item fast
Allow non spec compliant speedup tricks.
+@item fast_unsafe
+Allow speedup tricks which can lead to out of array reads and crashes on
damaged or crafted files.
@item noout
Skip bitstream encoding.
@item ignorecrop
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 01099bc8cd..479f219b43 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -346,6 +346,12 @@ typedef struct RcOverride{
* Allow non spec compliant speedup tricks.
*/
#define AV_CODEC_FLAG2_FAST (1 << 0)
+
+/**
+ * Allow speedups tricks which can read out of array on non compliant streams.
+ */
+#define AV_CODEC_FLAG2_FAST_UNSAFE(1 << 1)
+
/**
* Skip bitstream encoding.
*/
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index e463fde2a5..b764caa942 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -603,7 +603,7 @@ static int decode_nal_units(H264Context *h, const uint8_t
*buf, int buf_size)
}
ret = ff_h2645_packet_split(&h->pkt, buf, buf_size, avctx, h->is_avc,
h->nal_length_size,
-avctx->codec_id, avctx->flags2 &
AV_CODEC_FLAG2_FAST, 0);
+avctx->codec_id, avctx->flags2 &
AV_CODEC_FLAG2_FAST_UNSAFE, 0);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR,
"Error splitting the input into NAL units.\n");
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 8ba137f51e..4e26b844f6 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -71,6 +71,7 @@ static const AVOption avcodec_options[] = {
{"drop_changed", "Drop frames whose parameters differ from first decoded
frame", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG_DROPCHANGED }, INT_MIN,
INT_MAX, A|V|D, "flags"},
{"flags2", NULL, OFFSET(flags2), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT}, 0,
UINT_MAX, V|A|E|D|S, "flags2"},
{"fast", "allow non-spec-compliant speedup tricks", 0, AV_OPT_TYPE_CONST,
{.i64 = AV_CODEC_FLAG2_FAST }, INT_MIN, INT_MAX, V|E, "flags2"},
+{"fast_unsafe", "allow speedup tricks which can read out of arrays", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_FAST_UNSAFE }, INT_MIN, INT_MAX, V|E,
"flags2"},
{"noout", "skip bitstream encoding", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_CODEC_FLAG2_NO_OUTPUT }, INT_MIN, INT_MAX, V|E, "flags2"},
{"ignorecrop", "ignore cropping information from sps", 0, AV_OPT_TYPE_CONST,
{.i64 = AV_CODEC_FLAG2_IGNORE_CROP }, INT_MIN, INT_MAX, V|D, "flags2"},
{"local_header", "place global headers at every keyframe instead of in
extradata", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_LOCAL_HEADER },
INT_MIN, INT_MAX, V|E, "flags2"},
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index d01deaf8d5..414cdab593 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -208,7 +208,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
if (flags & 8)
ctx->err_recognition |= AV_EF_EXPLODE;
}
-if ((flags & 0x10) && c->id != AV_CODEC_ID_H264)
+if (flags & 0x10)
ctx->flags2 |= AV_CODEC_FLAG2_FAST;
if (flags & 0x40)
--
2.17.1
___
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".
