- 12 Jan, 2012 19 commits
-
-
Alex Converse authored
-
Mans Rullgard authored
Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Janne Grunau <janne-libav@jannau.net>
-
Martin Storsjö authored
This isn't used in practice anywhere within libav at the moment, but change it for consistency until it is removed. URL_RDONLY/WRONLY were fixed in commit 5b81e295 (after the values that actually were used were changed at the major bump, in commit cbea3ac8), but this flag was unintentionally left unfixed. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Janne Grunau authored
The sporadic threading errors during fate-rv30 were caused by calling ff_thread_await_progress with mb row -1 as argument. That returns immediately since progress is initialized to -1. Not yet computed motion vectors from the reference could be used for the first macroblocks.
-
Janne Grunau authored
30-50% faster than the C implementation, 0.5% overall speedup on bourne.rmvb.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
The "new seeking API" was never finished and nobody is working on it.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
They are deprecated and will be purged on next major bump.
-
Kostya Shishkov authored
From the patch by Reimar Döffinger.
-
Christophe GISQUET authored
When decoding coefficients, detect whether the block is DC-only, and take advantage of this knowledge to perform DC-only inverse transform. This is achieved by: - first, changing the 108x4 element modulo_three_table into a 108 element table (kind of base4), and accessing each value using mask and shifts. - then, checking low bits for 0 (as they represent the presence of higher frequency coefficients) Also provide x86 SIMD code for the DC-only inverse transform. Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
- 11 Jan, 2012 13 commits
-
-
Paul B Mahol authored
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Alex Converse authored
This is different than a normal get_bits() over read because decode_audio_specific_config() creates its own GetBitContext. Fixes Bug 170.
-
Henrik Gramner authored
This is required to handle clobbering of XMM registers on Win64 correctly. Fixes FFT and all tests depending on FFT on Win64. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> Signed-off-by: Janne Grunau <janne-libav@jannau.net>
-
Justin Ruggles authored
This indicates that the actual frame size is based on the buf_size passed to avcodec_encode_audio().
-
Justin Ruggles authored
Since packets all contain only a single block, the generic seek function can be used while still maintaining block-accuracy.
-
Justin Ruggles authored
fixes stream copy of raw gsm to mov. tested with QuickTime.
-
Justin Ruggles authored
The WAVE demuxer returns packets with many blocks per frame, which needs to be parsed into single blocks. This has a side-effect of fixing the timestamps.
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Reinhard Tartler authored
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
-
Reinhard Tartler authored
update documentation to inform developers that it may be removed in a later release. Signed-off-by: Reinhard Tartler <siretart@tauware.de>
-
Janne Grunau authored
-
- 10 Jan, 2012 8 commits
-
-
Janne Grunau authored
-
Janne Grunau authored
Statistics for bourne.rmvb -an -f null 1 thread: 37.12s user 0.03s system 99% cpu 37.174 total 2 threads: 47.63s user 0.24s system 185% cpu 25.807 total 4 threads: 41.21s user 0.30s system 327% cpu 12.674 total
-
Janne Grunau authored
Under certain conditions pictures could be released before they were returned with frame-threading. Broken mv computation in the upcoming rv34 frame-threading patch was caused by this. To prevent contexts from running out of available pictures the loop releasing "unused" pictures has to be run for B frames too.
-
Alex Converse authored
Fixes Libav Bug 195. This doesn't make the code handle sample rate or upsample/downsample change properly but this is still a good sanity check. Based on change by Michael Niedermayer. Signed-off-by: Alex Converse <alex.converse@gmail.com>
-
Justin Ruggles authored
frame sample count calculation was incorrect
-
Justin Ruggles authored
The duration of the first packet was being calculated incorrectly, leading to an incorrect timestamp offset.
-
Aneesh Dogra authored
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-