- 30 Apr, 2020 14 commits
-
-
Lynne authored
This makes decoding far more robust, since OggS, the ogg magic, can be commonly found randomly in streams, which previously made the demuxer think there's a new stream or a change in such.
-
Lynne authored
This also makes implementing CRC checking far simpler and more robust.
-
Limin Wang authored
Reviewed-by:
Michael Niedermayer <michael@niedermayer.cc> Signed-off-by:
Limin Wang <lance.lmwang@gmail.com>
-
James Almer authored
We only care about the right most bit. Signed-off-by:
James Almer <jamrial@gmail.com>
-
Andriy Gelman authored
v4l2_m2m uses device memory mapped buffers to store dequeued frames/packets (reference counted by AVBufferRef). When the reference count drops to zero, the buffer ownership is returned back to the device, so that they can re-filled with frames/packets. There are some cases when all the capture buffers are in userspace (i.e. due to internal buffering in ffmpeg). On the s5p-mfc this causes an infinite wait when polling to dequeue the buffers, which can be prevented by increasing the total number of buffers. This commit adds a warning when all the capture buffers are dequeued. Reviewed-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
Andriy Gelman <andriy.gelman@gmail.com>
-
Martin Storsjö authored
Apparently the changes from 3c9185bf aren't enough; even with that in place, I got errors like this when trying to build for iOS: src/libavdevice/avfoundation.m:135:5: error: 'AVCaptureDeviceTransportControlsPlaybackMode' is unavailable: not available on iOS AVCaptureDeviceTransportControlsPlaybackMode observed_mode; ^
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
Use A in calculation.
-
Paul B Mahol authored
-
Josh de Kock authored
Signed-off-by:
Josh de Kock <josh@itanimul.li>
-
Andreas Rheinhardt authored
The data of an AVPacket may be a part of the data of an AVBufferRef; Therefore av_grow_packet() doesn't reallocate if the available space in the actual buffer is sufficient for the enlargement. But given that it also zeroes the padding it also needs to make sure that the buffer is actually writable; this commit implements this. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
hdsenc already had an explicit function to free all allocations in case of an error, but it was not marked as deinit function, so that it was not called automatically when the AVFormatContext for muxing gets freed. Using an explicit deinit function also makes the code cleaner by allowing to return immediately without "goto fail". Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Ming Qian authored
Enqueue/dequeue of the capture buffers should continue while draining. Reference: linux/Documentation/media/uapi/v4l/dev-decoder.rst "The client must continue to handle both queues independently, similarly to normal decode operation. This includes: ... - queuing and dequeuing CAPTURE buffers, until a buffer marked with the V4L2_BUF_FLAG_LAST flag is dequeued" Signed-off-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
Andriy Gelman <andriy.gelman@gmail.com>
-
- 29 Apr, 2020 21 commits
-
-
Michael Niedermayer authored
Found-by:
黄宁 <tsukimurarin@163.com> Reviewed-by:
Nick Renieris <velocityra@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
The DNG code hardcodes plane 0 at some places, so its better to disallow cases that have more planes. Fixes: eg_crash Found-by:
黄宁 <tsukimurarin@163.com> Reviewed-by:
Nick Renieris <velocityra@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
This is less confusing Reviewed-by:
Nick Renieris <velocityra@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
dng spec 1.5.0.0 "BitsPerSample Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if SamplesPerPixel is not equal to 1." Fixes: eg_crash Found-by:
黄宁 <tsukimurarin@163.com> Reviewed-by:
Nick Renieris <velocityra@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: Timeout (21sec -> 80ms) Fixes: 20673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TXD_fuzzer-5177453863763968 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 (21sec -> 255ms) Fixes: 20709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ1_fuzzer-5085075089915904 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Linjie Fu authored
"slice mode" option seems to be unnecessary since it could be determined by -slices/max_nal_size. default: SM_FIXEDSLCNUM_SLICE mode with cpu-number slices. -slices N: SM_FIXEDSLCNUM_SLICE mode with N slices. -max_nal_size: SM_SIZELIMITED_SLICE mode with limited size slices. Add FF_API_OPENH264_SLICE_MODE macro to remove this option after LIBAVCODEC_VERSION_MAJOR = 59. Signed-off-by:
Linjie Fu <linjie.fu@intel.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Linjie Fu authored
Libopenh264enc would set the slice according to the number of cpu cores if uiSliceNum equals to 0 (auto) in SM_FIXEDSLCNUM_SLICE mode. Prompt a warning for user to catch this. Signed-off-by:
Linjie Fu <linjie.fu@intel.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Linjie Fu authored
RC_BITRATE_MODE: set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust in RcCalculatePictureQp(). RC_BUFFERBASED_MODE: use buffer status to adjust the video quality. RC_TIMESTAMP_MODE: bit rate control based on timestamp, introduced in release 1.4. Default to use RC_QUALITY_MODE. Signed-off-by:
Linjie Fu <linjie.fu@intel.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Linjie Fu authored
It would be 200kbps bitrate with gop size = 12 by default which generated too many IDR frames in rather low bit rate. The quality would be poor. Set these default values to -1 to check whether it's specified by user explicitly. Use 2Mbps bitrate as nvenc sugguested, and leave gop size untouched in libopenh264. Signed-off-by:
Linjie Fu <linjie.fu@intel.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Linjie Fu authored
Clip iMinQp/iMaxQp to (1, 51) for user specified qp range. If not set, leave iMinQp/iMaxQp untouched and use the values (0, 51) initialized in FillDefault(), and the QP range would be adjusted to the defaults inside libopenh264 library according to the iUsageType, (12, 42) for iUsageType == CAMERA_VIDEO_REAL_TIME which is default. <https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/encoder_ext.cpp#L375> Signed-off-by:
Linjie Fu <linjie.fu@intel.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Paul B Mahol authored
Remove any usage of padding for this format.
-
Paul B Mahol authored
-
Limin Wang authored
Signed-off-by:
Limin Wang <lance.lmwang@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
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 1 commit
-
-
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>
-