- 29 Apr, 2020 7 commits
-
-
Steven Liu authored
Because not every user know about in_pad and out_pad reasonable value range so maybe try to set 1.0, but setting 1.0 is so hugh to get an fatal error. Suggested-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
Linjie Fu authored
Signed-off-by: Linjie Fu <linjie.fu@intel.com> Signed-off-by: Josh de Kock <josh@itanimul.li>
-
Josh Brewster authored
The current implementation allows passing levels to libavcodec as integers (such as "31" instead of "3.1"). However, in this case, the maximum reference frame value per level was ignored because libavcodec converted the string to 310 instead of 31. Since libx264 has correctly parsed the level to int (x4->params.i_level_idc), we should rely on this value instead of attempting to parse the level string on our own. Signed-off-by: Josh Brewster <josh.brewster@protonmail.com> Signed-off-by: Josh de Kock <josh@itanimul.li>
-
Jun Zhao authored
Follow the http://id3.org/ID3v1, setting the year metadata for ID3v1. fix #8623 Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
- 28 Apr, 2020 2 commits
-
-
Andriy Gelman authored
Without this setting, bitrate and qmin/qmax options have no effect on the s5p-mfc hardware encoder. Reviewed-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Andriy Gelman authored
Currently the user gets unhelpful warnings when some default parameters are not supported by the device. The verbosity of these log messages has been changed to AV_LOG_DEBUG. Reviewed-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
- 27 Apr, 2020 2 commits
-
-
Andreas Rheinhardt authored
libswscale/vscale.c makes extensive use of function pointers and in doing so it converts these function pointers to and from a pointer to void. Yet this is actually against the C standard: C90 only guarantees that one can convert a pointer to any incomplete type or object type to void* and back with the result comparing equal to the original which makes pointers to void generic pointers to incomplete or object type. Yet C90 lacks a generic function pointer type. C99 additionally guarantees that a pointer to a function of one type may be converted to a pointer to a function of another type with the result and the original comparing equal when converting back. This makes any function pointer type a generic function pointer type. Yet even this does not make pointers to void generic function pointers. Both GCC and Clang emit warnings for this when in pedantic mode. This commit fixes this by using a union that can hold one member of any of the required function pointer types to store the function pointer. This works even for C90. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Mark Thompson authored
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
-
- 26 Apr, 2020 14 commits
-
-
Marton Balint authored
Current muxers only use a single bitstream filter, so there is no need to maintain code which operates on a list of bitstream filters. When multiple bitstream filters are needed muxers can simply use a list bitstream filter. If there is a use case in the future when different bitstream filters should be added at subsequent packets then a new API possibly involving reconfiguring the list bitstream filter can be added knowing the exact requirements. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
These tests are also in the same size range as the previously skipped 2k and 4k tests. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Mark Thompson authored
The ad-hoc libmfx setup code is the only place its still used, so move it into that file.
-
Mark Thompson authored
This can support encoders which want frames and/or device contexts. For the device case, it currently picks the first initialised device of the desired type to give to the encoder - a new option would be needed if it were necessary to choose between multiple devices of the same type.
-
Mark Thompson authored
Also move it into a dedicated function in the hardware file.
-
Mark Thompson authored
These encoders all accept VAAPI surfaces in a hardware frames context.
-
Mark Thompson authored
All of these encoders can accept libmfx surfaces directly in a hardware frames context, or they can accept software frames if a suitable device is supplied to use.
-
Mark Thompson authored
-
Mark Thompson authored
This already applied to decoders as well as hwaccels, and adding encoder support was going to make the name even more inaccurate.
-
Michael Niedermayer authored
avcodec/cbs_h265_syntax_template: Check num_negative/positive_pics when inter_ref_pic_set_prediction_flag is set Fixes: out of array access Fixes: 20446/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5707770718584832 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: Timeout (105sec -> 1sec) Fixes: 20479/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5769846937878528 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
-
- 25 Apr, 2020 8 commits
-
-
Michael Niedermayer authored
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int32_t' (aka 'int') Fixes: 21245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5683334274613248 Change to int16_t suggested by Lynne Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Lynne <dev@lynne.ee> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
-
Paul B Mahol authored
Also set state to ready if there is any inlink with queued frame.
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Peter Ross authored
Signed-off-by: Peter Ross <pross@xvid.org> Reviewed-by: Marton Balint <cus@passwd.hu>
-
Peter Ross authored
Signed-off-by: Peter Ross <pross@xvid.org> Reviewed-by: James Almer <jamrial@gmail.com>
-
Jun Zhao authored
bump minor version for DOVI sidedata, because added the dovi_meta.h as lavu API part. Also update APIchanges. Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
-
- 24 Apr, 2020 7 commits
-
-
Zane van Iperen authored
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Martin Storsjö authored
This fixes tests on 32 bit x86 mingw with clang, which uses x87 fpu by default. In this setup, while the get_expected function is declared to return float, the compiler is (especially given the optimization flags set) free to keep the intermediate values (in this case, the return value from the inlined function) in higher precision. This results in the situation where 7.28 (which actually, as a float, ends up as 7.2800002098), multiplied by 100, is 728.000000 when really forced into a 32 bit float, but 728.000021 when kept with higher intermediate precision. For the multiplication case, a more suitable epsilon would e.g. be 2*FLT_EPSILON*fabs(expected_output), but just increase the current hardcoded threshold for now. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Andreas Rheinhardt authored
libavutil/mem.h is unneeded since 33d18982, the commit that introduced the new packet-based bsf API, because with this switch the allocations were no longer performed directly, but by av_new_packet(). Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
With 33d18982, the commit introducing the new packet-based bsf API, a new buffer was no longer allocated directly, but via av_new_packet(), so that libavutil/mem.h was no longer needed. Moreover since commit dc99ee6b av_packet_make_writable() is employed which copies the data in case it is unavoidable so that string.h is no longer used (it was used for memcpy()). Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Since 33d18982 (the commit that introduced the new bsf API) allocating an enlarged buffer in case extradata needs to be added to a packet is done via av_new_packet(), so that libavutil/mem.h is no longer needed. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
This bsf never needed libavutil/mem.h. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
This bsf never needed internal.h. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-