- 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 10 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>
-
- 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
-
- 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>
-
- 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
-
- 27 Jul, 2015 3 commits
-
-
Vittorio Giovara authored
Express bitfields more simply. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
Convert doxygen to multiline and express bitfields more simply. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This option is extremely codec specific and only a few codecs employ it. Move it to codec private options instead: mpegenc family supports only 3 values, xavs and x264 use 5, and xvid has a different metric entirely. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 20 Jul, 2015 4 commits
-
-
Vittorio Giovara authored
The rationale is that coded_frame was only used to communicate key_frame, pict_type and quality to the caller, as well as a few other random fields, in a non predictable, let alone consistent way. There was agreement that there was no use case for coded_frame, as it is a full-sized AVFrame container used for just 2-3 int-sized properties, which shouldn't even belong into the AVCodecContext in the first place. The appropriate AVPacket flag can be used instead of key_frame, while quality is exported with the new AVPacketSideData quality factor. There is no replacement for the other fields as they were unreliable, mishandled or just not used at all. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
This is necessary to preserve the quality information currently exported with coded_frame. Add the new side data to every encoder that needs it, and use it in avconv. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
Allocating coded_frame is what most encoders do anyway, so it makes sense to always allocate and free it in a single place. Moreover a lot of encoders freed the frame with av_freep() instead of the correct API av_frame_free(). This bring uniformity to encoder behaviour and prevents applications from erroneusly accessing this field when not allocated. Additionally this helps isolating encoders that export information with coded_frame, and heavily simplifies its deprecation. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
coded_frame is already initialized where needed.
-
- 02 Jul, 2015 1 commit
-
-
Vittorio Giovara authored
They are used by dnxhd and mpegvideo_enc exclusively, move them to codec private options instead. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 12 Jun, 2015 3 commits
-
-
Vittorio Giovara authored
Having this macro in an header only facilitates the use of such header. The code increase is minimal and files have one less dependency on mpegvideo.h.
-
Vittorio Giovara authored
-
Vittorio Giovara authored
-
- 10 Jun, 2015 1 commit
-
-
Vittorio Giovara authored
Mark it as static.
-
- 08 Jun, 2015 2 commits
-
-
Vittorio Giovara authored
The main ff_alloc_picture() function is made more generic with all the parameters necessary as arguments. This will allows to move most of the related functions to a separate file later. Right now wrappers are provided to try and minimize the number of changes in the code.
-
Vittorio Giovara authored
-