- 03 Oct, 2015 14 commits
-
-
Hendrik Leppkes authored
* commit 'e54d7e4e': dnxhddata: Deduplicate cid 1256 chroma table Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit '1fb63d6f': dnxhddata: Deduplicate dnx100 tables Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit 'cc320296': dnxhddata: Fix cid 1260 luma and chroma tables Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit 'bfe1cd80': dnxhddata: Fix 10-bit DNxHD quant matrices Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit '38014692': x264: Add option to force IDR frames Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit 'eb02387a': x264: Expose the NV21 input support Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit '74942685': hls: Check av_opt_set_dict return value as well Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit 'd0a3e89d': dcadec: make a number of samples per subband per subsubframe a named constant Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
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 17 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>
-
Christophe Gisquet authored
CID 1256 is specified as using the same table for luma and chroma, which is the same as CID 1235 luma table. This is consistent with the format supposedly being RGB, although most sequences seem to actually be YCbCr-encoded. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Jeremy James authored
Tables 1258 and 1259 were not zigzagged when added, so it was not possible to notice the equivalence. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Jeremy James authored
These table was not zigzagged when added. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Joseph Artsimovich authored
Convert them to zigzag order, as the rest of them are. When I was adding support for 10-bit DNxHD, I just copy-pasted the missing quant matrices from the spec. Now it turns out the existing matrices in dnxhddata.c were in zigzag order. This resulted in wrong quantization for 10-bit DNxHD. The attached patch fixes the problem by converting 10-bit quant matrices to zigzag order. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
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 9 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>
-
Derek Buitenhuis authored
When forwarding the frame type information, by default x264 can decide which kind of keyframe output, add an option to force it to output IDR frames in to support use-cases such as preparing the content for segmented streams formats.
-
Yu Xiaolei authored
x264 build 147 adds the native support for NV21. Useful to avoid additional pixel format conversion when encoding from a wide range of capture devices, Android among those. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Luca Barbato authored
Bug-Id: CID 1320426
-