The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
YUVJ inputs were automatically converted back to limited range when converting
to a different pixfmt (in the absence of tagging). However, with proper YUV
negotiation in place, the default behavior is to preserve the YUV range
wherever possible. Since `rawvideo` does not signal or care about the YUV
range, we need to explicitly request the desired output range to force a
conversion.
Affects all rawvideo tests, in particular vsynth and owdenoise.
When ret is checked here, it was never assigned anything, making this
check useless, as highlighted by Coverity.
It seems to be a copy paste mistake given that opt_match_per_stream_str
does not return an error code that could be checked and the previous
value assigned to ret is already checked above. So just remove this
check.
Fixes: CID1616292
Should fix memory leaks show in fate-filter-join and fate-filter-crazychannels.
Reviewed-by: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Signed-off-by: James Almer <jamrial@gmail.com>
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA was set above in the normal
input case but forgotten for the same in the delayed surface codepath.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitrii Ovchinnikov <ovchinnikov.dmitrii@gmail.com>
Deprecate the option 'draw_bars' in favor of the new option 'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains unchanged to be backwards compatible.
The new option is more flexible for extending now and in the future.
The new value 'repeat' repeats the last video frame.
This is useful for very short dropouts and was not available before.
Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
The test constructs 66 sine waves of different frequencies and joins
them into a 7th order ambisonic layout with extra non-diegetic
stereo. The channels are then shifted circularly with channelmap and
separated into individual streams for muxing with channelsplit.
Note that the last step is necessary because swr is not capable of
interleaving planar to packed for more than 64 channels, which would be
necessary to mux such a stream as PCM.
The old query code never worked properly, and did some hideous
heuristics to read the status bit, and work that into a return
code.
This is all best left to callers to do, which simplifies
our code a lot.
This also fixes minor validation errors regarding calling queries
which are not in their active state.
The issue is that we ask for storage images by default if
available, but because that is gated by the format supporting
storage images, and the check for the format supporting storage
images is gated by the usage, this resulted in a catch-22.
Vulkan supports some stupidly odd hardware, that unfortunately,
most modern GPUs happen to be.
The DPB images for encoders may be required to be preallocated
all at once, and rather than be individual frames, be layers of
a single frame.
As the hw_base_encode code is written with the thought that either
the driver or the device itself supports sane image allocation,
Vulkan does not leave us with this option.
So, in the case that the hardware does not support individual
frames to be used as DPBs, make the DBP frames context optional,
and let the subsystem manage this.
