aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/cpu.c
diff options
context:
space:
mode:
authorRafaël Carré <funman@videolan.org>2013-08-27 17:35:49 +0200
committerJustin Ruggles <justin.ruggles@gmail.com>2013-08-28 15:00:34 -0400
commit91d4cfb8127f1de6c4ad173a30fffe584700046d (patch)
tree5deecfc1f906c53273f28d84f8352bfd5b3dbaf2 /libavutil/cpu.c
parent84146963d23d76b09af633e97413cd97d9b3021e (diff)
downloadffmpeg-91d4cfb8127f1de6c4ad173a30fffe584700046d.tar.gz
apedec: do not buffer decoded samples over AVPackets
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>
Diffstat (limited to 'libavutil/cpu.c')
0 files changed, 0 insertions, 0 deletions