- 03 Oct, 2015 6 commits
-
-
Hendrik Leppkes authored
* commit '8ae1d87a': build: Add support for known custom allocators Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit '9a3202a9': Screenpresso SPV1 decoder Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Rodger Combs authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: https://trac.ffmpeg.org/attachment/ticket/685/movie.264 In the available testcase the actual PPS only uses a few bits while there are 7kbyte of apparently random data after it Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Hendrik Leppkes authored
* commit '1aa24df7': lavu: Deprecate AVFrame.error[] Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit '3f1f6053': configure: address a copy-paste typo Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
- 02 Oct, 2015 13 commits
-
-
Michael Niedermayer authored
This error was produced by rtmproto.c, it is possibly such streams where dumped, this commit is needed to support them Fixes: z0e.flv Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
wm4 authored
This affects Annex B streams (such as demuxed from .ts and others). It also handles the format change in reinit-large_420_8-to-small_420_8.h264 correctly. Instead of passing through the extradata, create it on the fly it from the currently active SPS and PPS. Since reconstructing the PPS and SPS NALs would be very complicated and verbose, we use the NALs as they originally appeared in the bitstream. The code for writing the extradata is somewhat derived from libavformat/avc.c, but it's small and different enough that sharing it is not really worth it.
-
wm4 authored
We assume an upper bound of 4096 bytes for each raw SPS/PPS. It's hard to determine an exact maximum size, but this value was was considered high enough and safe. Needed for the following VideotoolBox commit.
-
Christophe Gisquet authored
Otherwise, the dsp may change without its permuation being applied. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Christophe Gisquet authored
The current one, while correct, does not yield the best possible results. The specificiations suggest another formula, which results in quality gains in the decoded output from fate tests. This justifies changing said formula. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Christophe Gisquet authored
The coded size is a multiple of the macroblock size, which is 16. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Derek Buitenhuis authored
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Christophe Gisquet authored
It is only (mis-)used to set the dsp fucntions clear_block(s). But these functions always work on 16bits-wide elements, which make the parameter useless and actually harmful, as it causes all content on more than 8-bits to not use accelerated functions. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
James Almer authored
Reviewed-by: Michael Niedermayer <michaelni@gmx.at> Signed-off-by: James Almer <jamrial@gmail.com>
-
Carl Eugen Hoyos authored
-
Michael Niedermayer authored
This should fix RTMP input which was broken by cbbd906b the 40 + 11 case is untested as it did not occur in the testcase Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 01 Oct, 2015 8 commits
-
-
Carl Eugen Hoyos authored
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Carl Eugen Hoyos authored
-
Henrik Gramner authored
Makes it possible to use them in arithmetic expressions.
-
Sven Dueking authored
Reviewed-by: Ivan Uskov <ivan.uskov@nablet.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Clément Bœsch authored
Fixes Ticket #4898
-
Clément Bœsch authored
-
- 30 Sep, 2015 13 commits
-
-
Michael Niedermayer authored
Fixes deadlock with threads Found-by: Paul B Mahol Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
The variable is not a constant and can lead to race conditions Fixes: repro.webm (not reproducable with FFmpeg alone) Found-by: Dale Curtis <dalecurtis@google.com> Tested-by: Dale Curtis <dalecurtis@google.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Michael Niedermayer authored
This ensures that chroma format is never set to an invalid value Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Luca Barbato authored
Makes slightly easier to use jemalloc and tcmalloc. The two are quite common choices for profiling and debugging.
-
Vittorio Giovara authored
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Vittorio Giovara authored
These field are difficult to interpret, and are provided by a single encoder (mpegvideoenc). In general they do not belong to a structure containing raw data only, so remove them from AVFrame. Mpegvideoenc now uses a private field in Picture for its internal computations. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
wm4 authored
Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3 packets. This code forgot to report to the user that data was skipped at all. Since audio codecs allow partial packet decoding, the user application has to rely on the return value. It will remove the data reported as consumed by the decoder, and feed it to the decoder again. This resulted in the mp3 frame after the zero region to be decoded over and over again, until the zero region was finally skipped by the application. Fix this by including the amount of skipped bytes to the number of consumed bytes returned by the decode call. Fixes trac ticket #4890.
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
James Almer authored
Tested-by: Michael Niedermayer <michaelni@gmx.at> Signed-off-by: James Almer <jamrial@gmail.com>
-
Matt Oliver authored
-
Matt Oliver authored
-