Am 07.12.2017 20:40 schrieb "Mateusz" <mateu...@poczta.onet.pl>:
W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz <mateu...@poczta.onet.pl> wrote:
>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>> we have included windows.h in much more files and we should
>> avoid conflicts with defines/function declarations.
>>
>> We should declare compatible variables for atomic compat wrappers
>> that expect fixed size variables in atomic_compare_exchange* macro.
>>
>> Signed-off-by: Mateusz Brzostek <mateu...@poczta.onet.pl>
>> ---
>> libavcodec/jpegls.h | 2 ++
>> libavcodec/mjpegdec.h | 2 ++
>> libavcodec/mss2.c | 6 +++---
>> libavcodec/utils.c | 12 ++++++++++++
>> libavformat/mxfenc.c | 2 +-
>> 5 files changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
>> index c8997c7861..6b89b2afa3 100644
>> --- a/libavcodec/jpegls.h
>> +++ b/libavcodec/jpegls.h
>> @@ -32,6 +32,8 @@
>> #include "avcodec.h"
>> #include "internal.h"
>>
>> +#undef near /* This file uses struct member 'near' which in windows.h
is defined as empty. */
>> +
>> typedef struct JpeglsContext {
>> AVCodecContext *avctx;
>> } JpeglsContext;
>> diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
>> index c84a40aa6e..c36fba5f22 100644
>> --- a/libavcodec/mjpegdec.h
>> +++ b/libavcodec/mjpegdec.h
>> @@ -39,6 +39,8 @@
>> #include "hpeldsp.h"
>> #include "idctdsp.h"
>>
>> +#undef near /* This file uses struct member 'near' which in windows.h
is defined as empty. */
>> +
>> #define MAX_COMPONENTS 4
>>
>> typedef struct MJpegDecodeContext {
>> diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
>> index 9e7cc466de..3180af1d60 100644
>> --- a/libavcodec/mss2.c
>> +++ b/libavcodec/mss2.c
>> @@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const
uint8_t *buf, int buf_size,
>> return 0;
>> }
>>
>> -typedef struct Rectangle {
>> +struct Rectangle {
>> int coded, x, y, w, h;
>> -} Rectangle;
>> +};
>>
>> #define MAX_WMV9_RECTANGLES 20
>> #define ARITH2_PADDING 2
>> @@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx,
void *data, int *got_frame,
>>
>> int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
>>
>> - Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>> + struct Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>> int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
>>
>> if ((ret = init_get_bits8(&gb, buf, buf_size)) < 0)
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..70a0764714 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,13 @@ int av_lockmgr_register(int (*cb)(void **mutex,
enum AVLockOp op))
>>
>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>> {
>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>> + !defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>> _Bool exp = 0;
>> +#else
>> + atomic_bool exp = 0;
>> +#endif
>> +
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
!codec->init)
>> return 0;
>>
>> @@ -1969,7 +1975,13 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
const AVCodec *codec)
>>
>> int ff_unlock_avcodec(const AVCodec *codec)
>> {
>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>> + !defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>> _Bool exp = 1;
>> +#else
>> + atomic_bool exp = 1;
>> +#endif
>> +
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
!codec->init)
>> return 0;
>>
>
> These ifdefs here are very ugly, and as mentioned in another mail, the
> atomics in those two functions arent even required - all access to
> those variables is supposed to be protected by the lockmgr anyway.
> So it would be easier to just remove any atomic nature of those
> variables (or at the very lease replace the compare_exchange with a
> store to solve this problem at hand).
I'm not sure but are you proposed to revert commit
https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d
47a559a461
Basically, yes. Atomics are not needed for this variable, as access to it
should be serialized anyways.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
