Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 21 Mar, 2017 7 commits
    • Wan-Teh Chang's avatar
      pthread_frame: use better memory orders for frame progress · c358c625
      Wan-Teh Chang authored 
      This improves commit 59c70227.

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: 's avatarWan-Teh Chang <wtc@google.com>
Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>

Merges Libav commit 343e2833.
Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      c358c625
    • Mark Thompson's avatar
      pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts · fb69a8e1
      Mark Thompson authored 
      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.

Merges Libav commit fd0fae60.
Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      fb69a8e1
    • Anton Khirnov's avatar
      pthread_frame: properly propagate the hw frame context across frame threads · 98f89d61
      Anton Khirnov authored 
      Merges Libav commit 84f22568.
Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      98f89d61
    • Anton Khirnov's avatar
      pthread_frame: use atomics for frame progress · b6587421
      Anton Khirnov authored 
      Merges Libav commit 59c70227.
Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      b6587421
    • Anton Khirnov's avatar
      pthread_frame: use atomics for PerThreadContext.state · 74926269
      Anton Khirnov authored 
      Merges Libav commit 64a31b28.
Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      74926269
    • wm4's avatar
      ffmpeg: don't unnecessarily use a deprecated API function · 87c082c4
      wm4 authored 
      Since we've disabled side data merging in ffmpeg.c, this really changes
nothing.
      87c082c4
    • wm4's avatar
      avcodec, avformat: deprecate anything related to side data merging · d682ae70
      wm4 authored 
      This patch deprecates anything that has to do with merging/splitting
side data. Automatic side data merging (and splitting), as well as all
API symbols involved in it, are removed completely.

Two FF_API_ defines are dedicated to deprecating API symbols related to
this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.

Since it was claimed that changing the default from merging side data to
not doing it is an ABI change, there are two additional FF_API_ defines,
which stop using the side data merging/splitting by default (and remove
any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
and FF_API_LAVF_MERGE_SD in libavformat.

It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
are quickly defined to 0 in the next ABI bump, while the API symbols are
retained for a longer time for the sake of compatibility.
AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
most of the time it will still be defined. Keep in mind that no code
exists that actually tries to unset this flag for any reason, nor does
such code need to exist. Code setting this flag explicitly will work as
before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
side data merging has been removed from libavformat.

In order to avoid that anyone in the future does this incorrectly, here
is a small guide how to update the internal code on bumps:

- next ABI bump (probably soon):
  - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
  - define FF_API_MERGE_SD to 0, and remove all code covered by it
- next API bump (typically two years in the future or so):
  - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered
    by it
  - define FF_API_MERGE_SD_API to 0, and remove all code covered by it

This forces anyone who actually wants packet side data to temporarily
use deprecated API to get it all. If you ask me, this is batshit fucked
up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
set by default was rejected as an ABI change, so I'm going all the way
to get rid of this once and for all.
Reviewed-by: 's avatarJames Almer <jamrial@gmail.com>
Reviewed-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      d682ae70
  3. 20 Mar, 2017 33 commits