- 31 Jan, 2023 10 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Leo Izen authored
libjxl only accepts 16-bit buffers with its API, but it can accept 9-bit to 15-bit input via a 16-bit buffer, provided the flag is set declaring the buffer to be of the respective significant depth. Likewise, it can only provide pixel data on decode as a 16-bit buffer (if higher than 8) but does provide the metadata tagging the actual bit depth. This commit causes libjxlenc.c and libjxldec.c to respect this metadata and tag/read it accordingly from AVCodecContext->bits_per_raw_sample. Signed-off-by: Leo Izen <leo.izen@gmail.com>
-
Cameron Gutman authored
mfenc sets FF_CODEC_CAP_INIT_CLEANUP, so calling mf_close() on failure inside mf_init() results in a double-free. Signed-off-by: Cameron Gutman <aicommander@gmail.com> Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Only warn if the advanced_editlist option is enabled (it is enabled by default though) so we don't print one warning for each track, and demote the warning to AV_LOG_LEVEL_VERBOSE; this message does get generated whenever parsing a fragmented MP4 file, regardless of whether the file actually uses multiple edits or not. Later when parsing the mov structures, the demuxer does warn if the file did contain multiple edits which would require the advanced_editlist option enabled for decoding correctly. Adjust the warning message for the case when the file seemed like it actually would have needed handling of advanced edit lists, to reflect the fact that it doesn't help to try set the option as it has been automatically disabled. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
The construct of using offsetof on a (potentially anonymous) struct defined within the offsetof expression, while supported by all current compilers, has been declared explicitly undefined by the C standards committee [1]. Clang recently got a change to identify this as an issue [2]; initially it was treated as a hard error, but it was soon after softened into a warning under the -Wgnu-offsetof-extensions option (not enabled automatically as part of -Wall though). Nevertheless - in this particular case, it's trivial to fix the code not to rely on the construct that the standards committee has explicitly called out as undefined. [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm [2] https://reviews.llvm.org/D133574Signed-off-by: Martin Storsjö <martin@martin.st>
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
If the dictionary provided on input contains multiple entries for an option (relevant for flags modifying the previous value with '+' or '-') and the option is not found in the target object, only the last entry would be returned to the caller. Pass AV_DICT_MULTIKEY to av_dict_set() to make sure all such entries are returned.
-
Anton Khirnov authored
They discard all input without ever returning any output. Useful for development.
-
- 30 Jan, 2023 11 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Niklas Haas authored
This warning was introduced when ee650398 removed the cast.
-
Paul B Mahol authored
-
Haihao Xiang authored
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
-
Haihao Xiang authored
QSVScaleContext and VPPContext have the same base context, and all features in scale_qsv are implemented in vpp_qsv filter, so scale_qsv can be taken as a special case of vpp_qsv filter, and we may use VPPContext with a different option array, preinit callback and supported pixel formats to implement scale_qsv then remove QSVScaleContext Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
-
Haihao Xiang authored
Use QSVVPPContext as a base context of QSVScaleContext, hence we may re-use functions defined for QSVVPPContext to manage MFX session for scale_qsv filter. In addition, system memory has been taken into account in QSVVVPPContext, we may add support for non-QSV pixel formats in the future. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
-
galinart authored
Hyper Encode uses Intel integrated and discrete graphics on one system to accelerate encoding of a single video stream. Depending on the selected parameters and codecs, performance gain on AlderLake iGPU + ARC Gfx up to 1.6x. More information: https://www.intel.co.uk/content/www/uk/en/architecture-and-technology/adaptix/deep-link.html Developer guide: https://github.com/oneapi-src/oneVPL-intel-gpu/blob/main/doc/HyperEncode_FeatureDeveloperGuide.md Hyper Encode is supported only on Windows and requires D3D11 and oneVPL. To enable Hyper Encode need to specify: -Hyper Encode mode (-dual_gfx on or dual_gfx adaptive) -Encoder: h264_qsv or hevc_qsv -BRC: VBR, CQP or ICQ -Lowpower mode (-low_power 1) -Closed GOP for AVC or strict GOP for HEVC -idr_interval = 0 used by default Depending on the encoding parameters, the following parameters may need to be adjusted: -g recommended >= 30 for better performance -async_depth recommended >= 30 for better performance -extra_hw_frames recommended equal to async_depth value -bf recommended = 0 for better performance In the cases with fast encoding (-preset veryfast) there may be no performance gain due to the fact that the decode is slower than the encode. Command line examples: ffmpeg.exe -init_hw_device qsv:hw,child_device_type=d3d11va,child_device=0 -v verbose -y -hwaccel qsv -extra_hw_frames 60 -async_depth 60 -c:v h264_qsv -i bbb_sunflower_2160p_60fps_normal.mp4 -async_depth 60 -c:v h264_qsv -preset medium -g 60 -low_power 1 -bf 0 -dual_gfx on output.h265 Signed-off-by: galinart <artem.galin@intel.com>
-
Haihao Xiang authored
Include hstack_vaapi, vstack_vaapi and xstack_vaapi. They may accept input streams with different sizes. libva2 (VA-API 1.0+) is required. Example: $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.h265 -filter_complex "[0:v][0:v]hstack_vaapi" -c:v h264_vaapi out.h264 $ ffmpeg \ -hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \ -hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \ -hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \ -hwaccel vaapi -hwaccel_output_format vaapi -i input.h264 \ -filter_complex "[0:v][1:v][2:v][3:v]xstack_vaapi=inputs=4:fill=0x000000:layout=0_0_1920x1080|w0_0_1920x1080|0_h0_1920x1080|w0_h0_1920x1080" \ -c:v hevc_vaapi out.h265 Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
-
David Rosca authored
v3: pic_order_cnt steps by 2
-
- 29 Jan, 2023 19 commits
-
-
Marton Balint authored
Let's ignore the index table if the number of index entries does not match the index duration (or the special AVID index entry counts). Fixes: OOM Fixes: 50551/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-6607795234930688 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
WebP does not have reordering, so dts=pts is set by the generic code.
-
Anton Khirnov authored
Except for the mjpeg_vaapi encoder, which is already handled generically.
-
Anton Khirnov authored
For delay-capable encoders, i.e. mpeg12 and mpeg4video. Generic code in encode.c already handles this for all other mpegvideo encoders.
-
Anton Khirnov authored
Theora is not marked as supporting reordering, so dts will be set from pts by the generic code.
-
Anton Khirnov authored
-
Anton Khirnov authored
APNG is not marked as supporting reordering, so dts will be set from pts by the generic code.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
The generic code can only handle the no-delay case. Encoders with delay need to be handled individually, which will be done in the following commits.
-