- 11 May, 2016 1 commit
-
-
Diego Biurrun authored
This avoids unused variable warnings after the next version bump. Also drop a trace level av_log() call that is in the way.
-
- 04 May, 2016 1 commit
-
-
Vittorio Giovara authored
Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
- 26 Feb, 2016 1 commit
-
-
Anton Khirnov authored
-
- 21 Jan, 2016 11 commits
-
-
Vittorio Giovara authored
This option is only used by mpegvideoenc. It is a very codec-specific option, so deprecate the global variant. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is only used by mpegvideoenc. It is a very codec-specific options, so deprecate the global variant. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This options is only used by huffyuv, ffvhuv, jpegls, mjpeg, mpegvideoenc, png, utvideo. It is a very codec-specific options, so deprecate the global variant. Set proper limits to the maximum allowed values, and update utvideoenc tests to use the new option name. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is only used by mpegvideoenc and openh264. It is a very codec-specific option, so deprecate the global variant. The openh264 option is dropped altogether since it is just a fallback for -max_nal_size anyway. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is only used by mpegvideoenc, and xvid. It is a very codec-specific option, so deprecate the global variant. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is only used by mpegvideoenc, x264, xavs, and vpx. It is a very codec-specific option, so deprecate the global variant. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is only used by mpegvideoenc, x264, and xavs. It is a very codec-specific option, so deprecate the global variant. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
These options are only used by mpegvideoenc and vpx. They are very codec-specific options, so deprecate the global variants. Add an allowed value to the private options for frame_skip_cmp which seems to have been forgotten, but perfectly working. The libvpx frame dropping feature uses one of such option (frame_skip_threshold) without the other three. For this reason rename the option to something more consistent with the other libvpx variables. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is only used by mpegvideoenc, It is a very codec-specific option, so deprecate the global variant. Set proper limits to the maximum allowed values. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
The b_frame_strategy option is only used by mpegvideoenc, qsv, x264, and xavs, while b_sensitivity is only used by mpegvideoenc. These are very codec-specific options, so deprecate the global variants. Set proper limits to the maximum allowed values. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Michael Niedermayer authored
Fixes assertion failure Fixes: 6568d187979ce17878b6fe5fbbb89142/signal_sigabrt_7ffff6ae7cb7_7176_564bbc6741bdcf907f5c4e685c9a77a2.mpg Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 12 Jan, 2016 1 commit
-
-
Michael Niedermayer authored
Fixes assertion failure Fixes out of memory access Fixes: test_casex.ivf Found-by:
Tyson Smith <twsmith@mozilla.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 06 Jan, 2016 1 commit
-
-
Michael Niedermayer authored
Fixes out of array read Fixes: test_case-mdc.264 (b47be15a120979f5a1a945c938cbef33) Found-by:
Tyson Smith <twsmith@mozilla.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 05 Jan, 2016 1 commit
-
-
Michael Niedermayer authored
Fixes out of array read Found-by:
Tyson Smith <twsmith@mozilla.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 12 Dec, 2015 1 commit
-
-
Anton Khirnov authored
Fixes 2507b5dd
-
- 07 Dec, 2015 1 commit
-
-
Vittorio Giovara authored
These variables are coming from mpegvideoenc where are supposedly used as bit counters on various frame properties. However their use is unclear as they lack documentation, are available only from a very small subset of encoders, and they are hardly used in the wild. Also frame_bits in aacenc is employed in a similar way. Remove this functionality from AVCodecContex, these variable are mostly frame properties, and too few encoders support setting them with anything useful. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 06 Dec, 2015 2 commits
-
-
Anton Khirnov authored
Deprecate AVCodecContext.vbv_delay
-
Anton Khirnov authored
-
- 04 Dec, 2015 1 commit
-
-
Clément Bœsch authored
-
- 23 Nov, 2015 1 commit
-
-
Michael Niedermayer authored
avcodec/mpegvideo_enc: Remove slice structured mode from H.263 as well as the code automatically enabing it There is no such thing as a slice structured mode in the original version 1 H.263, that mode was added in H.263+ in 1998. Also the headers for slice structured mode are not part of the older version 1 and this would result in unplayable files An alternative to this patch would be to merge the H263 and H263P AVCodecs and use other means to distinguish the older and newer versions. Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 20 Nov, 2015 3 commits
-
-
Vittorio Giovara authored
This function returns the encoded data of a frame, one slice at a time directly when that slice is encoded, instead of waiting for the full frame to be done. However this field has a debatable usefulness, since it looks like it is just a convoluted way to get data at lowest possible latency, or a somewhat hacky way to store h263 in RFC-2190 rtp encapsulation. Moreover when multi-threading is enabled (which is by default) the order of returned slices is not deterministic at all, making the use of this function not reliable at all (or at the very least, more complicated than it should be). So, for the reasons stated above, and being used by only a single encoder family (mpegvideo), this field is deemed unnecessary, overcomplicated, and not really belonging to libavcodec. Libavformat features a complete implementation of RFC-2190, for any other case. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Anton Khirnov authored
Currently, multiple slices with just one thread produce corrupted output. Additionally, enable slice structured mode for h263(+) Bug-Id: 912 CC: libav-stabl@libav.org
-
Anton Khirnov authored
They do not work and produce corrupted output. CC: libav-stable@libav.org
-
- 26 Oct, 2015 1 commit
-
-
Luca Barbato authored
`av_packet_unref` matches the AVFrame ref-counted API and can be used as a drop in replacement. Deprecate `av_free_packet`.
-
- 25 Oct, 2015 3 commits
-
-
Alexis Ballier authored
When the encoder is fed with less frames than its delay, the picture list looks like { NULL, NULL, ..., frame, frame, frame }. When flushing the encoder (input frame == NULL), we need to ensure the picture list is shifted enough so that we do not return an empty packet, which would mean the encoder has finished, while it has not encoded any frame. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 18 Oct, 2015 3 commits
-
-
Alexis Ballier authored
When the encoder is fed with less frames than its delay, the picture list looks like { NULL, NULL, ..., frame, frame, frame }. When flushing the encoder (input frame == NULL), we need to ensure the picture list is shifted enough so that we do not return an empty packet, which would mean the encoder has finished, while it has not encoded any frame. Before the patch, the command: './ffmpeg_g -loglevel debug -f lavfi -i "testsrc=d=0.01" -bf 2 -vcodec mpeg2video out.mxf' prints: Output stream #0:0 (video): 1 frames encoded; 0 packets muxed (0 bytes); After: Output stream #0:0 (video): 1 frames encoded; 1 packets muxed (8058 bytes); Relates to ticket #4817. Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 12 Oct, 2015 1 commit
-
-
Christophe Gisquet authored
Dequant or encoding were trying to reverse a scan that hadn't been applied... Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 09 Oct, 2015 1 commit
-
-
Ganesh Ajjanagadde authored
This should fix the first undefined behavior reported in: https://trac.ffmpeg.org/ticket/4727. I can't reproduce the runtime behavior reported in the ticket, hence I can't confirm that this actually fixes the exact issue reported in the ticket. Regardless, I can confirm that this is a genuine issue, and that negative shifts can (and do) occur, fixed by this. Tested with FATE. Signed-off-by:
Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 30 Sep, 2015 1 commit
-
-
Vittorio Giovara authored
These field are difficult to interpret, and are provided by a single encoder (mpegvideoenc). In general they do not belong to a structure containing raw data only, so remove them from AVFrame. Mpegvideoenc now uses a private field in Picture for its internal computations. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 29 Sep, 2015 1 commit
-
-
Vittorio Giovara authored
-
- 22 Sep, 2015 1 commit
-
-
Michael Niedermayer authored
Reduces the number of times the vbv retry code is used and should have no effect on quality Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 18 Sep, 2015 2 commits
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-