Re: [FFmpeg-devel] [PATCH v5 01/10] lavc/avcodec: Add HEVC Screen Content Coding Extensions profile

2023-02-13 Thread Xiang, Haihao
On Ma, 2023-02-06 at 13:44 +0800, Fei Wang wrote:
> From: Linjie Fu 
> 
> Described in HEVC spec A.3.7.
> 
> Signed-off-by: Linjie Fu 
> Signed-off-by: Fei Wang 
> ---
> 1. fix compile warning with VAAPI version less than 1.2.0
> 
>  libavcodec/avcodec.h  | 1 +
>  libavcodec/hevc_ps.c  | 2 ++
>  libavcodec/profiles.c | 1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 90b437ccbe..9e36d2402a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1672,6 +1672,7 @@ typedef struct AVCodecContext {
>  #define FF_PROFILE_HEVC_MAIN_10 2
>  #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE  3
>  #define FF_PROFILE_HEVC_REXT4
> +#define FF_PROFILE_HEVC_SCC 9
>  
>  #define FF_PROFILE_VVC_MAIN_10  1
>  #define FF_PROFILE_VVC_MAIN_10_444 33
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 5fe62ec35b..4aa5b76d5f 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -259,6 +259,8 @@ static int decode_profile_tier_level(GetBitContext *gb,
> AVCodecContext *avctx,
>  av_log(avctx, AV_LOG_DEBUG, "Main Still Picture profile
> bitstream\n");
>  else if (ptl->profile_idc == FF_PROFILE_HEVC_REXT)
>  av_log(avctx, AV_LOG_DEBUG, "Range Extension profile bitstream\n");
> +else if (ptl->profile_idc == FF_PROFILE_HEVC_SCC)
> +av_log(avctx, AV_LOG_DEBUG, "Screen Content Coding Extension profile
> bitstream\n");
>  else
>  av_log(avctx, AV_LOG_WARNING, "Unknown HEVC profile: %d\n", ptl-
> >profile_idc);
>  
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index 7af7fbeb13..2230fc5415 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -85,6 +85,7 @@ const AVProfile ff_hevc_profiles[] = {
>  { FF_PROFILE_HEVC_MAIN_10,  "Main 10" },
>  { FF_PROFILE_HEVC_MAIN_STILL_PICTURE,   "Main Still Picture"  },
>  { FF_PROFILE_HEVC_REXT, "Rext"},
> +{ FF_PROFILE_HEVC_SCC,  "Scc" },
>  { FF_PROFILE_UNKNOWN },
>  };
>  

Patchset LGTM and it works for me. 

Thanks
Haihao

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v3 3/3] qsv: remove CONFIG_VAAPI for mutiple formats

2023-02-13 Thread Tong Wu
Remove CONFIG_VAAPI for VUYX, YUYV422, Y210, XV30, Y212, XV36.

Make 8-bit, 10-bit, 12-bit YUV 4:2:2 video sources as well as YUV 4:4:4
video sources supported by d3d11va and dxva2 just like what VAAPI does.

Sign-off-by: Tong Wu 
---
 libavcodec/qsv.c  | 4 
 libavutil/hwcontext_qsv.c | 6 +++---
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 7af154202c..8eabf46b45 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -208,7 +208,6 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
 case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
 case MFX_FOURCC_A2RGB10: return AV_PIX_FMT_X2RGB10;
 case MFX_FOURCC_RGB4: return AV_PIX_FMT_BGRA;
-#if CONFIG_VAAPI
 case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
 case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
 case MFX_FOURCC_AYUV: return AV_PIX_FMT_VUYX;
@@ -217,7 +216,6 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
 case MFX_FOURCC_P016: return AV_PIX_FMT_P012;
 case MFX_FOURCC_Y216: return AV_PIX_FMT_Y212;
 case MFX_FOURCC_Y416: return AV_PIX_FMT_XV36;
-#endif
 #endif
 }
 return AV_PIX_FMT_NONE;
@@ -245,7 +243,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc, uint16_t *shi
 *fourcc = MFX_FOURCC_RGB4;
 *shift = 0;
 return AV_PIX_FMT_BGRA;
-#if CONFIG_VAAPI
 case AV_PIX_FMT_YUV422P:
 case AV_PIX_FMT_YUYV422:
 *fourcc = MFX_FOURCC_YUY2;
@@ -277,7 +274,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc, uint16_t *shi
 *fourcc = MFX_FOURCC_Y416;
 *shift = 1;
 return AV_PIX_FMT_XV36;
-#endif
 #endif
 default:
 return AVERROR(ENOSYS);
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 42851d4fd5..6780428875 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -115,11 +115,12 @@ static const struct {
 { AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4, 0 },
 { AV_PIX_FMT_P010, MFX_FOURCC_P010, 1 },
 { AV_PIX_FMT_PAL8, MFX_FOURCC_P8,   0 },
-#if CONFIG_VAAPI
 { AV_PIX_FMT_YUYV422,
MFX_FOURCC_YUY2, 0 },
+#if CONFIG_VAAPI
 { AV_PIX_FMT_UYVY422,
MFX_FOURCC_UYVY, 0 },
+#endif
 { AV_PIX_FMT_Y210,
MFX_FOURCC_Y210, 1 },
 // VUYX is used for VAAPI child device,
@@ -144,7 +145,6 @@ static const struct {
 { AV_PIX_FMT_XV36,
MFX_FOURCC_Y416, 1 },
 #endif
-#endif
 };
 
 extern int ff_qsv_get_surface_base_handle(mfxFrameSurface1 *surf,
@@ -1526,7 +1526,6 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 surface->Data.R = frame->data[0] + 2;
 surface->Data.A = frame->data[0] + 3;
 break;
-#if CONFIG_VAAPI
 case AV_PIX_FMT_YUYV422:
 surface->Data.Y = frame->data[0];
 surface->Data.U = frame->data[0] + 1;
@@ -1558,6 +1557,7 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 // use the value from the frame.
 surface->Data.A = frame->data[0] + 6;
 break;
+#if CONFIG_VAAPI
 case AV_PIX_FMT_UYVY422:
 surface->Data.Y = frame->data[0] + 1;
 surface->Data.U = frame->data[0];
-- 
2.39.1.windows.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v3 2/3] hwcontext_dxva2: add mutiple supported formats

2023-02-13 Thread Tong Wu
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on dxva2 acceleration(-hwaccel dxva2) since so far
these formats are still not supported by using dxva2 acceleration.

Hwupload and hwdownload can work with the added formats.

Signed-off-by: Tong Wu 
---
 libavutil/hwcontext_dxva2.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 53d00fa815..ea378df720 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -82,6 +82,13 @@ static const struct {
 } supported_formats[] = {
 { MKTAG('N', 'V', '1', '2'), AV_PIX_FMT_NV12 },
 { MKTAG('P', '0', '1', '0'), AV_PIX_FMT_P010 },
+{ MKTAG('A', 'Y', 'U', 'V'), AV_PIX_FMT_VUYX },
+{ MKTAG('Y', 'U', 'Y', '2'), AV_PIX_FMT_YUYV422 },
+{ MKTAG('Y', '2', '1', '0'), AV_PIX_FMT_Y210 },
+{ MKTAG('Y', '4', '1', '0'), AV_PIX_FMT_XV30 },
+{ MKTAG('P', '0', '1', '6'), AV_PIX_FMT_P012 },
+{ MKTAG('Y', '2', '1', '6'), AV_PIX_FMT_Y212 },
+{ MKTAG('Y', '4', '1', '6'), AV_PIX_FMT_XV36 },
 { D3DFMT_P8, AV_PIX_FMT_PAL8 },
 { D3DFMT_A8R8G8B8,   AV_PIX_FMT_BGRA },
 };
-- 
2.39.1.windows.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v3 1/3] hwcontext_d3d11va: add mutiple supported DXGI formats

2023-02-13 Thread Tong Wu
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.

The added formats work with qsv acceleration and will not have
impact on d3d11va acceleration(-hwaccel d3d11va) since so far
these formats are still not supported by using d3d11va acceleration.

Hwupload and hwdownload can work with the added formats.

Signed-off-by: Tong Wu 
---
 libavutil/hwcontext_d3d11va.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 363ec6a47d..aa50538d64 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -89,6 +89,13 @@ static const struct {
 { DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
 { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
 { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
+{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },
+{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
+{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
+{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
+{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
 // Special opaque formats. The pix_fmt is merely a place holder, as the
 // opaque format cannot be accessed directly.
 { DXGI_FORMAT_420_OPAQUE,   AV_PIX_FMT_YUV420P },
-- 
2.39.1.windows.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH] avformat: deprecate AVFormatContext io_close callback

2023-02-13 Thread Marton Balint
io_close2 should be used instead.

Signed-off-by: Marton Balint 
---
 doc/APIchanges  | 4 
 libavformat/avformat.c  | 6 ++
 libavformat/avformat.h  | 5 +
 libavformat/dashenc.c   | 4 
 libavformat/fifo.c  | 4 
 libavformat/hlsenc.c| 4 
 libavformat/imfdec.c| 4 
 libavformat/options.c   | 6 ++
 libavformat/segment.c   | 4 
 libavformat/tee.c   | 4 
 libavformat/version.h   | 2 +-
 libavformat/version_major.h | 1 +
 12 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 3ca724724b..69116e296a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,10 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2023-02-xx - xx - lavf 60.3.100 - avformat.h
+  Deprecate AVFormatContext io_close callback.
+  The superior io_close2 callback should be used instead.
+
 2023-02-13 - xx - lavu 58.1.100 - frame.h
   Deprecate AVFrame.coded_picture_number and display_picture_number.
   Their usefulness is questionable and very few decoders set them.
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index fe7b068f4a..708d90b38c 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -854,10 +854,16 @@ int ff_format_io_close(AVFormatContext *s, AVIOContext 
**pb)
 {
 int ret = 0;
 if (*pb) {
+#if FF_API_AVFORMAT_IO_CLOSE
+FF_DISABLE_DEPRECATION_WARNINGS
 if (s->io_close == ff_format_io_close_default || s->io_close == NULL)
+#endif
 ret = s->io_close2(s, *pb);
+#if FF_API_AVFORMAT_IO_CLOSE
 else
 s->io_close(s, *pb);
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 }
 *pb = NULL;
 return ret;
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b986aacc78..1916aa2dc5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1663,10 +1663,15 @@ typedef struct AVFormatContext {
 int (*io_open)(struct AVFormatContext *s, AVIOContext **pb, const char 
*url,
int flags, AVDictionary **options);
 
+#if FF_API_AVFORMAT_IO_CLOSE
 /**
  * A callback for closing the streams opened with 
AVFormatContext.io_open().
+ *
+ * @deprecated use io_close2
  */
+attribute_deprecated
 void (*io_close)(struct AVFormatContext *s, AVIOContext *pb);
+#endif
 
 /**
  * ',' separated list of disallowed protocols.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 52865eacb5..17fe5f430c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1551,7 +1551,11 @@ static int dash_init(AVFormatContext *s)
 return AVERROR_MUXER_NOT_FOUND;
 ctx->interrupt_callback= s->interrupt_callback;
 ctx->opaque= s->opaque;
+#if FF_API_AVFORMAT_IO_CLOSE
+FF_DISABLE_DEPRECATION_WARNINGS
 ctx->io_close  = s->io_close;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 ctx->io_close2 = s->io_close2;
 ctx->io_open   = s->io_open;
 ctx->strict_std_compliance = s->strict_std_compliance;
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index ebadeef645..9a3a23729c 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -501,7 +501,11 @@ static int fifo_mux_init(AVFormatContext *avf, const 
AVOutputFormat *oformat,
 if (ret < 0)
 return ret;
 avf2->opaque = avf->opaque;
+#if FF_API_AVFORMAT_IO_CLOSE
+FF_DISABLE_DEPRECATION_WARNINGS
 avf2->io_close = avf->io_close;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 avf2->io_close2 = avf->io_close2;
 avf2->io_open = avf->io_open;
 avf2->flags = avf->flags;
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index dcc363b42e..e1f96feda3 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -869,7 +869,11 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 oc->max_delay= s->max_delay;
 oc->opaque   = s->opaque;
 oc->io_open  = s->io_open;
+#if FF_API_AVFORMAT_IO_CLOSE
+FF_DISABLE_DEPRECATION_WARNINGS
 oc->io_close = s->io_close;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 oc->io_close2= s->io_close2;
 oc->strict_std_compliance= s->strict_std_compliance;
 av_dict_copy(>metadata, s->metadata, 0);
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 03de9ce151..4932b7ff1f 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -379,7 +379,11 @@ static int open_track_resource_context(AVFormatContext *s,
 return AVERROR(ENOMEM);
 
 track_resource->ctx->io_open = s->io_open;
+#if FF_API_AVFORMAT_IO_CLOSE
+FF_DISABLE_DEPRECATION_WARNINGS
 track_resource->ctx->io_close = s->io_close;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 track_resource->ctx->io_close2 = s->io_close2;
 track_resource->ctx->flags |= s->flags & 

[FFmpeg-devel] [PATCH] avcodec/libx265: fix else clause when zeroing reordered_opaque

2023-02-13 Thread Marton Balint
CC  libavcodec/libx265.o
libavcodec/libx265.c: In function ‘libx265_encode_frame’:
libavcodec/libx265.c:781:5: warning: this ‘else’ clause does not guard... 
[-Wmisleading-indentation]
 else
 ^~~~
libavcodec/libx265.c:782:1: note: ...this statement, but the latter is 
misleadingly indented as if it were guarded by the ‘else’
 FF_DISABLE_DEPRECATION_WARNINGS
 ^~~

Signed-off-by: Marton Balint 
---
 libavcodec/libx265.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 6a2600c5e7..420d0953af 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -778,10 +778,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 rd_release(ctx, idx);
 }
 #if FF_API_REORDERED_OPAQUE
-else
+else {
 FF_DISABLE_DEPRECATION_WARNINGS
 avctx->reordered_opaque = 0;
 FF_ENABLE_DEPRECATION_WARNINGS
+}
 #endif
 
 *got_packet = 1;
-- 
2.35.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY

2023-02-13 Thread Marton Balint



On Mon, 13 Feb 2023, Tomas Härdin wrote:


mån 2023-02-13 klockan 20:33 +0100 skrev Marton Balint:



On Mon, 13 Feb 2023, Tomas Härdin wrote:

> Passes FATE because we don't have any tests that mux files with a
> whopping 250 frames. Tested with a jpeg2000 Tears of Steel sample.

Have you checked what BMX does? Because as far as I remember for 
RDD9 (XDCAM HD) this should not exceed 10 seconds.


I have not checked BMX. Also such constraints should be explicitly
documented and there should be tests for them. An option like -xdcam
might be appropriate. Currently there is no justification at all in the
code for the choice of 250.


Intent of RDD9 compliance.



I suggest adding an option for this with -1 default, and unless the
user 
overrides it make it 238 in case of MPEG2 essence, and infinite (0) 
otherwise.


I wouldn't be opposed to having it use a dynamic array. As for MPEG2,
that does stink a bit but perhaps it avoids causing grief for most
users. Here we again come to the problem that we don't know the
workflows in which mxf* are used, and I don't like that we're cargo
culting defaults.


I think we have a pretty good idea that MPEG2 in MXF usually means some 
broadcast realted use, therefore intent of RDD9 compliance by default is 
not insane at all for MPEG2 essence. Can we please keep it as default for 
MPEG2?






There is also code which allocates the index entries in 
EDIT_UNITS_PER_BODY increments, that probably should be replaced with

av_dynarray2_add...


That (re)allocation happens at most twice for assuming GOP size <
EDIT_UNITS_PER_BODY

The reason I bring this all up is because opening MXF files muxed by
lavf over HTTP is slow as hell. This will be true for any other storage
where seeking incurs a non-trivial cost. HDDs come to mind. Perhaps
that is really an mxfdec problem, but then parsing becomes even hairier
than it already is. We'd have to binary search the file when seeking,
hoping to find the necessary index table segments on-the-fly..


A sane muxer duplicates all index table segments in the footer, so a smart 
demuxer can read the whole index from there. Yes, mxfdec problem. I have a 
WIP patch somewhere fixing that.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY

2023-02-13 Thread Tomas Härdin
mån 2023-02-13 klockan 20:33 +0100 skrev Marton Balint:
> 
> 
> On Mon, 13 Feb 2023, Tomas Härdin wrote:
> 
> > Passes FATE because we don't have any tests that mux files with a
> > whopping 250 frames. Tested with a jpeg2000 Tears of Steel sample.
> 
> Have you checked what BMX does? Because as far as I remember for 
> RDD9 (XDCAM HD) this should not exceed 10 seconds.

I have not checked BMX. Also such constraints should be explicitly
documented and there should be tests for them. An option like -xdcam
might be appropriate. Currently there is no justification at all in the
code for the choice of 250.

> 
> I suggest adding an option for this with -1 default, and unless the
> user 
> overrides it make it 238 in case of MPEG2 essence, and infinite (0) 
> otherwise.

I wouldn't be opposed to having it use a dynamic array. As for MPEG2,
that does stink a bit but perhaps it avoids causing grief for most
users. Here we again come to the problem that we don't know the
workflows in which mxf* are used, and I don't like that we're cargo
culting defaults.

> 
> There is also code which allocates the index entries in 
> EDIT_UNITS_PER_BODY increments, that probably should be replaced with
> av_dynarray2_add...

That (re)allocation happens at most twice for assuming GOP size <
EDIT_UNITS_PER_BODY

The reason I bring this all up is because opening MXF files muxed by
lavf over HTTP is slow as hell. This will be true for any other storage
where seeking incurs a non-trivial cost. HDDs come to mind. Perhaps
that is really an mxfdec problem, but then parsing becomes even hairier
than it already is. We'd have to binary search the file when seeking,
hoping to find the necessary index table segments on-the-fly..

/Tomas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY

2023-02-13 Thread Marton Balint



On Mon, 13 Feb 2023, Tomas Härdin wrote:


Passes FATE because we don't have any tests that mux files with a
whopping 250 frames. Tested with a jpeg2000 Tears of Steel sample.


Have you checked what BMX does? Because as far as I remember for 
RDD9 (XDCAM HD) this should not exceed 10 seconds.


I suggest adding an option for this with -1 default, and unless the user 
overrides it make it 238 in case of MPEG2 essence, and infinite (0) 
otherwise.


There is also code which allocates the index entries in 
EDIT_UNITS_PER_BODY increments, that probably should be replaced with 
av_dynarray2_add...


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 6/6] avformat/wavdec: Test s337m

2023-02-13 Thread Nicolas Gaullier
Test s337m probing in wav container.
Test dolby_e demuxing for 20 bits with program config '5.1+2'.
---
 tests/Makefile   |  1 +
 tests/fate/audio.mak |  3 +++
 tests/ref/fate/s337m-wav | 10 ++
 3 files changed, 14 insertions(+)
 create mode 100644 tests/ref/fate/s337m-wav

diff --git a/tests/Makefile b/tests/Makefile
index 1d50e1d175..d78f78d1b8 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -99,6 +99,7 @@ REMUX = $(call ALLYES, $(firstword $(1))_MUXER $(lastword 
$(1))_DEMUXER \
$(2) FILE_PROTOCOL PIPE_PROTOCOL FRAMECRC_MUXER)
 
 DEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER) $(3) FILE_PROTOCOL)
+DEMDEMDEC = $(call ALLYES, $(1)_DEMUXER $(2)_DEMUXER $(3:%=%_DECODER))
 ENCMUX  = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER   $(3))
 
 FRAMEMD5 = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER) $(3)  \
diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak
index 65317c8d45..1d1c75b0b3 100644
--- a/tests/fate/audio.mak
+++ b/tests/fate/audio.mak
@@ -31,6 +31,9 @@ fate-dolby-e: CMD = pcm -i $(TARGET_SAMPLES)/dolby_e/16-11
 fate-dolby-e: CMP = oneoff
 fate-dolby-e: REF = $(SAMPLES)/dolby_e/16-11.pcm
 
+FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += fate-s337m-wav
+fate-s337m-wav: CMD = framecrc -i $(TARGET_SAMPLES)/dolby_e/512.wav -vn -c:a 
copy
+
 FATE_SAMPLES_AUDIO-$(call DEMDEC, DSS, DSS_SP) += fate-dss-lp fate-dss-sp
 fate-dss-lp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/lp.dss -frames 30 -af 
aresample
 fate-dss-sp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/sp.dss -frames 30
diff --git a/tests/ref/fate/s337m-wav b/tests/ref/fate/s337m-wav
new file mode 100644
index 00..768a6f0161
--- /dev/null
+++ b/tests/ref/fate/s337m-wav
@@ -0,0 +1,10 @@
+#tb 0: 1/48000
+#media_type 0: audio
+#codec_id 0: dolby_e
+#sample_rate 0: 44800
+#channel_layout_name 0: 7.1
+0,  0,  0, 1920,11496, 0x05a9c147
+0,   1920,   1920, 1920,11496, 0x1d44d2b4
+0,   3840,   3840, 1920,11496, 0x4e078953
+0,   5760,   5760, 1920,11496, 0x1c73b1a1
+0,   7680,   7680, 1920,11262, 0xfa179fc8
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 5/6] avformat/wavdec.c: Reindent after last commit

2023-02-13 Thread Nicolas Gaullier
---
 libavformat/wavdec.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index fd9ca89880..29192e48f0 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -793,14 +793,14 @@ smv_out:
 size = FFMIN(S337M_MAX_OFFSET, left);
 ret  = ff_s337m_get_packet(s->pb, pkt, size, NULL, s, 
st->codecpar->bits_per_coded_sample);
 } else {
-size = wav->max_size;
-if (st->codecpar->block_align > 1) {
-if (size < st->codecpar->block_align)
-size = st->codecpar->block_align;
-size = (size / st->codecpar->block_align) * st->codecpar->block_align;
-}
-size = FFMIN(size, left);
-ret  = av_get_packet(s->pb, pkt, size);
+size = wav->max_size;
+if (st->codecpar->block_align > 1) {
+if (size < st->codecpar->block_align)
+size = st->codecpar->block_align;
+size = (size / st->codecpar->block_align) * 
st->codecpar->block_align;
+}
+size = FFMIN(size, left);
+ret  = av_get_packet(s->pb, pkt, size);
 }
 
 if (ret < 0)
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 4/6] avformat/wavdec: s337m support

2023-02-13 Thread Nicolas Gaullier
Add s337m probing and demuxing similarly to spdif.
Add 'non_pcm_mode' option to disable s337m demuxing (pass-through).
---
 libavformat/wavdec.c | 47 +++-
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index e3f790fcc9..fd9ca89880 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -45,6 +45,7 @@
 #include "riff.h"
 #include "w64.h"
 #include "spdif.h"
+#include "s337m.h"
 
 typedef struct WAVDemuxContext {
 const AVClass *class;
@@ -61,9 +62,11 @@ typedef struct WAVDemuxContext {
 int ignore_length;
 int max_size;
 int spdif;
+int s337m;
 int smv_given_first;
 int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
 int rifx; // RIFX: integer byte order for parameters is big endian
+int non_pcm_mode;
 } WAVDemuxContext;
 
 #define OFFSET(x) offsetof(WAVDemuxContext, x)
@@ -74,12 +77,18 @@ static const AVOption demux_options[] = {
 { "ignore_length", "Ignore length", OFFSET(ignore_length), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
 #endif
 { "max_size",  "max size of single packet", OFFSET(max_size), 
AV_OPT_TYPE_INT, { .i64 = 4096 }, 1024, 1 << 22, DEC },
+#if CONFIG_S337M_DEMUXER
+{"non_pcm_mode", "Chooses what to do with s337m", OFFSET(non_pcm_mode), 
AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC, "non_pcm_mode"},
+{"copy", "Pass s337m through unchanged", 0, AV_OPT_TYPE_CONST, 
{.i64 = 0}, 0, 1, DEC, "non_pcm_mode"},
+{"demux"   , "Demux s337m" , 0, AV_OPT_TYPE_CONST, 
{.i64 = 1}, 0, 1, DEC, "non_pcm_mode"},
+#endif
 { NULL },
 };
 
-static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
+static void set_spdif_s337m(AVFormatContext *s, WAVDemuxContext *wav)
 {
-if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
+AVCodecParameters *par = s->streams[0]->codecpar;
+if ((CONFIG_SPDIF_DEMUXER || CONFIG_S337M_DEMUXER) && par->codec_tag == 1) 
{
 enum AVCodecID codec;
 int len = 1<<16;
 int ret = ffio_ensure_seekback(s->pb, len);
@@ -92,10 +101,24 @@ static void set_spdif(AVFormatContext *s, WAVDemuxContext 
*wav)
 int64_t pos = avio_tell(s->pb);
 len = ret = avio_read(s->pb, buf, len);
 if (len >= 0) {
-ret = ff_spdif_probe(buf, len, );
-if (ret > AVPROBE_SCORE_EXTENSION) {
-s->streams[0]->codecpar->codec_id = codec;
-wav->spdif = 1;
+if (CONFIG_SPDIF_DEMUXER) {
+ret = ff_spdif_probe(buf, len, );
+if (ret > AVPROBE_SCORE_EXTENSION) {
+par->codec_id = codec;
+wav->spdif = 1;
+}
+}
+if (CONFIG_S337M_DEMUXER && !wav->spdif
+&& (par->codec_id == AV_CODEC_ID_PCM_S16LE || 
par->codec_id == AV_CODEC_ID_PCM_S24LE) && par->ch_layout.nb_channels == 2) {
+ret = ff_s337m_probe(buf, len, , 
par->bits_per_coded_sample);
+if (ret > AVPROBE_SCORE_EXTENSION) {
+if (wav->non_pcm_mode) {
+par->codec_id = codec;
+wav->s337m = 1;
+} else {
+av_log(s, AV_LOG_INFO, "Passing through S337M 
data: codec will not be reported\n");
+}
+}
 }
 }
 avio_seek(s->pb, pos, SEEK_SET);
@@ -104,7 +127,7 @@ static void set_spdif(AVFormatContext *s, WAVDemuxContext 
*wav)
 }
 
 if (ret < 0)
-av_log(s, AV_LOG_WARNING, "Cannot check for SPDIF\n");
+av_log(s, AV_LOG_WARNING, "Cannot check for SPDIF/S337M\n");
 }
 }
 
@@ -668,7 +691,7 @@ break_loop:
 ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
 ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
 
-set_spdif(s, wav);
+set_spdif_s337m(s, wav);
 
 return 0;
 }
@@ -766,6 +789,10 @@ smv_out:
 wav->data_end = avio_tell(s->pb) + left;
 }
 
+if (CONFIG_S337M_DEMUXER && wav->s337m == 1) {
+size = FFMIN(S337M_MAX_OFFSET, left);
+ret  = ff_s337m_get_packet(s->pb, pkt, size, NULL, s, 
st->codecpar->bits_per_coded_sample);
+} else {
 size = wav->max_size;
 if (st->codecpar->block_align > 1) {
 if (size < st->codecpar->block_align)
@@ -774,6 +801,8 @@ smv_out:
 }
 size = FFMIN(size, left);
 ret  = av_get_packet(s->pb, pkt, size);
+}
+
 if (ret < 0)
 return ret;
 pkt->stream_index = 0;
@@ -960,7 +989,7 @@ static int w64_read_header(AVFormatContext *s)
 
 avio_seek(pb, data_ofs, SEEK_SET);
 
-set_spdif(s, wav);
+set_spdif_s337m(s, wav);
 
  

[FFmpeg-devel] [PATCH 3/6] avformat/s337m: New ff_s337m_probe()

2023-02-13 Thread Nicolas Gaullier
Similar to ff_spdif_probe() with just an additional checking of
the bit resolution of the container as it may be 16 or 24 for s337m.
---
 libavformat/s337m.c | 32 
 libavformat/s337m.h | 16 
 2 files changed, 48 insertions(+)

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 2a566e3cba..9d2ac265b6 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -135,6 +135,38 @@ static int s337m_probe(const AVProbeData *p)
 return 0;
 }
 
+int ff_s337m_probe(const uint8_t *buf, int size, enum AVCodecID *codec, int 
container_word_bits)
+{
+int pos = 0;
+int consecutive_codes = 0;
+
+if ( size < S337M_MIN_OFFSET)
+return 0;
+size = FFMIN(3 * S337M_MAX_OFFSET, size);
+if (container_word_bits != 16 && container_word_bits != 24)
+return AVERROR_INVALIDDATA;
+
+do {
+uint64_t state;
+int data_type, data_size, offset;
+while (pos < size - 12 && !buf[pos]) {
+pos++;
+}
+if (pos >= size - 12 || pos < S337M_PROBE_GUARDBAND_MIN_BYTES || pos % 
(container_word_bits == 16 ? 4 : 6))
+return 0;
+state = container_word_bits == 16 ? AV_RB32(buf + pos) : AV_RB48(buf + 
pos);
+if (!IS_LE_MARKER(state))
+return 0;
+data_type = container_word_bits == 16 ? AV_RL16(buf + pos + 4) : 
AV_RL24(buf + pos + 6);
+data_size = container_word_bits == 16 ? AV_RL16(buf + pos + 6) : 
AV_RL24(buf + pos + 9);
+if (s337m_get_offset_and_codec(NULL, state, data_type, data_size, 
container_word_bits, , codec))
+return 0;
+pos = ++consecutive_codes * (offset + 4*(container_word_bits == 16 ? 4 
: 6));
+} while (consecutive_codes < 3);
+
+return AVPROBE_SCORE_MAX;
+}
+
 static int s337m_read_header(AVFormatContext *s)
 {
 s->ctx_flags |= AVFMTCTX_NOHEADER;
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
index af2c4c85a3..94e79dce5d 100644
--- a/libavformat/s337m.h
+++ b/libavformat/s337m.h
@@ -21,6 +21,22 @@
 #ifndef AVFORMAT_S337M_H
 #define AVFORMAT_S337M_H
 
+#define S337M_MIN_OFFSET 1601*4
+#define S337M_MAX_OFFSET 2002*6
+
+#define S337M_PROBE_GUARDBAND_MIN_BYTES 0
+
+/**
+ * Detect s337m packets in a PCM_S16LE/S24LE stereo stream
+ * Requires 3 samples with enough (S337M_PROBE_GUARDBAND_MIN_BYTES) and clean 
(set to zero) guard band
+ * @param p_buf Buffer
+ * @param size Buffer size
+ * @param codec Returns AV_CODEC_ID_DOLBY_E upon successful probing
+ * @param container_word_bits 16 or 24
+ * @return = AVPROBE_SCORE
+ */
+int ff_s337m_probe(const uint8_t *p_buf, int size, enum AVCodecID *codec, int 
container_word_bits);
+
 /**
  * Read s337m packets in a PCM_S16LE/S24LE stereo stream
  * Returns the first inner packet found
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution

2023-02-13 Thread Nicolas Gaullier
Prepare the support of s337m in muxers other than raw (ex: wav).
For example, this forbids reading 16 bits DolbyE stream from a 24 bit wav file.
---
 libavformat/s337m.c | 21 +++--
 libavformat/s337m.h |  3 ++-
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 582c8b3670..2a566e3cba 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -35,7 +35,7 @@
 
 static int s337m_get_offset_and_codec(void *avc,
   uint64_t state,
-  int data_type, int data_size,
+  int data_type, int data_size, int 
container_word_bits,
   int *offset, enum AVCodecID *codec)
 {
 int word_bits;
@@ -56,6 +56,12 @@ static int s337m_get_offset_and_codec(void *avc,
 avpriv_report_missing_feature(avc, "Data type %#x in SMPTE 337M", 
data_type & 0x1F);
 return AVERROR_PATCHWELCOME;
 }
+if (container_word_bits &&
+!(container_word_bits == 16 && word_bits == 16) &&
+!(container_word_bits == 24 && word_bits == 20) &&
+!(container_word_bits == 24 && word_bits == 24)) {
+return AVERROR_INVALIDDATA;
+}
 
 if (codec)
 *codec = AV_CODEC_ID_DOLBY_E;
@@ -105,7 +111,7 @@ static int s337m_probe(const AVProbeData *p)
 data_size = AV_RL24(buf + 3);
 }
 
-if (s337m_get_offset_and_codec(NULL, state, data_type, data_size, 
, NULL))
+if (s337m_get_offset_and_codec(NULL, state, data_type, data_size, 0, 
, NULL))
 continue;
 
 i = IS_16LE_MARKER(state) ? 0 : IS_20LE_MARKER(state) ? 1 : 2;
@@ -143,13 +149,16 @@ static void bswap_buf24(uint8_t *data, int size)
 FFSWAP(uint8_t, data[0], data[2]);
 }
 
-int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc)
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc, int container_word_bits)
 {
 uint64_t state = 0;
 int ret, data_type, data_size, offset;
 int64_t orig_pos = avio_tell(pb);
 
-while (!IS_LE_MARKER(state)) {
+if (container_word_bits && container_word_bits != 16 && 
container_word_bits != 24)
+return AVERROR_INVALIDDATA;
+while ((container_word_bits == 24 || !IS_16LE_MARKER(state))
+&& (container_word_bits == 16 || !IS_20LE_MARKER(state) && 
!IS_24LE_MARKER(state))) {
 state = (state << 8) | avio_r8(pb);
 if (avio_feof(pb))
 return AVERROR_EOF;
@@ -167,7 +176,7 @@ int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int 
size, enum AVCodecID
 data_size = avio_rl24(pb);
 }
 
-if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size, 
, codec)) < 0)
+if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size, 
container_word_bits, , codec)) < 0)
 return ret;
 offset = FFMIN(offset, size - (avio_tell(pb) - orig_pos));
 
@@ -187,7 +196,7 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 enum AVCodecID codec;
 int ret;
 
-if ((ret = ff_s337m_get_packet(s->pb, pkt, avio_size(s->pb), , s)) < 
0)
+if ((ret = ff_s337m_get_packet(s->pb, pkt, avio_size(s->pb), , s, 
0)) < 0)
 return ret;
 
 if (!s->nb_streams) {
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
index f7bd0c16f6..af2c4c85a3 100644
--- a/libavformat/s337m.h
+++ b/libavformat/s337m.h
@@ -30,8 +30,9 @@
  * @param size Maximum IO read size available for reading at current position
  * @param codec Returns AV_CODEC_ID_DOLBY_E
  * @param avc For av_log
+ * @param container_word_bits 16,24, or 0 for autodetect
  * @return = 0 on success (an error is raised if no s337m was found)
  */
-int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc);
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc, int container_word_bits);
 
 #endif /* AVFORMAT_S337M_H */
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 1/6] avformat/s337m: Split read_packet/get_packet

2023-02-13 Thread Nicolas Gaullier
Prepare use of s337m_get_packet from outside.
---
 libavformat/s337m.c | 24 
 libavformat/s337m.h | 37 +
 2 files changed, 57 insertions(+), 4 deletions(-)
 create mode 100644 libavformat/s337m.h

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 6fecfeffae..582c8b3670 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -22,6 +22,7 @@
 #include "avformat.h"
 #include "internal.h"
 #include "spdif.h"
+#include "s337m.h"
 
 #define MARKER_16LE 0x72F81F4E
 #define MARKER_20LE 0x20876FF0E154
@@ -142,17 +143,20 @@ static void bswap_buf24(uint8_t *data, int size)
 FFSWAP(uint8_t, data[0], data[2]);
 }
 
-static int s337m_read_packet(AVFormatContext *s, AVPacket *pkt)
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc)
 {
-AVIOContext *pb = s->pb;
 uint64_t state = 0;
 int ret, data_type, data_size, offset;
-enum AVCodecID codec;
+int64_t orig_pos = avio_tell(pb);
 
 while (!IS_LE_MARKER(state)) {
 state = (state << 8) | avio_r8(pb);
 if (avio_feof(pb))
 return AVERROR_EOF;
+if (avio_tell(pb) - orig_pos + 6 >= size) {
+av_log(avc, AV_LOG_ERROR, "s337m : sync bytes not found at packet 
pos=0x%"PRIx64" size=%d\n", orig_pos, size);
+return AVERROR_INVALIDDATA;
+}
 }
 
 if (IS_16LE_MARKER(state)) {
@@ -163,8 +167,9 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 data_size = avio_rl24(pb);
 }
 
-if ((ret = s337m_get_offset_and_codec(s, state, data_type, data_size, 
, )) < 0)
+if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size, 
, codec)) < 0)
 return ret;
+offset = FFMIN(offset, size - (avio_tell(pb) - orig_pos));
 
 if ((ret = av_get_packet(pb, pkt, offset)) != offset)
 return ret < 0 ? ret : AVERROR_EOF;
@@ -174,6 +179,17 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 else
 bswap_buf24(pkt->data, pkt->size);
 
+return 0;
+}
+
+static int s337m_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+enum AVCodecID codec;
+int ret;
+
+if ((ret = ff_s337m_get_packet(s->pb, pkt, avio_size(s->pb), , s)) < 
0)
+return ret;
+
 if (!s->nb_streams) {
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st) {
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
new file mode 100644
index 00..f7bd0c16f6
--- /dev/null
+++ b/libavformat/s337m.h
@@ -0,0 +1,37 @@
+/*
+ * SMPTE ST 337 common header
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFORMAT_S337M_H
+#define AVFORMAT_S337M_H
+
+/**
+ * Read s337m packets in a PCM_S16LE/S24LE stereo stream
+ * Returns the first inner packet found
+ * Note that it does not require a clean guard band
+ * @param pb Associated IO context
+ * @param pkt On success, returns a DOLBY E packet
+ * @param size Maximum IO read size available for reading at current position
+ * @param codec Returns AV_CODEC_ID_DOLBY_E
+ * @param avc For av_log
+ * @return = 0 on success (an error is raised if no s337m was found)
+ */
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc);
+
+#endif /* AVFORMAT_S337M_H */
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files

2023-02-13 Thread Lynne
Feb 13, 2023, 10:29 by d.kozin...@samsung.com:

> Lynne, if it concerns us, we will comply with both the current and the new
> maintainership policy once your patchset is pushed. We see that your change
> has not yet been pushed into the main branch, and it appears that the
> discussion on this topic may still be ongoing, although both Michael and
> other maintainers have reviewed and commented on it.
>

What do you mean both current and new policy?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] Use '-' instead of '/' for rc.exe options (take 2)

2023-02-13 Thread Martin Storsjö

On Sat, 11 Feb 2023, Martin Storsjö wrote:


On Fri, 10 Feb 2023, Ziemowit Laski wrote:


Second version of my patch.  Please let me know if I forgot something.


I believe this looks good, thanks. I'll give it another try (in a day or 
two), and push it once I've done that if it works fine.


I pushed this patch now - thanks!

// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vf_colorspace: Add support for 14- and 16-bit YUV

2023-02-13 Thread Tomas Härdin
We've had some discussion on IRC about how to get tonemap support into
vf_colorspace and converting from/to PQ (and maybe HLG) and 31-bit
intermediate values. If that is done then the second patch in this set
becomes superfluous. But I'd still like to see this patch (1/2) pushed
if no one objects since it just adds more pixel formats. SIMD can come
later.

/Tomas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY

2023-02-13 Thread Tomas Härdin
Passes FATE because we don't have any tests that mux files with a
whopping 250 frames. Tested with a jpeg2000 Tears of Steel sample.

/Tomas
From ad87019bf1ec7540a43e9a56acaf7adb32c917ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Mon, 13 Feb 2023 10:55:06 +0100
Subject: [PATCH] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY

250 is ridiculously low and leads to excessive partitions and allocations.
This change also makes muxed files smaller, and makes demuxing them faster.
---
 libavformat/mxfenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index a29d678098..124b5a6b41 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -67,7 +67,7 @@ extern const FFOutputFormat ff_mxf_opatom_muxer;
 #define IS_D10(s)((s)->oformat == _mxf_d10_muxer.p)
 #define IS_OPATOM(s) ((s)->oformat == _mxf_opatom_muxer.p)
 
-#define EDIT_UNITS_PER_BODY 250
+#define EDIT_UNITS_PER_BODY (1 << 20)
 #define KAG_SIZE 512
 
 typedef struct MXFIndexEntry {
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files

2023-02-13 Thread Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics
Lynne, if it concerns us, we will comply with both the current and the new
maintainership policy once your patchset is pushed. We see that your change
has not yet been pushed into the main branch, and it appears that the
discussion on this topic may still be ongoing, although both Michael and
other maintainers have reviewed and commented on it.
Therefore, can we count on you to review our patchset in your spare time? As
I mentioned before, we would like to get moving, make some progress, and get
closer to the moment when our patchset is ready to be pushed to the master
branch.



-Original Message-
From: ffmpeg-devel  On Behalf Of Lynne
Sent: poniedziałek, 30 stycznia 2023 00:18
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
Changelog and MAINTAINERS files

Jan 29, 2023, 10:57 by mich...@niedermayer.cc:

> Hi
>
> On Fri, Jan 27, 2023 at 01:03:00PM +0100, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
>
>> Hi,
>> It's been almost a month since we submitted our latest changes to the
FFmpeg patchwork. I know that EVC implementation isn't the only thing you
are working on at the moment but we'd like to do another step forward,
toward merging our implementation into the master branch of the FFmpeg
repository. 
>> The contribution is something that we take seriously so we'd like to
finally do some progress.
>> We would like to merge it as soon as it is enough good and it meets the
expected quality. Continual synchronization of our changes with the latest
FFmpeg changes and splitting our changes into patches is, let's say a
painstaking job. It would be much easier to develop and refine the code if
we could skip that hard splitting on patches step that we have to do each
time we do any, even small change.
>> We know that the new FFmpeg version will be released soon and you may be
absorbed and overwhelmed with the work related to the new release. However,
we'd be grateful if you found a little time and take a look at our latest
changes.
>> Last but not least. Do you have any plans related to including such
changes as our EVC implementation in the next release?
>>
>
> I cannot speak for others but ATM for me its difficult to add this 
> patchset to my todo list. If someone reviews and applies it it could 
> make it in for the release but will anyone, i do not know.
> What i can say is that if a patch which adds you to MAINTAINERS is 
> applied ping me and ill give you git write (unless there are some new 
> standing objections), and once you have that you can work on this code
with less pain.
> But i will leave applying the MAINTAINERS change to others too as some 
> people seemed not happy anout it and i think in such case its better 
> if a 2nd developer does that
>
> PS: Maybe you can troll the people who didnt like your MAINTAINERS 
> addition into reviewing & applying your patchset. Its not an 
> unreasonable request because if you dont have git write someone else 
> has to apply changes
>

I assign myself to personally review the patchset and push it, if you review
my policy change on maintainership. As I said, I have no objection on who
gets maintainership, just that it is done explicitly via a separate list in
the maintainers file.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v2] libavcodec/qsvenc: Flush cached frames before reset encoder

2023-02-13 Thread wenbin . chen-at-intel . com
From: Wenbin Chen 

According to 
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#configuration-change.
Before calling MFXVideoENCODE_Reset, The application needs to retrieve
any cached frames in the SDK encoder.
A loop is added before MFXVideoENCODE_Reset to retrieve cached frames
and add them to async_fifo, so that dynamic configuration works when
async_depth > 1.

Signed-off-by: Wenbin Chen 
---
 libavcodec/qsvenc.c | 122 
 1 file changed, 66 insertions(+), 56 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 2f0e94a914..3951f40e7b 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1600,7 +1600,7 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext 
*q)
 
 q->param.AsyncDepth = q->async_depth;
 
-q->async_fifo = av_fifo_alloc2(q->async_depth, sizeof(QSVPacket), 0);
+q->async_fifo = av_fifo_alloc2(q->async_depth, sizeof(QSVPacket), 
AV_FIFO_FLAG_AUTO_GROW);
 if (!q->async_fifo)
 return AVERROR(ENOMEM);
 
@@ -2296,58 +2296,6 @@ static int update_pic_timing_sei(AVCodecContext *avctx, 
QSVEncContext *q)
 return updated;
 }
 
-static int update_parameters(AVCodecContext *avctx, QSVEncContext *q,
- const AVFrame *frame)
-{
-int needReset = 0, ret = 0;
-
-if (!frame || avctx->codec_id == AV_CODEC_ID_MJPEG)
-return 0;
-
-needReset = update_qp(avctx, q);
-needReset |= update_max_frame_size(avctx, q);
-needReset |= update_gop_size(avctx, q);
-needReset |= update_rir(avctx, q);
-needReset |= update_low_delay_brc(avctx, q);
-needReset |= update_frame_rate(avctx, q);
-needReset |= update_bitrate(avctx, q);
-needReset |= update_pic_timing_sei(avctx, q);
-ret = update_min_max_qp(avctx, q);
-if (ret < 0)
-return ret;
-needReset |= ret;
-if (!needReset)
-return 0;
-
-if (avctx->hwaccel_context) {
-AVQSVContext *qsv = avctx->hwaccel_context;
-int i, j;
-q->param.ExtParam = q->extparam;
-for (i = 0; i < qsv->nb_ext_buffers; i++)
-q->param.ExtParam[i] = qsv->ext_buffers[i];
-q->param.NumExtParam = qsv->nb_ext_buffers;
-
-for (i = 0; i < q->nb_extparam_internal; i++) {
-for (j = 0; j < qsv->nb_ext_buffers; j++) {
-if (qsv->ext_buffers[j]->BufferId == 
q->extparam_internal[i]->BufferId)
-break;
-}
-if (j < qsv->nb_ext_buffers)
-continue;
-q->param.ExtParam[q->param.NumExtParam++] = 
q->extparam_internal[i];
-}
-} else {
-q->param.ExtParam= q->extparam_internal;
-q->param.NumExtParam = q->nb_extparam_internal;
-}
-av_log(avctx, AV_LOG_DEBUG, "Parameter change, call msdk reset.\n");
-ret = MFXVideoENCODE_Reset(q->session, >param);
-if (ret < 0)
-return ff_qsv_print_error(avctx, ret, "Error during resetting");
-
-return 0;
-}
-
 static int encode_frame(AVCodecContext *avctx, QSVEncContext *q,
 const AVFrame *frame)
 {
@@ -2438,7 +2386,7 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 
 if (ret < 0) {
 ret = (ret == MFX_ERR_MORE_DATA) ?
-   0 : ff_qsv_print_error(avctx, ret, "Error during encoding");
+   AVERROR(EAGAIN) : ff_qsv_print_error(avctx, ret, "Error during 
encoding");
 goto free;
 }
 
@@ -2448,7 +2396,9 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 ret = 0;
 
 if (*pkt.sync) {
-av_fifo_write(q->async_fifo, , 1);
+ret = av_fifo_write(q->async_fifo, , 1);
+if (ret < 0)
+goto free;
 } else {
 free:
 av_freep();
@@ -2466,6 +2416,66 @@ nomem:
 goto free;
 }
 
+static int update_parameters(AVCodecContext *avctx, QSVEncContext *q,
+ const AVFrame *frame)
+{
+int needReset = 0, ret = 0;
+
+if (!frame || avctx->codec_id == AV_CODEC_ID_MJPEG)
+return 0;
+
+needReset = update_qp(avctx, q);
+needReset |= update_max_frame_size(avctx, q);
+needReset |= update_gop_size(avctx, q);
+needReset |= update_rir(avctx, q);
+needReset |= update_low_delay_brc(avctx, q);
+needReset |= update_frame_rate(avctx, q);
+needReset |= update_bitrate(avctx, q);
+needReset |= update_pic_timing_sei(avctx, q);
+ret = update_min_max_qp(avctx, q);
+if (ret < 0)
+return ret;
+needReset |= ret;
+if (!needReset)
+return 0;
+
+if (avctx->hwaccel_context) {
+AVQSVContext *qsv = avctx->hwaccel_context;
+int i, j;
+q->param.ExtParam = q->extparam;
+for (i = 0; i < qsv->nb_ext_buffers; i++)
+q->param.ExtParam[i] = qsv->ext_buffers[i];
+q->param.NumExtParam = qsv->nb_ext_buffers;
+
+for (i = 0; i < q->nb_extparam_internal; i++) {
+for (j = 0; 

[FFmpeg-devel] [PATCH v2] libavcodec/qsvenc: Do not pass RGB solorspace to VPL/MSDK

2023-02-13 Thread wenbin . chen-at-intel . com
From: Wenbin Chen 

When encode RGB frame, Intel driver convert RGB to YUV, so we cannot
set RGB colorspace to VPL/MSDK.

Signed-off-by: Wenbin Chen 
---
 libavcodec/qsvenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 2f0e94a914..d3f7532fc0 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1185,7 +1185,12 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->extvsi.ColourDescriptionPresent = 1;
 q->extvsi.ColourPrimaries = avctx->color_primaries;
 q->extvsi.TransferCharacteristics = avctx->color_trc;
-q->extvsi.MatrixCoefficients = avctx->colorspace;
+if (avctx->colorspace == AVCOL_SPC_RGB)
+// RGB will be converted to YUV, so RGB colorspace is not supported
+q->extvsi.MatrixCoefficients = AVCOL_SPC_UNSPECIFIED;
+else
+q->extvsi.MatrixCoefficients = avctx->colorspace;
+
 }
 
 if ((avctx->codec_id != AV_CODEC_ID_VP9) && (q->extvsi.VideoFullRange || 
q->extvsi.ColourDescriptionPresent)) {
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: Flush cached frames before reset encoder

2023-02-13 Thread Chen, Wenbin
> wenbin.chen-at-intel@ffmpeg.org:
> > From: Wenbin Chen 
> >
> > According to https://github.com/Intel-Media-
> SDK/MediaSDK/blob/master/doc/mediasdk-man.md#configuration-change.
> > Before calling MFXVideoENCODE_Reset, The application needs to retrieve
> > any cached frames in the SDK encoder.
> > A loop is added before MFXVideoENCODE_Reset to retrieve cached frames
> > and add them to async_fifo, so that dynamic configuration works when
> > async_depth > 1.
> >
> > Signed-off-by: Wenbin Chen 
> > ---
> >  libavcodec/qsvenc.c | 118 +++-
> >  1 file changed, 63 insertions(+), 55 deletions(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index 2f0e94a914..f3b488dec8 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1600,7 +1600,7 @@ int ff_qsv_enc_init(AVCodecContext *avctx,
> QSVEncContext *q)
> >
> >  q->param.AsyncDepth = q->async_depth;
> >
> > -q->async_fifo = av_fifo_alloc2(q->async_depth, sizeof(QSVPacket), 0);
> > +q->async_fifo = av_fifo_alloc2(q->async_depth, sizeof(QSVPacket),
> AV_FIFO_FLAG_AUTO_GROW);
> 
> If you use AV_FIFO_FLAG_AUTO_GROW, you need to handle av_fifo_write()
> errors.

Thanks. I will fix it in patch v2.

> 
> >  if (!q->async_fifo)
> >  return AVERROR(ENOMEM);
> >
> > @@ -2296,58 +2296,6 @@ static int
> update_pic_timing_sei(AVCodecContext *avctx, QSVEncContext *q)
> >  return updated;
> >  }
> >
> > -static int update_parameters(AVCodecContext *avctx, QSVEncContext *q,
> > - const AVFrame *frame)
> > -{
> > -int needReset = 0, ret = 0;
> > -
> > -if (!frame || avctx->codec_id == AV_CODEC_ID_MJPEG)
> > -return 0;
> > -
> > -needReset = update_qp(avctx, q);
> > -needReset |= update_max_frame_size(avctx, q);
> > -needReset |= update_gop_size(avctx, q);
> > -needReset |= update_rir(avctx, q);
> > -needReset |= update_low_delay_brc(avctx, q);
> > -needReset |= update_frame_rate(avctx, q);
> > -needReset |= update_bitrate(avctx, q);
> > -needReset |= update_pic_timing_sei(avctx, q);
> > -ret = update_min_max_qp(avctx, q);
> > -if (ret < 0)
> > -return ret;
> > -needReset |= ret;
> > -if (!needReset)
> > -return 0;
> > -
> > -if (avctx->hwaccel_context) {
> > -AVQSVContext *qsv = avctx->hwaccel_context;
> > -int i, j;
> > -q->param.ExtParam = q->extparam;
> > -for (i = 0; i < qsv->nb_ext_buffers; i++)
> > -q->param.ExtParam[i] = qsv->ext_buffers[i];
> > -q->param.NumExtParam = qsv->nb_ext_buffers;
> > -
> > -for (i = 0; i < q->nb_extparam_internal; i++) {
> > -for (j = 0; j < qsv->nb_ext_buffers; j++) {
> > -if (qsv->ext_buffers[j]->BufferId == 
> > q->extparam_internal[i]-
> >BufferId)
> > -break;
> > -}
> > -if (j < qsv->nb_ext_buffers)
> > -continue;
> > -q->param.ExtParam[q->param.NumExtParam++] = q-
> >extparam_internal[i];
> > -}
> > -} else {
> > -q->param.ExtParam= q->extparam_internal;
> > -q->param.NumExtParam = q->nb_extparam_internal;
> > -}
> > -av_log(avctx, AV_LOG_DEBUG, "Parameter change, call msdk reset.\n");
> > -ret = MFXVideoENCODE_Reset(q->session, >param);
> > -if (ret < 0)
> > -return ff_qsv_print_error(avctx, ret, "Error during resetting");
> > -
> > -return 0;
> > -}
> > -
> >  static int encode_frame(AVCodecContext *avctx, QSVEncContext *q,
> >  const AVFrame *frame)
> >  {
> > @@ -2438,7 +2386,7 @@ static int encode_frame(AVCodecContext *avctx,
> QSVEncContext *q,
> >
> >  if (ret < 0) {
> >  ret = (ret == MFX_ERR_MORE_DATA) ?
> > -   0 : ff_qsv_print_error(avctx, ret, "Error during encoding");
> > +   AVERROR(EAGAIN) : ff_qsv_print_error(avctx, ret, "Error 
> > during
> encoding");
> >  goto free;
> >  }
> >
> > @@ -2466,6 +2414,66 @@ nomem:
> >  goto free;
> >  }
> >
> > +static int update_parameters(AVCodecContext *avctx, QSVEncContext *q,
> > + const AVFrame *frame)
> > +{
> > +int needReset = 0, ret = 0;
> > +
> > +if (!frame || avctx->codec_id == AV_CODEC_ID_MJPEG)
> > +return 0;
> > +
> > +needReset = update_qp(avctx, q);
> > +needReset |= update_max_frame_size(avctx, q);
> > +needReset |= update_gop_size(avctx, q);
> > +needReset |= update_rir(avctx, q);
> > +needReset |= update_low_delay_brc(avctx, q);
> > +needReset |= update_frame_rate(avctx, q);
> > +needReset |= update_bitrate(avctx, q);
> > +needReset |= update_pic_timing_sei(avctx, q);
> > +ret = update_min_max_qp(avctx, q);
> > +if (ret < 0)
> > +return ret;
> > +needReset |= ret;
> > +if (!needReset)
> > +return 0;
> > +
> > +if (avctx->hwaccel_context) {
> > +   

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: Do not pass RGB solorspace to VPL/MSDK

2023-02-13 Thread Chen, Wenbin
> From: Wenbin Chen 
> 
> When encode RGB frame, Intel driver convert RGB to YUV, so we cannot
> set RGB colorspace to VPL/MSDK.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavcodec/qsvenc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2f0e94a914..944a76f4f1 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1185,7 +1185,12 @@ static int init_video_param(AVCodecContext
> *avctx, QSVEncContext *q)
>  q->extvsi.ColourDescriptionPresent = 1;
>  q->extvsi.ColourPrimaries = avctx->color_primaries;
>  q->extvsi.TransferCharacteristics = avctx->color_trc;
> -q->extvsi.MatrixCoefficients = avctx->colorspace;
> +if (avctx->colorspace == AVCOL_SPC_RGB)
> +//YUV will be converted to RGB, so RGB colorspace is not 
> supported

Comment is wrong. It should be " RGB will be converted to YUV".  I will send 
patch v2.

> +q->extvsi.MatrixCoefficients = AVCOL_SPC_UNSPECIFIED;
> +else
> +q->extvsi.MatrixCoefficients = avctx->colorspace;
> +
>  }
> 
>  if ((avctx->codec_id != AV_CODEC_ID_VP9) && (q->extvsi.VideoFullRange
> || q->extvsi.ColourDescriptionPresent)) {
> --
> 2.34.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".