| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
* commit 'fe66671bd5f446f8d0a9c70968ba8fe891efe028':
cmdutils: Check for and report the correct codec capability
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '3c5cf2a31b4b29a8e4282cbe6a3f0617c14698b8':
screenpresso: Drop parameter change check
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| | |
Size can never change, allowing us to use ff_reget_buffer, and to
simplify the code a little.
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '447b5b278c689b21bbb7b5747c8773145cbd9448':
mpegvideo_enc: Fix encoding videos with less frames than the delay of the encoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
encoder
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>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '27eeee76b2546fd313808997b3d07ba9cce94551':
mpegvideo_enc: Merge ifs with identical conditions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'f0a88d4d2a74534460f4a8b79c448bd5890dbd41':
mpegvideo_enc: Factor new_picture unref out
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '533a6198505edd1379e1cd722852350ae4a85acc':
innoHeim/Rsupport Screen Capture Codec decoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '233d2fa0443197df12b4f7823d591dad964149b3':
kvazaar: Add libkvazaar HEVC encoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| | |
Signed-off-by: Arttu Ylä-Outinen <arttu.yla-outinen@tut.fi>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
| |
| |
| |
| | |
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '18f9308e6a96bbeb034ee5213a6d41e0b6c2ae74':
mpjpeg: Cope with multipart lacking the initial CRLF
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some server in the wild do not put the boundary at a newline
as rfc1347 7.2.1 states.
Cope with that by reading a line and if it is not empty reading
a second one.
Reported-By: bitingsock
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '22f4d9c303ede1a240538fd105c97047db40dc86':
img2enc: Make sure the images are atomically written
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| | |
Users that want to generate a live-preview and serve it
would otherwise get partial images.
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '1ec72c6c68dbc78bf4ebb6f06c13316dc488bdfa':
libx264: Make sure the extradata are padded
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '5ea5a24eb70646a9061b85af407fcbb5dd4f89fd':
movenc: Honor flush requests with delay_moov, when some tracks lack samples
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This also makes sure that a fragmented file without the empty_moov
flag (i.e. with a non-empty initial moov fragment) actually gets
written, if some of the tracks turn out to not have any samples.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'e02dcdf6bb6835ef4b49986b85a67efcb3495a7f':
rtsp: Allow $ as interleaved packet indicator before a complete response header
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some RTSP servers ("HiIpcam/V100R003 VodServer/1.0.0") respond to
our keepalive GET_PARAMETER request by a truncated RTSP header
(lacking the final empty line to indicate a complete response
header). Prior to 764ec70149, this worked just fine since we
reacted to the $ as interleaved packet indicator anywhere.
Since $ is a valid character within the response header lines,
764ec70149 changed it to be ignored there. But to keep
compatibility with such broken servers, we need to at least
allow reacting to it at the start of lines.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'dca23ffbc7568c9af5c5fbaa86e6a0761ecae50c':
lavc: Deprecate AVPicture structure and related functions
Deprecation flag on AVPicture struct replaced by a comment, as it causes
excess deprecation warnings for every include of avcodec.h
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This structure served as a bridge between data pointers and frames,
but it suffers from several limitations:
- it is not refcounted and data must be copied to every time
- it cannot be expanded without ABI break due to being used on the stack
- its functions are just wrappers to imgutils which add a layer of
unneeded indirection, and maintenance burden
- it allows hacks like embedding uncompressed data in packets
- its use is often confusing to our users
AVFrame provides a much better API, and, if a full blown frame is not
needed, it is just as simple and more straightfoward to use data and
linesize arrays directly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
| |
| |
| |
| | |
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| |
| | |
Signed-off-by: AppChecker <support.appc@cnpo.ru>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
HWAccels with frame threads are fundamentally flawed in avcodecs current
design, and there are several known problems ranging from image corruption
to driver crashes.
These problems come down to two design problems in the interaction of
threads and HWAccel decoding:
(1)
While avcodec prevents parallel decoding and as such simultaneous access
to the hardware accelerator from the decoding threads, it cannot account
for the user code and its access to the hardware surfaces and the hardware
itself.
This can result in image corruption or even driver crashes if the
user code locks image surfaces while they are being used by the decoder
threads as reference frames.
The current HWAccel API does not offer any way to ensure exclusive access
to the hardware or the surfaces if frame threading is used.
(2)
Initialization of the HWAccel with frame threads is non-trivial, and many
decoders had and still have issues that cause excess calls to the
get_format callback.
This will potentially cause duplicate HWAccel initialization, which in
extreme cases can even lead to driver crashes if the HWAccel is
re-initialized while the user code is actively accessing the hardware
surfaces associated with it, or lead to image corruption due to lost
reference frames.
While both of these issues are solvable, fixing (1) would at least require
a huge API redesign which would move a lot of complexity into the user
code.
The only reason the combination of frame threads and HWAccel was
considered useful is to allow a seamless fallback to multi-threaded
software decoding if the HWAccel is not available, however the issues
outlined above far outweigh this.
The proper solution for a fallback is to re-open the AVCodecContext with
threading enabled if the HWAccel failed, which is a practice commonly used
by various user applications using avcodec today already.
Reviewed-by: Gwenole Beauchesne <gb.devel@gmail.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| |
| |
| |
| | |
Clang prerelease on Darwin is making the test fail.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Found-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
| |
| |
| |
| | |
They barely fail on some systems by being off by 0.81.
|
| |
| |
| |
| |
| |
| |
| | |
Fixes crashes on fuzzed files
Fixes Ticket4969 part2
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| |
| |
| |
| | |
Fixes crash
Fixes Ticket4969 part 1
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| | |
Signed-off-by: Kyle Swanson <k@ylo.ph>
|
| | |
|
| |
| |
| |
| | |
option
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Apple dev specification:
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html
Basically the structure is like:
|--meta
|----hdlr
|----keys
|----ilst
1) The handler type in the metadata handler atom is ‘mdta’.
2) The key and value are stored separately for each key-value pair.
The 'keys' atom stores the key table, while 'ilst' atom stores the
values corresponding to the indices in the key table.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| | |
|
| |
| |
| |
| |
| |
| | |
Instead just warn, and use the parse fps normally.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a fate failure after bumping the minor version
Its unknown why this is not needed for the other aac tests,
more investigation needed but for now i dont want to leave
it broken while its investigated
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
filter_slice calls qsort, so qsort is in a performance critical
position. AV_QSORT is substantially faster due to the inlining of the
comparison callback. Thus, the increase in performance is worth the
increase in binary size.
Sample benchmark (x86-64, Haswell, GNU/Linux),
filter-removegrain-mode-02 (from FATE)
new:
24060 decicycles in qsort, 1 runs, 0 skips
15690 decicycles in qsort, 2 runs, 0 skips
9307 decicycles in qsort, 4 runs, 0 skips
5572 decicycles in qsort, 8 runs, 0 skips
3485 decicycles in qsort, 16 runs, 0 skips
2517 decicycles in qsort, 32 runs, 0 skips
1979 decicycles in qsort, 64 runs, 0 skips
1911 decicycles in qsort, 128 runs, 0 skips
1568 decicycles in qsort, 256 runs, 0 skips
1596 decicycles in qsort, 512 runs, 0 skips
1614 decicycles in qsort, 1024 runs, 0 skips
1874 decicycles in qsort, 2046 runs, 2 skips
2186 decicycles in qsort, 4094 runs, 2 skips
old:
246960 decicycles in qsort, 1 runs, 0 skips
135765 decicycles in qsort, 2 runs, 0 skips
70920 decicycles in qsort, 4 runs, 0 skips
37710 decicycles in qsort, 8 runs, 0 skips
20831 decicycles in qsort, 16 runs, 0 skips
12225 decicycles in qsort, 32 runs, 0 skips
8083 decicycles in qsort, 64 runs, 0 skips
6270 decicycles in qsort, 128 runs, 0 skips
5321 decicycles in qsort, 256 runs, 0 skips
4860 decicycles in qsort, 512 runs, 0 skips
4424 decicycles in qsort, 1024 runs, 0 skips
4191 decicycles in qsort, 2046 runs, 2 skips
4934 decicycles in qsort, 4094 runs, 2 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|