| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Certain hardware decoding APIs are not guaranteed to be thread-safe, so
having the user access decoded hardware surfaces while the decoder is
running in another thread can cause failures (this is mainly known to
happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the user
is inside a lavc decode call (avcodec_send_packet/receive_frame).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.
ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.
In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn't need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.
In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
| |
|
|
|
|
|
|
|
|
|
| |
The current code stores a pointer to the packet passed to the decoder,
which is then used during get_buffer() for timestamps and side data
passthrough. However, since this is a pointer to user data which we do
not own, storing it is potentially dangerous. It is also ill defined for
the new decoding API with split input/output.
Fix this problem by making an explicit internally owned copy of the
packet properties.
|
| |
|
|
|
|
|
|
|
|
| |
When decoding with threads enabled, the get_format callback will be
called with one of the per-thread codec contexts rather than with the
outer context. If a hwaccel is in use too, this will add a reference
to the hardware frames context on that codec context, which will then
propagate to all of the other per-thread contexts for decoding. Once
the decoder finishes, however, the per-thread contexts are not freed
normally, so these references leak.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Current code uses a plain int in a racy way, which is UB.
|
| |
|
|
| |
Deprecated in 11/2012.
|
| |
|
|
|
|
| |
Express bitfields more simply.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| | |
|
| |
|
|
|
|
| |
CC: libav-stable@libav.org
Bug-Id: CID 1135767
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
When decoding, this field holds the inverse of the framerate that can be
written in the headers for some codecs. Using a field called 'time_base'
for this is very misleading, as there are no timestamps associated with
it. Furthermore, this field is used for a very different purpose during
encoding.
Add a new field, called 'framerate', to replace the use of time_base for
decoding.
|
| | |
|
| |
|
|
| |
This also handles side data properly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
avcodec_flush_buffers() must release all internally held references
according to its documentation, for which all the threads need to be
flushed.
CC:libav-stable@libav.org
Bug-Id: vlc/9665
|
| |
|
|
|
|
|
| |
This is similar to what the non-threaded code already does.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
|
| |
|
|
|
| |
Remove the extended_data workaround, all decoders should now handle this
properly.
|
| |
|
|
| |
data[0] may be NULL for valid frames with hwaccel pixel formats.
|
| |
|
|
| |
It's a private field, not meant to be accessed from outside lavc.
|
| |
|
|
|
|
| |
It's a private field, it should not be visible to callers.
Deprecate AVCodecContext.thread_opaque
|
| |
|
