- normalize score to [0..100] instead of [0..85]
- change the default score to 8.2 to roughly keep existing behaviour
- take into account bit depth
- do not truncate to integer

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: sfan5 <sfan5@live.de>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>

Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>

It was addressed in a5679933,
0c162854 and
5a366f97.

Signed-off-by: James Almer <jamrial@gmail.com>

Done in 9f00fa53 and
40b75a94.

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 47687a2f.

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>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.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>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Continues where commit 52c75d48 left off.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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>

Fixes CID #1424882.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@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>

This removes all remaining device-type specificity.

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>

Implement detection in h264 and hevc and insertion in framepack filter.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Also fix a typo and fill hashes and dates.

Signed-off-by: Paul B Mahol <onemda@gmail.com>