jpeg2000_ict_float_c: 2296.0
jpeg2000_ict_float_sse: 628.0
jpeg2000_ict_float_avx: 317.0
jpeg2000_ict_float_fma3: 262.0
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

It is unused.
Signed-off-by: Marton Balint <cus@passwd.hu>

Fixes: runtime error: left shift of negative value -255
Fixes: 4037/clusterfuzz-testcase-minimized-5290998163832832

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Previously the codec kept an entire copy of the SPS, and restarted the VT decoder
session whenever it changed. This fixed decoding errors in [1], as
described in 9519983c. On further inspection, that sample features an SPS change
from High/4.0 to High/3.2 while moving from one scene to another.

Yesterday I received [2], which contains minor SPS changes where the
profile and level do not change. These occur frequently and are not associated with
scene changes. After 9519983c, the VT decoder session is recreated unnecessarily when
these are encountered causing visual glitches.

This commit simplifies the state kept in the VTContext to include just the first three
bytes of the SPS, containing the profile and level details. This is populated initially
when the VT decoder session is created, and used to detect changes and force a restart.

This means minor SPS changes are fed directly into the existing decoder, whereas
profile/level changes force the decoder session to be recreated with the new parameters.

After this commit, both samples [1] and [2] playback as expected.

[1] https://s3.amazonaws.com/tmm1/videotoolbox/spschange.ts
[2] https://s3.amazonaws.com/tmm1/videotoolbox/spschange2.tsSigned-off-by: Aman Gupta <aman@tmm1.net>

This reverts commit 218ce1f6.

Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>

Fixes the build warning of "ignoring return value of ‘ff_formats_ref’,
declared with attribute warn_unused_result"
Signed-off-by: Zhong Li <zhong.li@intel.com>
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Fixes the build warning of "ignoring return value of ‘ff_formats_ref’,
declared with attribute warn_unused_result"
Signed-off-by: Zhong Li <zhong.li@intel.com>
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Fixes build warning of "variable 's' is declared but not used"
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

VA-API 2.0 have enable the I420, so enable this map.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

This was predictably nightmarish, given how ridiculous mpeg4 is.
I had to stare at the cuvid parser output for a long time to work
out what each field was supposed to be, and even then, I still don't
fully understand some of them. Particularly:

vop_coded: If I'm reading the decoder correctly, this flag will always
           be 1 as the decoder will not pass the hwaccel any frame
           where it is not 1.
divx_flags: There's obviously no documentation on what the possible
            flags are. I simply observed that this is '0' for a
            normal bitstream and '5' for packed b-frames.
gmc_enabled: I had a number of guesses as to what this mapped to.
             I picked the condition I did based on when the cuvid
             parser was setting flag.

Also note that as with the vdpau hwaccel, the decoder needs to
consume the entire frame and not the slice.

Once I remembered that there's a separate decoder type for mpeg1,
even though params struct is shared with mpeg2, everything worked.

The 'simple' hwaccels (not h.264 and hevc) all use the same bitstream
management and reference lookup logic so let's refactor all that into
common functions.

I verified that casting a signed int -1 to unsigned char produces 255
according to the C language specification.

Previously video flags where set for audio option.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes a warning:
libavformat/mov.c:1195:5: warning: ISO C90 forbids mixed declarations and code

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Reviewed-by: Steven Liu <lingjiujianke@gmail.com>

Reviewed-by: Steven Liu <lingjiujianke@gmail.com>

Reviewed-by: Steven Liu <lingjiujianke@gmail.com>

fixes 6145
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Per
https://developer.apple.com/library/content/technotes/tn2162/_index.htmlSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

 Adds ui64 (uint64_t) as a possible type for SpecifierOpt. This enables
 use of uint64_t options with SpecifierOpt such as channel_layout
 when expressed as a 64 bit channel mask.
Signed-off-by: pkviet <pkv.stream@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: James Almer <jamrial@gmail.com>

The flags were removed in b79a7da3

* commit '3152058b':
  libavcodec: Don't use dllexport, only dllimport when building DLLs
Merged-by: James Almer <jamrial@gmail.com>

select should not be used with external libraries. It's mean to soft
enable internal modules/features.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

The only purpose of dllexport (which is set while building the library
that exports the symbols) is to have the linker automatically
export such symbols into a DLL without using a def file - it doesn't
affect the generated code.

For both MSVC and mingw builds, this isn't essential since we override
what symbols to export via an autogenerated def file instead.

Update a comment in configure to refer to the right concept.

With lld, this avoids warnings about duplicate export directives,
when some symbols are requested to be exported both via dllexport
attributes and via the autogenerated def file.

This also reduces the number of lines of code marginally.
Signed-off-by: Martin Storsjö <martin@martin.st>

Users can set end offset as 0 to extract till end of file.
Tested locally and documented.