W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze: > 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.
OK for me. I've sent smaller patch (only near/Rectangle stuff). Mateusz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel