diff mbox series

[FFmpeg-devel,1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

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
Related show

Checks

Context Check Description
andriy/default pending
andriy/make success Make finished
andriy/make_fate success Make fate finished

Commit Message

Michael Niedermayer May 28, 2020, 4:20 p.m. UTC
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(-)

Comments

Lynne May 28, 2020, 4:26 p.m. UTC | #1
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.
James Almer May 28, 2020, 4:43 p.m. UTC | #2
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)
>
Michael Niedermayer May 28, 2020, 6:09 p.m. UTC | #3
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

[...]
Anton Khirnov May 28, 2020, 6:22 p.m. UTC | #4
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
Anton Khirnov May 28, 2020, 6:30 p.m. UTC | #5
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?
Michael Niedermayer May 28, 2020, 6:36 p.m. UTC | #6
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

[...]
Michael Niedermayer May 28, 2020, 7:13 p.m. UTC | #7
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


[...]
Kieran Kunhya May 28, 2020, 10:57 p.m. UTC | #8
>
> 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
Michael Niedermayer May 29, 2020, 1:10 p.m. UTC | #9
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

[...]
Kieran Kunhya May 29, 2020, 1:22 p.m. UTC | #10
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
James Almer May 29, 2020, 1:37 p.m. UTC | #11
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?
Michael Niedermayer May 29, 2020, 2:33 p.m. UTC | #12
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
[...]
Michael Niedermayer May 29, 2020, 2:56 p.m. UTC | #13
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


[...]
Jean-Baptiste Kempf May 29, 2020, 3:10 p.m. UTC | #14
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
Paul B Mahol May 29, 2020, 4:46 p.m. UTC | #15
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".
Derek Buitenhuis May 31, 2020, 1:42 p.m. UTC | #16
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
Anton Khirnov June 1, 2020, 1:02 p.m. UTC | #17
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.
Kieran Kunhya June 1, 2020, 1:30 p.m. UTC | #18
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
Michael Niedermayer June 1, 2020, 11:45 p.m. UTC | #19
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

[...]
Paul B Mahol June 2, 2020, 6:45 a.m. UTC | #20
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.
>
James Almer June 2, 2020, 12:39 p.m. UTC | #21
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 mbox series

Patch

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)