This allows creation of frame accurate chapter marks from sources like
DVD and BD where the precise chapter location is not known until the
chapter mark has been reached during reading.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This makes sure that linesize * start_y doesn't overflow, so that
emulated_edge_mc can get back the original value if needed.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The code tries to decode a number of channels at the
offset given by the ff_alac_channel_layout_offsets table.
Even if the number of channels decoded so far doesn't
exceed the total number of channels, we need to check that
we actually can decode that number of channels at this offset
as well.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
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>
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
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>
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>
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.
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.ape
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
The i686 feature really is a CPU feature and should be handled as such.
The cpunop dependency on i686 should be expressed with a standard _deps
declaration instead of a manual test.
