- 03 Jun, 2019 3 commits
-
-
Ruiling Song authored
benchmarking with a simple command: ffmpeg -i 1080p.mp4 -vf unsharp=la=3:ca=3 -an -f null /dev/null with the patch, the fps increase from 50 to 120 on my local machine (i7-6770HQ). Signed-off-by: Ruiling Song <ruiling.song@intel.com>
-
Jun Zhao authored
Used the command for 1080p h264 clip as follow: a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null after enabled the slice threading, the fps change from: a). 144fps to 258fps (lutyuv) b). 94fps to 153fps (lutrgb) in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
-
Jun Zhao authored
Add slice threading support, use the command like: ./ffmpeg -i input -vf colorlevels -f null /dev/null with 1080p h264 clip, the fps from 39 fps to 79 fps in the local(Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz) Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
-
- 02 Jun, 2019 19 commits
-
-
Mark Thompson authored
Tries to find a device backed by the i915 kernel driver and loads the iHD VAAPI driver to use with it. This reduces confusion on machines with multiple DRM devices and removes the surprising requirement to set the LIBVA_DRIVER_NAME environment variable to use libmfx at all.
-
Mark Thompson authored
Opening the device via X11 (DRI2/DRI3) rather than opening a DRM render node directly is only useful if you intend to use the legacy X11 interop functions. That's never true for the ffmpeg utility, and a library user who does want this will likely provide their own display instance rather than making a new one here.
-
Mark Thompson authored
For example: -init_hw_device vaapi:/dev/dri/renderD128,driver=foo This may be more convenient that using the environment variable, and allows loading different drivers for different devices in the same process.
-
Mark Thompson authored
Iterate over available render devices and pick the first one which looks usable. Adds an option to specify the name of the kernel driver associated with the desired device, so that it is possible to select a specific type of device in a multiple-device system without knowing the card numbering. For example: -init_hw_device vaapi:,kernel_driver=amdgpu will select only devices using the "amdgpu" driver (as used with recent AMD graphics cards). Kernel driver selection requires libdrm to work.
-
Mark Thompson authored
Can be set to "drm" or "x11" to force a specific connection type.
-
Mark Thompson authored
The implementation will use some default in this case. The empty string is not a meaningful device for any existing hardware type, and indeed OpenCL treats it identically to no device already to work around the lack of this setting on the command line.
-
Mark Thompson authored
-
Mark Thompson authored
Cropping is not supported by VAAPI encode.
-
Mark Thompson authored
The "out_color_matrix" and "out_range" properties match the same options in vf_scale; the others attempt to follow the same pattern.
-
Mark Thompson authored
Attempts to pick the set of supported colour properties best matching the input. Output is then set with the same values, except for the colour matrix which may change when converting between RGB and YUV.
-
Mark Thompson authored
Parameter buffer creation can fail.
-
Mark Thompson authored
Also enables cropping on all VAAPI filters, inherited from the existing support in scale_vaapi.
-
Mark Thompson authored
-
Mark Thompson authored
Set the cropping fields in the AVFrame.
-
Steven Liu authored
And fix typo of the 1833 of hlsenc.c Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro> Signed-off-by: Steven Liu <lq@onvideo.cn>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
- 01 Jun, 2019 2 commits
-
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Steven Liu authored
Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
- 31 May, 2019 4 commits
-
-
Michael Niedermayer authored
Improves: Timeout (355sec -> 97sec) Improves: 14709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5704215281795072 Reviewed-by: Paul B Mahol <onemda@gmail.com> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
-
Michael Niedermayer authored
This is based on target_dec_fuzzer Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Carl Eugen Hoyos authored
Fixes two warnings: libavfilter/avf_showspatial.c:157:26: warning: variable ‘w’ set but not used libavfilter/avf_showspatial.c:157:23: warning: variable ‘h’ set but not used
-
Paul B Mahol authored
-
- 30 May, 2019 4 commits
-
-
Nick Renieris authored
Additionally: - Renamed TIFF_WHITE_LEVEL to DNG_WHITE_LEVEL since it is specified in the DNG spec. - Added/changed some comments to be more precise in differentiating between TIFF, TIFF/EP and DNG values. Related to ticket: https://trac.ffmpeg.org/ticket/4364Signed-off-by: Nick Renieris <velocityra@gmail.com>
-
Nick Renieris authored
SubIFDs that were part of more than single-sized "SubIFDs" tags were being ignored due to existing code ignoring that case. This patch makes is so the first entry is read, which is not ideal but enough for some DNG images present in the wild to be decodeable More specifically, the first SubIFD which we would process with this patch is the main image and the second one is a second thumbnail, which is not as important to decode. In DNG images with the .tiff extension, it solves the issue where the TIFF thumbnail in IFD 0 was incorrectly parsed (related confusion: [1]). Embedded thumbnails for DNG images can still be decoded with the "-thumbnail" option. Related to ticket: https://trac.ffmpeg.org/ticket/4364 [1]: https://superuser.com/questions/546879/creating-video-from-dng-images-with-ffmpegSigned-off-by: Nick Renieris <velocityra@gmail.com>
-
Nick Renieris authored
Adds the "-thumbnail" option, that works like the current "-subifd" option, but only for non-full-sized images. This is particularly useful for DNG images (see next commit) that have SubIFDs that are not necessarily thumbnails. Signed-off-by: Nick Renieris <velocityra@gmail.com>
-
Linjie Fu authored
Currently, picref will be freed by calling av_frame_free(&picref) in submit_frame() in qsvvpp.c when working in system memory mode,and normally it is freed in filter_frame() in vf_vpp_qsv.c when working in other modes. Double free happens when working in system memory mode, remove to fix the memory issue. Reproduce: ffmpeg -init_hw_device qsv=foo -filter_hw_device foo -f rawvideo -pix_fmt nv12 -s:v 852x480 \ -i 852x480.nv12 -vf 'vpp_qsv=w=500:h=400' -f rawvideo -pix_fmt nv12 qsv.nv12 Signed-off-by: Linjie Fu <linjie.fu@intel.com> Signed-off-by: Zhong Li <zhong.li@intel.com>
-
- 29 May, 2019 1 commit
-
-
Paul B Mahol authored
Fixes crash when writting trailer without any previous packets.
-
- 28 May, 2019 7 commits
-
-
James Almer authored
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>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
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. For the same reason 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>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Paul B Mahol authored
-
Paul B Mahol authored
-