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 5b81e29593 (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>
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.
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>
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>
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.
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
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.
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>
If the creation time is stored in the file as a zero, the
mov demuxer skips exporting the creation time. Currently,
files muxed without a creation time get demuxed with a
Jan 1st 1970 creation timestamp.
Signed-off-by: Martin Storsjö <martin@martin.st>
