This improves network throughput of the hls demuxer by avoiding
the latency introduced by downloading segments one at a time.
The problem is particularly noticable over high-latency network
connections: for instance, if RTT is 250ms, there will a 250ms idle
period between when one segment response is read and the next one
starts.
The obvious solution to this is to use HTTP pipelining, where a
second request can be sent (on the persistent http/1.1 connection)
before the first response is fully read. Unfortunately the way the
http protocol is implemented in avformat makes implementing pipleining
very complex.
Instead, this commit simulates pipelining using two separate persistent
http connections. This has the advantage of working independently of
the http_persistent option, and can be used with http/1.0 servers as
well. The pair of connections is swapped every time a new segment starts
downloading, and a request for the next segment is sent on the secondary
connection right away. This means the second response will be ready and
waiting by the time the current response is fully read.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
This teaches the HLS demuxer to use the HTTP protocols
multiple_requests=1 option, to take advantage of "Connection:
Keep-Alive" when downloading playlists and segments from the HLS server.
With the new option, you can avoid TCP connection and TLS negotiation
overhead, which is particularly beneficial when streaming via a
high-latency internet connection.
Similar to the http_persistent option recently implemented in hlsenc.c
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
- 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>
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).
