If the user-supplied color in drawbox and drawgrid filters is non-opaque,
the box & grid painting overwrites the input's pixels (including alpha).
Users typically expect the alpha of the specified color to only act as a key
for compositing on top of the main input.
Added option allows users to select between replacement and composition.
Tested and documented.
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Merges Libav commit 47687a2f8a.
Additionally:
* Mention that allrgb and allyuv do not support the "size" option.
* Separate examples into subsection.
Fixes ticket #6906.
Signed-off-by: Lou Logan <lou@lrcd.com>
The Developer Documentation had instructions to
subscribe to the ffmpeg-cvslog email list. But that is
no longer accurate. For the purposes in this section --
review of patches, discussion of development issues --
ffmpeg_devel is the appropriate email list. Some developers
may want to monitor ffmpeg-cvslog, but it is not mandatory.
This is v3 of this doc, based on discussion in thread
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220528.html>
and in response to docs Maintainer comments in
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221596.html>.
1. In doc/developer.texi, add a new section about
ffmpeg-devel, based on existing text from ffmpeg-cvslog
section regarding discussion of patches and of
development issues. Reflect wording from discussion at
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221199.html>
but with copy-editing to make wording more concise.
2. In doc/developer.texi, rewrite the ffmpeg-cvslog section
to match the current usage of ffmpeg-cvslog. Some
developers choose to follow this list, but it is not
mandatory.
There are a lot of improvements possible to the
Developer Documentation page, beyond this refactoring.
However, making those improvements is a much bigger
and more difficult task. This change is "low hanging
fruit".
Signed-off-by: Jim DeLaHunt <from.ffmpeg-dev@jdlh.com>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Previously, the Developer Documentation <ffmpeg.org/developer.html>
contained a single chapter, "1. Developer Guide," with all content under
that single chapter. Thus the document structure was one level deeper
and more complicated than it needed to be. It differed from similar
documents such as /faq.html, which have multiple chapters.
Eliminate the single chapter, and promote each section underneath to
chapter, and each subsection to section. Thus content and relative
structure remains the same, but the overall structure is simpler.
Anchors within the page remain the same.
Signed-off-by: Jim DeLaHunt <from.ffmpeg-dev@jdlh.com>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
This is to take full advantage of Common Media Application Format(CMAF).
Now server can generate one content and serve both HLS and DASH players.
Reviewed-by: Steven Liu <lq@onvideo.cn>
Corpus VBR mode is a variant of standard VBR where the complexity
distribution midpoint is passed in rather than calculated for a specific
clip or chunk.
The valid range is [0, 10000]. 0 (default) uses standard VBR.
Signed-off-by: James Zern <jzern@google.com>
Supports only raw NV12 input.
Example use:
./vaapi_encode 1920 1080 test.yuv test.h264
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Liu, Kaixuan <kaixuan.liu@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
The present value name for maximum thickness is 'max' which results in a
parse error of any thickness expression containing 'max(val1,val2)'.
Value renamed to 'fill'. Tested locally and documented.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was added in early 2013 and abandoned several months later; as far as
I can tell, there are no external users. Future OpenCL use will be via
hwcontext, which requires neither special OpenCL-only API nor global state
in libavutil.
All internal users are also deleted - this is just the unsharp filter
(replaced by unsharp_opencl, which is more flexible) and the deshake filter
(no replacement).
Add two FAQs about running FFmpeg in the background.
The first explains the use of the -nostdin option in
a straightforward way. Text revised based on review.
The second FAQ starts from a confusing error message,
and leads to the solution, use of the -nostdin option.
The purpose of the second FAQ is to attract web searches
from people having the problem, and offer them a solution.
Add an anchor to the Main Options section of the ffmpeg
documentation, so that the FAQs can link directly there.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For some strange reason "-t" option was only implemented
for input files while both "-t" and "-to" were available
for use for output files. This made extracting a range from
input file inconvenient.
This patch enables -to option for input so one can do
ffmpeg -ss 1:23:20 -to 1:27:22.3 -i myinput.mkv ...
Signed-off-by: Vitaly _Vi Shukela <vi0oss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
James Almer
Mark Thompson
Gyan Doshi
wm4
Lou Logan
Paul B Mahol
Jim DeLaHunt
sfan5
Karthick J
James Zern
Jun Zhao
Vittorio Giovara
Richard Ling
Werner Robitza
Vishwanath Dixit
Carl Eugen Hoyos
Vitaly _Vi Shukela