Re: [FFmpeg-devel] [PATCH] fate.sh: Allow overriding what targets to make for running the tests

[Rémi Denis-Courmont]

Le 28 novembre 2023 01:22:14 GMT+02:00, Michael Niedermayer 
 a écrit :
>On Mon, Nov 27, 2023 at 05:46:40PM +0200, Rémi Denis-Courmont wrote:
>[...]
>> Also FWIW, RV broke due to misaligned accesses and illegal vector types that
>> QEMU tolerated. That is rather an argument against QEMU than against this MR 
>> but still.
>
>has someone reported this to qemu ?
>(seems like a bug)

It's not a bug. The specification leaves those cases *undefined*. QEMU supports 
them because they can, and adding sanity checks would just slow stuff down.

Also generally QEMU TCG policy seems to be maximize perf and compatibility, not 
formal correctness.

>
>thx
>
>[...]
___
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] [ANNOUNCE] upcoming vote: extra members for GA v2

[Anton Khirnov]

Hi all,
the vote has ended, with the result that ALL proposed candidates are
added to GA. See [1] for more details.

Raw votes in CSV format are attached for posterity (also downloadable
from [1]).

[1] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_d0b225b9aa8d45d5

Cheers,
-- 
Anton Khirnov
Ronald Bultje,Alexander Strasser,Hendrik Leppkes,Reimar Döffinger,Baptiste Coudurier,Shiyou Yin,NOT_CHOSEN
1,3,1,3,3,3,2
1,4,2,3,7,7,7
1,1,1,1,2,7,7
1,7,3,5,6,2,4
1,1,1,1,1,1,7
1,1,1,1,7,7,7
6,1,7,2,5,4,3
1,6,3,5,2,7,4
7,2,7,3,1,4,5
3,6,4,5,1,2,7
4,2,1,3,6,7,6
1,4,2,6,7,5,3
7,7,7,7,7,1,2
1,3,2,4,7,6,5
5,4,3,2,1,6,7
1,3,1,7,7,7,5
2,1,4,5,6,3,7
3,4,1,5,2,6,7
7,1,1,1,1,5,5
1,5,1,3,3,5,5
5,3,2,6,1,4,7
4,3,1,2,7,5,6
1,3,1,3,3,3,3
1,7,2,7,7,3,7
1,6,1,3,7,7,3
7,2,4,1,3,5,6
2,4,3,6,5,1,7
1,7,2,3,4,7,6
___
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] lavu/hwcontext_vaapi: ignore nonexistent device in default DRM device selection

[Xiang, Haihao]

From: Haihao Xiang 

It is possible that renderD128 doesn't exist but renderD129 is
available in a system (see [1]). This change can make sure the default
DRM device selection works even if renderD128 doesn't exist.

[1] 
https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/cmd/gpu_plugin/README.md#issues-with-media-workloads-on-multi-gpu-setups

Signed-off-by: Haihao Xiang 
---
 libavutil/hwcontext_vaapi.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 12bc95119a..29fc8bd648 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1733,8 +1733,19 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, 
const char *device,
  "/dev/dri/renderD%d", 128 + n);
 priv->drm_fd = open(path, O_RDWR);
 if (priv->drm_fd < 0) {
-av_log(ctx, AV_LOG_VERBOSE, "Cannot open "
-   "DRM render node for device %d.\n", n);
+if (errno == ENOENT) {
+if (n != max_devices - 1) {
+av_log(ctx, AV_LOG_VERBOSE,
+   "No render device %s, try next device for "
+   "DRM render node.\n", path);
+continue;
+}
+
+av_log(ctx, AV_LOG_VERBOSE, "No available render 
device "
+   "for DRM render node.\n");
+} else
+av_log(ctx, AV_LOG_VERBOSE, "Cannot open "
+   "DRM render node for device %d.\n", n);
 break;
 }
 #if CONFIG_LIBDRM
-- 
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] [PATCH v2 3/3] lavu/hwcontext_qsv: Make sure hardware vendor is Intel for qsv on d3d11va

[Xiang, Haihao]

From: Haihao Xiang 

When multiple hardwares are available, the default one might not be
Intel Hardware. We can use option vendor_id to choose the required
vendor.

Tested-by: Artem Galin 
Signed-off-by: Haihao Xiang 
---
 libavutil/hwcontext_qsv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 1bfda9e69b..7a9cd0cc37 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -2200,6 +2200,12 @@ static int qsv_device_create(AVHWDeviceContext *ctx, 
const char *device,
 #endif
 #if CONFIG_D3D11VA
 case AV_HWDEVICE_TYPE_D3D11VA:
+{
+// Make sure the hardware vendor is Intel when multiple devices are
+// available, it will be ignored if user specifies the child device
+// explicitly
+av_dict_set(_device_opts, "vendor_id","0x8086",  0);
+}
 break;
 #endif
 #if CONFIG_DXVA2
-- 
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] [PATCH v2 2/3] doc/ffmpeg: Update the description about d3d11va

[Xiang, Haihao]

From: Haihao Xiang 

Signed-off-by: Haihao Xiang 
---
 doc/ffmpeg.texi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 68363ae045..145cbb1032 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1165,6 +1165,21 @@ Choose the first device and use the primary device 
context.
 
 @item d3d11va
 @var{device} is the number of the Direct3D 11 display adapter.
+If not specified, it will attempt to use the default Direct3D 11 display 
adapter
+or the first Direct3D 11 display adapter whose hardware VendorId is specified
+by @samp{vendor_id}.
+
+Examples:
+@table @emph
+@item -init_hw_device d3d11va
+Create a d3d11va device on the default Direct3D 11 display adapter.
+
+@item -init_hw_device d3d11va:1
+Create a d3d11va device on the Direct3D 11 display adapter specified by index 
1.
+
+@item -init_hw_device d3d11va:,vendor_id=0x8086
+Create a d3d11va device on the first Direct3D 11 display adapter whose 
hardware VendorId is 0x8086.
+@end table
 
 @item vaapi
 @var{device} is either an X11 display name, a DRM render node or a DirectX 
adapter index.
-- 
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] [PATCH v2 1/3] lavu/hwcontext_d3d11va: Add option vendor_id

[Xiang, Haihao]

From: Artem Galin 

User may choose the hardware via option vendor_id when multiple
hardwares are available.

Signed-off-by: Artem Galin 
Signed-off-by: Haihao Xiang 
---
 libavutil/hwcontext_d3d11va.c | 59 ++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index cc8c97d2b6..2fd3561c88 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -552,6 +552,47 @@ static void d3d11va_device_uninit(AVHWDeviceContext *hwdev)
 }
 }
 
+static int d3d11va_device_find_adapter_by_vendor_id(AVHWDeviceContext *ctx, 
uint32_t flags, const char *vendor_id)
+{
+HRESULT hr;
+IDXGIAdapter *adapter = NULL;
+IDXGIFactory2 *factory;
+int adapter_id = 0;
+long int id = strtol(vendor_id, NULL, 0);
+
+hr = mCreateDXGIFactory(_IDXGIFactory2, (void **));
+if (FAILED(hr)) {
+av_log(ctx, AV_LOG_ERROR, "CreateDXGIFactory returned error\n");
+return -1;
+}
+
+while (IDXGIFactory2_EnumAdapters(factory, adapter_id++, ) != 
DXGI_ERROR_NOT_FOUND) {
+ID3D11Device* device = NULL;
+DXGI_ADAPTER_DESC adapter_desc;
+
+hr = mD3D11CreateDevice(adapter, D3D_DRIVER_TYPE_UNKNOWN, NULL, flags, 
NULL, 0, D3D11_SDK_VERSION, , NULL, NULL);
+if (FAILED(hr)) {
+av_log(ctx, AV_LOG_DEBUG, "D3D11CreateDevice returned error, try 
next adapter\n");
+IDXGIAdapter_Release(adapter);
+continue;
+}
+
+hr = IDXGIAdapter2_GetDesc(adapter, _desc);
+ID3D11Device_Release(device);
+IDXGIAdapter_Release(adapter);
+if (FAILED(hr)) {
+av_log(ctx, AV_LOG_DEBUG, "IDXGIAdapter2_GetDesc returned error, 
try next adapter\n");
+continue;
+} else if (adapter_desc.VendorId == id) {
+IDXGIFactory2_Release(factory);
+return adapter_id - 1;
+}
+}
+
+IDXGIFactory2_Release(factory);
+return -1;
+}
+
 static int d3d11va_device_create(AVHWDeviceContext *ctx, const char *device,
  AVDictionary *opts, int flags)
 {
@@ -563,6 +604,7 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
const char *device,
 UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
 int is_debug   = !!av_dict_get(opts, "debug", NULL, 0);
 int ret;
+int adapter = -1;
 
 // (On UWP we can't check this.)
 #if !HAVE_UWP
@@ -581,10 +623,25 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
const char *device,
 }
 
 if (device) {
+adapter = atoi(device);
+} else {
+AVDictionaryEntry *e = av_dict_get(opts, "vendor_id", NULL, 0);
+if (e && e->value) {
+adapter = d3d11va_device_find_adapter_by_vendor_id(ctx, 
creationFlags, e->value);
+if (adapter < 0) {
+av_log(ctx, AV_LOG_ERROR, "Failed to find d3d11va adapter by "
+   "vendor id %s\n", e->value);
+return AVERROR_UNKNOWN;
+}
+}
+}
+
+if (adapter >= 0) {
 IDXGIFactory2 *pDXGIFactory;
+
+av_log(ctx, AV_LOG_VERBOSE, "Selecting d3d11va adapter %d\n", adapter);
 hr = mCreateDXGIFactory(_IDXGIFactory2, (void **));
 if (SUCCEEDED(hr)) {
-int adapter = atoi(device);
 if (FAILED(IDXGIFactory2_EnumAdapters(pDXGIFactory, adapter, 
)))
 pAdapter = NULL;
 IDXGIFactory2_Release(pDXGIFactory);
-- 
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 11/13] avformat/demux: support inserting bitstream filters in demuxing scenarios

[Gyan Doshi]

On 2023-11-28 12:13 am, James Almer wrote:

Packets will be passed to the bsf immediately after being generated by a
demuxer, and no further data will be read from the input until all packets
have been returned by the bsf.


Do you plan to add a lib/cli option for user-specified insertions?
Will be useful for something like dts2pts in some cases.

Regards,
Gyan




Signed-off-by: James Almer 
---
  libavformat/avformat.c |  47 
  libavformat/demux.c| 162 ++---
  libavformat/internal.h |  13 +++-
  libavformat/mux.c  |  43 ---
  libavformat/mux.h  |  11 ---
  libavformat/rawenc.c   |   1 +
  6 files changed, 181 insertions(+), 96 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index a02ec965dd..a41c0b391c 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -1033,3 +1033,50 @@ FF_ENABLE_DEPRECATION_WARNINGS
  *pb = NULL;
  return ret;
  }
+
+int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char 
*args)
+{
+int ret;
+const AVBitStreamFilter *bsf;
+FFStream *const sti = ffstream(st);
+AVBSFContext *bsfc;
+
+av_assert0(!sti->bsfc);
+
+if (name) {
+bsf = av_bsf_get_by_name(name);
+if (!bsf) {
+av_log(NULL, AV_LOG_ERROR, "Unknown bitstream filter '%s'\n", 
name);
+return AVERROR_BSF_NOT_FOUND;
+}
+ret = av_bsf_alloc(bsf, );
+} else
+ret = av_bsf_get_null_filter();
+if (ret < 0)
+return ret;
+
+bsfc->time_base_in = st->time_base;
+if ((ret = avcodec_parameters_copy(bsfc->par_in, st->codecpar)) < 0) {
+av_bsf_free();
+return ret;
+}
+
+if (args && bsfc->filter->priv_class) {
+if ((ret = av_set_options_string(bsfc->priv_data, args, "=", ":")) < 
0) {
+av_bsf_free();
+return ret;
+}
+}
+
+if ((ret = av_bsf_init(bsfc)) < 0) {
+av_bsf_free();
+return ret;
+}
+
+sti->bsfc = bsfc;
+
+av_log(NULL, AV_LOG_VERBOSE,
+   "Automatically inserted bitstream filter '%s'; args='%s'\n",
+   name, args ? args : "");
+return 1;
+}
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..fb9bf9e4ac 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -540,6 +540,109 @@ static int update_wrap_reference(AVFormatContext *s, 
AVStream *st, int stream_in
  return 1;
  }
  
+static void update_timestamps(AVFormatContext *s, AVStream *st, AVPacket *pkt)

+{
+FFStream *const sti = ffstream(st);
+
+if (update_wrap_reference(s, st, pkt->stream_index, pkt) && 
sti->pts_wrap_behavior == AV_PTS_WRAP_SUB_OFFSET) {
+// correct first time stamps to negative values
+if (!is_relative(sti->first_dts))
+sti->first_dts = wrap_timestamp(st, sti->first_dts);
+if (!is_relative(st->start_time))
+st->start_time = wrap_timestamp(st, st->start_time);
+if (!is_relative(sti->cur_dts))
+sti->cur_dts = wrap_timestamp(st, sti->cur_dts);
+}
+
+pkt->dts = wrap_timestamp(st, pkt->dts);
+pkt->pts = wrap_timestamp(st, pkt->pts);
+
+force_codec_ids(s, st);
+
+/* TODO: audio: time filter; video: frame reordering (pts != dts) */
+if (s->use_wallclock_as_timestamps)
+pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q, 
st->time_base);
+}
+
+static int filter_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFFormatContext *const si = ffformatcontext(s);
+FFStream *const sti = ffstream(st);
+const AVPacket *pkt1;
+int err;
+
+if (!sti->bsfc) {
+const PacketListEntry *pktl = si->raw_packet_buffer.head;
+if (AVPACKET_IS_EMPTY(pkt))
+return 0;
+
+update_timestamps(s, st, pkt);
+
+if (!pktl && sti->request_probe <= 0)
+return 0;
+
+err = avpriv_packet_list_put(>raw_packet_buffer, pkt, NULL, 0);
+if (err < 0) {
+av_packet_unref(pkt);
+return err;
+}
+
+pkt1 = >raw_packet_buffer.tail->pkt;
+si->raw_packet_buffer_size += pkt1->size;
+
+if (sti->request_probe <= 0)
+return 0;
+
+return probe_codec(s, s->streams[pkt1->stream_index], pkt1);
+}
+
+err = av_bsf_send_packet(sti->bsfc, pkt);
+if (err < 0) {
+av_log(s, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d\n",
+sti->bsfc->filter->name, st->index);
+return err;
+}
+
+do {
+AVStream *out_st;
+FFStream *out_sti;
+
+err = av_bsf_receive_packet(sti->bsfc, pkt);
+if (err < 0) {
+if (err == AVERROR(EAGAIN) || err == AVERROR_EOF)
+return 0;
+av_log(s, AV_LOG_ERROR, "Error applying bitstream filters to an output 
"
+   "packet for stream #%d: %s\n", st->index, 

Re: [FFmpeg-devel] [PATCH v1] lavc/vaapi_encode_av1: Add qp option explicitly to set base q index

[Xiang, Haihao]

On Ma, 2023-11-27 at 13:36 +, Mark Thompson wrote:
> On 27/11/2023 00:58, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang 
> > 
> > Keep same way with librav1e/libsvtav1/qsv_av1.. to make it more
> > acceptable instead of using global option "-global_quality".
> > 
> > Fix #10615
> > 
> > Signed-off-by: Fei Wang 
> > ---
> >   doc/encoders.texi | 1 +
> >   libavcodec/vaapi_encode_av1.c | 6 ++
> >   2 files changed, 7 insertions(+)
> > 
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 27a9acf076..2cffc32daf 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -4079,6 +4079,7 @@ Each encoder also has its own specific options:
> >   @table @option
> >   
> >   @item av1_vaapi
> > +@option{qp} sets the value of @emph{base_q_index}.
> >   @option{profile} sets the value of @emph{seq_profile}.
> >   @option{tier} sets the value of @emph{seq_tier}.
> >   @option{level} sets the value of @emph{seq_level_idx}.
> > diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
> > index 5a9ff0f798..2e327fec5a 100644
> > --- a/libavcodec/vaapi_encode_av1.c
> > +++ b/libavcodec/vaapi_encode_av1.c
> > @@ -79,6 +79,7 @@ typedef struct VAAPIEncodeAV1Context {
> >   int cdef_param_size;
> >   
> >   /** user options */
> > +    int qp;
> >   int profile;
> >   int level;
> >   int tier;
> > @@ -786,6 +787,9 @@ static av_cold int vaapi_encode_av1_init(AVCodecContext
> > *avctx)
> >   return AVERROR(EINVAL);
> >   }
> >   
> > +    if (priv->qp > 0)
> > +    ctx->explicit_qp = priv->qp;
> > +
> >   ret = ff_vaapi_encode_init(avctx);
> >   if (ret < 0)
> >   return ret;
> > @@ -864,6 +868,8 @@ static av_cold int vaapi_encode_av1_close(AVCodecContext
> > *avctx)
> >   static const AVOption vaapi_encode_av1_options[] = {
> >   VAAPI_ENCODE_COMMON_OPTIONS,
> >   VAAPI_ENCODE_RC_OPTIONS,
> > +    { "qp", "Base q index (for P-frames; scaled by qfactor/qoffset for
> > I/B)",
> > +  OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 255, FLAGS },
> >   { "profile", "Set profile (seq_profile)",
> >     OFFSET(profile), AV_OPT_TYPE_INT,
> >     { .i64 = AV_PROFILE_UNKNOWN }, AV_PROFILE_UNKNOWN, 0xff, FLAGS,
> > "profile" },
> 
> Disagree; QP is not a concept in AV1. 

Yes, it not a concept in AV1.

nvenc h264/hevc/av1 encoders provide the same qp option:

libavcodec/nvenc_av1.c:{ "qp",   "Constant quantization parameter
rate control method",
libavcodec/nvenc_h264.c:{ "qp",   "Constant quantization parameter
rate control method",
libavcodec/nvenc_hevc.c:{ "qp",   "Constant quantization parameter
rate control method",

May we provide the same qp option for vaapi h264/hevc/av1 encoders too? User
will be able to use same options when using these encoders.

Thanks
Haihao


>  Further, your examples from other encoders do not have a consistent view of
> what it should mean.
> 
> librav1e.c:
> 
>  { "qp", "use constant quantizer mode", OFFSET(quantizer),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, VE },
> 
> 0-255 is presumably the base_q_idx scale.
> 
> libsvtav1.c:
> 
>  { "qp", "Initial Quantizer level value", OFFSET(qp), 
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 63, VE },
> 
> 0-63 is presumably the H.26x-qp-ish scale used by some VP9/AV1 encoders which
> maps nonlinearly to the internal scale.
> 
> qsv_av1 doesn't seem to have such an option.
> 
> Thanks,
> 
> - Mark
> ___
> 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".

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: ignore nonexistent device in default DRM device selection

[Xiang, Haihao]

> Quoting Xiang, Haihao (2023-11-27 05:42:20)
> > > 
> > > Also, the else is unnecessary since the if() block ends with continue.
> > > 
> > 
> > I wanted to print a message if all devices don't exist. I'll remove it in
> > the
> > new version if you think such info is unnecessary. 
> 
> I don't object to the message, I mean just that
> 
> if (foo) {
>   
>   continue;
> } else
>   bar;
> 
> is equivalent to
> 
> if (foo) {
>   
>   continue;
> }
> 
> bar;
> 
> The latter saves you one level of indentation and I find it more
> readable.

I got your point, many thanks for your explanations. 

BRs
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".

Re: [FFmpeg-devel] [PATCH 1/2] lavc/cbs_h265: Add sps_multilayer_extension support

[myp...@gmail.com]

On Tue, Nov 28, 2023 at 1:59 AM Mark Thompson  wrote:
>
> On 17/11/2023 13:03, Jun Zhao wrote:
> > Add sps_multilayer_extensio support.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >   libavcodec/cbs_h265.h |  3 +++
> >   libavcodec/cbs_h265_syntax_template.c | 12 +++-
> >   2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
> > index 1b1195f198..15951269fd 100644
> > --- a/libavcodec/cbs_h265.h
> > +++ b/libavcodec/cbs_h265.h
> > @@ -330,6 +330,9 @@ typedef struct H265RawSPS {
> >   uint8_t persistent_rice_adaptation_enabled_flag;
> >   uint8_t cabac_bypass_alignment_enabled_flag;
> >
> > +// Multilayer extension.
> > +uint8_t inter_view_mv_vert_constraint_flag;
> > +
> >   // Screen content coding extension.
> >   uint8_t sps_curr_pic_ref_enabled_flag;
> >   uint8_t palette_mode_enabled_flag;
> > diff --git a/libavcodec/cbs_h265_syntax_template.c 
> > b/libavcodec/cbs_h265_syntax_template.c
> > index 2d4b954718..1e3bc1acd8 100644
> > --- a/libavcodec/cbs_h265_syntax_template.c
> > +++ b/libavcodec/cbs_h265_syntax_template.c
> > @@ -717,6 +717,16 @@ static int 
> > FUNC(sps_range_extension)(CodedBitstreamContext *ctx, RWContext *rw,
> >   return 0;
> >   }
> >
> > +static int FUNC(sps_multilayer_extension)(CodedBitstreamContext *ctx, 
> > RWContext *rw,
> > +  H265RawSPS *current)
> > +{
> > +int err;
> > +
> > +flag(inter_view_mv_vert_constraint_flag);
> > +
> > +return 0;
> > +}
> > +
> >   static int FUNC(sps_scc_extension)(CodedBitstreamContext *ctx, RWContext 
> > *rw,
> >  H265RawSPS *current)
> >   {
> > @@ -952,7 +962,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
> > RWContext *rw,
> >   if (current->sps_range_extension_flag)
> >   CHECK(FUNC(sps_range_extension)(ctx, rw, current));
> >   if (current->sps_multilayer_extension_flag)
> > -return AVERROR_PATCHWELCOME;
> > +CHECK(FUNC(sps_multilayer_extension)(ctx, rw, current));
> >   if (current->sps_3d_extension_flag)
> >   return AVERROR_PATCHWELCOME;
> >   if (current->sps_scc_extension_flag)
>
> This doesn't seem like it it sufficient - when in multilayer the SPS format 
> isn't the same (§F.7.3.2.2.1).
>
> Alternatively: maybe this works for the first layer (haven't verified this 
> but seems plausible), and therefore to work there only it would be sufficient 
> to check if MultiLayerExtSpsFlag is true in an SPS and stop if it is?
>
Actually, this case is from MV-HEVC, and I didn't find any other real
examples like the Spec  above
> (A sample suitable for using with fate would help.)
>
Will add a new MV-HEVC fate test case
> Thanks,
>
> - Mark
___
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] fate.sh: Allow overriding what targets to make for running the tests

[Michael Niedermayer]

On Mon, Nov 27, 2023 at 05:46:40PM +0200, Rémi Denis-Courmont wrote:
[...]
> Also FWIW, RV broke due to misaligned accesses and illegal vector types that
> QEMU tolerated. That is rather an argument against QEMU than against this MR 
> but still.

has someone reported this to qemu ?
(seems like a bug)

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: PGP signature
___
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] fate.sh: Allow overriding what targets to make for running the tests

[Alexander Strasser]

Hi Martin,

patch looks technically good to me.

On 2023-11-27 17:46 +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsjö a écrit :
> > This can be useful if doing testing of uncommon CPU extensions by
> > running tests with QEMU (by configuring with e.g.
> > "target_exec=qemu-aarch64"), by only running the checkasm tests,
> > to get a reasonable test coverage without excessive test runtime.
>
> For the purpose of testing future or bleeding-edge CPU extensions on emulator,
> you would normally want to be able to actually filter those in. That is more 
> of
> a matter of patching checkasm than FATE.
>
> Considering the poor coverage of checkasm, I fear that this just gives the
> wrong impression, not to say a false sense of security. It feels misleading to
> encourage or support that paradigm into FATE, in light of that poor coverage.
> Afterall, if it's just about running checkasm, anybody can just run
> `make tests/checkasm/checkasm && tests/checkasm/checkasm`.

Agree, the practice should not be encouraged over cases where it is
necessary to be practical, but having fate clients run the tests and
submit the results seems still worthwhile to me.

We shouldn't get a false sense of security and it can be a problem.
Improving checkasm and qemu and maybe getting actual bleeding edge
hardware into fate could help with that. Not saying it is easy or
effortless...

Still having tests run and some failures detected seems better
than nothing to me. It would be only problematic if the false
positives or negatives weigh out the cases where it is helpful.

@Remi: Please take no offense. This does not look like a black
and white issue to me , thus I wanted to voice what I thought
when initially saw the patch and your response.


Best regards,
  Alexander


> Either way, this feels like a case of cart before horse.
>
> Also FWIW, RV broke due to misaligned accesses and illegal vector types that
> QEMU tolerated. That is rather an argument against QEMU than against this MR
> but still.
___
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] fate.sh: Allow overriding what targets to make for running the tests

[Martin Storsjö]

On Mon, 27 Nov 2023, Rémi Denis-Courmont wrote:


Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsjö a écrit :

This can be useful if doing testing of uncommon CPU extensions by
running tests with QEMU (by configuring with e.g.
"target_exec=qemu-aarch64"), by only running the checkasm tests,
to get a reasonable test coverage without excessive test runtime.


For the purpose of testing future or bleeding-edge CPU extensions on 
emulator, you would normally want to be able to actually filter those 
in. That is more of a matter of patching checkasm than FATE.


Sorry, can you elaborate on what you mean with "filter those in" here?

Considering the poor coverage of checkasm, I fear that this just gives 
the wrong impression, not to say a false sense of security. It feels 
misleading to encourage or support that paradigm into FATE, in light of 
that poor coverage. Afterall, if it's just about running checkasm, 
anybody can just run `make tests/checkasm/checkasm && 
tests/checkasm/checkasm`.


Yes, anybody can run that - but having those results posted continuously 
somewhere where other can see them can be valuable as well.


Anyway, the concrete case I'm considering, is that we've got AArch64 code 
merged, that uses the I8MM extensions. We don't have any FATE 
configuration that continuously test that. Whenever there are patches, I 
do spin up a cloud instance that supports this extension and test the 
patches there, but inbetween that we're pretty much blind.


While checkasm's coverage isn't fantastic, for this particular case I'm 
not merging any AArch64 code for new extensions unless that code is 
covered by checkasm.


The other AArch64 feature that we do have code for, which also is 
untested, is the assembly support for branch protection and pointer 
authentication. Also this is testable pretty easily with QEMU. It's of 
course more interesting to run the full fate suite, but if we're not 
looking for bugs in the compiler but only for bugs in our assembly, then 
checkasm should cover most of it.


Yes there's potential for QEMU bugs hiding real issues, but I'd rather 
have a regular run of QEMU+checkasm than not have it tested at all. And 
I'm volunteering HW+time for testing these cases with QEMU for whatever 
checkasm covers, but I'm not volunteering it for full fate runs with QEMU.


And sure, I can just run such configs privately, as I already do run a 
bunch of various regular builds for projects I care about - but as we do 
have FATE with the public status page, hooking it up to be reported there 
would feel like added value for everybody.


// 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 10 bit support v5 1/3] avcodec/amfenc: Fixes the color information in the output.

[Mark Thompson]

On 31/10/2023 18:57, Evgeny Pavlov wrote:

From: Michael Fabian 'Xaymar' Dirks 

added 10 bit support for amf hevc.

before:

command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format 
d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
output -  Format of input frames context (p010le) is not supported by AMF.
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format 
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output -  Format of input frames context (p010le) is not supported by AMF.

after:

command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format 
d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
output -  10-bit input video is not supported by AMF H264 encoder
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format 
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output -  10bit file

v2 - lost line returned in ff_amf_pix_fmts
v3 - fixes after review
v4 - extract duplicated code, fix incorrect processing of 10-bit input for h264
v5 - non-functional changes after review

Co-authored-by: Evgeny Pavlov 
---
  libavcodec/amfenc.c  | 37 +
  libavcodec/amfenc.h  |  3 +++
  libavcodec/amfenc_h264.c | 24 
  libavcodec/amfenc_hevc.c | 26 +-
  4 files changed, 85 insertions(+), 5 deletions(-)


There is something very wrong with how the header information is working here.

With this series applied, I ran:

ffmpeg_g.exe -report -y -i in.mp4 -an -c:v hevc_amf -bsf:v trace_headers 
-frames:v 1 out.mp4

My input file is:

  Stream #0:0[0x1](und), 60, 1/6: Video: hevc (Main 10) (hvc1 / 
0x31637668), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 
16:9], 74462 kb/s, 59.94 fps, 59.94 tbr, 60k tbn (default)

[trace_headers @ 023184c753c0] Extradata
[trace_headers @ 023184c753c0] Sequence Parameter Set
...
[trace_headers @ 023184c753c0] 222 vui_parameters_present_flag  
   0 = 0

So no colour information at all in the headers, and the output file indeed says:

  Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), 
yuv420p10le(tv, progressive), 3840x2160, 977 kb/s, SAR 1:1 DAR 16:9, 59.94 fps, 
59.94 tbr, 60k tbn (default)

However!  Reading further:

[trace_headers @ 023184c753c0] Packet: 2039 bytes, key frame, pts 0, dts 0.
...
[trace_headers @ 023184c753c0] Sequence Parameter Set
...
[trace_headers @ 023184c753c0] 222 vui_parameters_present_flag  
   1 = 1
[trace_headers @ 023184c753c0] 223 aspect_ratio_info_present_flag   
   1 = 1
[trace_headers @ 023184c753c0] 224 aspect_ratio_idc 
 = 255
[trace_headers @ 023184c753c0] 232 sar_width
0001 = 1
[trace_headers @ 023184c753c0] 248 sar_height   
0001 = 1
[trace_headers @ 023184c753c0] 264 overscan_info_present_flag   
   0 = 0
[trace_headers @ 023184c753c0] 265 video_signal_type_present_flag   
   1 = 1
[trace_headers @ 023184c753c0] 266 video_format 
 101 = 5
[trace_headers @ 023184c753c0] 269 video_full_range_flag
   0 = 0
[trace_headers @ 023184c753c0] 270 colour_description_present_flag  
   1 = 1
[trace_headers @ 023184c753c0] 271 colour_primaries 
1001 = 9
[trace_headers @ 023184c753c0] 279 transfer_characteristics 
0001 = 16
[trace_headers @ 023184c753c0] 287 matrix_coefficients  
1001 = 9
[trace_headers @ 023184c753c0] 295 chroma_loc_info_present_flag 
   0 = 0
[trace_headers @ 023184c753c0] 296 neutral_chroma_indication_flag   
   0 = 0
[trace_headers @ 023184c753c0] 297 field_seq_flag   
   0 = 0
[trace_headers @ 023184c753c0] 298 frame_field_info_present_flag
   0 = 0
[trace_headers @ 023184c753c0] 299 default_display_window_flag  
   0 = 0
[trace_headers @ 023184c753c0] 300 vui_timing_info_present_flag 
   1 = 1
[trace_headers @ 023184c753c0] 301 vui_num_units_in_tick
00101001 = 1001
[trace_headers @ 023184c753c0] 333 vui_time_scale   
111010100110 = 6
[trace_headers @ 023184c753c0] 365 

[FFmpeg-devel] [PATCH 13/13] avformat/mov: add support for Immersive Audio Model and Formats in ISOBMFF

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/Makefile |   3 +-
 libavformat/isom.h   |   6 +
 libavformat/mov.c| 290 +++
 3 files changed, 272 insertions(+), 27 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 521bf5fef6..0272311828 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -364,7 +364,8 @@ OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
 OBJS-$(CONFIG_MODS_DEMUXER)  += mods.o
 OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
 OBJS-$(CONFIG_MOV_DEMUXER)   += mov.o mov_chan.o mov_esds.o \
-qtpalette.o replaygain.o 
dovi_isom.o
+qtpalette.o replaygain.o 
dovi_isom.o \
+iamf.o
 OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o 
\
 movenchint.o mov_chan.o rtp.o \
 movenccenc.o movenc_ttml.o 
rawutils.o \
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 3d375d7a46..32d42490b5 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -33,6 +33,7 @@
 #include "libavutil/stereo3d.h"
 
 #include "avio.h"
+#include "iamf.h"
 #include "internal.h"
 #include "dv.h"
 
@@ -166,6 +167,7 @@ typedef struct MOVIndexRange {
 typedef struct MOVStreamContext {
 AVIOContext *pb;
 int pb_is_copied;
+int id;   ///< AVStream id
 int ffindex;  ///< AVStream index
 int next_chunk;
 unsigned int chunk_count;
@@ -260,6 +262,10 @@ typedef struct MOVStreamContext {
 AVEncryptionInfo *default_encrypted_sample;
 MOVEncryptionIndex *encryption_index;
 } cenc;
+
+IAMFContext *iamf;
+uint8_t *iamf_descriptors;
+int iamf_descriptors_size;
 } MOVStreamContext;
 
 typedef struct MOVContext {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d1f214a441..11c68a2f6e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -59,6 +59,7 @@
 #include "internal.h"
 #include "avio_internal.h"
 #include "demux.h"
+#include "iamf.h"
 #include "dovi_isom.h"
 #include "riff.h"
 #include "isom.h"
@@ -851,6 +852,163 @@ static int mov_read_dac3(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_iamf(MOVContext *c, AVIOContext *pb, int64_t size)
+{
+AVStream *st;
+MOVStreamContext *sc;
+FFIOContext b;
+AVIOContext *descriptor_pb;
+AVDictionary *metadata;
+IAMFContext *iamf;
+char args[32];
+int64_t start_time, duration;
+int nb_frames, disposition;
+int ret;
+
+if ((int)size != size)
+return AVERROR(ENOMEM);
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = mov_get_stream_context(st);
+
+metadata = st->metadata;
+st->metadata = NULL;
+start_time = st->start_time;
+nb_frames = st->nb_frames;
+duration = st->duration;
+disposition = st->disposition;
+
+iamf = sc->iamf = av_mallocz(sizeof(*iamf));
+if (!iamf) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+sc->iamf_descriptors = av_malloc(size);
+if (!sc->iamf_descriptors) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+sc->iamf_descriptors_size = size;
+ret = avio_read(pb, sc->iamf_descriptors, size);
+if (ret != size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+ffio_init_context(, sc->iamf_descriptors, size, 0, NULL, NULL, NULL, 
NULL);
+descriptor_pb = 
+
+ret = ff_iamfdec_read_descriptors(iamf, descriptor_pb, size, c->fc);
+if (ret < 0)
+goto fail;
+
+for (int i = 0; i < iamf->nb_audio_elements; i++) {
+IAMFAudioElement *audio_element = >audio_elements[i];
+AVStreamGroup *stg = avformat_stream_group_create(c->fc, 
AV_STREAM_GROUP_PARAMS_IAMF_AUDIO_ELEMENT, NULL);
+
+if (!stg) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+stg->id = audio_element->audio_element_id;
+stg->params.iamf_audio_element = audio_element->element;
+audio_element->element = NULL;
+
+for (int j = 0; j < audio_element->nb_substreams; j++) {
+IAMFSubStream *substream = _element->substreams[j];
+AVStream *stream;
+
+if (!i && !j)
+stream = st;
+else
+stream = avformat_new_stream(c->fc, NULL);
+if (!stream) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+stream->start_time = start_time;
+stream->nb_frames = nb_frames;
+stream->duration = duration;
+stream->disposition = disposition;
+if (stream != st && !(stream->priv_data = 
av_buffer_ref(st->priv_data))) {
+ret = AVERROR(ENOMEM);
+

[FFmpeg-devel] [PATCH 12/13] avformat/mov: make MOVStreamContext refcounted

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/mov.c | 257 ++
 1 file changed, 145 insertions(+), 112 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 34ca8095c2..d1f214a441 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -31,6 +31,7 @@
 
 #include "libavutil/attributes.h"
 #include "libavutil/bprint.h"
+#include "libavutil/buffer.h"
 #include "libavutil/channel_layout.h"
 #include "libavutil/dict_internal.h"
 #include "libavutil/internal.h"
@@ -184,10 +185,20 @@ static int mov_read_mac_string(MOVContext *c, AVIOContext 
*pb, int len,
 return p - dst;
 }
 
+static void mov_free_stream_context(void *opaque, uint8_t *data);
+
+static inline MOVStreamContext *mov_get_stream_context(const AVStream *st)
+{
+AVBufferRef *buf = st->priv_data;
+
+return (MOVStreamContext *)buf->data;
+}
+
 static int mov_read_covr(MOVContext *c, AVIOContext *pb, int type, int len)
 {
 AVStream *st;
-MOVStreamContext *sc;
+AVBufferRef *buf;
+uint8_t *data;
 enum AVCodecID id;
 int ret;
 
@@ -201,16 +212,22 @@ static int mov_read_covr(MOVContext *c, AVIOContext *pb, 
int type, int len)
 return 0;
 }
 
-sc = av_mallocz(sizeof(*sc));
-if (!sc)
+data = av_mallocz(sizeof(MOVStreamContext));
+if (!data)
+return AVERROR(ENOMEM);
+buf = av_buffer_create(data, sizeof(MOVStreamContext), 
mov_free_stream_context, c->fc, 0);
+if (!buf) {
+av_free(data);
 return AVERROR(ENOMEM);
+}
+
 ret = ff_add_attached_pic(c->fc, NULL, pb, NULL, len);
 if (ret < 0) {
-av_free(sc);
+av_buffer_unref();
 return ret;
 }
 st = c->fc->streams[c->fc->nb_streams - 1];
-st->priv_data = sc;
+st->priv_data = buf;
 
 if (st->attached_pic.size >= 8 && id != AV_CODEC_ID_BMP) {
 if (AV_RB64(st->attached_pic.data) == 0x89504e470d0a1a0a) {
@@ -590,7 +607,7 @@ static int mov_read_dref(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 if (c->fc->nb_streams < 1)
 return 0;
 st = c->fc->streams[c->fc->nb_streams-1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 avio_rb32(pb); // version + flags
 entries = avio_rb32(pb);
@@ -1369,7 +1386,7 @@ static int64_t get_frag_time(AVFormatContext *s, AVStream 
*dst_st,
  MOVFragmentIndex *frag_index, int index)
 {
 MOVFragmentStreamInfo * frag_stream_info;
-MOVStreamContext *sc = dst_st->priv_data;
+MOVStreamContext *sc = mov_get_stream_context(dst_st);
 int64_t timestamp;
 int i, j;
 
@@ -1567,7 +1584,7 @@ static int mov_read_mdhd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 if (c->fc->nb_streams < 1)
 return 0;
 st = c->fc->streams[c->fc->nb_streams-1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 if (sc->time_scale) {
 av_log(c->fc, AV_LOG_ERROR, "Multiple mdhd?\n");
@@ -1710,7 +1727,7 @@ static int mov_read_pcmc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return AVERROR_INVALIDDATA;
 
 st = fc->streams[fc->nb_streams - 1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 if (sc->format == MOV_MP4_FPCM_TAG) {
 switch (pcm_sample_size) {
@@ -2213,7 +2230,7 @@ static int mov_read_stco(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 if (c->fc->nb_streams < 1)
 return 0;
 st = c->fc->streams[c->fc->nb_streams-1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 avio_r8(pb); /* version */
 avio_rb24(pb); /* flags */
@@ -2546,7 +2563,7 @@ static int mov_parse_stsd_data(MOVContext *c, AVIOContext 
*pb,
 if (ret < 0)
 return ret;
 if (size > 16) {
-MOVStreamContext *tmcd_ctx = st->priv_data;
+MOVStreamContext *tmcd_ctx = mov_get_stream_context(st);
 int val;
 val = AV_RB32(st->codecpar->extradata + 4);
 tmcd_ctx->tmcd_flags = val;
@@ -2712,7 +2729,7 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext 
*pb, int entries)
 
 av_assert0 (c->fc->nb_streams >= 1);
 st = c->fc->streams[c->fc->nb_streams-1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 for (pseudo_stream_id = 0;
  pseudo_stream_id < entries && !pb->eof_reached;
@@ -2810,7 +2827,7 @@ static int mov_read_stsd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 if (c->fc->nb_streams < 1)
 return 0;
 st = c->fc->streams[c->fc->nb_streams - 1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 sc->stsd_version = avio_r8(pb);
 avio_rb24(pb); /* flags */
@@ -2875,7 +2892,7 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 if (c->fc->nb_streams < 1)
 return 0;
 st = c->fc->streams[c->fc->nb_streams-1];
-sc = st->priv_data;
+sc = mov_get_stream_context(st);
 
 avio_r8(pb); /* version */
 avio_rb24(pb); /* flags */

[FFmpeg-devel] [PATCH 11/13] avformat/demux: support inserting bitstream filters in demuxing scenarios

[James Almer]

Packets will be passed to the bsf immediately after being generated by a
demuxer, and no further data will be read from the input until all packets
have been returned by the bsf.

Signed-off-by: James Almer 
---
 libavformat/avformat.c |  47 
 libavformat/demux.c| 162 ++---
 libavformat/internal.h |  13 +++-
 libavformat/mux.c  |  43 ---
 libavformat/mux.h  |  11 ---
 libavformat/rawenc.c   |   1 +
 6 files changed, 181 insertions(+), 96 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index a02ec965dd..a41c0b391c 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -1033,3 +1033,50 @@ FF_ENABLE_DEPRECATION_WARNINGS
 *pb = NULL;
 return ret;
 }
+
+int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char 
*args)
+{
+int ret;
+const AVBitStreamFilter *bsf;
+FFStream *const sti = ffstream(st);
+AVBSFContext *bsfc;
+
+av_assert0(!sti->bsfc);
+
+if (name) {
+bsf = av_bsf_get_by_name(name);
+if (!bsf) {
+av_log(NULL, AV_LOG_ERROR, "Unknown bitstream filter '%s'\n", 
name);
+return AVERROR_BSF_NOT_FOUND;
+}
+ret = av_bsf_alloc(bsf, );
+} else
+ret = av_bsf_get_null_filter();
+if (ret < 0)
+return ret;
+
+bsfc->time_base_in = st->time_base;
+if ((ret = avcodec_parameters_copy(bsfc->par_in, st->codecpar)) < 0) {
+av_bsf_free();
+return ret;
+}
+
+if (args && bsfc->filter->priv_class) {
+if ((ret = av_set_options_string(bsfc->priv_data, args, "=", ":")) < 
0) {
+av_bsf_free();
+return ret;
+}
+}
+
+if ((ret = av_bsf_init(bsfc)) < 0) {
+av_bsf_free();
+return ret;
+}
+
+sti->bsfc = bsfc;
+
+av_log(NULL, AV_LOG_VERBOSE,
+   "Automatically inserted bitstream filter '%s'; args='%s'\n",
+   name, args ? args : "");
+return 1;
+}
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..fb9bf9e4ac 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -540,6 +540,109 @@ static int update_wrap_reference(AVFormatContext *s, 
AVStream *st, int stream_in
 return 1;
 }
 
+static void update_timestamps(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFStream *const sti = ffstream(st);
+
+if (update_wrap_reference(s, st, pkt->stream_index, pkt) && 
sti->pts_wrap_behavior == AV_PTS_WRAP_SUB_OFFSET) {
+// correct first time stamps to negative values
+if (!is_relative(sti->first_dts))
+sti->first_dts = wrap_timestamp(st, sti->first_dts);
+if (!is_relative(st->start_time))
+st->start_time = wrap_timestamp(st, st->start_time);
+if (!is_relative(sti->cur_dts))
+sti->cur_dts = wrap_timestamp(st, sti->cur_dts);
+}
+
+pkt->dts = wrap_timestamp(st, pkt->dts);
+pkt->pts = wrap_timestamp(st, pkt->pts);
+
+force_codec_ids(s, st);
+
+/* TODO: audio: time filter; video: frame reordering (pts != dts) */
+if (s->use_wallclock_as_timestamps)
+pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q, 
st->time_base);
+}
+
+static int filter_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFFormatContext *const si = ffformatcontext(s);
+FFStream *const sti = ffstream(st);
+const AVPacket *pkt1;
+int err;
+
+if (!sti->bsfc) {
+const PacketListEntry *pktl = si->raw_packet_buffer.head;
+if (AVPACKET_IS_EMPTY(pkt))
+return 0;
+
+update_timestamps(s, st, pkt);
+
+if (!pktl && sti->request_probe <= 0)
+return 0;
+
+err = avpriv_packet_list_put(>raw_packet_buffer, pkt, NULL, 0);
+if (err < 0) {
+av_packet_unref(pkt);
+return err;
+}
+
+pkt1 = >raw_packet_buffer.tail->pkt;
+si->raw_packet_buffer_size += pkt1->size;
+
+if (sti->request_probe <= 0)
+return 0;
+
+return probe_codec(s, s->streams[pkt1->stream_index], pkt1);
+}
+
+err = av_bsf_send_packet(sti->bsfc, pkt);
+if (err < 0) {
+av_log(s, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d\n",
+sti->bsfc->filter->name, st->index);
+return err;
+}
+
+do {
+AVStream *out_st;
+FFStream *out_sti;
+
+err = av_bsf_receive_packet(sti->bsfc, pkt);
+if (err < 0) {
+if (err == AVERROR(EAGAIN) || err == AVERROR_EOF)
+return 0;
+av_log(s, AV_LOG_ERROR, "Error applying bitstream filters to an 
output "
+   "packet for stream #%d: %s\n", st->index, av_err2str(err));
+if (!(s->error_recognition & AV_EF_EXPLODE) && err != 
AVERROR(ENOMEM))
+continue;
+return err;
+}
+out_st = s->streams[pkt->stream_index];
+  

[FFmpeg-devel] [PATCH 10/13] avcodec: add an Immersive Audio Model and Formats frame split bsf

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/Makefile|   1 +
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/iamf_stream_split_bsf.c | 807 +
 3 files changed, 809 insertions(+)
 create mode 100644 libavcodec/iamf_stream_split_bsf.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 748806e702..a2c345570e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1245,6 +1245,7 @@ OBJS-$(CONFIG_HAPQA_EXTRACT_BSF)  += 
hapqa_extract_bsf.o hap.o
 OBJS-$(CONFIG_HEVC_METADATA_BSF)  += h265_metadata_bsf.o 
h265_profile_level.o \
  h2645data.o
 OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF)   += hevc_mp4toannexb_bsf.o
+OBJS-$(CONFIG_IAMF_STREAM_SPLIT_BSF)  += iamf_stream_split_bsf.o
 OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= imx_dump_header_bsf.o
 OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += media100_to_mjpegb_bsf.o
 OBJS-$(CONFIG_MJPEG2JPEG_BSF) += mjpeg2jpeg_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1e9a676a3d..640b821413 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -42,6 +42,7 @@ extern const FFBitStreamFilter ff_h264_redundant_pps_bsf;
 extern const FFBitStreamFilter ff_hapqa_extract_bsf;
 extern const FFBitStreamFilter ff_hevc_metadata_bsf;
 extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
+extern const FFBitStreamFilter ff_iamf_stream_split_bsf;
 extern const FFBitStreamFilter ff_imx_dump_header_bsf;
 extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
 extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
diff --git a/libavcodec/iamf_stream_split_bsf.c 
b/libavcodec/iamf_stream_split_bsf.c
new file mode 100644
index 00..28c8101719
--- /dev/null
+++ b/libavcodec/iamf_stream_split_bsf.c
@@ -0,0 +1,807 @@
+/*
+ * Copyright (c) 2023 James Almer 
+ *
+ * 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
+ */
+
+#include "libavutil/dict.h"
+#include "libavutil/opt.h"
+#include "libavformat/iamf.h"
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "get_bits.h"
+
+typedef struct ParamDefinition {
+AVIAMFParamDefinition *param;
+size_t param_size;
+int recon_gain_present_bitmask;
+} ParamDefinition;
+
+typedef struct IAMFSplitContext {
+AVClass *class;
+AVPacket *buffer_pkt;
+
+ParamDefinition *param_definitions;
+unsigned int nb_param_definitions;
+
+unsigned int *ids;
+int nb_ids;
+
+// AVOptions
+int first_index;
+
+// Packet side data
+AVIAMFParamDefinition *mix;
+size_t mix_size;
+AVIAMFParamDefinition *demix;
+size_t demix_size;
+AVIAMFParamDefinition *recon;
+size_t recon_size;
+} IAMFSplitContext;
+
+static int param_parse(AVBSFContext *ctx, GetBitContext *gb,
+   unsigned int param_definition_type,
+   ParamDefinition **out)
+{
+IAMFSplitContext *const c = ctx->priv_data;
+ParamDefinition *param_definition = NULL;
+AVIAMFParamDefinition *param;
+unsigned int parameter_id, parameter_rate, param_definition_mode;
+unsigned int duration = 0, constant_subblock_duration = 0, num_subblocks = 
0;
+size_t param_size;
+
+parameter_id = get_leb(gb);
+
+for (int i = 0; i < c->nb_param_definitions; i++)
+if (c->param_definitions[i].param->parameter_id == parameter_id) {
+param_definition = >param_definitions[i];
+break;
+}
+
+parameter_rate = get_leb(gb);
+param_definition_mode = get_bits(gb, 8) >> 7;
+
+if (param_definition_mode == 0) {
+duration = get_leb(gb);
+constant_subblock_duration = get_leb(gb);
+if (constant_subblock_duration == 0) {
+num_subblocks = get_leb(gb);
+} else
+num_subblocks = duration / constant_subblock_duration;
+}
+
+param = av_iamf_param_definition_alloc(param_definition_type, NULL, 
num_subblocks, NULL, _size);
+if (!param)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < num_subblocks; i++) {
+if (constant_subblock_duration == 0)
+get_leb(gb); // subblock_duration
+
+switch (param_definition_type) {
+case 

Re: [FFmpeg-devel] [PATCH] doc/filters: restore libvmaf option pool entry

[Kyle Swanson]

Hi,

On Mon, Nov 27, 2023 at 10:15 AM Gyan Doshi  wrote:
> Do you mean in the lib? Because in ffmpeg git master, in the wrapper,
> the option remains available and undeprecated.
>
> Regards,
> Gyan

Oops, you're right. Ignore everything I just said, sorry for the noise.

Thanks,
Kyle
___
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] doc/filters: restore libvmaf option pool entry

[Gyan Doshi]

On 2023-11-27 11:38 pm, Kyle Swanson wrote:

Hi,

On Mon, Nov 27, 2023 at 1:29 AM Gyan Doshi  wrote:

Will push soon.

This filter can take any number of models now, each defining their own
pooling methods. Looking at the docs now, I can see that it's not
clear how to do this, I'll need to send a patch on that. The global
`pool` option has been deprecated and removed already.


Do you mean in the lib? Because in ffmpeg git master, in the wrapper, 
the option remains available and undeprecated.


Regards,
Gyan

___
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] doc/filters: restore libvmaf option pool entry

[Kyle Swanson]

Hi,

On Mon, Nov 27, 2023 at 1:29 AM Gyan Doshi  wrote:
>
> Will push soon.

This filter can take any number of models now, each defining their own
pooling methods. Looking at the docs now, I can see that it's not
clear how to do this, I'll need to send a patch on that. The global
`pool` option has been deprecated and removed already.

Thanks,
Kyle
___
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] lavc/cbs_h265: Add sps_multilayer_extension support

[Mark Thompson]

On 17/11/2023 13:03, Jun Zhao wrote:

Add sps_multilayer_extensio support.

Signed-off-by: Jun Zhao 
---
  libavcodec/cbs_h265.h |  3 +++
  libavcodec/cbs_h265_syntax_template.c | 12 +++-
  2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index 1b1195f198..15951269fd 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -330,6 +330,9 @@ typedef struct H265RawSPS {
  uint8_t persistent_rice_adaptation_enabled_flag;
  uint8_t cabac_bypass_alignment_enabled_flag;
  
+// Multilayer extension.

+uint8_t inter_view_mv_vert_constraint_flag;
+
  // Screen content coding extension.
  uint8_t sps_curr_pic_ref_enabled_flag;
  uint8_t palette_mode_enabled_flag;
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 2d4b954718..1e3bc1acd8 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -717,6 +717,16 @@ static int FUNC(sps_range_extension)(CodedBitstreamContext 
*ctx, RWContext *rw,
  return 0;
  }
  
+static int FUNC(sps_multilayer_extension)(CodedBitstreamContext *ctx, RWContext *rw,

+  H265RawSPS *current)
+{
+int err;
+
+flag(inter_view_mv_vert_constraint_flag);
+
+return 0;
+}
+
  static int FUNC(sps_scc_extension)(CodedBitstreamContext *ctx, RWContext *rw,
 H265RawSPS *current)
  {
@@ -952,7 +962,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, RWContext 
*rw,
  if (current->sps_range_extension_flag)
  CHECK(FUNC(sps_range_extension)(ctx, rw, current));
  if (current->sps_multilayer_extension_flag)
-return AVERROR_PATCHWELCOME;
+CHECK(FUNC(sps_multilayer_extension)(ctx, rw, current));
  if (current->sps_3d_extension_flag)
  return AVERROR_PATCHWELCOME;
  if (current->sps_scc_extension_flag)


This doesn't seem like it it sufficient - when in multilayer the SPS format 
isn't the same (§F.7.3.2.2.1).

Alternatively: maybe this works for the first layer (haven't verified this but 
seems plausible), and therefore to work there only it would be sufficient to 
check if MultiLayerExtSpsFlag is true in an SPS and stop if it is?

(A sample suitable for using with fate would help.)

Thanks,

- Mark
___
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 02/25] avfilter: always call ff_default_query_formats

[Anton Khirnov]

Quoting Niklas Haas (2023-11-09 13:19:34)
> From: Niklas Haas 
> 
> Even if a query func is set. This is safe to do, because
> ff_default_query_formats is documented not to touch any filter lists
> that were already set by the query func.
> 
> The reason to do this is because it allows us to extend
> AVFilterFormatsConfig without having to touch every filter in existence.
> An alternative implementation of this commit would be to explicitly add
> a `ff_default_query_formats` call at the end of every query_formats
> function, but that would end up functionally equivalent to this change
> while touching a whole lot more code paths for no reason.
> 
> As a bonus, eliminates some code/logic duplication from this function.
> ---
>  libavfilter/avfiltergraph.c | 39 -
>  1 file changed, 12 insertions(+), 27 deletions(-)

Looks ok.

I'm also wondering whether we could/should now remove all
ff_default_query_formats() calls from the filters and make that function
filtergraph-only.

-- 
Anton Khirnov
___
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 04/25] fftools/ffmpeg_filter: don't clear buffersrc params

[Anton Khirnov]

Quoting Niklas Haas (2023-11-09 13:19:36)
> From: Niklas Haas 
> 
> This memset is bogus, it accomplishes nothing in the best case and
> regresses future additions to AVBufferSrcParameters in the worst case.
> ---
>  fftools/ffmpeg_filter.c | 3 ---
>  1 file changed, 3 deletions(-)

Looks very ok.

-- 
Anton Khirnov
___
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] fftools/ffplay_renderer: declare function argument as const

[Zhao Zhili]

> 在 2023年11月23日，下午10:38，Leo Izen  写道：
> 
> Declaring the function argument as const fixes a warning down the line
> that the const parameter is stripped. We don't modify this argument.
> 
> Signed-off-by: Leo Izen 
> ---
> fftools/ffplay_renderer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fftools/ffplay_renderer.c b/fftools/ffplay_renderer.c
> index a57e4980eb..45ca84fa95 100644
> --- a/fftools/ffplay_renderer.c
> +++ b/fftools/ffplay_renderer.c
> @@ -133,7 +133,7 @@ static const char *optional_device_exts[] = {
> "VK_MESA_video_decode_av1",
> };
> 
> -static inline int enable_debug(AVDictionary *opt)
> +static inline int enable_debug(const AVDictionary *opt)
> {
> AVDictionaryEntry *entry = av_dict_get(opt, "debug", NULL, 0);
> int debug = entry && strtol(entry->value, NULL, 10);
> --
> 2.42.1

Applied, thanks!

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email

___
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] fate.sh: Allow overriding what targets to make for running the tests

[Rémi Denis-Courmont]

Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsjö a écrit :
> This can be useful if doing testing of uncommon CPU extensions by
> running tests with QEMU (by configuring with e.g.
> "target_exec=qemu-aarch64"), by only running the checkasm tests,
> to get a reasonable test coverage without excessive test runtime.

For the purpose of testing future or bleeding-edge CPU extensions on emulator, 
you would normally want to be able to actually filter those in. That is more of 
a matter of patching checkasm than FATE.

Considering the poor coverage of checkasm, I fear that this just gives the 
wrong impression, not to say a false sense of security. It feels misleading to 
encourage or support that paradigm into FATE, in light of that poor coverage. 
Afterall, if it's just about running checkasm, anybody can just run
`make tests/checkasm/checkasm && tests/checkasm/checkasm`.

Either way, this feels like a case of cart before horse.

Also FWIW, RV broke due to misaligned accesses and illegal vector types that 
QEMU tolerated. That is rather an argument against QEMU than against this MR 
but still.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



___
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] [FOSDEM] Call For Participation: Open Media devroom

[Kieran Kunhya]

Dear FFmpeg community.
Please see FOSDEM Open Media Devroom invite:

Hey all,

The Open Media devroom returns at FOSDEM 2024, and we are looking for
propositions of talks and panels. FOSDEM is one of the largest (8,000+
hackers!) gatherings of Free and Open Source Software contributors in
the world and happens every February in Brussels (Belgium, Europe).

This year, the Open Media devroom will take place in-person on:
Sunday, February 4th, 2024.


# About the Open Media devroom

The Open Media room will focus on all Free & Open Source media
projects, including software and hardware, spanning from building
audio & video applications, through standards, formats, codecs, video
analytics and search to Web video, IPTV, broadcasting and radio
practices and much more. If you're interested in video, image or audio
technologies, and the breadth of available open source technologies
and communities for media - the Open Media room is for you!

For more information about the previous year
sessions:https://archive.fosdem.org/2023/schedule/track/open_media/


# CFP Guidelines

The deadline for submission is: December 14th, 2023.

* To submit your proposal, visit: https://pretalx.fosdem.org/fosdem-2024/cfp

* IMPORTANT: Please make sure to select "Open Media" track for your submission.

* Your submission must include the following information
- The title and subtitle of your talk (please be descriptive).
- A short single paragraph detailing what the talk will discuss, and
why attendees should attend it.
- A longer description if you have more details to share.
- Links to related material/websites/blogs etc.
- A biography of yourself.
- If you have a complicated schedule (plane to catch, other talk...)
or need an invitation for a visa, please tell us in the submission
notes and we will try to accommodate.

* You can submit a session of one of the following formats:
- lightning talk (10 minutes incl. questions),
- regular talk (25 minutes incl. questions),
- workshop (40 minutes or more)

* Selected talks will be notified by December 15th 2023.

* All sessions will be recorded and be made available under CC-BY
licence by FOSDEM at https://video.fosdem.org/ .

* You have to be present in Brussels in-person on Sunday, February 4th, 2024.


# Community

The official communication channel is the Open Media devroom
mailing-list. Join the list
at:https://lists.fosdem.org/listinfo/open-media-devroom
You can also find us on IRC at #fosdem-open-media on libera.chat

And please don't hesitate to contact us for more information!

Jaron, Jean-Baptiste and Kieran,
On behalf of the Open Media devroom
___
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 3/3] fate/jpegxl: add parser test for extboxes and small files

[Leo Izen]

Add a fate test for the above commits fixing extremely small files or
files with extended box sizes.

Signed-off-by: Leo Izen 
---
 tests/fate/jxl.mak   | 8 
 tests/ref/fate/jxl-small-ext-box | 9 +
 2 files changed, 17 insertions(+)
 create mode 100644 tests/ref/fate/jxl-small-ext-box

diff --git a/tests/fate/jxl.mak b/tests/fate/jxl.mak
index 057d3be0e1..d653eb644a 100644
--- a/tests/fate/jxl.mak
+++ b/tests/fate/jxl.mak
@@ -14,3 +14,11 @@ FATE_JPEGXL_ANIM_DEMUX += $(FATE_JPEGXL_ANIM_DEMUX-yes)
 
 FATE_SAMPLES_FFMPEG-$(call FRAMECRC, JPEGXL_ANIM) += $(FATE_JPEGXL_ANIM_DEMUX)
 fate-jxl-anim-demux: $(FATE_JPEGXL_ANIM_DEMUX)
+
+# parser tests
+FATE_JPEGXL_PARSE += fate-jxl-small-ext-box
+fate-jxl-small-ext-box: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/l.jxl -c copy
+
+FATE_JPEGXL_PARSE += $(FATE_JPEGXL_PARSE-yes)
+FATE_SAMPLES_FFMPEG-$(call FRAMECRC, IMAGE_JPEGXL_PIPE, , JPEGXL_PARSER) += 
$(FATE_JPEGXL_PARSE)
+fate-jxl-parse: $(FATE_JPEGXL_PARSE)
diff --git a/tests/ref/fate/jxl-small-ext-box b/tests/ref/fate/jxl-small-ext-box
new file mode 100644
index 00..0f9adfe075
--- /dev/null
+++ b/tests/ref/fate/jxl-small-ext-box
@@ -0,0 +1,9 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: jpegxl
+#dimensions 0: 8x8
+#sar 0: 0/1
+0,  0,  0,1,  104, 0xd12d1d10
+0,  1,  1,1,  104, 0xd12d1d10
+0,  2,  2,1,  104, 0xd12d1d10
+0,  3,  3,1,  104, 0xd12d1d10
-- 
2.43.0

___
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 2/3] avcodec/jpegxl_parser: fix parsing sequences of extremely small files

[Leo Izen]

This patch allows the JXL parser to parse sequences of extremely small
files concatenated together. (e.g. smaller than the parser buffer)

Signed-off-by: Leo Izen 
---
 libavcodec/jpegxl_parser.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 750872f17f..006eb6b295 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1454,15 +1454,21 @@ static int jpegxl_parse(AVCodecParserContext *s, 
AVCodecContext *avctx,
 {
 JXLParseContext *ctx = s->priv_data;
 int next = END_NOT_FOUND, ret;
+const uint8_t *pbuf = ctx->pc.buffer;
+int pindex = ctx->pc.index;
 
 *poutbuf_size = 0;
 *poutbuf = NULL;
 
-if (!ctx->pc.index)
-goto flush;
+if (!ctx->pc.index) {
+if (ctx->pc.overread)
+goto flush;
+pbuf = buf;
+pindex = buf_size;
+}
 
 if ((!ctx->container || !ctx->codestream_length) && !ctx->next) {
-ret = try_parse(s, avctx, ctx, ctx->pc.buffer, ctx->pc.index);
+ret = try_parse(s, avctx, ctx, pbuf, pindex);
 if (ret < 0)
 goto flush;
 ctx->next = ret;
@@ -1471,7 +1477,7 @@ static int jpegxl_parse(AVCodecParserContext *s, 
AVCodecContext *avctx,
 }
 
 if (ctx->container && ctx->next >= 0) {
-ret = skip_boxes(ctx, ctx->pc.buffer, ctx->pc.index);
+ret = skip_boxes(ctx, pbuf, pindex);
 if (ret < 0) {
 if (ret == AVERROR_INVALIDDATA)
 ctx->next = -1;
-- 
2.43.0

___
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 1/3] avcodec/jpegxl_parse{, r}: use correct ISOBMFF extended size location

[Leo Izen]

According to ISO/IEC 14996-12, size == 1 means a 64-bit extended-size
field occurs *after* the 32-bit box type, not before. This fix should
allow correct parsing of JXL files with extended-size boxes.

Signed-off-by: Leo Izen 
---
 libavcodec/jpegxl_parse.c  | 6 +++---
 libavcodec/jpegxl_parser.c | 9 +
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavcodec/jpegxl_parse.c b/libavcodec/jpegxl_parse.c
index eb28e80867..7cfdd3e7d5 100644
--- a/libavcodec/jpegxl_parse.c
+++ b/libavcodec/jpegxl_parse.c
@@ -462,8 +462,10 @@ int ff_jpegxl_collect_codestream_header(const uint8_t 
*input_buffer, int input_l
 return AVERROR_BUFFER_TOO_SMALL;
 
 size = bytestream2_get_be32();
+tag = bytestream2_get_le32();
+
 if (size == 1) {
-if (bytestream2_get_bytes_left() < 12)
+if (bytestream2_get_bytes_left() < 8)
 return AVERROR_BUFFER_TOO_SMALL;
 size = bytestream2_get_be64();
 head_size = 16;
@@ -474,8 +476,6 @@ int ff_jpegxl_collect_codestream_header(const uint8_t 
*input_buffer, int input_l
 if (size)
 size -= head_size;
 
-tag = bytestream2_get_le32();
-
 if (tag == MKTAG('j','x','l','p')) {
 uint32_t idx;
 if (bytestream2_get_bytes_left() < 4)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 630fc8a60b..750872f17f 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1342,7 +1342,7 @@ static int skip_boxes(JXLParseContext *ctx, const uint8_t 
*buf, int buf_size)
 
 while (1) {
 uint64_t size;
-int head_size = 4;
+int head_size = 8;
 
 if (bytestream2_peek_le16() == FF_JPEGXL_CODESTREAM_SIGNATURE_LE)
 break;
@@ -1353,16 +1353,17 @@ static int skip_boxes(JXLParseContext *ctx, const 
uint8_t *buf, int buf_size)
 return AVERROR_BUFFER_TOO_SMALL;
 
 size = bytestream2_get_be32();
+bytestream2_skip(, 4); // tag
 if (size == 1) {
-if (bytestream2_get_bytes_left() < 12)
+if (bytestream2_get_bytes_left() < 8)
 return AVERROR_BUFFER_TOO_SMALL;
 size = bytestream2_get_be64();
-head_size = 12;
+head_size = 16;
 }
 if (!size)
 return AVERROR_INVALIDDATA;
 /* invalid ISOBMFF size */
-if (size <= head_size + 4 || size > INT_MAX - ctx->skip)
+if (size <= head_size || size > INT_MAX - ctx->skip)
 return AVERROR_INVALIDDATA;
 
 ctx->skip += size;
-- 
2.43.0

___
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 0/3] JPEG XL parser bug fixes

[Leo Izen]

Two bug fixes related to the JPEG XL parser. They're not exactly related and
don't need to be applied in sequence.

v2 change: patches themselves are identical, but now there's a FATE test.

Leo Izen (3):
  avcodec/jpegxl_parse{,r}: use correct ISOBMFF extended size location
  avcodec/jpegxl_parser: fix parsing sequences of extremely small files
  fate/jpegxl: add parser test for extboxes and small files

 libavcodec/jpegxl_parse.c|  6 +++---
 libavcodec/jpegxl_parser.c   | 23 +++
 tests/fate/jxl.mak   |  8 
 tests/ref/fate/jxl-small-ext-box |  9 +
 4 files changed, 35 insertions(+), 11 deletions(-)
 create mode 100644 tests/ref/fate/jxl-small-ext-box

-- 
2.43.0

___
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 v2] avcodec/amfenc: increase precision of Sleep() on Windows

[Henrik Gramner via ffmpeg-devel]

On Mon, Nov 27, 2023 at 2:42 PM Mark Thompson  wrote:
> Is it reasonable to set this global state from a library without the parent 
> program knowing?  We'd really prefer not to affect the global state 
> unexpectedly.

CreateWaitableTimerExW() with the
CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag might be an alternative?
___
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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust

[Paul B Mahol]

On Mon, Nov 27, 2023 at 2:49 PM Nicolas George  wrote:

> Paul B Mahol (12023-11-27):
> > Looks unrelated issue I just fixed, and sent patch to ML.
>
> No, it does not change anything, still “queued = 1081”. You could have
> tested.
>

I tested it, it passed:

-bash: mkvmerge: command not found


>
> --
>   Nicolas George
> ___
> 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".

Re: [FFmpeg-devel] [PATCH 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust

[Nicolas George]

Paul B Mahol (12023-11-27):
> Looks unrelated issue I just fixed, and sent patch to ML.

No, it does not change anything, still “queued = 1081”. You could have
tested.

-- 
  Nicolas George
___
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] hwcontext_d3d11: Add BGR0 support

[Mark Thompson]

On 22/10/2023 15:54, Mark Thompson wrote:

The 8-bit four-component DXGI container is also used for three-component
RGB without alpha.
---
This list is only used for AV->DXGI mapping, so it doesn't matter that there 
are duplicate DXGI formats in the list.

  libavutil/hwcontext_d3d11va.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index cc8c97d2b6..1d249f2088 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -86,6 +86,7 @@ static const struct {
  } supported_formats[] = {
  { DXGI_FORMAT_NV12, AV_PIX_FMT_NV12 },
  { DXGI_FORMAT_P010, AV_PIX_FMT_P010 },
+    { DXGI_FORMAT_B8G8R8A8_UNORM,    AV_PIX_FMT_BGR0 },
  { DXGI_FORMAT_B8G8R8A8_UNORM,    AV_PIX_FMT_BGRA },
  { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
  { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },


Ping for set.

Thanks,

- Mark
___
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 v2] avcodec/amfenc: increase precision of Sleep() on Windows

[Mark Thompson]

On 13/11/2023 14:37, Evgeny Pavlov wrote:

This commit increase precision of Sleep() function on Windows.
This fix reduces the sleep time on Windows to improve AMF encoding
performance on low resolution input videos.

Fix for issue #10622

v2: use timeBeginPeriod/timeEndPeriod for increasing precision of Sleep()

Signed-off-by: Evgeny Pavlov 
---
  libavcodec/amfenc.c | 31 +++
  libavcodec/amfenc.h |  3 +++
  2 files changed, 34 insertions(+)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 061859f85c..55e24856e8 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -42,7 +42,12 @@
  #endif
  
  #ifdef _WIN32

+#include 
  #include "compat/w32dlfcn.h"
+
+typedef MMRESULT (*timeapi_fun)(UINT uPeriod);
+#define WINMM_DLL "winmm.dll"
+
  #else
  #include 
  #endif
@@ -113,6 +118,9 @@ static int amf_load_library(AVCodecContext *avctx)
  AMFInit_Fn init_fun;
  AMFQueryVersion_Fn version_fun;
  AMF_RESULT res;
+#ifdef _WIN32
+timeapi_fun time_begin_fun;
+#endif
  
  ctx->delayed_frame = av_frame_alloc();

  if (!ctx->delayed_frame) {
@@ -145,6 +153,16 @@ static int amf_load_library(AVCodecContext *avctx)
  AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() failed 
with error %d\n", res);
  res = ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
  AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() failed 
with error %d\n", res);
+
+#ifdef _WIN32
+// Increase precision of Sleep() function on Windows platform
+ctx->winmm_lib = dlopen(WINMM_DLL, RTLD_NOW | RTLD_LOCAL);
+AMF_RETURN_IF_FALSE(ctx, ctx->winmm_lib != NULL, 0, "DLL %s failed to 
open\n", WINMM_DLL);
+time_begin_fun = (timeapi_fun)dlsym(ctx->winmm_lib, "timeBeginPeriod");
+AMF_RETURN_IF_FALSE(ctx, time_begin_fun != NULL, 0, "DLL %s failed to find function 
%s\n", WINMM_DLL, "timeBeginPeriod");
+time_begin_fun(1);
+#endif //_WIN32
+
  return 0;
  }
  
@@ -375,6 +393,9 @@ static int amf_init_encoder(AVCodecContext *avctx)

  int av_cold ff_amf_encode_close(AVCodecContext *avctx)
  {
  AmfContext *ctx = avctx->priv_data;
+#ifdef _WIN32
+timeapi_fun time_end_fun;
+#endif //_WIN32
  
  if (ctx->delayed_surface) {

  ctx->delayed_surface->pVtbl->Release(ctx->delayed_surface);
@@ -410,6 +431,16 @@ int av_cold ff_amf_encode_close(AVCodecContext *avctx)
  av_frame_free(>delayed_frame);
  av_fifo_freep2(>timestamp_list);
  
+#ifdef _WIN32

+if (ctx->winmm_lib) {
+time_end_fun = (timeapi_fun)dlsym(ctx->winmm_lib, "timeEndPeriod");
+AMF_RETURN_IF_FALSE(ctx, time_end_fun != NULL, 0, "DLL %s failed to find function 
%s\n", WINMM_DLL, "timeEndPeriod");
+time_end_fun(1);
+dlclose(ctx->winmm_lib);
+ctx->winmm_lib = NULL;
+}
+#endif //_WIN32
+
  return 0;
  }
  
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h

index 2dbd378ef8..35bcf1dfe3 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -50,6 +50,9 @@ typedef struct AmfContext {
  AVClass*avclass;
  // access to AMF runtime
  amf_handle  library; ///< handle to DLL library
+#ifdef _WIN32
+amf_handle  winmm_lib; ///< handle to winmm DLL library
+#endif //_WIN32
  AMFFactory *factory; ///< pointer to AMF factory
  AMFDebug   *debug;   ///< pointer to AMF debug interface
  AMFTrace   *trace;   ///< pointer to AMF trace interface


Is it reasonable to set this global state from a library without the parent 
program knowing?  We'd really prefer not to affect the global state 
unexpectedly.

It's also unclear to me what the effect of this tradeoff on power is, given 
that the whole reason why this happens is that Windows is trying to keep the 
CPU asleep for as long as possible to save power.

Thanks,

- Mark
___
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 v1] lavc/vaapi_encode_av1: Add qp option explicitly to set base q index

[Mark Thompson]

On 27/11/2023 00:58, fei.w.wang-at-intel@ffmpeg.org wrote:

From: Fei Wang 

Keep same way with librav1e/libsvtav1/qsv_av1.. to make it more
acceptable instead of using global option "-global_quality".

Fix #10615

Signed-off-by: Fei Wang 
---
  doc/encoders.texi | 1 +
  libavcodec/vaapi_encode_av1.c | 6 ++
  2 files changed, 7 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 27a9acf076..2cffc32daf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -4079,6 +4079,7 @@ Each encoder also has its own specific options:
  @table @option
  
  @item av1_vaapi

+@option{qp} sets the value of @emph{base_q_index}.
  @option{profile} sets the value of @emph{seq_profile}.
  @option{tier} sets the value of @emph{seq_tier}.
  @option{level} sets the value of @emph{seq_level_idx}.
diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 5a9ff0f798..2e327fec5a 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -79,6 +79,7 @@ typedef struct VAAPIEncodeAV1Context {
  int cdef_param_size;
  
  /** user options */

+int qp;
  int profile;
  int level;
  int tier;
@@ -786,6 +787,9 @@ static av_cold int vaapi_encode_av1_init(AVCodecContext 
*avctx)
  return AVERROR(EINVAL);
  }
  
+if (priv->qp > 0)

+ctx->explicit_qp = priv->qp;
+
  ret = ff_vaapi_encode_init(avctx);
  if (ret < 0)
  return ret;
@@ -864,6 +868,8 @@ static av_cold int vaapi_encode_av1_close(AVCodecContext 
*avctx)
  static const AVOption vaapi_encode_av1_options[] = {
  VAAPI_ENCODE_COMMON_OPTIONS,
  VAAPI_ENCODE_RC_OPTIONS,
+{ "qp", "Base q index (for P-frames; scaled by qfactor/qoffset for I/B)",
+  OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 255, FLAGS },
  { "profile", "Set profile (seq_profile)",
OFFSET(profile), AV_OPT_TYPE_INT,
{ .i64 = AV_PROFILE_UNKNOWN }, AV_PROFILE_UNKNOWN, 0xff, FLAGS, 
"profile" },


Disagree; QP is not a concept in AV1.  Further, your examples from other 
encoders do not have a consistent view of what it should mean.

librav1e.c:

{ "qp", "use constant quantizer mode", OFFSET(quantizer), AV_OPT_TYPE_INT, 
{ .i64 = -1 }, -1, 255, VE },

0-255 is presumably the base_q_idx scale.

libsvtav1.c:

{ "qp", "Initial Quantizer level value", OFFSET(qp),  AV_OPT_TYPE_INT, 
{ .i64 = 0 }, 0, 63, VE },

0-63 is presumably the H.26x-qp-ish scale used by some VP9/AV1 encoders which 
maps nonlinearly to the internal scale.

qsv_av1 doesn't seem to have such an option.

Thanks,

- Mark
___
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 v2] avcodec/amfenc: add smart access video option

[Mark Thompson]

On 26/11/2023 14:40, Dmitrii Ovchinnikov wrote:

The code looks significantly duplicated.


This is not moved to amfenc.c since the property has different names
  for different encoders, and many other properties (also common to
different encoders, but with different names) are separated in this way.


Seems like we could template this to avoid the duplication, something like:

#define PER_CODEC_OPTION(name) \
  (ctx->codec == AV1  ? AMF_VIDEO_ENCODER_AV1_  ## name : \
   ctx->codec == HEVC ? AMF_VIDEO_ENCODER_HEVC_ ## name : \
AMF_VIDEO_ENCODER_  ## name)

?

Thanks,

- Mark
___
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 v2] avcodec/amfenc: add smart access video option

[Mark Thompson]

On 23/11/2023 09:41, Evgeny Pavlov wrote:

This commit adds option for enabling SmartAccess Video (SAV)
in AMF encoders. SAV is an AMD hardware-specific feature which
enables the parallelization of encode and decode streams across
multiple Video Codec Engine (VCN) hardware instances.

Signed-off-by: Evgeny Pavlov 
---
  libavcodec/amfenc.h  |  1 +
  libavcodec/amfenc_av1.c  | 18 ++
  libavcodec/amfenc_h264.c | 18 ++
  libavcodec/amfenc_hevc.c | 18 ++
  4 files changed, 55 insertions(+)


Can you explain a bit more about what this option actually does?  I can't find any 
details about it beyond nebulous "make things better", but presumably there is 
some tradeoff so you don't always enable it.

Some documentation explaining what it does and hinting when the user might want 
it on or off would be helpful (can be a separate patch).

Patch itself seems fine for a standalone option, though I would mildly prefer 
not to put meaningless marketing names in the code if it's possible to have a 
descriptive name instead.

Thanks,

- Mark
___
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] cbs_av1: Reject thirty-two zero bits in uvlc code

[Mark Thompson]

On 25/10/2023 21:55, Michael Niedermayer wrote:

On Sun, Oct 22, 2023 at 07:35:52PM +0100, Mark Thompson wrote:

The spec allows at least thirty-two zero bits followed by a one to mean
2^32-1, with no constraint on the number of zeroes.  The libaom
reference decoder does not match this, instead reading thirty-two zeroes
but not the following one to mean 2^32-1.  These two interpretations are
incompatible and other implementations may follow one or the other.
Therefore reject thirty-two zeroes because the intended behaviour is not
clear.
---
libaom, dav1d and SVT-AV1 all have the same nonstandard behaviour of stopping 
at thirty-two zeroes and not reading the one.  gav1 just rejects thirty-two 
zeroes.


I would suggest to contact the authors of the spec to bring this discrepancy
to their attention, unless this is already known and
unless this sequence is declared invalid by some other part of the spec
(which would make the discrepancy only occur in invalid sequences)



Since this only occurs in nonconforming streams, fixing the spec seems like the 
better option.

Thanks,

- Mark
___
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] checkasm: add test for dcmul_add

[Paul B Mahol]

On Mon, Nov 27, 2023 at 1:53 PM flow gg  wrote:

> In this email, I first attached the original patch, and then sent the
> content of this patch in the second reply.
> So I tried downloading the attached original patch and running git am
> without any issues.
> then I tried copying the content from the second reply into the patch and
> then running git am also posed no problems.
> (I am using the Gmail web page.)
>
>
Please do not top post.

I can confirm that first patch in this thread applies cleanly  without any
issues.



> Rémi Denis-Courmont  于2023年11月27日周一 20:17写道：
>
> >
> >
> > Le 26 novembre 2023 22:54:28 GMT+02:00, flow gg  a
> > écrit :
> > >This is a bit confusing for me.. I tried pulling the latest code, and
> then
> > >used `git am checkasm-test-for-dcmul_add.patch` without any patch
> > >corruption.
> >
> > Did you try with the actual sent email or only with the original patch
> > 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 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 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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust

[Paul B Mahol]

On Mon, Nov 27, 2023 at 10:43 AM Nicolas George  wrote:

> Nicolas George (12023-11-27):
> > Just as I warned you, it breaks the test case I suggested:
> >
> > ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi
> '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv
> >
> > (/tmp/dummy_with_sub.mkv is created like I told a few days ago)
> > thousands of frame queued, eventually failing on OOM.
>
> … And it fails with just this patch but also with the whole patch
> series.
>

Looks unrelated issue I just fixed, and sent patch to ML.


>
> --
>   Nicolas George
> ___
> 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".

Re: [FFmpeg-devel] [PATCH] checkasm: add test for dcmul_add

[flow gg]

In this email, I first attached the original patch, and then sent the
content of this patch in the second reply.
So I tried downloading the attached original patch and running git am
without any issues.
then I tried copying the content from the second reply into the patch and
then running git am also posed no problems.
(I am using the Gmail web page.)

Rémi Denis-Courmont  于2023年11月27日周一 20:17写道：

>
>
> Le 26 novembre 2023 22:54:28 GMT+02:00, flow gg  a
> écrit :
> >This is a bit confusing for me.. I tried pulling the latest code, and then
> >used `git am checkasm-test-for-dcmul_add.patch` without any patch
> >corruption.
>
> Did you try with the actual sent email or only with the original patch
> 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 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] fate.sh: Allow overriding what targets to make for running the tests

[Martin Storsjö]

This can be useful if doing testing of uncommon CPU extensions by
running tests with QEMU (by configuring with e.g.
"target_exec=qemu-aarch64"), by only running the checkasm tests,
to get a reasonable test coverage without excessive test runtime.

For such a config, setting fate_targets="fate-checkasm fate-cpu"
can be a good tradeoff.
---
 doc/fate_config.sh.template | 2 ++
 tests/fate.sh   | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/fate_config.sh.template b/doc/fate_config.sh.template
index ab1bda45e4..06bb79a832 100644
--- a/doc/fate_config.sh.template
+++ b/doc/fate_config.sh.template
@@ -31,3 +31,5 @@ makeopts=   # extra options passed to 'make'
 # defaulting to makeopts above if this is not set
 #tar=   # command to create a tar archive from its arguments on stdout,
 # defaults to 'tar c'
+#fate_targets=  # targets to make when running fate; defaults to "fate",
+# can be set to run a subset of tests, e.g. "fate-checkasm".
diff --git a/tests/fate.sh b/tests/fate.sh
index 072e471256..d07a1cf90c 100755
--- a/tests/fate.sh
+++ b/tests/fate.sh
@@ -101,7 +101,7 @@ compile_extra()(
 fate()(
 test "$build_only" = "yes" && return
 cd ${build} || return
-${make} ${makeopts_fate-${makeopts}} -k fate
+${make} ${makeopts_fate-${makeopts}} -k ${fate_targets}
 )
 
 clean(){
@@ -132,6 +132,7 @@ cd ${workdir}   || die "cd ${workdir} failed"
 src=${workdir}/src
 : ${build:=${workdir}/build}
 : ${inst:=${workdir}/install}
+: ${fate_targets:=fate}
 
 test -d "$src" && update || checkout || die "Error fetching source"
 
-- 
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] checkasm: add test for dcmul_add

[Rémi Denis-Courmont]

Le 26 novembre 2023 22:54:28 GMT+02:00, flow gg  a écrit :
>This is a bit confusing for me.. I tried pulling the latest code, and then
>used `git am checkasm-test-for-dcmul_add.patch` without any patch
>corruption.

Did you try with the actual sent email or only with the original patch 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 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] avfilter/framesync: fix OOM case

[Paul B Mahol]

Attached.
From 8ce6bd0090666ef94b0455b7f8f4d3c05e273093 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Mon, 27 Nov 2023 13:04:16 +0100
Subject: [PATCH] avfilter/framesync: fix OOM case

Fixes OOM when caller keeps adding frames into filtergraph
that reached EOF by other means, for example EOF is signalled
by other filter in filtergraph or by buffersink.

Signed-off-by: Paul B Mahol 
---
 libavfilter/framesync.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index 6cb4b21fed..23681b5183 100644
--- a/libavfilter/framesync.c
+++ b/libavfilter/framesync.c
@@ -354,8 +354,11 @@ static int consume_from_fifos(FFFrameSync *fs)
 
 int ff_framesync_activate(FFFrameSync *fs)
 {
+AVFilterContext *ctx = fs->parent;
 int ret;
 
+FF_FILTER_FORWARD_STATUS_BACK_ALL(ctx->outputs[0], ctx);
+
 ret = framesync_advance(fs);
 if (ret < 0)
 return ret;
-- 
2.42.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 2/2] avcodec/jpegxl_parser: fix parsing sequences of extremely small files

[Thilo Borgmann via ffmpeg-devel]

On 27.11.23 00:33, Leo Izen wrote:

On 11/26/23 13:07, Thilo Borgmann wrote:




Am 26.11.2023 um 14:47 schrieb Leo Izen :
On 11/26/23 05:56, Anton Khirnov wrote:

Would be nice to have tests for these.


I have a sample at: https://buzo.us/l.jxl

It would test both of these patches. I can send a fate test for 
these to the ML if the sample gets uploaded. I CC'd 
samples-requ...@ffmpeg.org as well.


Can do this in a bit. What about the file you‘d sent to 
samples-request in August, is there still a test to be pushed about 
it as well?


-Thilo


There is not, that sample from August was already uploaded and the 
fate test utilizing it has been merged.


Ok, then its done:

e19bb66167c096e86f8cf567a7df3528  fate-suite/jxl/l.jxl

-Thilo

___
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 v2 0/6] WebRTC sub-second live streaming support

[Nicolas George]

Michael Riedl (12023-11-27):
> Regardless, this will only test the implementation against itself. If that 
> makes
> sense and sounds reasonable, I will add the server support to this patch 
> series.

Thanks. It will not be enough in a perfect world, but it still is a very
good start and much better than no testing at all.

Regards,

-- 
  Nicolas George
___
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 v2 0/6] WebRTC sub-second live streaming support

[Michael Riedl]

On 11/15/23 22:45, Michael Niedermayer wrote:
> On Tue, Nov 14, 2023 at 01:59:48PM +0100, Michael Riedl wrote:
>> On 11/14/23 11:05, Tomas Härdin wrote:
>>> This patchset is missing tests. I know that we for some reason don't
>>> really have tests for protocols, but I feel the issue is worthwhile to
>>> bring up. I've worked a bit with WebRTC recently and it's fiddly, so
>>> it'd be nice to have some automated thing that keeps track of which
>>> WebRTC implementations this works with. Or maybe this is better handled
>>> with an external project, testing which implementations interoperate?
>>
>> I agree that having automated tests would be useful for stability in the 
>> future.
>> I tested the patchset with both SRS and Millicast, and it worked well.
>>
>> For automated testing, we could use FATE, but it needs an extra server with
>> protection and someone to keep it updated. Testing with paid services like
>> Millicast is tricky.
>>
>> Another option is an external project for WebRTC testing, but the challenge 
>> is
>> keeping it maintained and compatible with changes in implementations.
>>
>> External services might update their software, causing issues with tests. We
>> would need a plan for dealing with that.
>>
>> For paid services like Millicast, we need to figure out who pays for the 
>> tests.
>> Understanding the costs is essential if we want to use paid services for
>> testing.
>>
>> I'd like to hear your thoughts on these points and how you would propose to
>> proceed with adding tests for protocols like WebRTC.
> simple, add server support for this to FFmpeg.
>
> FATE is run in cases without network access (for example googles ossfuzz setup
> i belives does not permit the fuzzed code to access external things IIRC)
>
> The practice of implementing only one end of a protocol is honestly wrong.
> And if there is no usable free server, then even more so.
>
> thx

Server support was planned for later, but maybe it's better to do it now.
Multiple solutions are possible, but one solution requires adding 2 more
(de)muxers for server support to this patch series. It would also be possible to
split the patch series into 2 parts, one for WHIP client and server support and
one for WHEP client and server support. But I'm not sure which solution is
better.

My idea is to add 2 more (de)muxers for server support. This would allow us to
test the following:
- WHIP muxer (client) --> WHIP demuxer (server)
- WHEP muxer (server) --> WHEP demuxer (client)

Regardless, this will only test the implementation against itself. If that makes
sense and sounds reasonable, I will add the server support to this patch series.

Please let me know what you think.

___
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 01/13] lavfi/buffersink: avoid leaking peeked_frame on uninit

[Nicolas George]

Anton Khirnov (12023-11-23):
> ---
>  libavfilter/buffersink.c | 9 +
>  1 file changed, 9 insertions(+)

LGTM, thanks.

Regards,

-- 
  Nicolas George
___
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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust

[Nicolas George]

Nicolas George (12023-11-27):
> Just as I warned you, it breaks the test case I suggested:
> 
> ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi 
> '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv
> 
> (/tmp/dummy_with_sub.mkv is created like I told a few days ago)
> thousands of frame queued, eventually failing on OOM.

… And it fails with just this patch but also with the whole patch
series.

-- 
  Nicolas George
___
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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust

[Nicolas George]

Anton Khirnov (12023-11-23):
> Avoid making decisions based on current graph input state, which makes
> the output dependent on the order in which the frames from different
> inputs are interleaved.
> 
> Makes the output of fate-filter-overlay-dvdsub-2397 more correct - the
> subtitle appears two frames later, which is closer to its PTS as stored
> in the file.
> ---
>  fftools/ffmpeg_filter.c   | 3 +--
>  tests/ref/fate/filter-overlay-dvdsub-2397 | 4 ++--
>  tests/ref/fate/sub2video  | 8 +---
>  3 files changed, 8 insertions(+), 7 deletions(-)

Just as I warned you, it breaks the test case I suggested:

./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi 
'[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv

(/tmp/dummy_with_sub.mkv is created like I told a few days ago)
thousands of frame queued, eventually failing on OOM.

Regards,

-- 
  Nicolas George
___
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] doc/filters: restore libvmaf option pool entry

[Gyan Doshi]

Will push soon.

On 2023-11-26 04:08 pm, Gyan Doshi wrote:

3d29724c00 removed the doc entry for the option pool while adding
a parser function for it at the same time!

The option remains available and undeprecated.
---
  doc/filters.texi | 4 
  1 file changed, 4 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 5268b2003c..80ffbb2c65 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16864,6 +16864,10 @@ Set the file path to be used to store log files.
  @item log_fmt
  Set the format of the log file (xml, json, csv, or sub).
  
+@item pool

+Set the pool method to be used for computing vmaf.
+Options are @code{min}, @code{harmonic_mean} or @code{mean} (default).
+
  @item n_threads
  Set number of threads to be used when initializing libvmaf.
  Default value: @code{0}, no threads.


___
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] lavu/hwcontext_vaapi: ignore nonexistent device in default DRM device selection

[Anton Khirnov]

Quoting Xiang, Haihao (2023-11-27 05:42:20)
> > 
> > Also, the else is unnecessary since the if() block ends with continue.
> > 
> 
> I wanted to print a message if all devices don't exist. I'll remove it in the
> new version if you think such info is unnecessary. 

I don't object to the message, I mean just that

if (foo) {
  
  continue;
} else
  bar;

is equivalent to

if (foo) {
  
  continue;
}

bar;

The latter saves you one level of indentation and I find it more
readable.

-- 
Anton Khirnov
___
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] configure: don't warn deprecated symbols from libvpl

[Xiang, Haihao]

From: Haihao Xiang 

libvpl deprecated some symbols (e.g. MFX_EXTBUFF_VPP_DENOISE2 is used to
replace MFX_EXTBUFF_VPP_DENOISE), however the new symbols aren't support
by MediaSDK runtime. In order to support the combination of libvpl and
MediaSDK runtime on legacy devices, we continue to use the deprecated
symbols in FFmpeg. This patch added -DMFX_DEPRECATED_OFF to CFLAGS to
silence the corresponding compilation warnings.

Signed-off-by: Haihao Xiang 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 838e627084..d77c053226 100755
--- a/configure
+++ b/configure
@@ -6776,6 +6776,7 @@ elif enabled libvpl; then
 # is extracted from "vpl >= 2.6"
 check_pkg_config libmfx "vpl >= 2.6" "mfxvideo.h mfxdispatcher.h" MFXLoad 
|| \
 die "ERROR: libvpl >= 2.6 not found"
+add_cflags -DMFX_DEPRECATED_OFF
 fi
 
 if enabled libmfx; then
-- 
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".