Age | Commit message (Collapse) | Author |
|
The reason is the same as for e588615d938f8581f0d6f3771662d08cadfc00de
Based on a patch by Ronald S. Bultje <rsbultje@gmail.com>
|
|
They are not measurably faster on x86, they might be somewhat faster on
other platforms due to missing emu edge SIMD, but the gain is not large
enough to justify the added complexity.
|
|
Allow supporting files for which the image stride is smaller than
the maximum block size + number of subpel mc taps, e.g. a 64x64 VP9
file or a 16x16 VP8 file with -fflags +emu_edge.
|
|
|
|
|
|
|
|
Container and lossy decoding by Aneesh Dogra <aneesh@sugarlabs.org>
Lossless decoding by Justin Ruggles <justin.ruggles@gmail.com>
|
|
This fixes occasional failures of vp8-test-vector-010 with frame-level
multithreading enabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Move some functions from dsputil. The idea is that videodsp contains
functions that are useful for a large and varied set of video decoders.
Currently, it contains emulated_edge_mc() and prefetch().
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
It's got_frame, not data size
|
|
Indexing across array boundaries is not allowed by C99.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
|
|
Idea stolen from webp (by Pascal Massimino) - because it's Cool.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
This fixes building with threads disabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
This was unnoticed on linux, since stdlib.h apparently includes
files declaring the pthread_mutex_t and pthread_cond_t types.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Testing gives 25-30% gain on HD clips with two threads and
up to 50% gain with eight threads.
Sliced threading uses more memory than single or frame threading.
Frame threading and single threading keep the previous memory
layout.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
In preparation for sliced threading.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
This is in preperation for sliced threading.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
This prevents gcc from assuming that contents of it may have changed
between calls to vp56_range_get_prob(), thus preventing countless (and
unnecessary) movs. Decoding of sintel trailer goes from (avg+SG) 9.796
+/- 0.003 to 9.635 +/- 0.010.
|
|
This properly synchronizes frame size changes between threads if
subsequent threads abort decoding before frame size is initialized, i.e.
it prevents the thread after that from ping-ponging back to the original
value.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
|
|
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
lf_delta.ref[i] and lf_delta.mode[i] were incorrectly reset to 0 if
specific delta value was not updated. Fixed to keep the previous value
if flag indicates that element in question is not updated.
Signed-off-by: Janne Salonen <jsalonen@google.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
This change avoids accessing the segment map of the previous frame if
segmentation is not enabled for the current frame. The caller of
decode_mb_mode() only calls ff_thread_await_progress() on the reference
segmentation index array if segmentation is enabled, so Chromium's TSAN
will report a race when accessing this data while segmentation is not
enabled.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Also slightly move around code not allocate a new frame if we won't
decode it. This prevents us from putting undecoded frames in frame
pointers, which (in mt decoding) other threads will use and wait on
as references, causing a deadlock (if we skipped decoding) or a crash
(if we didn't initialized next_framep[] at all).
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
|
|
|
|
|
|
A new field, AVCodecContext.internal is used to hold a new struct
AVCodecInternal, which has private fields that are not codec-specific and are
used by general libavcodec functions.
Moved internal_buffer, internal_buffer_count, and is_copy.
|
|
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Associate segmentation_map[] with reference frame, rather than
decoding instance. This fixes cases where the map would be free()'ed
on e.g. a size change in one thread, whereas the other thread was
still accessing it. Also, it fixes cases where threads overwrite data
that is still being referenced by the previous thread, who thinks that
it's part of the frame previously decoded by the next thread.
|
|
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
|
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
|
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
|
In addition to avoiding undefined behaviour, an unsigned type
makes more sense for packing multiple 8-bit values.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
It's more readable and less prone to breakage.
|
|
|
|
|
|
Fixes occasional failure of make fate-vp8-test-vector-010 with
frame-multithreading enabled.
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
decoder.
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Tested on a Mac Pro, 2 CPUs, 2 cores each, OSX 10.6.6:
time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \
~/Downloads/sintel_trailer_1080p_vp8_vorbis.webm \
-f null -vcodec rawvideo -an -
1: 0m14.630s (89.9 fps)
2: 0m8.056s (163.2 fps)
3: 0m5.882s (223.6 fps)
4: 0m4.952s (265.6 fps)
time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \
~/Downloads/Elephants_Dream-720p-Stereo.webm \
-f null -vcodec rawvideo -an -
1: 1m12.962s (215.1 fps)
2: 0m44.682s (351.2 fps)
3: 0m31.183s (503.2 fps)
4: 0m25.284s (620.6 fps)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|