- 23 Feb, 2012 21 commits
-
-
Ronald S. Bultje authored
Fixes crashes for extremely large resizes (several 100-fold). Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Ronald S. Bultje authored
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Ronald S. Bultje authored
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
This is done in preparation for the following patch implementing encode2(). This commit is analogous to 05d69922 for libx264.
-
Anton Khirnov authored
-
Ronald S. Bultje authored
This prevents crashers and errors further down when reading nodes in the empty tree. Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Martin Storsjö authored
Also return a proper error code. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
According to newer RFCs, this packetization scheme should only be used for interfacing with legacy systems. Implementing this packetization mode properly requires parsing the full H263 bitstream to find macroblock boundaries (and knowing their macroblock and gob numbers and motion vector predictors). This implementation tries to look for GOB headers (which can be inserted by using -ps <small number>), but if the GOBs aren't small enough to fit into the MTU, the packetizer blindly splits packets at any offset and claims it to be a GOB boundary (by using Mode A from the RFC). While not correct, this seems to work with some receivers. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This simplifies adding more flags to the macro. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Justin Ruggles authored
Channel layouts are specified in the FLAC format description at http://flac.sourceforge.net/format.html fixes Bug 209
-
Justin Ruggles authored
fixes Bug 225
-
Ronald S. Bultje authored
if srcW<=2, clip(x, 1, srcW-2) still allows srcW to be < 1.
-
- 22 Feb, 2012 16 commits
-
-
Rafaël Carré authored
This structure is well defined by Microsoft at: http://msdn.microsoft.com/en-us/library/windows/hardware/ff564012(v=vs.85).aspx Thus, the wDecodedPictureIndex member is guaranteed to exist. Also, both the MPEG-2 and VC-1 hwaccel decoders depend on this struct member, but only the VC-1 decoder was disabled if the check failed. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Ronald S. Bultje authored
Specifically, prevent jumping back in the file for the next index, since this can lead to infinite loops where we jump between indexes referring to each other, and don't read indexes that don't fit in the file. Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Alex Converse authored
Based-on-work-by: Ronald S. Bultje <rsbultje@gmail.com> Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Alex Converse authored
Reference: VLC
-
Anton Khirnov authored
It is not supposed to be done outside lavc. This is basically a revert of 818062f2. It is unclear what issue this was supposed to fix, if it reappears again it will have to be fixed in a more proper place. The wtv-demux test change is because the sample starts with a B-frame.
-
Ronald S. Bultje authored
We read sub_packet_h / 2 packets per line of data (during deinterleaving), which equals zero if sub_packet_h <= 1, thus causing us to not read any data, leading to an infinite loop. Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
-
Tim Walker authored
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
-
Tim Walker authored
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
-
Martin Storsjö authored
This allows writing QuickTime-compatible fragmented mp4 (with a non-empty moov atom) to a non-seekable output. This buffers the mdat for the initial fragment just as it does for all normal fragments, too. Previously, the resulting atom structure was mdat,moov, moof,mdat ..., while it now is moov,mdat, moof,mdat. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Also split a long line. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
In nonseekable files, we already stop parsing the toplevel atoms after finding moov and one mdat. In large seekable files (or files that are seekable, but slowly, e.g. http), reading all the fragments at the start can take a considerable amount of time. This allows opting out from this behaviour. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
If parsing moov+mdat in a non-seekable file, we currently abort parsing directly after parsing the header of the mdat atom. If we want to continue parsing later (if looking to parse later fragments), we need to skip past the content of the mdat atom, otherwise we end up parsing the content of the mdat atom as root level atoms. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Christophe GISQUET authored
The operations that use it require it to be promoted to a larger (natural) type and thus perform sign extension on it. While an optimal compiler may account for this, gcc 4.6 (for x86 Windows) fails. Using the natural integer type provides a 2% speedup for Win64 and 1% for Win32. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
- 21 Feb, 2012 3 commits
-
-
Alex Converse authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-