Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 10 December 2017 at 02:41, Aaron Levinson
wrote:
> On 12/9/2017 6:24 PM, Aaron Levinson wrote:
>
>> On 12/9/2017 6:15 PM, Aaron Levinson wrote:
>>
>>> On 12/9/2017 1:18 AM, Hendrik Leppkes wrote:
>>>
On Fri, Dec 8, 2017 at 8:49 AM, Mateusz
wrote:
> W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
>
>> Am 07.12.2017 20:40 schrieb "Mateusz" :
>>
>> W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
>>
>>> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz
>>> 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
---
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
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/9/2017 6:24 PM, Aaron Levinson wrote:
On 12/9/2017 6:15 PM, Aaron Levinson wrote:
On 12/9/2017 1:18 AM, Hendrik Leppkes wrote:
On Fri, Dec 8, 2017 at 8:49 AM, Mateusz wrote:
W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
Am 07.12.2017 20:40 schrieb "Mateusz" :
W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
On Thu, Dec 7, 2017 at 2:02 AM, Mateusz
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
---
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).
LGTM.
This patch doesn't apply anymore to the latest code base due to
changes to mxfenc.c.
I should add that the changes to mxfenc.c aren't needed any longer. With
the subpatch to mxfenc.c removed, the remain patch applies cleanly, and
I can confirm that it fixes MSVC build issues as well.
Aaron Levinson
One more detail--while it builds with the patch altered as described
above, it doesn't work at run-time with MSVC builds without reverting
patch
https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
as described in earlier comments.
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/9/2017 6:15 PM, Aaron Levinson wrote:
On 12/9/2017 1:18 AM, Hendrik Leppkes wrote:
On Fri, Dec 8, 2017 at 8:49 AM, Mateusz wrote:
W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
Am 07.12.2017 20:40 schrieb "Mateusz" :
W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
On Thu, Dec 7, 2017 at 2:02 AM, Mateusz
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
---
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).
LGTM.
This patch doesn't apply anymore to the latest code base due to changes
to mxfenc.c.
I should add that the changes to mxfenc.c aren't needed any longer.
With the subpatch to mxfenc.c removed, the remain patch applies cleanly,
and I can confirm that it fixes MSVC build issues as well.
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/9/2017 1:18 AM, Hendrik Leppkes wrote:
On Fri, Dec 8, 2017 at 8:49 AM, Mateusz wrote:
W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
Am 07.12.2017 20:40 schrieb "Mateusz" :
W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
On Thu, Dec 7, 2017 at 2:02 AM, Mateusz 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
---
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).
LGTM.
This patch doesn't apply anymore to the latest code base due to changes
to mxfenc.c.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 09/27] avcodec/fraps: replace YUVJ pixel format
On Sat, Dec 09, 2017 at 04:38:01PM +0100, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavcodec/fraps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) breaks ./ffmpeg -y -i tickets/2593/fraps_flv1_decoding_errors.avi -t 1 file.nut should be here: https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2593/fraps_flv1_decoding_errors.avi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 27/27] all: remove rest of YUVJ pixel formats usage
On Sat, Dec 09, 2017 at 04:38:19PM +0100, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > fftools/ffmpeg_filter.c | 4 +-- > libavcodec/raw.c | 18 +++--- > libavcodec/utils.c | 11 -- > libavutil/pixdesc.c | 60 > > libavutil/pixfmt.h | 5 --- > libswscale/utils.c | 20 --- > tests/ref/fate/filter-pixdesc-yuvj411p | 1 - > tests/ref/fate/filter-pixdesc-yuvj420p | 1 - > tests/ref/fate/filter-pixdesc-yuvj422p | 1 - > tests/ref/fate/filter-pixdesc-yuvj440p | 1 - > tests/ref/fate/filter-pixdesc-yuvj444p | 1 - > tests/ref/fate/filter-pixfmts-copy | 5 --- > tests/ref/fate/filter-pixfmts-crop | 5 --- > tests/ref/fate/filter-pixfmts-field | 5 --- > tests/ref/fate/filter-pixfmts-fieldorder | 3 -- > tests/ref/fate/filter-pixfmts-hflip | 5 --- > tests/ref/fate/filter-pixfmts-il | 5 --- > tests/ref/fate/filter-pixfmts-null | 5 --- > tests/ref/fate/filter-pixfmts-pad| 5 --- > tests/ref/fate/filter-pixfmts-scale | 5 --- > tests/ref/fate/filter-pixfmts-swapuv | 5 --- > tests/ref/fate/filter-pixfmts-vflip | 5 --- > tests/ref/fate/sws-pixdesc-query | 15 > 23 files changed, 5 insertions(+), 186 deletions(-) > delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj411p > delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj420p > delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj422p > delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj440p > delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj444p I assume you already know but this breaks several jpeg related fate tests [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode
On Sat, Dec 09, 2017 at 09:46:53PM +0100, Marton Balint wrote:
>
>
> On Mon, 27 Nov 2017, Michael Niedermayer wrote:
>
> >On Sun, Nov 26, 2017 at 12:09:35PM -0300, James Almer wrote:
> >>On 11/21/2017 6:48 PM, Marton Balint wrote:
> >>>
> >>>
> >>>On Thu, 9 Nov 2017, James Cowgill wrote:
> >>>
> Hi,
>
> On 09/11/17 14:02, Hendrik Leppkes wrote:
> >On Thu, Nov 9, 2017 at 1:21 PM, James Cowgill
> >wrote:
> >>In commit 061a0c14bb57 ("decode: restructure the core decoding
> >>code"), the
> >>deprecated avcodec_decode_* APIs were reworked so that they called
> >>into the
> >>new avcodec_send_packet / avcodec_receive_frame API. This had the
> >>side effect
> >>of prohibiting sending new packets containing data after a drain
> >>packet, but in previous versions of FFmpeg this "worked" and some
> >>applications relied on it.
> >>
> >>To restore some compatibility, reset the codec if we receive a new
> >>non-drain
> >>packet using the old API after draining has completed. While this does
> >>not give the same behaviour as the old API did, in the majority of
> >>cases
> >>it works and it does not require changes to any other part of the
> >>decoding
> >>code.
> >>
> >>Fixes ticket #6775
> >>Signed-off-by: James Cowgill
> >>---
> >> libavcodec/decode.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >>diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> >>index 86fe5aef52..2f1932fa85 100644
> >>--- a/libavcodec/decode.c
> >>+++ b/libavcodec/decode.c
> >>@@ -726,6 +726,11 @@ static int compat_decode(AVCodecContext *avctx,
> >>AVFrame *frame,
> >>
> >> av_assert0(avci->compat_decode_consumed == 0);
> >>
> >>+ if (avci->draining_done && pkt && pkt->size != 0) {
> >>+ av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after
> >>EOF\n");
> >>+ avcodec_flush_buffers(avctx);
> >>+ }
> >>+
> >
> >I don't think this is a good idea. Draining and not flushing
> >afterwards is a bug in the calling code, and even before recent
> >changes it would result in inconsistent behavior and even crashes
> >(with select decoders).
>
> I am fully aware that this will only trigger if the calling code is
> buggy. I am trying to avoid silent breakage of those applications doing
> this when upgrading to ffmpeg 3.4.
>
> I was looking at the documentation of avcodec_decode_* recently because
> of this and I had some trouble deciding if using the API this way was
> incorrect. I expect the downstreams affected thought that what they were
> doing was fine and then got angry when ffmpeg suddenly "broke" their
> code. This patch at least allows some sort of "transitional period"
> until downstreams update.
> >>>
> >>>I think the intent was to flush the codec by passing the NULL packets to
> >>>it, so it makes a lot of sense to actually do that. Especially since by
> >>>implicitly doing a flush, we can avoid the undefined behaviour/crashes
> >>>on the codec side.
> >>>
> >>>Also this is only compatibility code, which probably will be removed at
> >>>the next bump, I see no harm in making it as compatible as realistically
> >>>possible.
> >>
> >>The old decode API is not scheduled for removal right now probably
> >>because 99% of decoders need to be ported.
> >>This compat code was written so the old API becomes a wrapper for the
> >>new rather than the other way around, as it was up to 3.3. Supposedly a
> >>good portion of the versatility of the new API would be handicapped
> >>otherwise.
> >>
> >
> >>Personally, I think this should be left as is. It is a good incentive
> >>for downstream to migrate to the new API, as they technically were
> >>misusing the old API to begin with.
> >
> >providing compatibility support for an old API that does not actually
> >work with how applications used the old API is something a tad bit
> >bizzare
> >
> >We want to minimize the work everyone has to do.
> >The more time people have, the more they can spend on improving free
> >software.
> >
> >If the old API is going to be removed, any work people have to do
> >to hunt and track implementation changes in our old API the more
> >they have wasted time.
> >If you want people to spend their time on the new API, then you
> >should not introduce issues in the old API that they need to
> >workaround
> >They that way just lost time (debug, fix, test) they could have spend
> >on the new API or on anything else
> >
>
> Applied and backported.
Thanks alot !
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] amf: fix wrong profile level after auto-correction in H264 and HEVC
On Fri, Dec 08, 2017 at 07:23:38PM +, Mironov, Mikhail wrote: > Moved bitrate parameters set before Init() call because bitrate is used in > profile level correction code inside Init(). > > Signed-off-by: Mikhail Mironov > --- > libavcodec/amfenc_h264.c | 10 +- > libavcodec/amfenc_hevc.c | 8 > 2 files changed, 9 insertions(+), 9 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode
On Mon, 27 Nov 2017, Michael Niedermayer wrote:
On Sun, Nov 26, 2017 at 12:09:35PM -0300, James Almer wrote:
On 11/21/2017 6:48 PM, Marton Balint wrote:
On Thu, 9 Nov 2017, James Cowgill wrote:
Hi,
On 09/11/17 14:02, Hendrik Leppkes wrote:
On Thu, Nov 9, 2017 at 1:21 PM, James Cowgill
wrote:
In commit 061a0c14bb57 ("decode: restructure the core decoding
code"), the
deprecated avcodec_decode_* APIs were reworked so that they called
into the
new avcodec_send_packet / avcodec_receive_frame API. This had the
side effect
of prohibiting sending new packets containing data after a drain
packet, but in previous versions of FFmpeg this "worked" and some
applications relied on it.
To restore some compatibility, reset the codec if we receive a new
non-drain
packet using the old API after draining has completed. While this does
not give the same behaviour as the old API did, in the majority of
cases
it works and it does not require changes to any other part of the
decoding
code.
Fixes ticket #6775
Signed-off-by: James Cowgill
---
libavcodec/decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 86fe5aef52..2f1932fa85 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -726,6 +726,11 @@ static int compat_decode(AVCodecContext *avctx,
AVFrame *frame,
av_assert0(avci->compat_decode_consumed == 0);
+ if (avci->draining_done && pkt && pkt->size != 0) {
+ av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after
EOF\n");
+ avcodec_flush_buffers(avctx);
+ }
+
I don't think this is a good idea. Draining and not flushing
afterwards is a bug in the calling code, and even before recent
changes it would result in inconsistent behavior and even crashes
(with select decoders).
I am fully aware that this will only trigger if the calling code is
buggy. I am trying to avoid silent breakage of those applications doing
this when upgrading to ffmpeg 3.4.
I was looking at the documentation of avcodec_decode_* recently because
of this and I had some trouble deciding if using the API this way was
incorrect. I expect the downstreams affected thought that what they were
doing was fine and then got angry when ffmpeg suddenly "broke" their
code. This patch at least allows some sort of "transitional period"
until downstreams update.
I think the intent was to flush the codec by passing the NULL packets to
it, so it makes a lot of sense to actually do that. Especially since by
implicitly doing a flush, we can avoid the undefined behaviour/crashes
on the codec side.
Also this is only compatibility code, which probably will be removed at
the next bump, I see no harm in making it as compatible as realistically
possible.
The old decode API is not scheduled for removal right now probably
because 99% of decoders need to be ported.
This compat code was written so the old API becomes a wrapper for the
new rather than the other way around, as it was up to 3.3. Supposedly a
good portion of the versatility of the new API would be handicapped
otherwise.
Personally, I think this should be left as is. It is a good incentive
for downstream to migrate to the new API, as they technically were
misusing the old API to begin with.
providing compatibility support for an old API that does not actually
work with how applications used the old API is something a tad bit
bizzare
We want to minimize the work everyone has to do.
The more time people have, the more they can spend on improving free
software.
If the old API is going to be removed, any work people have to do
to hunt and track implementation changes in our old API the more
they have wasted time.
If you want people to spend their time on the new API, then you
should not introduce issues in the old API that they need to
workaround
They that way just lost time (debug, fix, test) they could have spend
on the new API or on anything else
Applied and backported.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/2] lavf/hls: add option to defer parsing of variants
Rainer Hochecker kirjoitti 2017-12-03 16:54:
---
doc/demuxers.texi | 6
libavformat/hls.c | 106
++
2 files changed, 98 insertions(+), 14 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..33643f966a 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -316,6 +316,12 @@ segment index to start live streams at (negative
values are from the end).
@item max_reload
Maximum number of times a insufficient list is attempted to be
reloaded.
Default value is 1000.
+
+@item load_all_variants
+If 0, only the first variant/playlist is loaded on open. All other
variants
+get disabled and can be enabled by setting discard option in program.
+Default value is 1.
+
@end table
@section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3c2c720abe..500e3c15de 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -112,6 +112,7 @@ struct playlist {
int n_segments;
struct segment **segments;
int needed;
+int parsed;
int cur_seq_no;
int64_t cur_seg_offset;
int64_t last_load_time;
@@ -206,6 +207,7 @@ typedef struct HLSContext {
int strict_std_compliance;
char *allowed_extensions;
int max_reload;
+int load_all_variants;
} HLSContext;
[...]
-static int playlist_needed(struct playlist *pls)
+static int playlist_needed(AVFormatContext *s, struct playlist *pls,
int check_parsed)
{
-AVFormatContext *s = pls->parent;
+HLSContext *c = s->priv_data;
int i, j;
int stream_needed = 0;
int first_st;
/* If there is no context or streams yet, the playlist is needed
*/
-if (!pls->ctx || !pls->n_main_streams)
+if (check_parsed && (!pls->ctx || !pls->n_main_streams))
return 1;
+/* If the playlist belongs to a non discarded variant and is not
parsed,
+ * we need to parse and activate it later */
+for (i = 0; i < s->nb_programs; i++) {
+AVProgram *program = s->programs[i];
+struct variant *var = c->variants[i];
+if (program->discard < AVDISCARD_ALL) {
+for (j = 0; j < var->n_playlists; j++) {
+if (var->playlists[j] == pls &&
!var->playlists[j]->parsed)
+return 1;
I think this is mostly the same check that is in the same function a
couple of
lines down, except with the added extra is_parsed check and that your
version
works even without streams.
So maybe we could avoid duplication by making the flow in the function
like this:
1. If any streams in the playlist are needed => stream_needed = 1
2. If streams_needed == 0 and playlist has streams => return 0
3. If playlist in undiscarded program (your version) => return 1
4. All program were discarded => return 0
So we avoid having to check for ->parsed and separate "check_parsed"
handling, I think.
Unparsed discarded playlists would return 0 in step 4 and unparsed
non-discarded playlists
would return 1 in step 3.
+}
+}
+}
+
/* check if any of the streams in the playlist are needed */
for (i = 0; i < pls->n_main_streams; i++) {
if (pls->main_streams[i]->discard < AVDISCARD_ALL) {
@@ -1324,7 +1344,7 @@ restart:
/* Check that the playlist is still needed before opening a
new
* segment. */
-v->needed = playlist_needed(v);
+v->needed = playlist_needed(v->parent, v, 1);
if (!v->needed) {
av_log(v->parent, AV_LOG_INFO, "No longer receiving
playlist %d\n",
@@ -1418,23 +1438,41 @@ reload:
static void add_renditions_to_variant(HLSContext *c, struct variant
*var,
enum AVMediaType type, const
char *group_id)
{
-int i;
+int i, j;
+int found;
for (i = 0; i < c->n_renditions; i++) {
struct rendition *rend = c->renditions[i];
if (rend->type == type && !strcmp(rend->group_id, group_id)) {
-if (rend->playlist)
+if (rend->playlist) {
/* rendition is an external playlist
* => add the playlist to the variant */
-dynarray_add(&var->playlists, &var->n_playlists,
rend->playlist);
-else
+found = 0;
+for (j = 0; j < var->n_playlists; j++) {
+if (var->playlists[j] == rend->playlist) {
+found = 1;
+break;
+}
+}
+if (!found)
+dynarray_add(&var->playlists, &var->n_playlists,
rend->playlist);
+} else {
/* rendition is part of the variant main Media
Playlist
* => add the rendition to the main Media Playlist */
-dynarray_add(&var->playlists[0]->renditions,
- &var->playlists[0]->n_renditions,
- rend);
+found = 0;
+for (j = 0
Re: [FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android
On Sat, Dec 9, 2017 at 12:14 AM, James Almer wrote: > Compilation error "out of range" fixed for armeabi-v7a. Compilation failed > trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error > messages is "Offset out of range". The reason of the error is assembler LDR > directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage > in range <1k, but no such storage provided. > > Based on a patch by Ihor Bobalo > > Suggested-by: wbs > Signed-off-by: James Almer > --- Pushed. Thanks for posting the patch. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants
(Re-added ffmpeg-devel@)
Rainer Hochecker kirjoitti 2017-12-03 09:16:
2017-12-02 16:09 GMT+01:00 Anssi Hannula :
Hi,
Sorry about the delay.
Rainer Hochecker kirjoitti 2017-11-28 00:23:
2017-11-27 22:53 GMT+01:00 Anssi Hannula :
Hi,
Rainer Hochecker kirjoitti 2017-11-26 12:46:
fixed mem leak poined out by Steven
---
doc/demuxers.texi | 5 +
libavformat/hls.c | 304
--
2 files changed, 209 insertions(+), 100 deletions(-)
[...]
+
+@item load_all_variants
+If 0, only the first variant/playlist is loaded on open. All other
variants
+get disabled and can be enabled by setting discard option in
program.
+Default value is 1.
@end table
If playlist download+parsing is indeed taking long enough time that
this
is
warranted, I wonder if we should maybe just never read any variant
playlists
in read_header(), and instead set AVFMTCTX_NOHEADER.
Then the user may discard AVPrograms right after open, before
unneeded
playlists are loaded+parsed.
This would avoid having a separate option/mode for this.
Any thoughts?
I actually tried it like this but somwhow did not like it because
this
is different
to all other demuxers/formats. In general you open an input, call
find_stream_info,
and select a program. I did not like selecting the program between
open
and
find_stream_info.
OK I guess. Though arguably hls is already quite different from mpegts
which
is the only other demuxer that creates multiple AVPrograms.
In the long run, I think I'd prefer the HLS demuxer to have a mode
where
only a single program/variant is given to the user at a time, with the
demuxer handling the switching between the variants. But that would be
a lot
more work and I'm not even sure it would be feasible. So I guess your
solution is OK, at least for now.
Is there a reason the first variant/playlist is still parsed, i.e. why
not
simply not parse any media playlists (i.e. only master pls) when the
new
mode is selected?
I thought this could become the new default after a while. Clients that
don't
select a program would still work. Selecting the first available
program, if
none was selected seems the most natural way. Selecting all or none
make
less sense.
Hmm.. I wonder if selecting the highest-bandwidth-one might make more
sense as the playlist/program order is arbitrary (IIRC) so currently an
arbitrary playlist is parsed.
If the player is selecting the variant/program based on bitrate (like
Kodi
does), then the first playlist would likely have been
downloaded+parsed
unnecessarily.
Right, but this is acceptable. The majority of user don't have set
network
bandwidth anyway.
If the user does not have bandwidth set, Kodi selects the
highest-bandwidth program => so both the first playlist and the
highest-bandwidth playlist get parsed.
Also, even with your current patch you will need to set
AVFMTCTX_NOHEADER as
you defer avformat_new_stream() calls to read_packet(). I think you
can
update update_noheader_flag() to set flag_needed=1 if any pls is
!pls->is_parsed.
Actually I call open again after having set AVFMTCTX_NOHEADER.
Could you please be more verbose on how you would like to have it?
With your patch, with load_all_variants=0, this happens, if I follow the
code right:
1. hls_read_header()
- A single playlist is opened - in this case the subdemuxer has no
AVFTMCTX_NOHEADER so AVFMTCTX_NOHEADER is not set on the main context.
- Other playlists are not parsed.
...
2. user undiscards a program.
3. hls_read_packet()
- Discard flag checking notices a new playlist is needed and it is
parsed.
- update_streams_from_subdemuxer() gets called from init_playlist(), and
it calls avformat_new_stream()
The read_packet documentation says:
'avformat_new_stream' can be called only if the flag
* AVFMTCTX_NOHEADER is used and only in the calling thread (not in
a
* background thread).
And you have not set AVFMTCTX_NOHEADER.
So probably update_noheader_flag() needs this change:
-if (pls->has_noheader_flag) {
+if (pls->has_noheader_flag || !pls->is_parsed) {
So that AVFMTCTX_NOHEADER gets always set if there are unparsed
playlists left.
That might cause e.g. avformat_find_stream_info (if it is called - looks
like Kodi always does for HLS - which might be another thing to check to
improve launch performance) to probe longer as it tries to find the
missing streams in vain, though, so better check the performance is
still OK afterwards...
@section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 786934af03..c42e0b0f95 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -112,6 +112,7 @@ struct playlist {
int n_segments;
struct segment **segments;
int needed, cur_needed;
+int parsed;
int cur_seq_no;
int64_t cur_seg_offset;
int64_t last_load_time;
@@ -206,6 +207,7 @@ typedef struct HLSContext {
int strict_std_compli
[FFmpeg-devel] avcodec/magicyuv : use gradient dsp func
Hello, in attach patch to use gradient_pred dsp func for magicyuvdec pass fate test for me Martin 0004-avcodec-magicyuv-use-gradient_pred-dsp-func-for-8-bi.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avcodec/utvideodec : use gradient pred for interlace
Hello, in attach patch to use gradient_pred dsp func, for interlace pass fate test for me (x86 64) Martin 0003-avcodec-utvideodec-use-gradient_pred-dsp-in-interlac.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: modify code indentation
On Sat, Dec 09, 2017 at 12:39:29AM +0800, tiejun.peng wrote: > Signed-off-by: tiejun.peng > --- > libavformat/mov.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: add some useful warning log of eof
On Sat, Dec 09, 2017 at 12:28:41AM +0800, tiejun.peng wrote: > Signed-off-by: tiejun.peng > --- > libavformat/mov.c | 43 +-- > 1 file changed, 33 insertions(+), 10 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/Makefile: Fix opus parser dependency.
On Fri, Dec 08, 2017 at 11:35:06AM -0800, Jacob Trimble wrote: > On Fri, Dec 8, 2017 at 10:39 AM, Michael Niedermayer > wrote: > > On Thu, Dec 07, 2017 at 11:30:13AM -0800, Jacob Trimble wrote: > >> The opus.c file uses variables that are defined in opustab.c. The > >> opus parser needs to include that file to avoid linker errors when > >> not including the opus encoder/decoder. > > > > please list the symbols needed or the error message in the commmit > > message, so the reader knows about which symbols this is > > > > thx > > Done > Makefile |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > dac7fd9255ebedc1e5db63bf6079aa8d1b6c9c8b opus-parser-v2.patch > From 8519e5192bc3dbbc5aa49204321419b6e5a8bf4b Mon Sep 17 00:00:00 2001 > From: Jacob Trimble > Date: Thu, 7 Dec 2017 11:05:46 -0800 > Subject: [PATCH] avcodec/Makefile: Fix opus parser dependency. > > The opus.c file uses ff_celt_freq_range and ff_celt_freq_bands which are > defined in opustab.c. The opus parser needs to include that file to > avoid linker errors when not including the opus encoder/decoder. will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] libavfilter/vf_blackdetect.c
Hello!
I wanted to apologize for the mess! Last Monday I already sended this
patch, but the first was not correct, and on top the email format was
not right to. So I hope now everything is ok.
Here is again the description:
This patch unify vf_blackdetect with af_silencedetect. Now the logging
prints *black_start* and *black_end* in separate lines. This is the same
behavior like af_silencedetect and it is also more useful for monitoring
stream. It works in that way, that when the black duration passes the
duration limit the log massage is: *black_start: 7.56 *and when the last
black frame comes, the massage: *black_end: 25 | black_duration: 17.44
*pop up.
I did compiling tests on MacOS/Windows and Ubuntu, all works fine. I
also make a fate test, it runs to, but I was not able to run this command:
tests/fate.sh fate-suite/
It always says something with path not fund... Is it really necessary to
run a fate test, even with a little change like this?
Regards
Jonathan
From b6b6e4ab885f9b35a6696492286e504a4b3d6d92 Mon Sep 17 00:00:00 2001
From: Jonathan
Date: Mon, 4 Dec 2017 16:05:48 +0100
Subject: [PATCH] unify blackdetect with af_silencedetect. Is more useful for
monitoring streams.
---
libavfilter/vf_blackdetect.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c
index 06ef9988d..92ea39b33 100644
--- a/libavfilter/vf_blackdetect.c
+++ b/libavfilter/vf_blackdetect.c
@@ -38,6 +38,7 @@ typedef struct BlackDetectContext {
int64_t black_end; ///< pts end time of the last black
picture
int64_t last_picref_pts; ///< pts of the last input picture
int black_started;
+int black_match;
double picture_black_ratio_th;
double pixel_black_th;
@@ -107,15 +108,20 @@ static int config_input(AVFilterLink *inlink)
return 0;
}
-static void check_black_end(AVFilterContext *ctx)
+static void check_black(AVFilterContext *ctx)
{
BlackDetectContext *blackdetect = ctx->priv;
AVFilterLink *inlink = ctx->inputs[0];
-if ((blackdetect->black_end - blackdetect->black_start) >=
blackdetect->black_min_duration) {
+if ((blackdetect->last_picref_pts - blackdetect->black_start) >=
blackdetect->black_min_duration && blackdetect->black_match == 0) {
av_log(blackdetect, AV_LOG_INFO,
- "black_start:%s black_end:%s black_duration:%s\n",
- av_ts2timestr(blackdetect->black_start, &inlink->time_base),
+ "black_start: %s \n",
+ av_ts2timestr(blackdetect->black_start, &inlink->time_base));
+blackdetect->black_match = 1;
+}
+if ((blackdetect->black_end - blackdetect->black_start) >=
blackdetect->black_min_duration && blackdetect->black_started == 1) {
+av_log(blackdetect, AV_LOG_INFO,
+ "black_end: %s | black_duration: %s \n",
av_ts2timestr(blackdetect->black_end, &inlink->time_base),
av_ts2timestr(blackdetect->black_end -
blackdetect->black_start, &inlink->time_base));
}
@@ -131,7 +137,7 @@ static int request_frame(AVFilterLink *outlink)
if (ret == AVERROR_EOF && blackdetect->black_started) {
// FIXME: black_end should be set to last_picref_pts +
last_picref_duration
blackdetect->black_end = blackdetect->last_picref_pts;
-check_black_end(ctx);
+check_black(ctx);
}
return ret;
}
@@ -163,15 +169,17 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
if (!blackdetect->black_started) {
/* black starts here */
blackdetect->black_started = 1;
+blackdetect->black_match = 0;
blackdetect->black_start = picref->pts;
av_dict_set(&picref->metadata, "lavfi.black_start",
av_ts2timestr(blackdetect->black_start, &inlink->time_base),
0);
}
+check_black(ctx);
} else if (blackdetect->black_started) {
/* black ends here */
-blackdetect->black_started = 0;
blackdetect->black_end = picref->pts;
-check_black_end(ctx);
+check_black(ctx);
+blackdetect->black_started = 0;
av_dict_set(&picref->metadata, "lavfi.black_end",
av_ts2timestr(blackdetect->black_end, &inlink->time_base), 0);
}
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: add flag to discard timestamps on corrupted frames
On Fri, Dec 08, 2017 at 10:34:39PM -0600, Rodger Combs wrote:
>
>
> > On Dec 8, 2017, at 11:06, Michael Niedermayer
> > wrote:
> >
> > On Thu, Dec 07, 2017 at 10:23:15PM -0600, Rodger Combs wrote:
> >> ---
> >> libavformat/avformat.h | 1 +
> >> libavformat/options_table.h | 1 +
> >> libavformat/utils.c | 8
> >> 3 files changed, 10 insertions(+)
> >>
> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> index 4f2798a871..d10d583dff 100644
> >> --- a/libavformat/avformat.h
> >> +++ b/libavformat/avformat.h
> >> @@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
> >> #define AVFMT_FLAG_FAST_SEEK 0x8 ///< Enable fast, but inaccurate
> >> seeks for some formats
> >> #define AVFMT_FLAG_SHORTEST 0x10 ///< Stop muxing when the shortest
> >> stream stops.
> >> #define AVFMT_FLAG_AUTO_BSF 0x20 ///< Add bitstream filters as
> >> requested by the muxer
> >> +#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of
> >> frames marked corrupt
> >>
> >> /**
> >> * Maximum size of the data read from input for determining
> >> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
> >> index b8fa47c6fd..515574d3e0 100644
> >> --- a/libavformat/options_table.h
> >> +++ b/libavformat/options_table.h
> >> @@ -58,6 +58,7 @@ static const AVOption avformat_options[] = {
> >> {"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, {
> >> .i64 = AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
> >> {"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST,
> >> { .i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
> >> {"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64
> >> = AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
> >> +{"discardcorruptts", "discard timestamps on corrupted frames", 0,
> >> AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_DISCARD_CORRUPT_TS }, 0, 0, E,
> >> "fflags" },
> >> {"analyzeduration", "specify how many microseconds are analyzed to probe
> >> the input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 },
> >> 0, INT64_MAX, D},
> >> {"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl =
> >> 0}, 0, 0, D},
> >> {"indexmem", "max memory used for timestamp index (per stream)",
> >> OFFSET(max_index_size), AV_OPT_TYPE_INT, {.i64 = 1<<20 }, 0, INT_MAX, D},
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index 84e49208b8..98af941e9f 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >
> >> @@ -873,6 +873,14 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
> >> st->cur_dts = wrap_timestamp(st, st->cur_dts);
> >> }
> >>
> >> +if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT_TS) &&
> >> +(pkt->flags & AV_PKT_FLAG_CORRUPT)) {
> >> +pkt->pts = pkt->dts = AV_NOPTS_VALUE;
> >> +av_log(s, AV_LOG_WARNING,
> >> + "Discarded timestamp on corrupted packet (stream =
> >> %d)\n",
> >> + pkt->stream_index);
> >> +}
> >
> > how many of the cases that set AV_PKT_FLAG_CORRUPT can even be due to
> > the timestamp ?
>
> Pretty much just the new TEI check, or potentially other CRC checks. I don't
> _think_ the continuity-counter check failing could indicate an incorrect
> timestamp. I suppose we could add a second flag just for corruption that
> could affect timestamps?
I think thats a great idea, maybe if we already change it we should
also split the truncated case out as it is very common.
AV_PKT_FLAG_DATA_CORRUPT// the packet data may be corrupted
AV_PKT_FLAG_DATA_TRUNCATED // the packet size may be corrupted,
data available is undamaged unless another flag indicates otherwise. Any
headers or sub-packets which are complete are non corrupted-
AV_PKT_FLAG_TS_CORRUPT // the packets timestamps and or
duration may be corrupted
#define AV_PKT_FLAG_CORRUPT (AV_PKT_FLAG_DATA_CORRUPT |
AV_PKT_FLAG_DATA_TRUNCATED | AV_PKT_FLAG_TS_CORRUPT)
or some variation of this
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct answer.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avfilter/x86/vf_blend : add avx2 version for 8b func (WIP)
Hello, in attach patch to add AVX2 version for each 8b func (except divide) 001 : avutil : add ABS2 for avx2 002 : avfilter : add AVX2 version for most of the func, the AVX2 is a simple modification VBROADCASTi128, for constant loading when the process stay in 8bits when the process use intermediate 16 bits (the load use movh (64 bits load)) i create a macro (someone will probably have a better idea for the name of these new macro) the idea in AVX2 is to load 128bits of data (2x 64 bits) then shuffle accross lane, the two 64 bits in the low part of each lane, to keep the rest of the process similar to the sse version for the store, the idea is similar in the opposite way (shuffle before store) The speed improvment is not very significative for these func (grainextract, multiply, screen, average, grainmerge) (i'm not sure, the avx2 version is need (except for screen). Checkasm result (x86_64, kaby lake) ./tests/checkasm/checkasm --test=vf_blend --bench benchmarking with native FFmpeg timers nop: 36.2 checkasm: using random seed 2027036350 SSE2: - vf_blend.8bit [OK] SSSE3: - vf_blend.8bit [OK] AVX2: - vf_blend.8bit [OK] checkasm: all 37 tests passed addition_c: 21882.7 addition_sse2: 483.9 addition_avx2: 250.9 and_c: 15336.7 and_sse2: 421.9 and_avx2: 196.7 average_c: 15640.7 average_sse2: 1160.7 average_avx2: 1155.7 darken_c: 27204.7 darken_sse2: 486.7 darken_avx2: 251.9 difference_c: 17101.9 difference_sse2: 981.2 difference_ssse3: 965.4 difference_avx2: 514.2 extremity_c: 27748.9 extremity_sse2: 1174.4 extremity_ssse3: 983.7 extremity_avx2: 520.4 grainextract_c: 22755.9 grainextract_sse2: 1158.2 grainextract_avx2: 1152.9 grainmerge_c: 26173.9 grainmerge_sse2: 1156.9 grainmerge_avx2: 1153.9 hardmix_c: 15676.9 hardmix_sse2: 458.4 hardmix_avx2: 268.7 lighten_c: 27137.4 lighten_sse2: 422.2 lighten_avx2: 194.2 multiply_c: 16449.9 multiply_sse2: 1378.9 multiply_avx2: 1158.7 negation_c: 17372.9 negation_sse2: 1439.4 negation_ssse3: 1172.4 negation_avx2: 520.4 or_c: 14116.2 or_sse2: 483.9 or_avx2: 236.4 phoenix_c: 30905.9 phoenix_sse2: 553.7 phoenix_avx2: 388.7 screen_c: 20414.7 screen_sse2: 1803.9 screen_avx2: 1257.4 subtract_c: 20596.2 subtract_sse2: 439.7 subtract_avx2: 403.7 xor_c: 15380.7 xor_sse2: 445.7 xor_avx2: 405.2 Comment welcome Martin 0001-avutil-x86-x86util-add-ABS2-for-AVX2.patch Description: Binary data 0002-avfilter-x86-vf_blend-add-AVX2-version.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/matroskadec: resync if cluster parsing fails while seeking
On Fri, Dec 08, 2017 at 06:45:34AM -0600, Rodger Combs wrote: > --- > libavformat/matroskadec.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) can you add a fate test for this commit or patchset ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: LibreSSL (libtls) support
On 09.12.2017 at 17:29 Matt Oliver wrote: > OK I finally got around to looking through this (sorry for the delay I > previously hadnt had time) and everything looks good. > Since someone complains about LibreSSL not working with our OpenSSL support > every couple of months then this would be a welcome fix and in my opinion > this is the best way to support LibreSSL going forward. If Stefan is happy > to continue to support this in the future if needed then im on-board with > merging this. Thanks for taking a look. Previously, I was under the impression that LibreSSL support was not desired (though nobody has voiced their concerns on the ML). In any case, I'm fine with maintaining the libtls backend. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: LibreSSL (libtls) support
On 5 November 2017 at 02:11, Stefan _ wrote: > Attached patch adds support for LibreSSL. Instead of trying to implement > support into the existing tls_openssl.c using lots of #ifdefs (which was > rejected previously(?)) this adds a new TLS backend making use of the > new libtls library. > > Things to note: > > - Haven't looked at LibreSSL's license closely, I assume that it has the > same GPL licensing incompatibility as a derivative of OpenSSL (requires > --enable-nonfree if --enable-gpl is used) > Yes LibreSSl has the same apache license as OpenSSL - ffrtmpcrypt support is not implemented since the bignum functions are > not part of libtls itself > > - Not sure why anyone would use libtls without pkg-config but supporting > it probably doesn't hurt > pkg-config is generally preferred anyway I have tested all features (client mode, listen mode, cert/hostname > verification) on both Alpine and Arch Linux. > > Before michaelni asks again: Yes, the absence of my real name in git is > intended. > OK I finally got around to looking through this (sorry for the delay I previously hadnt had time) and everything looks good. Since someone complains about LibreSSL not working with our OpenSSL support every couple of months then this would be a welcome fix and in my opinion this is the best way to support LibreSSL going forward. If Stefan is happy to continue to support this in the future if needed then im on-board with merging this. If no one has any issues Ill merge this in a couple of days. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it
Signed-off-by: Paul B Mahol
---
libavcodec/avcodec.h | 1 +
libavcodec/utils.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5db6a81320..e5de4797c8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3376,6 +3376,7 @@ typedef struct AVCodec {
uint8_t max_lowres; ///< maximum value for lowres
supported by the decoder
const AVClass *priv_class; ///< AVClass for the private
context
const AVProfile *profiles; ///< array of recognized profiles,
or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
+int color_range;///< supported color range by
encoder, 0 means any is supported
/*
* No fields below this line are part of the public API. They
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index baf09119fe..aa81c21ef3 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
avctx->color_range = AVCOL_RANGE_JPEG;
}
+if (avctx->codec->color_range)
+avctx->color_range = avctx->codec->color_range;
if (avctx->codec->supported_samplerates) {
for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
if (avctx->sample_rate ==
avctx->codec->supported_samplerates[i])
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 17/27] avcodec/mjpegdec: remove YUVJ pixel format usage
Signed-off-by: Paul B Mahol
---
libavcodec/mjpegdec.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 55676d8576..160bbfd34b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2415,12 +2415,9 @@ the_end:
if (AV_RB32(s->upscale_h)) {
int p;
-av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
- avctx->pix_fmt == AV_PIX_FMT_YUV444P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ440P ||
+av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUV444P ||
avctx->pix_fmt == AV_PIX_FMT_YUV440P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA444P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV420P16||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P ||
@@ -2476,14 +2473,10 @@ the_end:
}
if (AV_RB32(s->upscale_v)) {
int p;
-av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
- avctx->pix_fmt == AV_PIX_FMT_YUV444P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
+av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUV444P ||
avctx->pix_fmt == AV_PIX_FMT_YUV422P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV440P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ440P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA444P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P16||
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 09/27] avcodec/fraps: replace YUVJ pixel format
Signed-off-by: Paul B Mahol --- libavcodec/fraps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/fraps.c b/libavcodec/fraps.c index 7a7673f73f..b2025b5d3f 100644 --- a/libavcodec/fraps.c +++ b/libavcodec/fraps.c @@ -218,7 +218,7 @@ static int decode_frame(AVCodecContext *avctx, f->pict_type = AV_PICTURE_TYPE_I; f->key_frame = 1; -avctx->pix_fmt = version & 1 ? is_pal ? AV_PIX_FMT_PAL8 : AV_PIX_FMT_BGR24 : AV_PIX_FMT_YUVJ420P; +avctx->pix_fmt = version & 1 ? is_pal ? AV_PIX_FMT_PAL8 : AV_PIX_FMT_BGR24 : AV_PIX_FMT_YUV420P; avctx->color_range = version & 1 ? AVCOL_RANGE_UNSPECIFIED : AVCOL_RANGE_JPEG; avctx->colorspace = version & 1 ? AVCOL_SPC_UNSPECIFIED : AVCOL_SPC_BT709; -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 14/27] avcodec/reqvideoenc: do not use YUVJ pixel format
Signed-off-by: Paul B Mahol
---
libavcodec/roqvideoenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index ac05123dc6..0f49450054 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -1132,7 +1132,8 @@ AVCodec ff_roq_encoder = {
.init = roq_encode_init,
.encode2 = roq_encode_frame,
.close= roq_encode_end,
-.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUVJ444P,
+.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE },
+.color_range = AVCOL_RANGE_JPEG,
.priv_class = &roq_class,
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 10/27] avcodec/roqvideodec: replace YUVJ pixel format
Signed-off-by: Paul B Mahol --- libavcodec/roqvideodec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/roqvideodec.c b/libavcodec/roqvideodec.c index 0ab7d399d6..c5b7bbe236 100644 --- a/libavcodec/roqvideodec.c +++ b/libavcodec/roqvideodec.c @@ -190,7 +190,7 @@ static av_cold int roq_decode_init(AVCodecContext *avctx) return AVERROR(ENOMEM); } -avctx->pix_fmt = AV_PIX_FMT_YUVJ444P; +avctx->pix_fmt = AV_PIX_FMT_YUV444P; avctx->color_range = AVCOL_RANGE_JPEG; return 0; -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 27/27] all: remove rest of YUVJ pixel formats usage
Signed-off-by: Paul B Mahol
---
fftools/ffmpeg_filter.c | 4 +--
libavcodec/raw.c | 18 +++---
libavcodec/utils.c | 11 --
libavutil/pixdesc.c | 60
libavutil/pixfmt.h | 5 ---
libswscale/utils.c | 20 ---
tests/ref/fate/filter-pixdesc-yuvj411p | 1 -
tests/ref/fate/filter-pixdesc-yuvj420p | 1 -
tests/ref/fate/filter-pixdesc-yuvj422p | 1 -
tests/ref/fate/filter-pixdesc-yuvj440p | 1 -
tests/ref/fate/filter-pixdesc-yuvj444p | 1 -
tests/ref/fate/filter-pixfmts-copy | 5 ---
tests/ref/fate/filter-pixfmts-crop | 5 ---
tests/ref/fate/filter-pixfmts-field | 5 ---
tests/ref/fate/filter-pixfmts-fieldorder | 3 --
tests/ref/fate/filter-pixfmts-hflip | 5 ---
tests/ref/fate/filter-pixfmts-il | 5 ---
tests/ref/fate/filter-pixfmts-null | 5 ---
tests/ref/fate/filter-pixfmts-pad| 5 ---
tests/ref/fate/filter-pixfmts-scale | 5 ---
tests/ref/fate/filter-pixfmts-swapuv | 5 ---
tests/ref/fate/filter-pixfmts-vflip | 5 ---
tests/ref/fate/sws-pixdesc-query | 15
23 files changed, 5 insertions(+), 186 deletions(-)
delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj411p
delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj420p
delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj422p
delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj440p
delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj444p
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index e69bfe295c..3aad564b81 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -42,12 +42,10 @@
static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum
AVCodecID codec_id, const enum AVPixelFormat default_formats[])
{
static const enum AVPixelFormat mjpeg_formats[] =
-{ AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
- AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
+{ AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE };
static const enum AVPixelFormat ljpeg_formats[] =
{ AV_PIX_FMT_BGR24 , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
- AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
AV_PIX_FMT_NONE};
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 8da2a9735e..e19049b455 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -39,13 +39,6 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
{ AV_PIX_FMT_YUV422P, MKTAG('Y', '4', '2', 'B') },
{ AV_PIX_FMT_YUV422P, MKTAG('P', '4', '2', '2') },
{ AV_PIX_FMT_YUV422P, MKTAG('Y', 'V', '1', '6') },
-/* yuvjXXX formats are deprecated hacks specific to libav*,
- they are identical to yuvXXX */
-{ AV_PIX_FMT_YUVJ420P, MKTAG('I', '4', '2', '0') }, /* Planar formats */
-{ AV_PIX_FMT_YUVJ420P, MKTAG('I', 'Y', 'U', 'V') },
-{ AV_PIX_FMT_YUVJ420P, MKTAG('Y', 'V', '1', '2') },
-{ AV_PIX_FMT_YUVJ422P, MKTAG('Y', '4', '2', 'B') },
-{ AV_PIX_FMT_YUVJ422P, MKTAG('P', '4', '2', '2') },
{ AV_PIX_FMT_GRAY8,MKTAG('Y', '8', '0', '0') },
{ AV_PIX_FMT_GRAY8,MKTAG('Y', '8', ' ', ' ') },
@@ -102,11 +95,8 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
{ AV_PIX_FMT_BGR24,MKTAG('B', 'G', 'R', 24 ) },
{ AV_PIX_FMT_YUV411P, MKTAG('4', '1', '1', 'P') },
{ AV_PIX_FMT_YUV422P, MKTAG('4', '2', '2', 'P') },
-{ AV_PIX_FMT_YUVJ422P, MKTAG('4', '2', '2', 'P') },
{ AV_PIX_FMT_YUV440P, MKTAG('4', '4', '0', 'P') },
-{ AV_PIX_FMT_YUVJ440P, MKTAG('4', '4', '0', 'P') },
{ AV_PIX_FMT_YUV444P, MKTAG('4', '4', '4', 'P') },
-{ AV_PIX_FMT_YUVJ444P, MKTAG('4', '4', '4', 'P') },
{ AV_PIX_FMT_MONOWHITE,MKTAG('B', '1', 'W', '0') },
{ AV_PIX_FMT_MONOBLACK,MKTAG('B', '0', 'W', '1') },
{ AV_PIX_FMT_BGR8, MKTAG('B', 'G', 'R', 8 ) },
@@ -247,10 +237,10 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
{ AV_PIX_FMT_YUV422P, MKTAG('I', '4', '2', '2') },
{ AV_PIX_FMT_YUV440P, MKTAG('I', '4', '4', '0') },
{ AV_PIX_FMT_YUV444P, MKTAG('I', '4', '4', '4') },
-{ AV_PIX_FMT_YUVJ420P,MKTAG('J', '4', '2', '0') },
-{ AV_PIX_FMT_YUVJ422P,MKTAG('J', '4', '2', '2') },
-{ AV_PIX_FMT_YUVJ440P,MKTAG('J', '4', '4', '0') },
-{ AV_PIX_FMT_YUVJ444P,MKTAG('J', '4', '4', '4') },
+{ AV_PIX_FMT_YUV420P, MKTAG('J', '4', '2', '0') },
+{ AV_PIX_FMT_YUV422P, MKTAG('J', '4', '2', '2') },
+{ AV_PIX_FMT_YUV440P, MKTAG('J', '4', '4', '0') },
+{ AV_PIX_FMT_YUV444P, MKTAG('J', '4', '4', '4') },
{ AV_PIX_FMT_YUVA444P,MKTAG('Y', 'U', 'V', 'A') },
{ AV_PIX_FMT_YUVA420P,MKTAG('I', '4', '0', 'A') },
{ AV_PIX_FMT_YUVA422P,MKTAG('
[FFmpeg-devel] [PATCH 25/27] avformat/rtpenc_jpeg: remove usage of YUVJ formats
Signed-off-by: Paul B Mahol
---
libavformat/rtpenc_jpeg.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index 38eb2e68eb..e0e7afebfc 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -46,13 +46,11 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t
*buf, int size)
h = AV_CEIL_RSHIFT(s1->streams[0]->codecpar->height, 3);
/* get the pixel format type or fail */
-if (s1->streams[0]->codecpar->format == AV_PIX_FMT_YUVJ422P ||
-(s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
- s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV422P)) {
+if (s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
+ s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV422P) {
type = 0;
-} else if (s1->streams[0]->codecpar->format == AV_PIX_FMT_YUVJ420P ||
- (s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
-s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV420P)) {
+} else if (s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
+s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV420P) {
type = 1;
} else {
av_log(s1, AV_LOG_ERROR, "Unsupported pixel format\n");
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 24/27] avfilter/vf_setrange: change outlink color_range too
Signed-off-by: Paul B Mahol
---
libavfilter/vf_setparams.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index 8427f98ba8..98a4aa2ad3 100644
--- a/libavfilter/vf_setparams.c
+++ b/libavfilter/vf_setparams.c
@@ -56,6 +56,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
return ff_filter_frame(ctx->outputs[0], frame);
}
+static int config_output(AVFilterLink *outlink)
+{
+SetParamsContext *s = outlink->src->priv;
+
+if (s->color_range >= 0)
+outlink->color_range = s->color_range;
+
+return 0;
+}
+
static const AVFilterPad inputs[] = {
{
.name = "default",
@@ -69,6 +79,7 @@ static const AVFilterPad outputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
+.config_props = config_output,
},
{ NULL }
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 26/27] avfilter: remove YUVJ pixel format usage
Signed-off-by: Paul B Mahol --- libavfilter/avf_showspectrum.c | 2 +- libavfilter/vaf_spectrumsynth.c| 4 +--- libavfilter/vf_atadenoise.c| 3 --- libavfilter/vf_avgblur.c | 4 +--- libavfilter/vf_bitplanenoise.c | 2 -- libavfilter/vf_blend.c | 1 - libavfilter/vf_bwdif.c | 2 -- libavfilter/vf_colorspace.c| 1 - libavfilter/vf_convolution.c | 4 +--- libavfilter/vf_convolve.c | 4 +--- libavfilter/vf_cover_rect.c| 3 +-- libavfilter/vf_cropdetect.c| 6 +++--- libavfilter/vf_deband.c| 4 +--- libavfilter/vf_deflicker.c | 3 --- libavfilter/vf_deshake.c | 3 +-- libavfilter/vf_displace.c | 4 +--- libavfilter/vf_drawbox.c | 3 +-- libavfilter/vf_extractplanes.c | 6 -- libavfilter/vf_fade.c | 3 +-- libavfilter/vf_fftfilt.c | 6 +++--- libavfilter/vf_fillborders.c | 4 +--- libavfilter/vf_find_rect.c | 1 - libavfilter/vf_framepack.c | 3 +-- libavfilter/vf_framerate.c | 10 +- libavfilter/vf_fspp.c | 2 -- libavfilter/vf_gblur.c | 4 +--- libavfilter/vf_histogram.c | 8 libavfilter/vf_hqdn3d.c| 4 libavfilter/vf_hysteresis.c| 4 +--- libavfilter/vf_idet.c | 4 libavfilter/vf_interlace.c | 4 ++-- libavfilter/vf_lenscorrection.c| 4 ++-- libavfilter/vf_limiter.c | 4 +--- libavfilter/vf_lut.c | 2 -- libavfilter/vf_lut2.c | 4 +--- libavfilter/vf_maskedclamp.c | 4 +--- libavfilter/vf_maskedmerge.c | 4 +--- libavfilter/vf_mestimate.c | 3 --- libavfilter/vf_midequalizer.c | 4 +--- libavfilter/vf_minterpolate.c | 3 --- libavfilter/vf_mpdecimate.c| 2 -- libavfilter/vf_neighbor.c | 1 - libavfilter/vf_nlmeans.c | 3 --- libavfilter/vf_nnedi.c | 3 --- libavfilter/vf_ocr.c | 3 --- libavfilter/vf_overlay.c | 6 +++--- libavfilter/vf_perspective.c | 1 - libavfilter/vf_phase.c | 1 - libavfilter/vf_pp.c| 12 libavfilter/vf_pp7.c | 2 -- libavfilter/vf_premultiply.c | 10 +- libavfilter/vf_psnr.c | 2 -- libavfilter/vf_pullup.c| 4 +--- libavfilter/vf_readeia608.c| 3 --- libavfilter/vf_readvitc.c | 5 - libavfilter/vf_remap.c | 1 - libavfilter/vf_removegrain.c | 2 -- libavfilter/vf_rotate.c| 4 ++-- libavfilter/vf_signalstats.c | 2 -- libavfilter/vf_signature.c | 3 --- libavfilter/vf_spp.c | 2 -- libavfilter/vf_ssim.c | 2 -- libavfilter/vf_stereo3d.c | 5 - libavfilter/vf_threshold.c | 4 +--- libavfilter/vf_tinterlace.c| 11 ++- libavfilter/vf_unsharp.c | 4 ++-- libavfilter/vf_uspp.c | 2 -- libavfilter/vf_vaguedenoiser.c | 3 --- libavfilter/vf_vectorscope.c | 10 +- libavfilter/vf_w3fdif.c| 3 --- libavfilter/vf_waveform.c | 10 ++ libavfilter/vf_yadif.c | 4 libavfilter/vf_zoompan.c | 3 --- libavfilter/vf_zscale.c| 3 --- libavfilter/vsrc_testsrc.c | 2 +- tests/ref/fate/filter-pixfmts-lut | 4 tests/ref/fate/filter-pixfmts-pullup | 5 - tests/ref/fate/filter-pixfmts-rotate | 2 -- tests/ref/fate/filter-pixfmts-tinterlace_cvlpf | 4 tests/ref/fate/filter-pixfmts-tinterlace_merge | 4 tests/ref/fate/filter-pixfmts-tinterlace_pad | 4 tests/ref/fate/filter-pixfmts-tinterlace_vlpf | 4 82 files changed, 63 insertions(+), 250 deletions(-) diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c index 956f62f3ad..33449df315 100644 --- a/libavfilter/avf_showspectrum.c +++ b/libavfilter/av
[FFmpeg-devel] [PATCH 19/27] avcodec/mjpegenc: remove usage of YUVJ pixel formats
Signed-off-by: Paul B Mahol
---
libavcodec/mjpegenc.c| 6 --
libavcodec/mjpegenc_common.c | 2 +-
libavcodec/mpegvideo_enc.c | 8 +---
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index d2fcb8e191..9602a6fe64 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -415,8 +415,9 @@ AVCodec ff_mjpeg_encoder = {
.close = ff_mpv_encode_end,
.capabilities = AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_FRAME_THREADS
| AV_CODEC_CAP_INTRA_ONLY,
.pix_fmts = (const enum AVPixelFormat[]) {
-AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NONE
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE
},
+.color_range= AVCOL_RANGE_JPEG,
.priv_class = &mjpeg_class,
};
#endif
@@ -439,8 +440,9 @@ AVCodec ff_amv_encoder = {
.encode2= amv_encode_picture,
.close = ff_mpv_encode_end,
.pix_fmts = (const enum AVPixelFormat[]) {
-AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE
},
+.color_range= AVCOL_RANGE_JPEG,
.priv_class = &amv_class,
};
#endif
diff --git a/libavcodec/mjpegenc_common.c b/libavcodec/mjpegenc_common.c
index 31868c9bed..4ecc05bc09 100644
--- a/libavcodec/mjpegenc_common.c
+++ b/libavcodec/mjpegenc_common.c
@@ -232,7 +232,7 @@ void ff_mjpeg_init_hvsample(AVCodecContext *avctx, int
hsample[4], int vsample[4
vsample[1] = hsample[1] =
vsample[2] = hsample[2] =
vsample[3] = hsample[3] = 1;
-} else if (avctx->pix_fmt == AV_PIX_FMT_YUV444P || avctx->pix_fmt ==
AV_PIX_FMT_YUVJ444P) {
+} else if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
vsample[0] = vsample[1] = vsample[2] = 2;
hsample[0] = hsample[1] = hsample[2] = 1;
} else {
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index f1f4989231..20830887dc 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -306,10 +306,7 @@ av_cold int ff_mpv_encode_init(AVCodecContext *avctx)
case AV_CODEC_ID_AMV:
format_supported = 0;
/* JPEG color space */
-if (avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
-avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
-avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
-(avctx->color_range == AVCOL_RANGE_JPEG &&
+if ((avctx->color_range == AVCOL_RANGE_JPEG &&
(avctx->pix_fmt == AV_PIX_FMT_YUV420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV422P ||
avctx->pix_fmt == AV_PIX_FMT_YUV444P)))
@@ -334,15 +331,12 @@ av_cold int ff_mpv_encode_init(AVCodecContext *avctx)
}
switch (avctx->pix_fmt) {
-case AV_PIX_FMT_YUVJ444P:
case AV_PIX_FMT_YUV444P:
s->chroma_format = CHROMA_444;
break;
-case AV_PIX_FMT_YUVJ422P:
case AV_PIX_FMT_YUV422P:
s->chroma_format = CHROMA_422;
break;
-case AV_PIX_FMT_YUVJ420P:
case AV_PIX_FMT_YUV420P:
default:
s->chroma_format = CHROMA_420;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 22/27] avcodec/qsv: remove YUVJ pixel format usage
Signed-off-by: Paul B Mahol
---
libavcodec/qsv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 250b4e61e3..6eee40a222 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -171,7 +171,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t
*fourcc)
{
switch (format) {
case AV_PIX_FMT_YUV420P:
-case AV_PIX_FMT_YUVJ420P:
case AV_PIX_FMT_NV12:
*fourcc = MFX_FOURCC_NV12;
return AV_PIX_FMT_NV12;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 20/27] avcodec/vdpau: remove YUVJ pixel format usage
Signed-off-by: Paul B Mahol
---
libavcodec/vdpau.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1b2ec989cd..f7d1535fc7 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -82,19 +82,16 @@ int av_vdpau_get_surface_parameters(AVCodecContext *avctx,
/* See for per-type alignment constraints. */
switch (avctx->sw_pix_fmt) {
case AV_PIX_FMT_YUV420P:
-case AV_PIX_FMT_YUVJ420P:
t = VDP_CHROMA_TYPE_420;
w = (w + 1) & ~1;
h = (h + 3) & ~3;
break;
case AV_PIX_FMT_YUV422P:
-case AV_PIX_FMT_YUVJ422P:
t = VDP_CHROMA_TYPE_422;
w = (w + 1) & ~1;
h = (h + 1) & ~1;
break;
case AV_PIX_FMT_YUV444P:
-case AV_PIX_FMT_YUVJ444P:
t = VDP_CHROMA_TYPE_444;
h = (h + 1) & ~1;
break;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 23/27] avfilter/vf_blackdetect: use color_range from inlink
Remove YUVJ pixel format usage.
Signed-off-by: Paul B Mahol
---
libavfilter/vf_blackdetect.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c
index 06ef9988d1..ff4b9eebb9 100644
--- a/libavfilter/vf_blackdetect.c
+++ b/libavfilter/vf_blackdetect.c
@@ -61,13 +61,6 @@ static const AVOption blackdetect_options[] = {
AVFILTER_DEFINE_CLASS(blackdetect);
-#define YUVJ_FORMATS \
-AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P
-
-static const enum AVPixelFormat yuvj_formats[] = {
-YUVJ_FORMATS, AV_PIX_FMT_NONE
-};
-
static int query_formats(AVFilterContext *ctx)
{
static const enum AVPixelFormat pix_fmts[] = {
@@ -76,7 +69,6 @@ static int query_formats(AVFilterContext *ctx)
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NV12, AV_PIX_FMT_NV21,
-YUVJ_FORMATS,
AV_PIX_FMT_NONE
};
@@ -94,7 +86,7 @@ static int config_input(AVFilterLink *inlink)
blackdetect->black_min_duration =
blackdetect->black_min_duration_time / av_q2d(inlink->time_base);
-blackdetect->pixel_black_th_i = ff_fmt_is_in(inlink->format, yuvj_formats)
?
+blackdetect->pixel_black_th_i = inlink->color_range == AVCOL_RANGE_JPEG ?
// luminance_minimum_value + pixel_black_th * luminance_range_size
blackdetect->pixel_black_th * 255 :
16 + blackdetect->pixel_black_th * (235 - 16);
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 21/27] avcodec/nvenc: remove YUVJ pixel formats usage
Signed-off-by: Paul B Mahol --- libavcodec/nvenc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 4a91d99720..6ef51adaf0 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -911,8 +911,7 @@ static av_cold int nvenc_setup_h264_config(AVCodecContext *avctx) vui->colourMatrix = avctx->colorspace; vui->colourPrimaries = avctx->color_primaries; vui->transferCharacteristics = avctx->color_trc; -vui->videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG -|| ctx->data_pix_fmt == AV_PIX_FMT_YUVJ420P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ422P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ444P); +vui->videoFullRangeFlag = avctx->color_range == AVCOL_RANGE_JPEG; vui->colourDescriptionPresentFlag = (avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2); @@ -999,8 +998,7 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext *avctx) vui->colourMatrix = avctx->colorspace; vui->colourPrimaries = avctx->color_primaries; vui->transferCharacteristics = avctx->color_trc; -vui->videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG -|| ctx->data_pix_fmt == AV_PIX_FMT_YUVJ420P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ422P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ444P); +vui->videoFullRangeFlag = avctx->color_range == AVCOL_RANGE_JPEG; vui->colourDescriptionPresentFlag = (avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2); -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 18/27] libavcodec/hevcdec: remove usage of YUVJ pixel format
Signed-off-by: Paul B Mahol
---
libavcodec/hevcdec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 433a7056ea..d1b54b1db5 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -363,7 +363,6 @@ static enum AVPixelFormat get_format(HEVCContext *s, const
HEVCSPS *sps)
switch (sps->pix_fmt) {
case AV_PIX_FMT_YUV420P:
-case AV_PIX_FMT_YUVJ420P:
#if CONFIG_HEVC_DXVA2_HWACCEL
*fmt++ = AV_PIX_FMT_DXVA2_VLD;
#endif
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 16/27] avcodec/ljpegenc: do not use YUVJ pixel formats
Signed-off-by: Paul B Mahol
---
libavcodec/ljpegenc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavcodec/ljpegenc.c b/libavcodec/ljpegenc.c
index 924d2e2fff..2d7235dd96 100644
--- a/libavcodec/ljpegenc.c
+++ b/libavcodec/ljpegenc.c
@@ -289,10 +289,7 @@ static av_cold int ljpeg_encode_init(AVCodecContext *avctx)
{
LJpegEncContext *s = avctx->priv_data;
-if ((avctx->pix_fmt == AV_PIX_FMT_YUV420P ||
- avctx->pix_fmt == AV_PIX_FMT_YUV422P ||
- avctx->pix_fmt == AV_PIX_FMT_YUV444P ||
- avctx->color_range == AVCOL_RANGE_MPEG) &&
+if (avctx->color_range == AVCOL_RANGE_MPEG &&
avctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
av_log(avctx, AV_LOG_ERROR,
"Limited range YUV is non-standard, set strict_std_compliance
to "
@@ -363,7 +360,6 @@ AVCodec ff_ljpeg_encoder = {
.capabilities = AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
.pix_fmts = (const enum AVPixelFormat[]){
AV_PIX_FMT_BGR24 , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
-AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
AV_PIX_FMT_NONE},
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 15/27] avcodec/libx264: do not use YUVJ pixel formats
Signed-off-by: Paul B Mahol
---
libavcodec/libx264.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9c67c91f33..7a7f21c3d0 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -152,7 +152,6 @@ static int avfmt2_num_planes(int avfmt)
{
switch (avfmt) {
case AV_PIX_FMT_YUV420P:
-case AV_PIX_FMT_YUVJ420P:
case AV_PIX_FMT_YUV420P9:
case AV_PIX_FMT_YUV420P10:
case AV_PIX_FMT_YUV444P:
@@ -414,14 +413,11 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
{
switch (pix_fmt) {
case AV_PIX_FMT_YUV420P:
-case AV_PIX_FMT_YUVJ420P:
case AV_PIX_FMT_YUV420P9:
case AV_PIX_FMT_YUV420P10: return X264_CSP_I420;
case AV_PIX_FMT_YUV422P:
-case AV_PIX_FMT_YUVJ422P:
case AV_PIX_FMT_YUV422P10: return X264_CSP_I422;
case AV_PIX_FMT_YUV444P:
-case AV_PIX_FMT_YUVJ444P:
case AV_PIX_FMT_YUV444P9:
case AV_PIX_FMT_YUV444P10: return X264_CSP_I444;
#if CONFIG_LIBX264RGB_ENCODER
@@ -743,10 +739,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
x4->params.i_slice_count = avctx->slices;
-x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
- avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
- avctx->color_range == AVCOL_RANGE_JPEG;
+x4->params.vui.b_fullrange = avctx->color_range == AVCOL_RANGE_JPEG;
if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED)
x4->params.vui.i_colmatrix = avctx->colorspace;
@@ -838,11 +831,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
static const enum AVPixelFormat pix_fmts_8bit[] = {
AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_YUVJ420P,
AV_PIX_FMT_YUV422P,
-AV_PIX_FMT_YUVJ422P,
AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NV12,
AV_PIX_FMT_NV16,
#ifdef X264_CSP_NV21
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 08/27] avcodec/svq3: replace YUVJ pixel format
Signed-off-by: Paul B Mahol
---
libavcodec/svq3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/svq3.c b/libavcodec/svq3.c
index a937b2f951..4c6d838a15 100644
--- a/libavcodec/svq3.c
+++ b/libavcodec/svq3.c
@@ -1158,7 +1158,7 @@ static av_cold int svq3_decode_init(AVCodecContext *avctx)
ff_hpeldsp_init(&s->hdsp, avctx->flags);
ff_tpeldsp_init(&s->tdsp);
-avctx->pix_fmt = AV_PIX_FMT_YUVJ420P;
+avctx->pix_fmt = AV_PIX_FMT_YUV420P;
avctx->color_range = AVCOL_RANGE_JPEG;
s->avctx = avctx;
@@ -1652,6 +1652,6 @@ AVCodec ff_svq3_decoder = {
.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND |
AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_DELAY,
-.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUVJ420P,
+.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE},
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 06/27] fftools/ffmpeg_filter: auto insert scale filter to convert between different color_ranges if necessary
Signed-off-by: Paul B Mahol
---
fftools/ffmpeg_filter.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 877fd670e6..e69bfe295c 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -449,6 +449,7 @@ static int configure_output_video_filter(FilterGraph *fg,
OutputFilter *ofilter,
OutputStream *ost = ofilter->ost;
OutputFile*of = output_files[ost->file_index];
AVFilterContext *last_filter = out->filter_ctx;
+AVDictionaryEntry *cre = NULL;
int pad_idx = out->pad_idx;
int ret;
char name[255];
@@ -461,7 +462,9 @@ static int configure_output_video_filter(FilterGraph *fg,
OutputFilter *ofilter,
if (ret < 0)
return ret;
-if (ofilter->width || ofilter->height) {
+cre = av_dict_get(ost->encoder_opts, "color_range", NULL, 0);
+
+if (ofilter->width || ofilter->height || (cre && cre->value) ||
ost->enc->color_range) {
char args[255];
AVFilterContext *filter;
AVDictionaryEntry *e = NULL;
@@ -474,6 +477,12 @@ static int configure_output_video_filter(FilterGraph *fg,
OutputFilter *ofilter,
av_strlcatf(args, sizeof(args), ":%s=%s", e->key, e->value);
}
+if (cre && cre->value) {
+av_strlcatf(args, sizeof(args), ":out_range=%s", cre->value);
+} else if (ost->enc->color_range) {
+av_strlcatf(args, sizeof(args), ":out_range=%s",
av_color_range_name(ost->enc->color_range));
+}
+
snprintf(name, sizeof(name), "scaler_out_%d_%d",
ost->file_index, ost->index);
if ((ret = avfilter_graph_create_filter(&filter,
avfilter_get_by_name("scale"),
@@ -777,10 +786,11 @@ static int configure_input_video_filter(FilterGraph *fg,
InputFilter *ifilter,
av_bprint_init(&args, 0, 1);
av_bprintf(&args,
"video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:"
- "pixel_aspect=%d/%d:sws_param=flags=%d",
+ "pixel_aspect=%d/%d:sws_param=flags=%d:color_range=%s",
ifilter->width, ifilter->height, ifilter->format,
tb.num, tb.den, sar.num, sar.den,
- SWS_BILINEAR + ((ist->dec_ctx->flags&AV_CODEC_FLAG_BITEXACT) ?
SWS_BITEXACT:0));
+ SWS_BILINEAR + ((ist->dec_ctx->flags&AV_CODEC_FLAG_BITEXACT) ?
SWS_BITEXACT:0),
+ av_color_range_name(ist->dec_ctx->color_range));
if (fr.num && fr.den)
av_bprintf(&args, ":frame_rate=%d/%d", fr.num, fr.den);
snprintf(name, sizeof(name), "graph %d input from stream %d:%d", fg->index,
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 13/27] avcodec/hevc_ps: do not use YUVJ pixel format
Color range is already set.
Signed-off-by: Paul B Mahol
---
libavcodec/hevc_ps.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index a4f7ed60f7..19ec2d7ebf 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -578,8 +578,6 @@ static void decode_vui(GetBitContext *gb, AVCodecContext
*avctx,
vui->video_format= get_bits(gb, 3);
vui->video_full_range_flag = get_bits1(gb);
vui->colour_description_present_flag = get_bits1(gb);
-if (vui->video_full_range_flag && sps->pix_fmt == AV_PIX_FMT_YUV420P)
-sps->pix_fmt = AV_PIX_FMT_YUVJ420P;
if (vui->colour_description_present_flag) {
vui->colour_primaries= get_bits(gb, 8);
vui->transfer_characteristic = get_bits(gb, 8);
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 12/27] avcodec/h264_slice: do not use YUVJ pixel formats
Signed-off-by: Paul B Mahol
---
libavcodec/h264_slice.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index aad5484588..a75ab08c29 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -820,15 +820,10 @@ static enum AVPixelFormat get_pixel_format(H264Context
*h, int force_callback)
if (CHROMA444(h)) {
if (h->avctx->colorspace == AVCOL_SPC_RGB)
*fmt++ = AV_PIX_FMT_GBRP;
-else if (h->avctx->color_range == AVCOL_RANGE_JPEG)
-*fmt++ = AV_PIX_FMT_YUVJ444P;
else
*fmt++ = AV_PIX_FMT_YUV444P;
} else if (CHROMA422(h)) {
-if (h->avctx->color_range == AVCOL_RANGE_JPEG)
-*fmt++ = AV_PIX_FMT_YUVJ422P;
-else
-*fmt++ = AV_PIX_FMT_YUV422P;
+*fmt++ = AV_PIX_FMT_YUV422P;
} else {
#if CONFIG_H264_DXVA2_HWACCEL
*fmt++ = AV_PIX_FMT_DXVA2_VLD;
@@ -845,8 +840,6 @@ static enum AVPixelFormat get_pixel_format(H264Context *h,
int force_callback)
#endif
if (h->avctx->codec->pix_fmts)
choices = h->avctx->codec->pix_fmts;
-else if (h->avctx->color_range == AVCOL_RANGE_JPEG)
-*fmt++ = AV_PIX_FMT_YUVJ420P;
else
*fmt++ = AV_PIX_FMT_YUV420P;
}
@@ -992,17 +985,6 @@ fail:
return ret;
}
-static enum AVPixelFormat non_j_pixfmt(enum AVPixelFormat a)
-{
-switch (a) {
-case AV_PIX_FMT_YUVJ420P: return AV_PIX_FMT_YUV420P;
-case AV_PIX_FMT_YUVJ422P: return AV_PIX_FMT_YUV422P;
-case AV_PIX_FMT_YUVJ444P: return AV_PIX_FMT_YUV444P;
-default:
-return a;
-}
-}
-
static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int
first_slice)
{
const SPS *sps;
@@ -1047,7 +1029,7 @@ static int h264_init_ps(H264Context *h, const
H264SliceContext *sl, int first_sl
|| h->mb_height != sps->mb_height
));
if (h->avctx->pix_fmt == AV_PIX_FMT_NONE
-|| (non_j_pixfmt(h->avctx->pix_fmt) !=
non_j_pixfmt(get_pixel_format(h, 0
+|| (h->avctx->pix_fmt != get_pixel_format(h, 0)))
must_reinit = 1;
if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 07/27] avfilter/mjpegdec: replace YUVJ pixel formats
Signed-off-by: Paul B Mahol
---
libavcodec/mjpegdec.c| 18 +-
libavcodec/tdsc.c| 2 +-
tests/fate/filter-video.mak | 2 +-
tests/fate/vcodec.mak| 4 ++--
tests/ref/fate/api-mjpeg-codec-param | 4 ++--
tests/ref/fate/exif-image-embedded | 2 +-
tests/ref/fate/exif-image-jpg| 2 +-
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index e005dd0cd3..55676d8576 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -467,7 +467,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' &&
s->component_id[2] == 'A') {
s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP :
AV_PIX_FMT_GBRP16;
} else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
else s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
}
@@ -509,7 +509,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
case 0x22122100:
case 0x21211100:
case 0x22211200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
else
goto unk_pixfmt;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
@@ -517,7 +517,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
case 0x1100:
case 0x22112200:
case 0x1100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
else
goto unk_pixfmt;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
@@ -549,7 +549,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
} else {
if (pix_fmt_id == 0x1400)
s->upscale_v[1] = s->upscale_v[2] = 1;
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV440P : AV_PIX_FMT_YUVJ440P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV440P;
else
goto unk_pixfmt;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
@@ -562,7 +562,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
goto unk_pixfmt;
s->upscale_h[0] = s->upscale_h[1] = 1;
} else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
else s->avctx->pix_fmt = AV_PIX_FMT_YUV422P16;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
}
@@ -570,13 +570,13 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
case 0x3100:
if (s->bits > 8)
goto unk_pixfmt;
-s->avctx->pix_fmt = s->cs_itu601 ? AV_PIX_FMT_YUV444P :
AV_PIX_FMT_YUVJ444P;
+s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
s->upscale_h[1] = s->upscale_h[2] = 2;
break;
case 0x22121100:
case 0x22111200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
else
goto unk_pixfmt;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
@@ -584,7 +584,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
case 0x2200:
case 0x4200:
case 0x2400:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUVJ420P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV420P;
else s->avctx->pix_fmt = AV_PIX_FMT_YUV420P16;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
if (pix_fmt_id == 0x4200) {
@@ -598,7 +598,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
break;
case 0x4100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV411P : AV_PIX_FMT_YUVJ411P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV411P;
else
goto unk_pixfmt;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
diff --git a/libavcodec/tdsc.c b/libavcodec/tdsc.c
index 4182404cf0..af92ef6ccc 100644
--- a/libavcodec/tdsc.c
+++ b/libavcodec/tdsc.c
@@ -357,7 +357,7 @@ static int t
[FFmpeg-devel] [PATCH 05/27] avfilter/vf_scale: make use of color_range from filter links
Signed-off-by: Paul B Mahol
---
libavfilter/vf_scale.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 9f45032e85..802f841cc3 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -303,9 +303,15 @@ static int config_props(AVFilterLink *outlink)
if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
av_opt_set_int(*s, "src_range",
scale->in_range == AVCOL_RANGE_JPEG, 0);
+else
+av_opt_set_int(*s, "src_range",
+ inlink->color_range == AVCOL_RANGE_JPEG, 0);
if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
av_opt_set_int(*s, "dst_range",
scale->out_range == AVCOL_RANGE_JPEG, 0);
+ else
+av_opt_set_int(*s, "dst_range",
+ outlink->color_range == AVCOL_RANGE_JPEG, 0);
if (scale->opts) {
AVDictionaryEntry *e = NULL;
@@ -416,6 +422,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
if( in->width != link->w
|| in->height != link->h
|| in->format != link->format
+ || in->color_range != link->color_range
|| in->sample_aspect_ratio.den != link->sample_aspect_ratio.den ||
in->sample_aspect_ratio.num != link->sample_aspect_ratio.num) {
int ret;
@@ -429,6 +436,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
link->dst->inputs[0]->format = in->format;
link->dst->inputs[0]->w = in->width;
link->dst->inputs[0]->h = in->height;
+link->dst->inputs[0]->color_range = in->color_range;
link->dst->inputs[0]->sample_aspect_ratio.den =
in->sample_aspect_ratio.den;
link->dst->inputs[0]->sample_aspect_ratio.num =
in->sample_aspect_ratio.num;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 11/27] avcodec/mdec: replace YUVJ pixel format
Signed-off-by: Paul B Mahol --- libavcodec/mdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c index 330b761279..637158d231 100644 --- a/libavcodec/mdec.c +++ b/libavcodec/mdec.c @@ -227,7 +227,7 @@ static av_cold int decode_init(AVCodecContext *avctx) ff_init_scantable(a->idsp.idct_permutation, &a->scantable, ff_zigzag_direct); -avctx->pix_fmt = AV_PIX_FMT_YUVJ420P; +avctx->pix_fmt = AV_PIX_FMT_YUV420P; avctx->color_range = AVCOL_RANGE_JPEG; /* init q matrix */ -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 04/27] avfilter/buffersink: export color_range from filtergraph output
Signed-off-by: Paul B Mahol --- libavfilter/buffersink.c | 1 + libavfilter/buffersink.h | 1 + 2 files changed, 2 insertions(+) diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c index 0f87b5439a..5f3c932d92 100644 --- a/libavfilter/buffersink.c +++ b/libavfilter/buffersink.c @@ -194,6 +194,7 @@ MAKE_AVFILTERLINK_ACCESSOR(AVRational , frame_rate ) MAKE_AVFILTERLINK_ACCESSOR(int , w ) MAKE_AVFILTERLINK_ACCESSOR(int , h ) MAKE_AVFILTERLINK_ACCESSOR(AVRational , sample_aspect_ratio) +MAKE_AVFILTERLINK_ACCESSOR(int , color_range) MAKE_AVFILTERLINK_ACCESSOR(int , channels ) MAKE_AVFILTERLINK_ACCESSOR(uint64_t , channel_layout ) diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h index 21d6bb505b..c0acee48d6 100644 --- a/libavfilter/buffersink.h +++ b/libavfilter/buffersink.h @@ -114,6 +114,7 @@ AVRational av_buffersink_get_frame_rate (const AVFilterContext *c int av_buffersink_get_w (const AVFilterContext *ctx); int av_buffersink_get_h (const AVFilterContext *ctx); AVRational av_buffersink_get_sample_aspect_ratio (const AVFilterContext *ctx); +int av_buffersink_get_color_range (const AVFilterContext *ctx); int av_buffersink_get_channels(const AVFilterContext *ctx); uint64_t av_buffersink_get_channel_layout (const AVFilterContext *ctx); -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 03/27] avfilter/buffersrc: recognize color_range as additonal parameter and set it to input link
Signed-off-by: Paul B Mahol
---
libavfilter/buffersrc.c | 13 +
libavfilter/buffersrc.h | 5 +
2 files changed, 18 insertions(+)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index cd56f8ca45..67f8bdf158 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -52,6 +52,7 @@ typedef struct BufferSourceContext {
int w, h;
enum AVPixelFormat pix_fmt;
AVRationalpixel_aspect;
+int color_range;
char *sws_param;
AVBufferRef *hw_frames_ctx;
@@ -109,6 +110,8 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx,
AVBufferSrcParameters *par
s->h = param->height;
if (param->sample_aspect_ratio.num > 0 &&
param->sample_aspect_ratio.den > 0)
s->pixel_aspect = param->sample_aspect_ratio;
+if (param->color_range > 0)
+s->color_range = param->color_range;
if (param->frame_rate.num > 0 && param->frame_rate.den > 0)
s->frame_rate = param->frame_rate;
if (param->hw_frames_ctx) {
@@ -309,6 +312,15 @@ static const AVOption buffer_options[] = {
{ "time_base", NULL, OFFSET(time_base),
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
{ "frame_rate",NULL, OFFSET(frame_rate),
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
{ "sws_param", NULL, OFFSET(sws_param),
AV_OPT_TYPE_STRING,.flags = V },
+{ "color_range", NULL, OFFSET(color_range),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, V, "range" },
+{ "unspecified", NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCOL_RANGE_UNSPECIFIED}, 0, 0, V, "range"},
+{ "unknown", NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCOL_RANGE_UNSPECIFIED}, 0, 0, V, "range"},
+{ "limited", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},
0, 0, V, "range"},
+{ "tv",NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},
0, 0, V, "range"},
+{ "mpeg", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},
0, 0, V, "range"},
+{ "full", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},
0, 0, V, "range"},
+{ "pc",NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},
0, 0, V, "range"},
+{ "jpeg", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},
0, 0, V, "range"},
{ NULL },
};
@@ -434,6 +446,7 @@ static int config_props(AVFilterLink *link)
link->w = c->w;
link->h = c->h;
link->sample_aspect_ratio = c->pixel_aspect;
+link->color_range = c->color_range;
if (c->hw_frames_ctx) {
link->hw_frames_ctx = av_buffer_ref(c->hw_frames_ctx);
diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h
index 0652113f2b..cc32d532c2 100644
--- a/libavfilter/buffersrc.h
+++ b/libavfilter/buffersrc.h
@@ -114,6 +114,11 @@ typedef struct AVBufferSrcParameters {
* Audio only, the audio channel layout
*/
uint64_t channel_layout;
+
+ /**
+ * Video only
+ */
+int color_range;
} AVBufferSrcParameters;
/**
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 02/27] avfilter/avfilter: add color_range to AVFilterLink struct
Signed-off-by: Paul B Mahol
---
libavfilter/avfilter.c | 2 ++
libavfilter/avfilter.h | 2 ++
libavfilter/video.c| 8 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b98b32bacb..4a579bb49d 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -336,6 +336,8 @@ int avfilter_config_links(AVFilterContext *filter)
link->w = inlink->w;
if (!link->h)
link->h = inlink->h;
+if (!link->color_range)
+link->color_range = inlink->color_range;
} else if (!link->w || !link->h) {
av_log(link->src, AV_LOG_ERROR,
"Video source filters must set their output link's "
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 47546c15e5..a5f4df74de 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -448,6 +448,8 @@ struct AVFilterLink {
*/
AVRational time_base;
+int color_range;
+
/*
* All fields below this line are not part of the public API. They
* may not be used outside of libavfilter and can be changed and
diff --git a/libavfilter/video.c b/libavfilter/video.c
index 6f9020b9fe..8f12cb7080 100644
--- a/libavfilter/video.c
+++ b/libavfilter/video.c
@@ -43,6 +43,7 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w,
int h)
AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
{
+AVFrame *frame = NULL;
int pool_width = 0;
int pool_height = 0;
int pool_align = 0;
@@ -86,7 +87,12 @@ AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int
w, int h)
}
}
-return ff_frame_pool_get(link->frame_pool);
+frame = ff_frame_pool_get(link->frame_pool);
+if (!frame)
+return NULL;
+frame->color_range = link->color_range;
+
+return frame;
}
AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD
> > > Do you test on X86_32 or x86_64 ? > > failure occurs on both > > > > Nasm or Yasm ? > > NASM version 2.10.09 compiled on Dec 29 2013 > > > > I try to compile with the same nasm version (on os X, X86_64) using --x86asmexe=nasm_exe_path2.10rc9 in the configure And the checkasm also pass ./tests/checkasm/checkasm --test=vf_hflip --bench --seed 1616253308 benchmarking with native FFmpeg timers nop: 34.9 checkasm: using random seed 1616253308 SSSE3: - vf_hflip.hflip_byte [OK] - vf_hflip.hflip_short [OK] checkasm: all 2 tests passed hflip_byte_c: 28.0 hflip_byte_ssse3: 27.0 hflip_short_c: 277.7 hflip_short_ssse3: 71.0 Any ideas, why it fail for you ? In attach new patch (who probably doesn't fix the problem in your sandybox) 001 : unchanged 002 : add test for various width, change bench new, to use w variable and remove the fate-checkasm. Don't know if it's ok, to add a checkasm, without adding it to fate/checkasm (because it fails). It's convenient to have this kind of test to improve the asm (instead of not having a test at all) Martin 0001-avfilter-vf_hflip-move-context-func-init-in.patch Description: Binary data 0002-checkasm-vf_hflip-add-test-for-vf_hflip-byte-and-sho.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/utvideodec : add SIMD (SSSE3 and AVX2) for gradient_pred (V2)
2017-12-02 19:55 GMT+01:00 Martin Vignali : > Hello, > > New patchs in attach for adding gradient pred SIMD (SSSE3 and AVX2) > (use by utvideo dec now (more use will be add later)) > > Checkasm result (width = 1024) > > add_gradient_pred_c: 2070.2 > add_gradient_pred_ssse3: 602.4 > add_gradient_pred_avx2: 385.7 > > > Need to be apply after add_left_pred AVX2 patchs > > > Pushed Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/x86/lossless_videodsp : add_left_pred AVX2 v2
2017-12-02 19:12 GMT+01:00 Martin Vignali : > New patch in attach > > 001, 002 : unchanged > > 003 : use VBROADCASTI128 macro for constant loading en XMM/YMM instead of > 256 bits constants. > > Martin > > Pushed Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/huffyuvenc : try to call dsp with aligned data, and remove code duplication
2017-12-02 18:59 GMT+01:00 Martin Vignali : > > >> requiring FFMIN() to be evaluated per iteration could be slower >> if the compiler fails to factor it out >> >> >> >> New patchs in attach : > > 001 : unchanged > 002 : add "int min_width = FFMIN(w, 32)" at the start of the func > 003 : add "int min_width = FFMIN(w, 8)" at the start of the func > > > Pass fate test for me. > > Pushed, thanks Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/utvideodec : use dsp add_median_pred for second line
2017-11-26 19:23 GMT+01:00 Martin Vignali : > Hello, > > Patch in attach > > dsp func need align16 data > make only the start of the line in scalar, and call the dsp for the rest > instead of process the entire line in scalar > > > pass make fate-utvideo for me > > Martin > Pushed, thanks Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/x86/vf_threshold : add SSE4 and AVX2 for threshold 16
Thanks for comments and testing Pushed Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvmaf: exit gracefully if the library fails.
Hi,
On Sat, Dec 9, 2017 at 2:34 AM, Gyan Doshi wrote:
>
> On 12/9/2017 7:05 AM, Ronald S. Bultje wrote:
>
>> Fixes trac issue #6884 and Netflix/vmaf issue #124.
>>
>
> static void *call_vmaf(void *ctx)
>> {
>>
> > ...
>
>> pthread_exit(NULL);
>> }
>>
>
> Fails to build unless I add 'return NULL;' in call_vmaf. Pre-existing
> issue. Open ticket is #6878.
>
I can fix that in the same patch also, sure.
Is it possible to have distinctive error messages? I get the same message
> whether the model is not found or found but not successfully parsed. Pasted
> below. Earlier, the console would have the exception reporting if "No
> newline at end o string". The error for missing file was generic, like now.
>
>
> t C:\avutils\ffmpeg-libs\compiled\share\model\nflxtrain_vmfv3a.pkl cannot
> be read successfully.
> Caught VmafException: Error loading model (.pkl): Trouble reading the
> file:C:\avutils\ffmpeg-libs\compiled\share\model\nflxtrain_vmfv3a.pkl
> [Parsed_libvmaf_0 @ 0050b4a0] libvmaf encountered an error, check
> log for details
> Error while filtering: Invalid argument
> Failed to inject frame into filter network: Invalid argument
> Error while processing the decoded data for stream #1:0
> Conversion failed!
>
>
> But no more "This application has requested the Runtime to terminate it in
> an unusual way.". Thanks.
This should be done in libvmaf. Right now it returns 0 or 1, and that's all
FFmpeg knows. If we want more, we have to ask Zhi to return more specific
error codes (or messages), so we can display more specific error messages.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android
On Sat, Dec 9, 2017 at 2:52 PM, Jan Ekström wrote: > On Sat, Dec 9, 2017 at 12:14 AM, James Almer wrote: >> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed >> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error >> messages is "Offset out of range". The reason of the error is assembler LDR >> directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage >> in range <1k, but no such storage provided. >> >> Based on a patch by Ihor Bobalo >> >> Suggested-by: wbs >> Signed-off-by: James Almer >> > > Can confirm that this fixes compilation, clang+gas-preprocessor works. Thanks. > > Jan Aditionally tested with armv7 GCC 4.9 as well, so nothing seems to be broken on that side, either. This is not surprising, as this only moves a function and a macro - as well as adds a .ltorg which causes the literal pool to be dumped. This helps as the offsets are getting too large otherwise for the SIMD used in the following function. Given the limited change in this, I'd say LGTM and will push tonight unless someone objects. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android
On Sat, Dec 9, 2017 at 12:14 AM, James Almer wrote: > Compilation error "out of range" fixed for armeabi-v7a. Compilation failed > trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error > messages is "Offset out of range". The reason of the error is assembler LDR > directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage > in range <1k, but no such storage provided. > > Based on a patch by Ihor Bobalo > > Suggested-by: wbs > Signed-off-by: James Almer > Can confirm that this fixes compilation, clang+gas-preprocessor works. Thanks. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/video: pick sar from link
On 12/9/17, Nicolas George wrote: > Paul B Mahol (2017-12-09): >> >> It should not be needed for each filter that sets sample aspect ratio >> >> to set it explicitly also for each and every frame, instead that is >> >> automatically done in get_buffer call. >> > Is this message ok? If yes then I will push this patch shortly. > > Ok, assuming you put it in the commit message. I think it would be > better to accompany it with patches that actually require the change, > though. No new patches require it, it is for case such stereo3d and setsar and bunch of others that may need to explicitly set sample aspect ratio to each frame. > >> Will push very soon. > > PLEASE STOP DOING THAT. > > Waiting less than 48 hours is unacceptably short for that kind of change > when there is a discussion. I had to stop a more urgent task to answer > right now, and that annoys me a lot. Do you work in White House or in nuclear power plant? > > YOU ARE NOT ALONE IN THIS PROJECT, AND PEOPLE DO NOT HAVE THE SAME > SCHEDULE AS YOU. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/video: pick sar from link
Paul B Mahol (2017-12-09): > >> It should not be needed for each filter that sets sample aspect ratio > >> to set it explicitly also for each and every frame, instead that is > >> automatically done in get_buffer call. > > Is this message ok? If yes then I will push this patch shortly. Ok, assuming you put it in the commit message. I think it would be better to accompany it with patches that actually require the change, though. > Will push very soon. PLEASE STOP DOING THAT. Waiting less than 48 hours is unacceptably short for that kind of change when there is a discussion. I had to stop a more urgent task to answer right now, and that annoys me a lot. YOU ARE NOT ALONE IN THIS PROJECT, AND PEOPLE DO NOT HAVE THE SAME SCHEDULE AS YOU. -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/video: pick sar from link
On 12/8/17, Paul B Mahol wrote: > On 12/7/17, Paul B Mahol wrote: >> On 12/7/17, Nicolas George wrote: >>> Paul B Mahol (2017-12-07): Signed-off-by: Paul B Mahol --- libavfilter/video.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> Please explain (in the commit message) why you think this patch is >>> needed. >> >> It should not be needed for each filter that sets sample aspect ratio >> to set it explicitly also for each and every frame, instead that is >> automatically done in get_buffer call. >> > > Is this message ok? If yes then I will push this patch shortly. > Will push very soon. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On Fri, Dec 8, 2017 at 8:49 AM, Mateusz wrote:
> W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
>> Am 07.12.2017 20:40 schrieb "Mateusz" :
>>
>> W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
>>> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz 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
---
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).
>
LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
