- 03 Sep, 2013 3 commits
-
-
Martin Storsjö authored
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Otherwise buffer size calculations in allocate_buffers could overflow later, making the code think a large enough buffer actually was allocated. Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This should improve write performance quite significantly. --- Tested with both writing a normal mp4, by using the faststart feature and writing a fragmented mp4 file; all turn out with the same md5sum as before. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 02 Sep, 2013 8 commits
-
-
Diego Biurrun authored
-
Anton Khirnov authored
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Anton Khirnov authored
Avoids a divide by zero. Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Anton Khirnov authored
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Anton Khirnov authored
-
Anton Khirnov authored
Fixes invalid reads. Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Anton Khirnov authored
Otherwise picmemset can get called with negative y, resulting in an invalid write. Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
Anton Khirnov authored
Fixes invalid reads with corrupted files. Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
- 31 Aug, 2013 6 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Vittorio Giovara authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Diego Elio Pettenò authored
The pixel format tables are never modified, mark them as constant. Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Christian Schmidt authored
Remove the header decoding for PCM audio from mpeg.c and the 20/24bit parts from pcm.c and merge them into a new decoder in pcm-dvd.c. The decoder has added support for samples that span multiple packets and modified 20/24bit group decoding. Both is needed to decode samples that have been generated with DVD-Lab Pro 2. The decoding of 16bit PCM and two channel 24bit is identical to before. No other samples are known to verify the correctness of the encoding this software does. The complete list of tested formats is 48kHz/16bit/2-8 channels 48kHz/24bit/2-5 channels 96kHz/16bit/2-4 channels 96kHz/24bit/2 channels Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Christian Schmidt authored
-
Christian Schmidt authored
The original idea was to collect PCM codecs that could appear in various MPEG streams in this file. Discussion in IRC lead to the conclusion that one codec per file would be better and stop the need for #ifdefs.
-
- 29 Aug, 2013 13 commits
-
-
Sean McGovern authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
Also give consistent names to init functions.
-
- 28 Aug, 2013 10 commits
-
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
Also give consistent names to init functions.
-
Diego Biurrun authored
Also give consistent names to init functions.
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Rafaël Carré authored
Only consume an AVPacket when all the samples have been read. When the rate of samples output is limited (by the default value of max_samples), consuming the first packet immediately will cause timing problems: - The first packet with PTS 0 will output 4608 samples and be consumed entirely - The second packet with PTS 64 will output the remaining samples (typically, a lot, that's why max_samples exist) until the decoded samples of the first packet have been exhausted, at which point the samples of the second packet will be decoded and output when av_decode_frame is called with the next packet). That means there's a PTS jump since the first packet is 'decoded' immediately, which can be seen with avplay or mplayer: the timing jumps immediately to 6.2s (which is the size of a packet). Sample: http://streams.videolan.org/issues/6348/Goldwave-MAClib.apeSigned-off-by: Justin Ruggles <justin.ruggles@gmail.com>
-