Hi,
This patch makes the one-time initialization in av_get_cpu_flags()
thread-safe. The data race was reported by ThreadSanitizer.
Wan-Teh Chang (1):
avutil: fix data race in av_get_cpu_flags().
libavutil/atomic.c | 40
libavutil/atomic.h
-off-by: Wan-Teh Chang
---
libavutil/atomic.c | 40
libavutil/atomic.h | 34 --
libavutil/atomic_gcc.h | 33 +
libavutil/atomic_suncc.h | 19 +++
libavutil
Hi Michael,
On Mon, Nov 21, 2016 at 4:35 PM, Michael Niedermayer
wrote:
> On Mon, Nov 21, 2016 at 03:37:49PM -0800, Wan-Teh Chang wrote:
>> Make the one-time initialization in av_get_cpu_flags() thread-safe.
>> The fix assumes -1 is an invalid value for cpu flags.
>
> p
cpu_init.c to verify the one-time
initialization in av_get_cpu_flags() is thread-safe.
Co-author: Dmitry Vyukov of Google, which suggested the data race fix.
Signed-off-by: Wan-Teh Chang
---
libavutil/Makefile | 1 +
libavutil/atomic.c | 40 ++
libavuti
Here is a new version of my patch to address Michael's review comments.
Wan-Teh Chang (1):
Make the one-time initialization in av_get_cpu_flags() thread-safe.
libavutil/Makefile | 1 +
libavutil/atomic.c | 40 ++
libavutil/atomic.h
ic_int_set() are also added.
Add a test program libavutil/tests/cpu_init.c to verify the one-time
initialization in av_get_cpu_flags() is thread-safe.
Co-author: Dmitry Vyukov of Google, which suggested the data race fix.
Signed-off-by: Wan-Teh Chang
---
libavutil/Makefile | 1 +
This patch was generated in error. Please ignore it.
Wan-Teh Chang
On Tue, Nov 22, 2016 at 11:30 AM, Wan-Teh Chang wrote:
> The static variables |flags| and |checked| in libavutil/cpu.c are read
> and written using normal load and store instructions. These are
> considered as data r
ed, .-set_flags_atomic_relaxed
.local flags
.comm flags,4,16
.ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4"
.section .note.GNU-stack,"",@progbits
==
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
efine atomic_load(object) \
(__sync_synchronize(), *(object))
#define atomic_load_explicit(object, order) \
atomic_load(object)
==
So I am wondering if there is a libav patch that implements the
|order| argument for atomic_store_explicit() and
atomic_load_explicit()
patch on top to
use atomic operations.
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
check whether the
one-time initialization in av_get_cpu_flags() has data races.
Co-author: Dmitry Vyukov of Google
Signed-off-by: Wan-Teh Chang
---
libavutil/Makefile | 1 +
libavutil/cpu.c| 40 ++
libavutil/tests/cpu_init.c | 72
Do you know when the atomics code in libav will be merged to ffmpeg?
I don't want add new code that will interfere with the merge. On the
other hand, the new code I wanted to add will be easy to rewrite using
C11 atomics. So this all depends on when the merge will be performe
code similar to my
ffmpeg patch http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190454.html,
and much more.
Note: libav/libavcodec/pthread_frame.c uses unnecessary (too strong)
memory barriers in ff_thread_report_progress(). We can fix those when
the code is merged
care of that in this patch.
Wan-Teh Chang (1):
avutil/tests: add cpu_init to .gitignore and tests/fate
libavfilter/tests/.gitignore | 1 +
libavutil/tests/.gitignore | 1 +
tests/fate/libavutil.mak | 5 +
3 files changed, 7 insertions(+)
--
2.8.0.r
This is a follow-up to commit d84a21207ea83055dc9b6dc1cd6a379f2ea756e7,
which added the libavutil/tests/cpu_init.c. Also add |integral| to
libavfilter/tests/.gitignore.
Signed-off-by: Wan-Teh Chang
---
libavfilter/tests/.gitignore | 1 +
libavutil/tests/.gitignore | 1 +
tests/fate
I found the commits to merge by inspecting the "git log configure"
output and the list of Anton Khirnov's commits at
http://git.libav.org/?p=libav.git;a=search;h=5cc0057f4910c8c72421b812c8f337ef6c43696c;s=Anton+Khirnov;st=author
Wan-Teh Chang
Anton Khirnov (1):
compat/atomics
eb34d40354e2474517c9b9bd787e0dadc89c2a81
Signed-off-by: Wan-Teh Chang
---
compat/atomics/dummy/stdatomic.h | 176 +
compat/atomics/gcc/stdatomic.h | 173
compat/atomics/pthread/stdatomic.c | 39
compat/atomics/pthread/stdatomic.h | 197
hould use the standard FFmpeg license header in the new .h files?
Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From: Anton Khirnov
Since this is a C11 feature, it requires -std=c11.
Not actually used for anything yet, that will be added in the following
commits.
This merges libav commit 13f5d2bf75b95a0bfdb9940a5e359a719e242bed.
Signed-off-by: Wan-Teh Chang
---
configure | 29
From: Anton Khirnov
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit 4e928ef340ac20325f529d92fcbc51e768085358.
Signed-off-by: Wan-Teh Chang
---
compat/atomics/gcc/stdatomic.h | 173 +
configure | 6
From: Anton Khirnov
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit c2755864afadfbaa349e8d583665c86fe99fa90b.
Signed-off-by: Wan-Teh Chang
---
compat/atomics/win32/stdatomic.h | 179 +++
configure| 2
From: Anton Khirnov
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit eb34d40354e2474517c9b9bd787e0dadc89c2a81.
Signed-off-by: Wan-Teh Chang
---
compat/atomics/dummy/stdatomic.h | 176 +++
configure| 3
From: Anton Khirnov
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit f9a6a80e065cdb95b233978f1d96ec9bc863daa1.
Signed-off-by: Wan-Teh Chang
---
compat/atomics/pthread/stdatomic.c | 39
compat/atomics/pthread/stdatomic.h | 197
From: Anton Khirnov
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit bb81ed476569b912a37ed553e756e123b6b13b14.
Signed-off-by: Wan-Teh Chang
---
compat/atomics/suncc/stdatomic.h | 186 +++
configure| 2
On Tue, Nov 29, 2016 at 6:46 AM, Carl Eugen Hoyos wrote:
> 2016-11-29 0:29 GMT+01:00 Wan-Teh Chang :
>
>> Adapted from the code by Rémi Denis-Courmont from VLC
>
> Missing copyright statement, please do not commit as-is!
Hi Carl,
I made only the following changes to the Li
Should I remove that copyright notice from
ffmpeg/compat/atomics/pthread/stdatomic.c?
Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
conservative, I changed -pie to -fPIE. But the documentation seems
to imply just -fsanitize=thread is enough:
http://clang.llvm.org/docs/ThreadSanitizer.html
https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual
Signed-off-by: Wan-Teh Chang
---
configure | 2 +-
1 file changed, 1
.
Signed-off-by: Wan-Teh Chang
---
libavutil/cpu.c | 12 +++-
libavutil/cpu.h | 2 --
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 73317c4..16e0c92 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -17,6 +17,7 @@
*/
#include
Also declare the main() function with void arguments because argc and
argv are unused.
These changes are suggested by Diego Biurrun and James Almer.
Signed-off-by: Wan-Teh Chang
---
libavutil/Makefile | 2 +-
libavutil/tests/cpu_init.c | 9 +
tests/fate/libavutil.mak | 2
On Thu, Nov 24, 2016 at 1:56 AM, wm4 wrote:
> On Wed, 23 Nov 2016 11:40:25 -0800
> Wan-Teh Chang wrote:
>
>> On Tue, Nov 22, 2016 at 3:30 PM, wm4 wrote:
>> > On Tue, 22 Nov 2016 23:57:15 +0100
>> > Michael Niedermayer wrote:
>> >
>> >>
On Tue, Dec 6, 2016 at 10:41 AM, Wan-Teh Chang wrote:
> Make the one-time initialization in av_get_cpu_flags() thread-safe. The
> static variable |cpu_flags| in libavutil/cpu.c is read and written using
> normal load and store operations. These are considered as data races.
> The f
.
Signed-off-by: Wan-Teh Chang
---
libavutil/cpu.c | 12 +++-
libavutil/cpu.h | 2 --
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 73317c4..16e0c92 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -17,6 +17,7 @@
*/
#include
On Mon, Dec 12, 2016 at 6:42 AM, Carl Eugen Hoyos wrote:
> 2016-12-02 23:04 GMT+01:00 Wan-Teh Chang :
>> -pie was added to C flags for ThreadSanitizer in commit
>> 19f251a2882a8d0779b432e63bf282e4d9c443bb. Under clang 3.8.0, the -pie
>> flag causes a compiler warning an
This fixes a data race warning by ThreadSanitizer.
FrameThreadContext.die is read by all the worker threads but is not
protected by any mutex. Move it to PerThreadContext so that each worker
thread reads its own copy of |die|, which can then be protected with
PerThreadContext.mutex.
---
libavcodec
This fixes data race warnings by ThreadSanitizer.
ff_thread_report_progress and ff_thread_await_progress should read
progress[field] only when holding progress_mutex because progress_mutex
guards frame progress values.
---
libavcodec/pthread_frame.c | 10 ++
1 file changed, 6 insertions(+)
gress[field] is
>= |n|, then the functions return immediately. Otherwise, the
functions take the slow code path, which acquires progress_mutex
properly and does what the functions need to do.
The fast code path is in the style of double-checked locking and has a
data race. ThreadSanitizer is righ
hat it uses
more memory. I think that's the right trade-off, but I would be happy
to use an atomic int. Please let me know what you prefer.
Thanks,
Wan-Teh Chang
PS: Here is the relevant part of the ThreadSanitizer report. I'm using
an old version of ffmpeg (the code is in libavcodec/pth
Although not documented, |state| is guarded by either |mutex| or
|progress_mutex|. In several places |state| is read without mutex
protection, often as a double-checked locking style performance
optimization. Fix the data races by reading |state| under mutex
protection.
---
libavcodec/pthread_fram
This is because the codec->decode() call in frame_worker_thread may be
modifying that avctx at the same time. This data race is reported by
ThreadSanitizer.
Although submit_thread holds two locks simultaneously, it always
acquires them in the same order because |prev_thread| is always the
array el
https://ffmpeg.org/developer.html#patch-submission-checklist
How do I run FFmpeg benchmarks?
Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ay, this data race is the
most difficult to analyze because the code that has the data race is
outside libavcodec/pthread_frame.c, in the h264 decoder I remember.
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
in the current version looks similar, but it
is certainly possible that the data race is gone.
Thanks a lot for your help!
Wan-Teh Chang
==
WARNING: ThreadSanitizer: data race (pid=161600)
Write of size 4 at 0x7f53af71a830 by thread T8 (mutexes: write M
big and threadsanitizer slow. Try for example fate-h264 in
> that
> case.
Thank you very much for the command line. I did this last Saturday on
the ffmpeg HEAD. Although the h264 decoding code has changed
significantly between the old version I'm using and the ffmpeg HE
a
look at the data races in the h264 decoding code. I think you will be
able to fix the data races much faster than I can. If you don't have a
lot of time, I'll be happy to implement a solution if you can outline
it after your investigation. Thanks.
Wan-Teh Chang
This bug was found by Dmitry Vyukov. If two threads may call
ff_thread_report_progress at the same time, progress[field] may
decrease. For example, suppose progress[field] is 10 and two threads
call ff_thread_report_progress to update progress[field] to 11 and
12, respectively. If the second thread
Correct the order of the load/store operation and the memory barrier in
avpriv_atomic_int_get and avpriv_atomic_int_set.
Use the atomic get and set functions in ff_thread_report_progress and
ff_thread_await_progress.
---
libavcodec/pthread_frame.c | 11 +++
libavutil/atomic.c | 48
s of the code.
By the way, I'm also wondering why ff_thread_report_progress is
sometimes called with progress[field] >= n? I saw it happen when I ran
make fate-h264, but did not investigate it.
Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpe
patch?
3. The Solaris Studio compiler intrinsics for memory barriers (which
are used in atomic_suncc.h) are documented at:
https://docs.oracle.com/cd/E24457_01/html/E21991/gjzmf.html
On Mon, Feb 29, 2016 at 7:05 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Feb 29, 2016 at 9:35 PM, Wan-
Correct the order of the load/store operation and the memory barrier in
avpriv_atomic_int_get and avpriv_atomic_int_set.
Signed-off-by: Wan-Teh Chang
---
libavutil/atomic.c | 48
libavutil/atomic.h | 45
does not issue a
memory barrier.
If you agree with my proposal, I can write a separate patch to do that.
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
: Wan-Teh Chang
---
libavcodec/pthread_frame.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index b77dd1e..c5ac44f 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -93,6 +93,8
l/ffmpeg-devel/2016-March/190520.html.
Does the patch need additional review? Could you approve and commit
the patch for me?
Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ersonal judgement and may not reflect
Dmitry's opinion. Dmitry and I seem to disagree on how to best fix the
|state| data races. To my surprise, he is fine with using atomics to
make the double-checked locking style access to |state| correct an
On Tue, Mar 1, 2016 at 7:44 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang
> wrote:
>
>> By the way, I'm also wondering why ff_thread_report_progress is
>> sometimes called with progress[field] >= n? I saw it happen when I
or some |p|. progress_mutex (of any
AVCodecContext) is not involved at all.
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Ronald,
Thank you for the quick reply!
On Wed, Jul 5, 2017 at 2:49 PM, Ronald S. Bultje wrote:
> Hi Wan-Teh,
>
> On Wed, Jul 5, 2017 at 5:30 PM, Wan-Teh Chang wrote:
>>
>> Hi Ronald,
>>
>> A variant of this patch is committed as
>> 2e664b9c1e73c
Hi Ronald,
On Wed, Jul 5, 2017 at 3:31 PM, Ronald S. Bultje wrote:
> Hi Wan-Teh,
>
> On Wed, Jul 5, 2017 at 6:12 PM, Wan-Teh Chang wrote:
>>
>> Thank you for all the tsan warning fixes. In the meantime, it would be
>> good to revert 2e664b9c1e73c80aab91070c1eb7676f04b
pkt is a pointer, so it should be dereferenced with the -> operator.
Signed-off-by: Wan-Teh Chang
---
ffmpeg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 6dae6e9078..888d19a647 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2253,8 +225
67ca0f19def682718.
Signed-off-by: Wan-Teh Chang
---
libavformat/avio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 1e79c9dd5c..64248e098b 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -263,8 +263,6 @@ static const struct URLPro
Hi Muhammad,
On Thu, Jul 6, 2017 at 7:56 PM, Muhammad Faiz wrote:
> On Fri, Jul 7, 2017 at 9:18 AM, Wan-Teh Chang
> wrote:
>> In url_find_protocol(), proto_str is either "file" or a string
>> consisting of only the characters in URL_SCHEME_CHARS, which does not
&
M248502, write M248500):
#0 ff_thread_await_progress [..]/libavcodec/pthread_frame.c:591:26
(5ab42bb1a6f4b068d7863dabe9b2bacc+0xe749a1)
Signed-off-by: Wan-Teh Chang
---
libavcodec/pthread_frame.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec
Hi Ronald,
On Wed, Jul 5, 2017 at 7:24 PM, Ronald S. Bultje wrote:
> Hi Wan-Teh,
>
> On Wed, Jul 5, 2017 at 8:08 PM, Wan-Teh Chang wrote:
>>
>> Hi Ronald,
>>
>> On Wed, Jul 5, 2017 at 3:31 PM, Ronald S. Bultje
>> wrote:
>> > Hi Wan-Teh,
>>
the user's AVCodecContext (src).
That line in update_context_from_user() was added in the initial
commit of libavcodec/pthread.c:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=37b00b47cbeecd66bb34c5c7c534d016d6e8da24
Does any user actually modify avctx->debug after the avcodec_open2() cal
Hi Ronald,
On Sat, Jul 8, 2017 at 6:19 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Jul 7, 2017 at 5:02 PM, Wan-Teh Chang
> wrote:
>
>> @@ -763,6 +764,7 @@ int ff_frame_thread_init(AVCodecContext *avctx)
>>
>> fctx->async_lock = 1;
>> fctx-
nd.
Yes, the syncing is trivial to add. When someone actually needs to
toggle the FF_DEBUG_THREADS option dynamically, we can easily add the
syncing at that time.
This is your call. Please let me know your decision. Thanks!
Wan-Teh Chang
___
ffmpeg-de
68d7863dabe9b2bacc+0xe749a1)
Signed-off-by: Wan-Teh Chang
---
libavcodec/pthread_frame.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 363b139f71..2cea232a36 100644
--- a/libavcodec/pthread_frame.
On Sat, Jul 8, 2017 at 3:49 PM, Michael Niedermayer
wrote:
> On Sat, Jul 08, 2017 at 03:38:11PM -0700, Wan-Teh Chang wrote:
>> Hi Ronald,
>>
>> On Sat, Jul 8, 2017 at 2:33 PM, Ronald S. Bultje wrote:
>> >
>> > I can see the design from the patch.
>>
>owner[0], dst);
> return AVERROR(ENOMEM);
> }
>
[...]
I don't understand why we pass dst->owner[0], not dst->owner[1], to
the ff_thread_release_buffer() call. Does this assume dst->owner[0] ==
dst->owner[1]?
Although dst->owner[0] and dst->owner[1] are initialized to the same
value, the changes to libavcodec/h264_slice.c seem to imply
dst->owner[0] and dst->owner[1] may become different.
Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Ronald,
Thank you for the quick reply.
On Tue, Jul 11, 2017 at 2:09 PM, Ronald S. Bultje wrote:
> Hi Wan-Teh,
>
> On Tue, Jul 11, 2017 at 4:53 PM, Wan-Teh Chang wrote:
>>
>> Hi Ronald,
>>
>> I have a question about this patch.
>>
>> On Mon, Apr 3
The patch does not fix the tsan warning it was intended to fix.
Reverting the patch moves the av_log() back to the outside of the lock.
Signed-off-by: Wan-Teh Chang
---
libavcodec/pthread_frame.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec
->default_ref, sizeof(h->default_ref));
memcpy(h->short_ref, h1->short_ref, sizeof(h->short_ref));
memcpy(h->long_ref,h1->long_ref,sizeof(h->long_ref));
memcpy(h->delayed_pic, h1->delayed_pic, sizeof(h->delayed_pic));
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 ff_h264_update_thread_context ffmpeg/libavcodec/h264_slice.c:411:5
(ffmpeg+0x118b7dc)
Signed-off-by: Wan-Teh Chang
---
libavcodec/h264_slice.c | 1 -
1 file changed, 1 deletion(-)
diff --git a
to sync short_ref[], long_ref[],
short_ref_count, and long_ref_count between threads?
> Can you send it as a git-formatted patch?
Done. Please see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213777.html.
Wan-Teh Chang
___
ffmpeg-devel mailing list
ff
m the associated H264SliceContext) in
h264_initialise_ref_list(), so it should not be propagated from one
decoding thread to the next.
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
that tsan ignores the read
of sl->ref_list[1][0].parent->mb_type[mb_xy] at line 505, then "make
fate-h264 THREADS=4" runs to completion with no tsan warning (assuming
the fix in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213777.html
is applied)
Hi Ronald,
Thank you for the reply.
On Wed, Jul 19, 2017 at 8:56 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Jul 19, 2017 at 12:26 AM, Wan-Teh Chang <
> wtc-at-google@ffmpeg.org> wrote:
>
>> WARNING: ThreadSanitizer: data race (pid=116081)
>> Read of s
Hi Ronald,
On Wed, Jul 19, 2017 at 11:50 AM, Ronald S. Bultje wrote:
> Hi Wan-Teh,
>
> On Wed, Jul 19, 2017 at 2:31 PM, Wan-Teh Chang > wrote:
>
>> In libavcodec/h264_direct.c, there is already an
>> await_reference_mb_row() call before the read of
>> sl->ref_
ff_h264_decode_mb_cabac() and ff_h264_decode_mb_cavlc() are very long
functions. Declaring decode_chroma as const makes it clear the variable
doesn't change after initialization.
Signed-off-by: Wan-Teh Chang
---
libavcodec/h264_cabac.c | 4 ++--
libavcodec/h264_cavlc.c | 4 ++--
2 files ch
ot;
working this way.
Signed-off-by: Wan-Teh Chang
---
libavcodec/x86/cavsdsp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c
index a8a198b46d..becb3a4808 100644
--- a/libavcodec/x86/cavsdsp.c
+++ b/libavcodec/x86/cavsdsp.c
@@ -29,7 +29,6 @@
#in
hevc_await_progress() uses the variable |y| only inside the "if" block.
So |y| only needs to be declared and initialized in that block.
Signed-off-by: Wan-Teh Chang
---
libavcodec/hevcdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h
Use the new codec control AV1E_GET_NUM_OPERATING_POINTS to get the
number of operating points. This is the size of the output arrays of
AV1E_GET_SEQ_LEVEL_IDX and AV1E_GET_TARGET_SEQ_LEVEL_IDX.
Signed-off-by: Wan-Teh Chang
---
libavcodec/libaomenc.c | 20 ++--
1 file changed, 14
81 matches
Mail list logo
