mkver / FFmpeg

Remove superfluous trailing zeros from slices. Because MPEG-2 slices
can end with zero bits a safe number of trailing zero bits is always
kept.

More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf}
is an upper bound for the number of possible trailing zeros that are
part of the slice. Here f_code[i][1] is the relevant value of the
picture coding extension the slice belongs to and the maximum of the
empty set is zero.
It is this number of trailing zero bits that is actually kept.

That this is really an upper bound can be seen as follows:

a) Every slice actually ends with a macroblock.

b) If the last macroblock of a slice ends with a block(i) structure
with pattern_code[i] != 0, then the slice ends with an "End of block"
VLC code (namely the "End of block" code of the last block with
pattern_code[i] != 0).
These codes are 10 and 0110, so that in this case there is exactly one
trailing zero bit.

c) Otherwise, all pattern_code[i] are zero. In this case,
if macroblock_pattern is set for the last macroblock of the slice, then
by the definition of pattern_code[i] in 6.3.17.4 cbp (derived
according to table B.9) must be zero and also the
coded_block_pattern_1/2 (if existing) must consist of zeros alone. The
value zero for cbp is coded by 0000 0000 1 so that the maximum number of
trailing zeros in this case is the length of coded_block_pattern_1/2 which
have a length of two resp. six bits. So six trailing zero bits at most.

d) Otherwise, if the slice actually ends with the marker bit of the
last macroblock, then there are certainly no trailing zero bits at
all.

e) Otherwise, if the slice ends with a motion_vectors(s) structure
(with s = 0 or 1 -- it doesn't matter which one), then it ends with a
motion_vector(r,s) (r, s = 0, 1 -- it doesn't matter) structure. This
structure ends with motion_code[r][s][1] (always existing) potentially
followed by motion_residual[r][s][1] and dmvector[1]. If dmvector[1]
exists, and contains a bit different from 0, there is at most one
trailing zero bit; if dmvector[1] consists of zeros alone, its length
is one according to B.11. motion_residual[r][s][1] (if it exists) has
a length of f_code[s][1] - 1 bits and can consist of zero bits alone.
Given that the value 0xf for f_code indicates that there is no motion
vector of the mentioned type, the length of motion_residual[r][s][1] is
bounded by max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf}. The
motion_code[r][s][1] can end with at most five zero bits (see B.10)
and always contains a bit set to one, so that in this case there are
at most 5 + max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf} + 1
zero trailing bits.

f) Otherwise, if the last macroblock of the slice ends with a
quantiser_scale_code, then there are at most four trailing zero bits,
because quantiser_scale_code has a length of five bits and must not
attain the value zero.

g) Otherwise, the last macroblock ends with the macroblock_modes
syntax structure. The potentially existing dct_type at the end might
be a zero bit; the frame/field_motion_type isn't present here, because
otherwise we would have a motion_vectors(i) (i = 0 or 1 or both) syntax
structure, so that e) (or b)-d)) would have applied.
spatial_temporal_weight_code might entirely consist of two zero bits.
The macroblock_type VLC code always contains a 1 bit and ends with two
zero bits at most (see B.2-B.8 for this), so we have maximally 2+2+1
trailing zero bits.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

MPEG-2 picture header can contain optional extra information, just like
slice header. While the latter has always been supported, the former has
been forgotten. This meant that if this extra information was present,
it was discarded during reading; and unfortunately writing created
invalid bitstreams (where extra_bit_picture indicated that there would
be a further byte of data, although the output didn't contain said
data).

This has been fixed; both types of extra information are now parsed via
the same code and essentially passed through.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

…mpeg2_read_slice_header()

cbs_mpeg2_free_slice() calls av_buffer_unref() on extra_information_ref,
meaning allocating with av_malloc() was not the intention.

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

Up until now, things that are merely unsupported by cbs_mpeg2 have been
declared to be invalid input. This has been changed.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
unknown/unspecified (namely 2). A value of zero is not only inappropriate,
but explicitly forbidden. This is fixed by inferring the right default
values during the reading process if the elements are absent; moreover,
changing any of the colour_description elements to zero is now no longer
permitted.

Furthermore, if a sequence display extension has to be added, the
earlier code set some fields to their default value twice. This has been
changed, too.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The frame_centre_horizontal/vertical_offset values contained in picture
display extensions are actually signed values (i.e. it is possible to
indicate that the display device should add black bars/pillars).

The files sony-ct3.bs and tcela-6.bits (which are both used in fate
tests for mpeg2_metadata) contain picture display extensions; the former
even contains a negative frame_centre_vertical_offset. Fortunately, the
old code did not damage the picture display extensions when one did a
cycle of reading and writing. Therefore the fate tests needn't be
updated either.

Furthermore these fields now use the trace output for matrices.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

MPEG-2 contains several elements that mustn't be zero according to the
specifications: horizontal/vertical_size_value, aspect_ratio_information,
frame_rate_code, the quantiser matrices, the colour_description
elements, picture_coding_type, the f_code[r][s] values and
quantiser_scale_code. It is now checked that the invalid values don't
occur.

The colour_description elements are treated specially in this regard:
Given that there are files in the wild which use illegal values for the
colour_description elements (some of them created by mpeg2_metadata),
they will be corrected to the value meaning "unknown" (namely 2) during
reading. This has been done in such a way that trace_headers will
nevertheless report the original value, together with a message about
the fixup.

Furthermore, the trace_headers output of user_data has been beautified.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

It's been unused since 5d48e4e.

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

This fixes the description of the values for src_range and dst_range to
include the possible values and their meanings.

Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>

missed the category AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT lead to
ffmpeg -devices doesn't show gdigrab as a input device

FIx #7848

Found-by: dangibson
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

srcw, srch, dstw, dsth, src_format and dst_format were blocked for
CLI use in a0af9fd in order to fix ticket #4856

The return code is 64bit, so this is more correct, especially in case it
actually would be a file of such large size

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

Because the Original repository author loss loss of communication,
add new sr filter script repository.

Thanks to Gyan Doshi for a suggestion.

Signed-Off-By: Steven Liu <lq@chinaffmpeg.org>

This reverts commit c2771bb.

ctx is a pointer to pointer here.

Signed-off-by: Ruiling Song <ruiling.song@intel.com>

Thanks to Steven Liu for the update.

There was a hardcoded value left. Wasn't caught earlier as no code uses
compound forward mod-3/5 MDCTs yet.

Fixes timestamp of last output frame.

Fixes Coverity CID 1445099

This patch is based on https://trac.ffmpeg.org/ticket/5680 provided by
Kylie McClain <somasis@exherbo.org> at Wed, 29 Jun 2016 16:37:20 -0400,
and have some changes.

contributor: Kylie McClain <somasis@exherbo.org>
contributor: avih <avihpit@yahoo.com>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>

I'm not sure why this was written the way it was originally. We
initialise the plane addresses correctly in hwcontext_cuda so
why try and play games to calculate the plane offsets directly
in this code?

This format is interesting because it's what you get for decoded
10/12bit HEVC 4:4:4.

When i converted the filter to use texture objects instead of
texture references, I incorrect dropped the `pixel_size` scaling
factor when setting `pitchInBytes`. `src_pitch` is in pixels and
so must be scaled up.

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in     fftwf_execute,     1024 runs,      0 skips
  21836 decicycles in compound_fft_15x8,     1024 runs,      0 skips

128:
  22003 decicycles in       fftwf_execute,   1024 runs,      0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,      0 skips

384:
  75939 decicycles in      fftwf_execute,    1024 runs,      0 skips
  73973 decicycles in compound_fft_3x128,    1024 runs,      0 skips

640:
 104354 decicycles in       fftwf_execute,   1024 runs,      0 skips
 149518 decicycles in compound_fft_5x128,    1024 runs,      0 skips

768:
 109323 decicycles in      fftwf_execute,    1024 runs,      0 skips
 164096 decicycles in compound_fft_3x256,    1024 runs,      0 skips

960:
 186210 decicycles in      fftwf_execute,    1024 runs,      0 skips
 215256 decicycles in compound_fft_15x64,    1024 runs,      0 skips

1024:
 163464 decicycles in       fftwf_execute,   1024 runs,      0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,      0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.

The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.

They're not used and they're incorrect.

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

b3b7ba6 introduced undefined behaviour: A (non-modifiable) string
literal has been assigned to a modifiable string; said string was indeed
modified later via av_strtok.
This of course caused compiler warnings because of the discarded
qualifier; these are in particular fixed by this commit.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Fixes: Timeout (12sec -> 2sec)
Fixes: 14606/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5738687561728000

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Commit cd48318 added support for NV24 and NV42, including several
fate tests for these formats, but did not include the reference files
for the tests filter-pixdesc-nv24 and filter-pixdesc-nv42. As a result,
these two tests were broken.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>