WebPAnimEncoder API is a combination of encoder (WebPEncoder) and muxer
(WebPMux). It performs several optimizations to make it more efficient
than the combination of WebPEncode() and native ffmpeg muxer.
When WebPAnimEncoder API is used:
- In the encoder layer: we use WebPAnimEncoderAdd() instead of
WebPEncode().
- The muxer layer: works like a raw muxer.
On the other hand, when WebPAnimEncoder API isn't available, the old code is
used as it is:
- In the codec layer: WebPEncode is used to encode each frame
- In the muxer layer: ffmpeg muxer is used
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Sufficiently new nvenc hardware (GM20x or later) has support for H.265
encoding. This works the same as the H.264 encoder except the
codec parameters are different.
Due to the fact that common codec parameters are not shareable, there's
quite a bit of conditional logic you'd wish we could do without, but
such is life.
Signed-off-by: Philip Langdale <philipl@overt.org>
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
* commit 'b21af32aed7e343f962753943e9f16baedfb1750':
lavc: Prefer x264 over openh264 if both libraries are available
See: ddae03f69b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anshul Maheshwari <anshul.ffmpeg@gmail.com>
To test Closed caption use following command
ffmpeg -f lavfi -i "movie=input.ts[out0+subcc]" -map s output.srt
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Compared to existing, common opensource H264 encoders, this can be
useful since it has got a different license (BSD instead of GPL).
Performance- and qualitywise it is comparable to x264 in ultrafast
mode.
Hooking it up as an encoder in libavcodec also simplifies comparing
it against other common encoders.
This requires OpenH264 1.3 or newer. Since the OpenH264 API and ABI
changes frequently, only releases are supported.
To take advantage of the OpenH264 patent offer, the OpenH264 library
must not be redistributed, but downloaded at runtime at the end-user's
system.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure the default behaviour of using the internal encoder
stays the same regardless if libtwolame is enabled or not (as for
any external library).
This fixes fate-lavf-mpg if libav is built with libtwolame enabled.
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Based off the srt encoder. The following features are unimplemented:
- fonts, colors, sizes
- alignment and positioning
The rest works well. For example, use ffmpeg to convert subtitles into the .vtt format:
ffmpeg -i input.srt output.vtt
Signed-off-by: Aman Gupta <ffmpeg@tmm1.net>
Signed-off-by: Clément Bœsch <u@pkh.me>
* commit 'b70d7a4ac72d23f3448f3b08b770fdf5f57de222':
lavc: add a native Opus decoder.
Conflicts:
Changelog
configure
libavcodec/version.h
Fate tests pass with both avresample as well as swresample based opus decoder, but
are disabled (reference files are very large so i want to think a day or 2 about
if theres an alternative or if they could be avoided, they also dont match the
official samples)
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Initial implementation by Andrew D'Addesio <modchipv12@gmail.com> during
GSoC 2012.
Completion by Anton Khirnov <anton@khirnov.net>, sponsored by the
Mozilla Corporation.
Further contributions by:
Christophe Gisquet <christophe.gisquet@gmail.com>
Janne Grunau <janne-libav@jannau.net>
Luca Barbato <lu_zero@gentoo.org>
It leverages the new hwaccel 1.2 features:
- get_buffer2 is never called
- the internal context is automatically initialized/deinitialized
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '6f273093e54cba130f3ffde3d6433e74baa4ad89':
LucasArts SMUSH VIMA audio decoder
Conflicts:
Changelog
libavcodec/avcodec.h
libavcodec/codec_desc.c
libavcodec/version.h
libavcodec/vima.c
This commit adds a AV_CODEC_ID_ADPCM_VIMA alias in addition to the previously
used AV_CODEC_ID_VIMA, as well as a AVCodec with name "adpcm_vima" in addition
to the previously used name "vima"
These changes are needed for compatibility with the renamed codec in libav
See: b18357326c and others
Merged-by: Michael Niedermayer <michaelni@gmx.at>
