If the Matroska muxer's AVIOContext was unseekable when writing the
header, but is seekable when writing the trailer, the code for writing
the trailer presumes that a dynamic buffer exists and tries to update
its content in order to overwrite data that has already been
preliminarily written when writing the header, yet said buffer doesn't
exist as it has been written finally and not preliminarily when writing
the header (because of the unseekability it was presumed that one won't
be able to update the data anyway).

This commit adds a check for this and also for a similar situation
involving updating extradata with new data from packet side-data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

It's the correct dedicated capability reported by supported encoders.
Otherwise, the frame thread path will be used for unsupported encoders
like r210 for no gain.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Enables HEVC Range Extension encoding support (Linux) for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform.

Restricted to linux only for now.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>

Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform.

Restricted to linux only for now.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>

The parsing process of the AVOpt-enabled string controlling the mapping
of input streams to variant streams is roughly as follows: Space and tab
separate variant stream group maps while the entries in each variant
stream group map are separated by ','.

The parsing process of each variant stream group proceeded as follows:
At first the number of occurences of "a:", "v:" and "s:" in each variant
stream group is calculated so that one can can allocate an array of
streams with this number of entries. Then the string is split along ','
and each substring is parsed. If such a substring starts with "a:", "s:"
or "v:" it is treated as stream specifier and (if there is a correct
number after ':') a stream of the variant stream is mapped to one of the
actual input streams.

Nothing actually guarantees that the number of streams allocated initially
equals the number of streams that are mapped to an actual input stream.
These numbers can differ if e.g. the name, the sgroup, agroup or ccgroup
of the variant stream contain "a:", "s:" or "v:".

The problem hereby is that the rest of the code presumes these numbers
to be equal and segfaults if it isn't (because the corresponding input
stream is NULL).

This commit fixes this by modifying the initial counting process to only
count occurences of "a:", "s:" or "v:" that are at the beginning or that
immediately follow a ','.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

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

This avoids accessing an old, no longer valid buffer.
Fixes: out of array access
Fixes: crash_audio-2020
Found-by: le wu <shoulewoba@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Prevents wrap-around to negative values while calculating the duration string.

Before:

    Duration: -411422:-59:-42.17, start: 0.000000, bitrate: 0 kb/s

After:

    Duration: 781623:28:34.17, start: 0.000000, bitrate: 0 kb/s
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 19950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-5765514337189888

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

Fixes: memleak
Fixes: 21784/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-565256551058636

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Gautam Ramakrishnan <gautamramk@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This function doesn't call emms.
Signed-off-by: Martin Storsjö <martin@martin.st>

Call it directly from write_packets_common() instead of indirectly
through prepare_input_packet().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This commit stops using pkt->stream_index as index in an AVFormatContext's
streams array before actually comparing the value with the count of
streams in said array. 96e5e6ab used
pkt->stream_index in prepare_input_packet() before checking and
64063512 did likewise in
write_packets_common().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This allows speeding up format conversions from yuv420 to nv12.

                             Cortex A53      A72      A73
interleave_bytes_c:             86077.5  51433.0  66972.0
interleave_bytes_neon:          19701.7  23019.2  15859.2
interleave_bytes_aligned_c:     86603.0  52017.2  67484.2
interleave_bytes_aligned_neon:   9061.0   7623.0   6309.0
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

                        Cortex A53    A72    A73
get_pixels_c:                140.7   87.7   72.5
get_pixels_neon:              46.0   20.0   19.5
get_pixels_unaligned_c:      140.7   87.7   73.0
get_pixels_unaligned_neon:    49.2   20.2   26.2
diff_pixels_c:               209.7  133.7  138.7
diff_pixels_neon:             54.2   31.7   23.5
diff_pixels_unaligned_c:     209.7  134.2  139.0
diff_pixels_unaligned_neon:   68.0   27.7   41.7
Signed-off-by: Martin Storsjö <martin@martin.st>

                         Cortex A7     A8     A9    A53   A72
get_pixels_c:                144.7  146.0  143.0  137.7   69.0
get_pixels_armv6:            112.0  106.7   90.2   95.0   72.5
get_pixels_neon:              69.0   29.7   68.7   40.2   19.0
get_pixels_unaligned_c:      144.7  146.2  143.0  137.7   69.0
get_pixels_unaligned_neon:    77.0   36.5   72.5   48.5   19.0
diff_pixels_c:               376.7  319.7  265.5  307.7  148.0
diff_pixels_armv6:           179.0  159.5  205.5  139.0  142.0
diff_pixels_neon:             69.0   40.2   77.5   53.2   26.0
diff_pixels_unaligned_c:     376.7  319.7  265.5  307.7  148.0
diff_pixels_unaligned_neon:   85.0   54.5   93.5   66.7   26.0
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added they will need to have checks here too.

The immediate usecase for this change is making the hscale checkasm
test easier and without NEON specific edge-cases (x86 already has these
guards).

This applies the same fix from 718c8f9a
on the 32 bit arm version of the function, fixing fate-checkasm-sw_scale
there.
Signed-off-by: Martin Storsjö <martin@martin.st>

If you have a file with multiple Metadata Keys, the second time you parse
the keys, you will re-alloc c->meta_keys without freeing the old one.
This change will avoid parsing all the consecutive Metadata keys.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Many places are using their own custom code for handling overflow
around timestamps or other int64_t values. There are enough of these
now that having some common saturated math functions seems sound.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Also fill x8-x17 with garbage before calling the function.

Figure out the number of stack parameters and make sure that the
value on the stack after those is untouched.
Signed-off-by: Martin Storsjö <martin@martin.st>

Figure out the number of stack parameters and make sure that the
value on the stack after those is untouched.
Signed-off-by: Martin Storsjö <martin@martin.st>

We should just use a normal bl here, and the linker will add the 'x'
bit if necessary.

This fixes calling the checkasm_fail_func on windows, where the
code is built in thumb mode (and the linker doesn't clear the 'x'
bit in the blx instruction).
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes it easier to share code with e.g. the dav1d implementation
of checkasm.
Signed-off-by: Martin Storsjö <martin@martin.st>

On windows and darwin (and modern android), the x18 register is reserved
and shouldn't be modified by user code, while it is freely available on
linux. Strictly avoid it, to keep the assembly code portable.

This would have helped catch the issue fixed in 872790b1
immediately.
Signed-off-by: Martin Storsjö <martin@martin.st>

This reverts commit 339593ca.

Fixes null pointer dereference.
Signed-off-by: Marton Balint <cus@passwd.hu>

This reverts commit d88e1c98.

Fixes null pointer dereference.
Signed-off-by: Marton Balint <cus@passwd.hu>

This tests the hscale 8bpp to 14/18bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock <josh@itanimul.li>

This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0).
Signed-off-by: Josh de Kock <josh@itanimul.li>

The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added they will need to have checks here too.

The immediate usecase for this change is making the hscale checkasm
test easier and without NEON specific edge-cases (x86 already has these
guards).
Signed-off-by: Josh de Kock <josh@itanimul.li>

The h264_nvenc and hevc_nvenc encoders aren't respecting the framerate in the codec context.
Instead it was using the timebase which in our use-case was 1/1000 so the encoder was behaving
as if we wanted 1000fps. This resulted in poor encoding results due to an extremely low bitrate.

Both the amf and qsv encoders already contain similar logic to first check the framerate before
falling back to the timebase.
Signed-off-by: Zachariah Brown <zachariah@renewedvision.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

It's not meant for audio or subtitles, or for encoders of any kind.
Reviewed-by: mypopy@gmail.com <mypopy@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

have tested on linux x86_32/64, mingw32/64 arm & mips qemu
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

 ./ffmpeg -loglevel debug -i ../fate-suite/svq3/Vertical400kbit.sorenson3.mov -vf
 minterpolate=fps=60:mi_mode=blend -an -f null -
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 1600
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 4120
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 5780
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 6700
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 8140
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 9740
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 14060
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 15680
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 18480
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 20020
 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 21740

 The results are consistent with tests/ref/fate/filter-metadata-scenedetect

 For the master, it'll detect more than 20 scene change for the same source.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>