There are still a couple of deprecated calls that I’m not sure what to do with.
They are both related to some logic around AVCodecContext.coded_frame.
I couldn’t find anywhere that really documented what that was, or where it was intended to move to.
I left the warnings on.
Reviewed-by: Deti Fliegl <deti@fliegl.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Larger values would imply file durations of astronomic proportions and cause
overflows
Fixes integer overflow
Fixes: usan_int64_overflow
Found-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We can only remove the logo if it is inside the picture. We need at
least one pixel around the logo area for interpolation.
Fixes ticket #5527 (Delogo crash with x=0 and/or y=0).
Signed-off-by: Jean Delvare <jdelvare@suse.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also check return value of av_frame_copy() in passthrough mode, so that
if a copy fails (as it did here, because bitdepth didn't match), the filter
doesn't return success, which would mean sending an uninitialized framebuffer
further down the filtergraph.
This tests automatic insertion of the vp9_superframe BSF as well as
ensuring that the colorspace properties in the video header can be
modified when remuxing (-c:v copy).
I have no idea why the first hunk uses ost->enc_ctx, because as far as
I understand, that is never used in case of -c:v copy, but this code
block is only entered if encoding_needed=0, which means stream_copy=1.
My point being: review from someone that knows this really well would
be appreciated.
Update print mode output header line format to be more consistent with
other log output of FFmpeg. The printf-modifiers have been inspired by
the showinfo filter.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows e.g. to correlate signalstats metadata to time position
without having to find out the filter chain timebase first.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit is a no-op.
* commit '4c6836db0f300d2c0401c6a1927a95c3258cc1ae':
nvenc_h264: Fix name of private AVClass
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'e3453fd44480d903338c663238bf280215dd9a07':
matroska: Write the field order information
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This commit is a no-op. We cherry picked it earlier.
* commit 'b3051a460cf02a5b86ff0d1e14abba23ea55ff6d':
vaapi_h264: Fix bit offset of slice data.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '44f05f15d4a34ef2f0d62259e5d5b43371bc0954':
build: Do not check the vaapi_encode.h header if VAAPI is not enabled
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'bd016dbf23e8e7dc34ff2696912575f7620cec0d':
Mark tables used only within their files as static
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The problem is that with particularly complex images and especially at
high bit depths and 5-level transforms the coefficients would overflow,
causing huge artifacts to appear. This was discovered thanks to the fate
tests, which will have to be redone as this fixes a multitude of
problems and increases PSNR.
There is a slight performance drop associated with this change, making
the encoder slower by 1.15 times, however this is necessary in order to
avoid undefined behavior and overflows.
It would be worth to template the transforms to keep the performance for
8 bit images as 32 bit coefficients are unnecessary for that case, but
the primary use of the encoder is to encode video at 10 bits.
Reviewed-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Commit ca2f19b9cc modified the meaning of
H264SliceContext.gb: it is now initialised at the start of the NAL unit
header, rather than at the start of the slice header. The VAAPI slice
decoder uses the offset after parsing to determine the offset of the
slice data in the bitstream, so with the changed meaning we no longer
need to add the extra byte to account for the NAL unit header because
it is now included directly.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>