The issue is that with a threadsafe hwaccel and multiple enabled
frame threads, hwaccel->uninit() is never called.
Previously, the function was guaranteed to never have any threads
with hwaccel contexts, so it never bothered to uninit any.
This reverts commit 9a245bdf5d.
This commit basically broke all samples with fractional framerates,
rather than fixing them.
I at this point do not understand the original issue anymore, and I'm
not sure how this slipped my initial testing.
All my test samples must have happened to have a simple timebase.
The actual dts values pretty much always are just a simple chain of
1,2,3,4,5,... Or maybe slightly bigger steps. Each increase by one means
an advance in time by one unit of the timebase.
So a fractional framerate/timebase is already not an issue.
So with this patch applied, the calculation might end up substracting
huge values (1001 is a common one) from the dts, which would be an
offset of that many frames, not of that many fractions of a second.
This broke at least muxing into mp4, if the sample happened to have a
fractional framerate.
I do not thing the original issue this patch tried to fix existed in the
first place, so it can be reverted without further consequences.
This flag is used to indicate to the hw frames in the gaps,
vaapi constructs it from a bunch of implicit API information
around surface ids. vulkan should just send it explicitly.
Reviewed-by: Lynne <dev@lynne.ee>
Determined experimentally, on various videos and hardware.
On Intel, using less resources in-flight is around 15% faster,
with similar results on Nvidia hardware.
It was introduced for Vulkan, but it is equivalent to
short_term_ref_pic_set_size when !short_term_ref_pic_set_sps_flag,
and when !!short_term_ref_pic_set_sps_flag, Vulkan hardcodes a zero
anyway.
Wrapped frames contain pointers so they need specific code to
noise them, the generic code would lead to segfaults
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Migrate the libjxl decoder wrapper from the decode_frame method to the
receive_frame method, which allows sending more than one frame from a
single packet. This allows the libjxl decoder to decode JPEG XL files
that are animated, and emit every frame of the animation. Now, clients
that feed the libjxl decoder with an animated JPEG XL file will be able
to receieve the full animation.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Fixes: signed integer overflow: -182838 * 32768 cannot be represented in type 'int'
Fixes: 58179/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-5333265899978752
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 538976288 by 13 places cannot be represented in type 'int'
Fixes: 56148/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-6257370708967424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In certain use cases, controlling the maximum frame size is critical. An
example is when transmitting AAC packets over Bluetooth A2DP.
While the spec allows the packets to be fragmented (but UNRECOMMENDED),
in practice most headsets do not recognize nor reassemble such packets.
In this patch, we allow setting `bit_rate_tolerance` to 0 to indicate
that the specified bit rate should be treated as an upper bound up to
frame level.
Signed-off-by: Jeremy Wu <jrwu@chromium.org>
Added support for more VideoToolbox encoder options:
- qmin and qmax options are now used
- max_slice_bytes: Max number of bytes per H.264 slice
- max_ref_frames: Limit the number of reference frames
- Disable open GOP when the cgop flag is set
- power_efficient: Enable power-efficient mode
Signed-off-by: Rick Kern <kernrj@gmail.com>
Added prerequisites that must be met before providing support for the MPEG-5 EVC codec
- Added new entry to codec IDs list
- Added new entry to the codec descriptor list
- Bumped libavcodec minor version
- Added profiles for EVC codec
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
According to Dave Airlie:
> <airlied> but I think ignoring it should be fine, I can't see any
> other way to get the imaeg extents correct for other usage
> <Lynne> what width/height should be used for the images?
> the final presentable dimensions, or the coded dimensions?
> <airlied> if you don't want noise I think the presentable dims
> <airlied> the driver should round up the allocations internally,
> but if you are going to sample from the images then w/h have to be
> the bounds of the image you want
> <airlied> since otherwise there's no way to stop the sampler from
> going outside the edges
Apparently, the alignment values are informative, rather than mandatory,
but the spec's wording makes it sound as if they're mandatory.
Previously floats where scaled up to 32bit int, but floats do not
have 32bits in their mantisse so a quarter of the bits where nonsense.
It seems no fate test is affected by this change, which is interresting
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When seeking through MBAFF-coded H264, this can happen. Decoding calls end_frame
without calling start_frame. We are unable to decode this, as no frame
state has been set.
Happens for both VAAPI and Vulkan. Could be an issue elsewhere, hence
the individual commit.
Dave Airlie
Lynne
Paul B Mahol
James Almer
Dawid Kozinski
Timo Rothenpieler
Michael Niedermayer
Roman Arzumanyan
Logan Lyu
Leo Izen
Jeremy Wu
Rick Kern
xufuji456
Arnie Chang