| Message ID | 20200528162056.23537-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it | expand |
| Context | Check | Description |
|---|---|---|
| andriy/default | pending | |
| andriy/make | success | Make finished |
| andriy/make_fate | success | Make fate finished |
May 28, 2020, 17:20 by michael@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.
On 5/28/2020 1:20 PM, Michael Niedermayer wrote: > TODO: Bump > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > 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 - xxxxxxxxxx - lavc 58.xx.100 - avcodec.h > + Add AV_CODEC_FLAG2_FAST_UNSAFE > + > 2020-xx-xx - xxxxxxxxxx - 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) >
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 <michael@niedermayer.cc> > > --- > > 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 - xxxxxxxxxx - lavc 58.xx.100 - avcodec.h > > + Add AV_CODEC_FLAG2_FAST_UNSAFE > > + > > 2020-xx-xx - xxxxxxxxxx - 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 [...]
Quoting Lynne (2020-05-28 18:26:44) > May 28, 2020, 17:20 by michael@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
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?
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 <michael@niedermayer.cc> > > > --- > > > 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 - xxxxxxxxxx - lavc 58.xx.100 - avcodec.h > > > + Add AV_CODEC_FLAG2_FAST_UNSAFE > > > + > > > 2020-xx-xx - xxxxxxxxxx - 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 [...]
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 [...]
> > 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
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 666601 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_packet_split, 32 runs, 0 skips 40815 decicycles in ff_h2645_packet_split, 16 runs, 16 skips h264-conformance/CABA1_SVA_B.264 1527961 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 220576 decicycles in ff_h2645_packet_split, 13 runs, 3 skips h264-conformance/CABA2_Sony_E.jsv 185679 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 31258 decicycles in ff_h2645_packet_split, 239 runs, 17 skips h264-conformance/CABA2_SVA_B.264 1581796 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 27168 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/CABA3_Sony_C.jsv 32413 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 29444 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/CABA3_SVA_B.264 1199786 decicycles in ff_h2645_packet_split, 30 runs, 2 skips 185816 decicycles in ff_h2645_packet_split, 29 runs, 3 skips h264-conformance/CABA3_TOSHIBA_E.264 69091 decicycles in ff_h2645_packet_split, 243 runs, 13 skips 34225 decicycles in ff_h2645_packet_split, 239 runs, 17 skips h264-conformance/CABACI3_Sony_B.jsv 44182 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 43256 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/CABAST3_Sony_E.jsv 1661901 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 527666 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CABASTBR3_Sony_B.jsv 1609475 decicycles in ff_h2645_packet_split, 30 runs, 2 skips 528498 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CABREF3_Sand_D.264 91351 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 62729 decicycles in ff_h2645_packet_split, 52 runs, 12 skips h264-conformance/CACQP3_Sony_D.jsv 135743 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 24395 decicycles in ff_h2645_packet_split, 15 runs, 17 skips h264-conformance/CAFI1_SVA_C.264 102883 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 117318 decicycles in ff_h2645_packet_split, 52 runs, 12 skips h264-conformance/CAMA1_Sony_C.jsv 1864106 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 822695 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/CAMA1_TOSHIBA_B.264 935579 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 294390 decicycles in ff_h2645_packet_split, 63 runs, 1 skips h264-conformance/cama1_vtc_c.avc 1596550 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 446127 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/cama2_vtc_b.avc 1727483 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 629693 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/CAMA3_Sand_E.264 1434270 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 271520 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/cama3_vtc_b.avc 1800003 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 671966 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/CAMACI3_Sony_C.jsv 250590 decicycles in ff_h2645_packet_split, 11 runs, 5 skips 45072 decicycles in ff_h2645_packet_split, 11 runs, 5 skips h264-conformance/CAMANL1_TOSHIBA_B.264 964067 decicycles in ff_h2645_packet_split, 63 runs, 1 skips 318552 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CAMANL2_TOSHIBA_B.264 950036 decicycles in ff_h2645_packet_split, 63 runs, 1 skips 299665 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CAMANL3_Sand_E.264 1446538 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 281052 decicycles in ff_h2645_packet_split, 30 runs, 2 skips h264-conformance/CAMASL3_Sony_B.jsv 276120 decicycles in ff_h2645_packet_split, 11 runs, 5 skips 122963 decicycles in ff_h2645_packet_split, 12 runs, 4 skips h264-conformance/camp_mot_fld0_full.26l 112387 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 180032 decicycles in ff_h2645_packet_split, 61 runs, 3 skips h264-conformance/camp_mot_frm0_full.26l 1589242 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 358720 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/camp_mot_mbaff0_full.26l 1533835 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 381529 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CAMP_MOT_MBAFF_L30.26l 1571424 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 458106 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CAMP_MOT_MBAFF_L31.26l 1453192 decicycles in ff_h2645_packet_split, 31 runs, 1 skips 404548 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/camp_mot_picaff0_full.26l 1368484 decicycles in ff_h2645_packet_split, 28 runs, 4 skips 307458 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CANL1_Sony_E.jsv 1353679 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 56849 decicycles in ff_h2645_packet_split, 17 runs, 15 skips h264-conformance/CANL1_SVA_B.264 1536517 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 34727 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/CANL1_TOSHIBA_G.264 200285 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 30096 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/CANL2_Sony_E.jsv 178856 decicycles in ff_h2645_packet_split, 255 runs, 1 skips 33402 decicycles in ff_h2645_packet_split, 239 runs, 17 skips h264-conformance/CANL2_SVA_B.264 1586214 decicycles in ff_h2645_packet_split, 15 runs, 1 skips 33987 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/CANL3_Sony_C.jsv 32458 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 28836 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/CANL3_SVA_B.264 1549698 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 28014 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/CANL4_SVA_B.264 1175757 decicycles in ff_h2645_packet_split, 29 runs, 3 skips 20128 decicycles in ff_h2645_packet_split, 15 runs, 17 skips h264-conformance/CANLMA2_Sony_C.jsv 2019460 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 632168 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-conformance/CANLMA3_Sony_C.jsv 1974019 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 604950 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-conformance/CAPA1_TOSHIBA_B.264 103028 decicycles in ff_h2645_packet_split, 110 runs, 18 skips 149465 decicycles in ff_h2645_packet_split, 126 runs, 2 skips h264-conformance/CAPAMA3_Sand_F.264 101618 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 151015 decicycles in ff_h2645_packet_split, 60 runs, 4 skips h264-conformance/CAPCM1_Sand_E.264 1828713 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 709833 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CAPCMNL1_Sand_E.264 1857284 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 669630 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CAPM3_Sony_D.jsv 231427 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 57398 decicycles in ff_h2645_packet_split, 244 runs, 12 skips h264-conformance/CAQP1_Sony_B.jsv 1412382 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 137085 decicycles in ff_h2645_packet_split, 20 runs, 12 skips h264-conformance/CAWP1_TOSHIBA_E.264 998381 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 307123 decicycles in ff_h2645_packet_split, 63 runs, 1 skips h264-conformance/CAWP5_TOSHIBA_E.264 977383 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 317945 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CI1_FT_B.264 214776 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 81378 decicycles in ff_h2645_packet_split, 255 runs, 1 skips h264-conformance/CI_MW_D.264 685361 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 28049 decicycles in ff_h2645_packet_split, 47 runs, 17 skips h264-conformance/CVBS3_Sony_C.jsv 29222 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 27742 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/CVCANLMA2_Sony_C.jsv 2164268 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 768374 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-conformance/CVFC1_Sony_C.jsv 1606482 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 422540 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CVFI1_Sony_D.jsv 330340 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 550333 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CVFI1_SVA_C.264 234738 decicycles in ff_h2645_packet_split, 14 runs, 2 skips 50584 decicycles in ff_h2645_packet_split, 14 runs, 2 skips h264-conformance/CVFI2_Sony_H.jsv 282024 decicycles in ff_h2645_packet_split, 22 runs, 10 skips 400757 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CVFI2_SVA_C.264 195915 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 166644 decicycles in ff_h2645_packet_split, 23 runs, 9 skips h264-conformance/CVMA1_Sony_D.jsv 1943008 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 930226 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/CVMA1_TOSHIBA_B.264 1028559 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 341695 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CVMANL1_TOSHIBA_B.264 992178 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 352933 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CVMANL2_TOSHIBA_B.264 967943 decicycles in ff_h2645_packet_split, 63 runs, 1 skips 332664 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CVMAPAQP3_Sony_E.jsv 1720523 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 1071011 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-conformance/CVMAQP2_Sony_G.jsv 1733796 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 460118 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-conformance/CVMAQP3_Sony_D.jsv 1190498 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 346528 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-conformance/cvmp_mot_fld0_full_B.26l 111578 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 181700 decicycles in ff_h2645_packet_split, 61 runs, 3 skips h264-conformance/CVMP_MOT_FLD_L30_B.26l 122439 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 184230 decicycles in ff_h2645_packet_split, 62 runs, 2 skips h264-conformance/cvmp_mot_frm0_full_B.26l 1569586 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 452718 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CVMP_MOT_FRM_L31_B.26l 123587 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 175141 decicycles in ff_h2645_packet_split, 62 runs, 2 skips h264-conformance/cvmp_mot_mbaff0_full_B.26l 1730998 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 459586 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/cvmp_mot_picaff0_full_B.26l 1301385 decicycles in ff_h2645_packet_split, 27 runs, 5 skips 360403 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CVNLFI1_Sony_C.jsv 1670167 decicycles in ff_h2645_packet_split, 29 runs, 3 skips 582865 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CVNLFI2_Sony_H.jsv 291475 decicycles in ff_h2645_packet_split, 22 runs, 10 skips 398549 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/CVPA1_TOSHIBA_B.264 110603 decicycles in ff_h2645_packet_split, 110 runs, 18 skips 159631 decicycles in ff_h2645_packet_split, 126 runs, 2 skips h264-conformance/CVPCMNL1_SVA_C.264 2437351 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 1239176 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/CVPCMNL2_SVA_C.264 12280947 decicycles in ff_h2645_packet_split, 4 runs, 0 skips 8682327 decicycles in ff_h2645_packet_split, 4 runs, 0 skips h264-conformance/CVSE2_Sony_B.jsv 172218 decicycles in ff_h2645_packet_split, 254 runs, 2 skips 33944 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/CVSE3_Sony_H.jsv 194504 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 61820 decicycles in ff_h2645_packet_split, 256 runs, 0 skips h264-conformance/CVSEFDFT3_Sony_E.jsv 353777 decicycles in ff_h2645_packet_split, 128 runs, 0 skips 100541 decicycles in ff_h2645_packet_split, 128 runs, 0 skips h264-conformance/CVWP1_TOSHIBA_E.264 1151376 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 583380 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CVWP2_TOSHIBA_E.264 1144808 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 492892 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/CVWP3_TOSHIBA_E.264 879854 decicycles in ff_h2645_packet_split, 63 runs, 1 skips 261131 decicycles in ff_h2645_packet_split, 63 runs, 1 skips h264-conformance/CVWP5_TOSHIBA_E.264 1111352 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 513213 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/FI1_Sony_E.jsv 178247 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 53626 decicycles in ff_h2645_packet_split, 16 runs, 16 skips h264-conformance/FM1_BT_B.h264 31911 decicycles in ff_h2645_packet_split, 489 runs, 23 skips 22116 decicycles in ff_h2645_packet_split, 468 runs, 44 skips h264-conformance/FM1_FT_E.264 211798 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 74783 decicycles in ff_h2645_packet_split, 255 runs, 1 skips h264-conformance/FM2_SVA_B.264 53272 decicycles in ff_h2645_packet_split, 48 runs, 16 skips 14961 decicycles in ff_h2645_packet_split, 48 runs, 16 skips h264-conformance/FM2_SVA_C.264 47780 decicycles in ff_h2645_packet_split, 51 runs, 13 skips 8734 decicycles in ff_h2645_packet_split, 51 runs, 13 skips h264-conformance/FRext h264-conformance/HCBP1_HHI_A.264 63701 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 73250 decicycles in ff_h2645_packet_split, 243 runs, 13 skips h264-conformance/HCBP2_HHI_A.264 32143 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 18471 decicycles in ff_h2645_packet_split, 237 runs, 19 skips h264-conformance/HCMP1_HHI_A.264 27728 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 19438 decicycles in ff_h2645_packet_split, 237 runs, 19 skips h264-conformance/LS_SVA_D.264 51500 decicycles in ff_h2645_packet_split, 1024 runs, 0 skips 9417 decicycles in ff_h2645_packet_split, 988 runs, 36 skips h264-conformance/md5sum h264-conformance/MIDR_MW_D.264 684476 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 32791 decicycles in ff_h2645_packet_split, 48 runs, 16 skips h264-conformance/MPS_MW_A.264 347083 decicycles in ff_h2645_packet_split, 128 runs, 0 skips 58146 decicycles in ff_h2645_packet_split, 112 runs, 16 skips h264-conformance/MR1_BT_A.h264 790794 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 228170 decicycles in ff_h2645_packet_split, 62 runs, 2 skips h264-conformance/MR1_MW_A.264 350335 decicycles in ff_h2645_packet_split, 128 runs, 0 skips 58212 decicycles in ff_h2645_packet_split, 112 runs, 16 skips h264-conformance/MR2_MW_A.264 185872 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 46592 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/MR2_TANDBERG_E.264 185592 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 53605 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/MR3_TANDBERG_B.264 182223 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 47114 decicycles in ff_h2645_packet_split, 238 runs, 18 skips h264-conformance/MR4_TANDBERG_C.264 36084 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 57664 decicycles in ff_h2645_packet_split, 227 runs, 29 skips h264-conformance/MR5_TANDBERG_C.264 37496 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 49987 decicycles in ff_h2645_packet_split, 218 runs, 38 skips h264-conformance/MR6_BT_B.h264 41555 decicycles in ff_h2645_packet_split, 112 runs, 16 skips 32532 decicycles in ff_h2645_packet_split, 107 runs, 21 skips h264-conformance/MR7_BT_B.h264 666335 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 86017 decicycles in ff_h2645_packet_split, 48 runs, 16 skips h264-conformance/MR8_BT_B.h264 670567 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 139160 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/MR9_BT_B.h264 674932 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 175709 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/NL1_Sony_D.jsv 1565076 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 44030 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/NL2_Sony_H.jsv 25847 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 26048 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/NL3_SVA_E.264 1276440 decicycles in ff_h2645_packet_split, 31 runs, 1 skips 20997 decicycles in ff_h2645_packet_split, 16 runs, 16 skips h264-conformance/NLMQ1_JVC_C.264 1538332 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 446740 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/NLMQ2_JVC_C.264 1430466 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 398663 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/NRF_MW_E.264 651153 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 34457 decicycles in ff_h2645_packet_split, 47 runs, 17 skips h264-conformance/Sharp_MP_Field_1_B.jvt 236013 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 295033 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/Sharp_MP_Field_2_B.jvt 200886 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 256989 decicycles in ff_h2645_packet_split, 30 runs, 2 skips h264-conformance/Sharp_MP_Field_3_B.jvt 201950 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 201934 decicycles in ff_h2645_packet_split, 26 runs, 6 skips h264-conformance/Sharp_MP_PAFF_1r2.jvt 209420 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 263644 decicycles in ff_h2645_packet_split, 29 runs, 3 skips h264-conformance/Sharp_MP_PAFF_2.jvt 210992 decicycles in ff_h2645_packet_split, 16 runs, 16 skips 278645 decicycles in ff_h2645_packet_split, 31 runs, 1 skips h264-conformance/SL1_SVA_B.264 1332584 decicycles in ff_h2645_packet_split, 31 runs, 1 skips 45255 decicycles in ff_h2645_packet_split, 16 runs, 16 skips h264-conformance/sp1_bt_a.h264 180802 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 34733 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/sp2_bt_b.h264 179929 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 25039 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/src19td.IBP.264 481307 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 358053 decicycles in ff_h2645_packet_split, 256 runs, 0 skips h264-conformance/SVA_BA1_B.264 1564498 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 37211 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/SVA_BA2_D.264 1518063 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 30498 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/SVA_Base_B.264 1482220 decicycles in ff_h2645_packet_split, 15 runs, 1 skips 46778 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/SVA_CL1_E.264 1370722 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 144232 decicycles in ff_h2645_packet_split, 22 runs, 10 skips h264-conformance/SVA_FM1_E.264 1580015 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 44717 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/SVA_NL1_B.264 1534482 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 33194 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/SVA_NL2_E.264 1545836 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 34145 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264/crew_cif.nal 246509 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 127784 decicycles in ff_h2645_packet_split, 255 runs, 1 skips h264/crew_cif_timecode-2.h264 250501 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 130439 decicycles in ff_h2645_packet_split, 256 runs, 0 skips h264/crop-to-container-dims-canon.mov 17211845 decicycles in ff_h2645_packet_split, 2 runs, 0 skips 15828600 decicycles in ff_h2645_packet_split, 2 runs, 0 skips h264/direct-bff.mkv 3979072 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 1705145 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264/dts_5frames.mkv 1389257 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 192664 decicycles in ff_h2645_packet_split, 7 runs, 1 skips h264/extradata-reload-multi-stsd.mov 2386037 decicycles in ff_h2645_packet_split, 4 runs, 0 skips 346690 decicycles in ff_h2645_packet_split, 4 runs, 0 skips h264/extreme-plane-pred.h264 1270990 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 647713 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/h264_3bf_nopyramid_nobsrestriction.mp4 2577766 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 409220 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264/h264_3bf_pyramid_nobsrestriction.mp4 2599990 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 435328 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264/h264_4bf_pyramid_nobsrestriction.mp4 2411590 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 432853 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264/h264_intra_first-small.ts 232407 decicycles in ff_h2645_packet_split, 47 runs, 17 skips 350875 decicycles in ff_h2645_packet_split, 61 runs, 3 skips h264/H264_might_overflow.mkv 5985027 decicycles in ff_h2645_packet_split, 4 runs, 0 skips 3699352 decicycles in ff_h2645_packet_split, 4 runs, 0 skips h264/h264refframeregression.mp4 1329841 decicycles in ff_h2645_packet_split, 127 runs, 1 skips 628778 decicycles in ff_h2645_packet_split, 127 runs, 1 skips h264-high-depth/high-qp.mkv 2528950 decicycles in ff_h2645_packet_split, 4 runs, 0 skips 371110 decicycles in ff_h2645_packet_split, 4 runs, 0 skips h264-high-depth/lossless.h264 2426691 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 1364513 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-high-depth/normal-10.h264 2547542 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 511108 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-high-depth/normal-9.h264 2577050 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 512773 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264/interlaced_crop.mp4 882461 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 247599 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/intra_refresh.h264 198782 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 68662 decicycles in ff_h2645_packet_split, 254 runs, 2 skips h264/lossless.h264 2639348 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 1261838 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264/mixed-nal-coding.mp4 2655027 decicycles in ff_h2645_packet_split, 4 runs, 0 skips 612627 decicycles in ff_h2645_packet_split, 4 runs, 0 skips h264/nondeterministic_cut.h264 1476542 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 337509 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264/ref_10.avi 1493100 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 262980 decicycles in ff_h2645_packet_split, 29 runs, 3 skips h264/ref-pic-mod-overflow.h264 2673481 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 461852 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264/reinit-large_420_8-to-small_420_8.h264 818810 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 184433 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/reinit-small_420_8-to-large_444_10.h264 728136 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 185104 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/reinit-small_420_9-to-small_420_8.h264 740219 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 167078 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/reinit-small_422_9-to-small_420_9.h264 765333 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 168448 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/sei-1.h264 2528580 decicycles in ff_h2645_packet_split, 4 runs, 0 skips 512727 decicycles in ff_h2645_packet_split, 4 runs, 0 skips h264/SonyXAVC_LongGOP_green_pixelation_early_Frames.MXF 6379678 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 4213560 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264/test-4867.flv 256106 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 107298 decicycles in ff_h2645_packet_split, 256 runs, 0 skips h264/thezerotheorem-cut.mp4 2788204 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 1423158 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264/twofields_packet.mp4 1433591 decicycles in ff_h2645_packet_split, 128 runs, 0 skips5.12x 739566 decicycles in ff_h2645_packet_split, 128 runs, 0 skips5.22x h264/unescaped_extradata.mp4 71028 decicycles in ff_h2645_packet_split, 1024 runs, 0 skips 31314 decicycles in ff_h2645_packet_split, 1004 runs, 20 skips h264/wwwq_cut.mp4 1041260 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 434873 decicycles in ff_h2645_packet_split, 63 runs, 1 skips >>>>>>>> #!/bin/bash for f in h264*/* ; do echo $f ./ffmpeg -an -i $f -f null - >& /dev/null ./ffmpeg -an -i $f -f null - 2>&1 | grep deci | tail -1 ./ffmpeg -an -flags2 fast_unsafe -i $f -f null - 2>&1 | grep deci | tail -1 done <<<<<<<< >>>>>>>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c index b764caa942..9c5ea8bfa3 100644 --- a/libavcodec/h264dec.c +++ b/libavcodec/h264dec.c @@ -601,9 +601,10 @@ static int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size) }else if(buf_size > 3 && AV_RB32(buf) > 1 && AV_RB32(buf) <= (unsigned)buf_size) h->is_avc = 1; } - +{START_TIMER 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_UNSAFE, 0); +STOP_TIMER("ff_h2645_packet_split");} if (ret < 0) { av_log(avctx, AV_LOG_ERROR, "Error splitting the input into NAL units.\n"); <<<<<<<< > Surely by your argument all your fuzzing fixes need an #ifdef to turn them > off to save CO2? many of the undefined behavior fixes make no difference in the resulting machiene code, these thus cannot be slower. many more are in speed irrelevant code pathes What is in speed relevant code and does slow it down could be also switched off by fast_unsafe, if such a flag is added. That will reduce CO2 produced, likely by a very small amount only though I do notice though that the replies in this thread are a bit "aggressive" iam not sure why, we can add fast_unsafe and connect it to cases where it fits or we can leave it and always go with the safe and slow. being angry isnt going to really make us choose a better solution i fear. iam not advocating one side here, just wanting to fix the issue that the fast flag without any warnings enables unsafe behavior <-- this is bad we can disable all this here and in the future or we can connect it to a new flag (fast_unsafe) where its known from day 1 that unsafe. I dont think adding a warning to a long existing flag is good Thanks [...]
On Fri, 29 May 2020 at 14:11, Michael Niedermayer <michael@niedermayer.cc> 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
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?
On Fri, May 29, 2020 at 02:22:03PM +0100, Kieran Kunhya wrote: > On Fri, 29 May 2020 at 14:11, Michael Niedermayer <michael@niedermayer.cc> > 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 [...]
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 [...]
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. 10000% 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
On 5/29/20, Jean-Baptiste Kempf <jb@videolan.org> 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. > > 10000% 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-request@ffmpeg.org with subject "unsubscribe".
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
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.
On Mon, 1 Jun 2020 at 14:02, Anton Khirnov <anton@khirnov.net> 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
On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote: > On Mon, 1 Jun 2020 at 14:02, Anton Khirnov <anton@khirnov.net> 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 [...]
On 6/2/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote: >> On Mon, 1 Jun 2020 at 14:02, Anton Khirnov <anton@khirnov.net> 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. >
On 6/2/2020 3:45 AM, Paul B Mahol wrote: > On 6/2/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >> On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote: >>> On Mon, 1 Jun 2020 at 14:02, Anton Khirnov <anton@khirnov.net> 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.
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 - xxxxxxxxxx - lavc 58.xx.100 - avcodec.h + Add AV_CODEC_FLAG2_FAST_UNSAFE + 2020-xx-xx - xxxxxxxxxx - 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)
TODO: Bump Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- 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(-)