Re: [FFmpeg-devel] [PATCH 3/3] libavfilter/dnn: Initialze DNNData variables

[zhilizhao(赵志立)]

> On Sep 20, 2023, at 10:26, wenbin.chen-at-intel@ffmpeg.org wrote:
> 
> From: Wenbin Chen 
> 
> Signed-off-by: Wenbin Chen 
> ---
> libavfilter/dnn/dnn_backend_tf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_tf.c 
> b/libavfilter/dnn/dnn_backend_tf.c
> index b521de7fbe..e1e8cef0d2 100644
> --- a/libavfilter/dnn/dnn_backend_tf.c
> +++ b/libavfilter/dnn/dnn_backend_tf.c
> @@ -629,6 +629,7 @@ static int fill_model_input_tf(TFModel *tf_model, 
> TFRequestItem *request) {
> TFContext *ctx = _model->ctx;
> int ret = 0;
> 
> +memset(, 0, sizeof(input));

Can be simplified with DNNData input = { 0 };

> lltask = ff_queue_pop_front(tf_model->lltask_queue);
> av_assert0(lltask);
> task = lltask->task;
> @@ -724,7 +725,7 @@ static void infer_completion_callback(void *args) {
> TFModel *tf_model = task->model;
> TFContext *ctx = _model->ctx;
> 
> -outputs = av_malloc_array(task->nb_output, sizeof(*outputs));
> +outputs = av_calloc(task->nb_output, sizeof(*outputs));
> if (!outputs) {
> av_log(ctx, AV_LOG_ERROR, "Failed to allocate memory for *outputs\n");
> goto err;
> -- 
> 2.34.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/qsvdec: fix dead loop of qsv decoding

[zhilizhao(赵志立)]

> On Sep 14, 2023, at 14:11, Xiang, Haihao 
>  wrote:
> 
> 
>> This seems like a bug in libmfx/libvpl.
> 
> I agree there should be a bug in libmfx/libvpl, but we have to avoid this dead
> loop in FFmpeg.

Is it possible that a normal case which do take more than 500ms now break out
early and return AVERROR(EBUSY)?

On the other hand, this isn’t the only place where dead loops can happen.
Third party encoder/decoder wrappers, especially those operating system 
framework
wrappers (e.g., Android MediaCodec) have the same risks. Something like a
interrupt callback in avcodec can be useful if more cases have been found. 

> 
> 
>> I encountered this problem in video conference scenario. Receive more over 9
>> RTP h264 video streams simultaneously.
> 
> Could you file a bug to https://github.com/oneapi-src/oneVPL-intel-gpu , then
> document this issue in your patch ? 
> 
> Thanks
> Haihao
> 
>> 
>> 获取 Outlook for iOS
>> 
>> 发件人: Anton Khirnov 
>> 发送时间: Tuesday, August 29, 2023 3:57:00 PM
>> 收件人: FFmpeg development discussions and patches 
>> 抄送: tinghu3 
>> 主题: Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/qsvdec: fix dead loop of qsv
>> decoding
>> 
>> Quoting Ting Hu (2023-08-29 09:49:06)
>>> From: tinghu3 
>>> 
>>> MFXVideoDECODE_DecodeFrameAsync always return MFX_WRN_DEVICE_BUSY in special
>>> scenario.
>> 
>> "special scenario"? What special scenario? Is this documented anywhere?
>> This seems like a bug in libmfx/libvpl.
>> 
>> --
>> 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 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 v3] avformat/mov: add interleaved_read option

[zhilizhao(赵志立)]

> On Sep 14, 2023, at 09:41, Steven Liu  wrote:
> 
> Zhao Zhili  于2023年9月12日周二 01:10写道：
>> 
>> From: Zhao Zhili 
>> 
>> For bad interleaved files, manually interleave multiple tracks at the
>> demuxer level can trigger seeking back and forth, which can be
>> dramatically slow depending on the protocol. Demuxer level interleave
>> can be useless sometimes, e.g., reading mp4 via http and then
>> transcoding/remux to DASH. Disable this option when you don't need the
>> demuxer level interleave, and want to avoid the IO penalizes.
>> 
>> Co-authored-by: Derek Buitenhuis 
>> Signed-off-by: Zhao Zhili 
>> ---
>> v3: update doc
>> v2: rename option
>> 
>> This issue is well known. Two samples can be found at here
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-December/304951.html
>> 
>> doc/demuxers.texi | 7 +++
>> libavformat/isom.h| 1 +
>> libavformat/mov.c | 5 -
>> libavformat/version.h | 2 +-
>> 4 files changed, 13 insertions(+), 2 deletions(-)
>> 
>> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
>> index 2d33b47a56..ca1563abb0 100644
>> --- a/doc/demuxers.texi
>> +++ b/doc/demuxers.texi
>> @@ -779,6 +779,13 @@ cast to int32 are used to adjust onward dts.
>> 
>> Unit is the track time scale. Range is 0 to UINT_MAX. Default is 
>> @code{UINT_MAX - 48000*10} which allows upto
>> a 10 second dts correction for 48 kHz audio streams while accommodating 
>> 99.9% of @code{uint32} range.
>> +
>> +@item interleaved_read
>> +Interleave packets from multiple tracks at demuxer level. For badly 
>> interleaved files, this prevents playback issues
>> +caused by large gaps between packets in different tracks, as MOV/MP4 do not 
>> have packet placement requirements.
>> +However, this can cause excessive seeking on very badly interleaved files, 
>> due to seeking between tracks, so disabling
>> +it may prevent I/O issues, at the expense of playback.
>> +
>> @end table
>> 
>> @subsection Audible AAX
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index 4b1cd42f0f..3d375d7a46 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -327,6 +327,7 @@ typedef struct MOVContext {
>> int64_t extent_offset;
>> } *avif_info;
>> int avif_info_size;
>> +int interleaved_read;
>> } MOVContext;
>> 
>> int ff_mp4_read_descr_len(AVIOContext *pb);
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index aa1d9e4ccc..8ad5f0b646 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -8780,6 +8780,8 @@ static AVIndexEntry 
>> *mov_find_next_sample(AVFormatContext *s, AVStream **st)
>> AVIndexEntry *sample = NULL;
>> int64_t best_dts = INT64_MAX;
>> int i;
>> +MOVContext *mov = s->priv_data;
>> +int no_interleave = !mov->interleaved_read || !(s->pb->seekable & 
>> AVIO_SEEKABLE_NORMAL);
>> for (i = 0; i < s->nb_streams; i++) {
>> AVStream *avst = s->streams[i];
>> FFStream *const avsti = ffstream(avst);
>> @@ -8788,7 +8790,7 @@ static AVIndexEntry 
>> *mov_find_next_sample(AVFormatContext *s, AVStream **st)
>> AVIndexEntry *current_sample = 
>> >index_entries[msc->current_sample];
>> int64_t dts = av_rescale(current_sample->timestamp, 
>> AV_TIME_BASE, msc->time_scale);
>> av_log(s, AV_LOG_TRACE, "stream %d, sample %d, dts %"PRId64"\n", 
>> i, msc->current_sample, dts);
>> -if (!sample || (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) && 
>> current_sample->pos < sample->pos) ||
>> +if (!sample || (no_interleave && current_sample->pos < 
>> sample->pos) ||
>> ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
>>  ((msc->pb != s->pb && dts < best_dts) || (msc->pb == s->pb 
>> && dts != AV_NOPTS_VALUE &&
>>  ((FFABS(best_dts - dts) <= AV_TIME_BASE && 
>> current_sample->pos < sample->pos) ||
>> @@ -9282,6 +9284,7 @@ static const AVOption mov_options[] = {
>> { "enable_drefs", "Enable external track support.", 
>> OFFSET(enable_drefs), AV_OPT_TYPE_BOOL,
>> {.i64 = 0}, 0, 1, FLAGS },
>> { "max_stts_delta", "treat offsets above this value as invalid", 
>> OFFSET(max_stts_delta), AV_OPT_TYPE_INT, {.i64 = UINT_MAX-48000*10 }, 0, 
>> UINT_MAX, .flags = AV_OPT_FLAG_DECODING_PARAM },
>> +{ "interleaved_read", "Manually interleave between multiple tracks", 
>> OFFSET(interleaved_read), AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, .flags = 
>> AV_OPT_FLAG_DECODING_PARAM },
>> 
>> { NULL },
>> };
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index cb67e0a1f8..e41362ac9d 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -32,7 +32,7 @@
>> #include "version_major.h"
>> 
>> #define LIBAVFORMAT_VERSION_MINOR  12
>> -#define LIBAVFORMAT_VERSION_MICRO 100
>> +#define LIBAVFORMAT_VERSION_MICRO 101
>> 
>> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>>LIBAVFORMAT_VERSION_MINOR, \
>> --
>> 2.34.1
>> 
>> 

Re: [FFmpeg-devel] [PATCH 1/2] lavc/videotoolboxenc: Dump the encoder

[zhilizhao(赵志立)]

> On Sep 5, 2023, at 18:43, Richard Kern  wrote:
> 
> 
> 
>> On Sep 3, 2023, at 11:53 PM, Jun Zhao  wrote:
>> 
>> Dump the encoder, it's will help debug some case
>> 
>> Signed-off-by: Jun Zhao 
>> ---
>> libavcodec/videotoolboxenc.c | 20 
>> 1 file changed, 20 insertions(+)
>> 
>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>> index bfc03787a0..5633640a30 100644
>> --- a/libavcodec/videotoolboxenc.c
>> +++ b/libavcodec/videotoolboxenc.c
>> @@ -1110,6 +1110,26 @@ static int vtenc_create_encoder(AVCodecContext   
>> *avctx,
>>return AVERROR_EXTERNAL;
>>}
>> 
>> +// Dump the init encoder
>> +{
>> +CFStringRef encoderID = NULL;

Nit: encoder_id.

>> +status = VTSessionCopyProperty(vtctx->session,
>> +   kVTCompressionPropertyKey_EncoderID,
>> +   kCFAllocatorDefault,
>> +   );
>> +if (status == noErr) {
>> +char names[256] = { 0 };
>> +
>> +CFStringGetCString(encoderID,
>> +   names,
>> +   255,
> Use sizeof(names) - 1 instead of 255. The hard coded value increases the 
> chance of a bug if the size of names is changed. 
> 
>> +   kCFStringEncodingUTF8);
>> +av_log(avctx, AV_LOG_INFO, "Init the encoder: %s\n", names);
> This should be logged at the debug level since it doesn’t help users when 
> encoding is successful. 
> 
>> +}
>> +if (encoderID != NULL)
>> +CFRelease(encoderID);
>> +}

How about extract it to a function so the encoder id can be used in error 
message?

>> +
>>if (avctx->flags & AV_CODEC_FLAG_QSCALE && !vtenc_qscale_enabled()) {
>>av_log(avctx, AV_LOG_ERROR, "Error: -q:v qscale not available for 
>> encoder. Use -b:v bitrate instead.\n");
>>return AVERROR_EXTERNAL;
>> -- 
>> 2.25.1
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
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] lavc/videotoolboxenc: Get the encoder supported properties

[zhilizhao(赵志立)]

> On Sep 5, 2023, at 17:36, myp...@gmail.com wrote:
> 
> On Tue, Sep 5, 2023 at 3:52 PM Tomas Härdin  wrote:
>> 
>> mån 2023-09-04 klockan 11:53 +0800 skrev Jun Zhao:
>>> Get the encoder supported properties list, it will be used for
>>> feature support checks.
>>> 
>>> Signed-off-by: Jun Zhao 
>>> ---
>>> libavcodec/videotoolboxenc.c | 27 +++
>>> 1 file changed, 27 insertions(+)
>>> 
>>> diff --git a/libavcodec/videotoolboxenc.c
>>> b/libavcodec/videotoolboxenc.c
>>> index 5633640a30..8e70915225 100644
>>> --- a/libavcodec/videotoolboxenc.c
>>> +++ b/libavcodec/videotoolboxenc.c
>>> @@ -232,6 +232,7 @@ typedef struct VTEncContext {
>>> AVClass *class;
>>> enum AVCodecID codec_id;
>>> VTCompressionSessionRef session;
>>> +CFDictionaryRef supported_props;
>>> CFStringRef ycbcr_matrix;
>>> CFStringRef color_primaries;
>>> CFStringRef transfer_function;
>>> @@ -1110,6 +,18 @@ static int
>>> vtenc_create_encoder(AVCodecContext   *avctx,
>>> return AVERROR_EXTERNAL;
>>> }
>>> 
>>> +status = VTCopySupportedPropertyDictionaryForEncoder(avctx-
 width,
>>> + avctx-
 height,
>>> + codec_type,
>>> + enc_info,
>>> + NULL,
>>> + 
 supported_props);
>>> +
>>> +if (status != noErr) {
>>> +av_log(avctx, AV_LOG_ERROR,"Error retrieving the supported
>>> property dictionary err=%"PRId64"", (int64_t)status);
>> 
>> Missing \n
> Good catch
>> 
>>> +return AVERROR_EXTERNAL;
>>> +}
>>> +
>>> // Dump the init encoder
>>> {
>>> CFStringRef encoderID = NULL;
>>> @@ -1656,6 +1669,7 @@ static av_cold int vtenc_init(AVCodecContext
>>> *avctx)
>>> if (vtctx->profile == FF_PROFILE_UNKNOWN)
>>> vtctx->profile = avctx->profile;
>>> vtctx->session = NULL;
>>> +vtctx->supported_props = NULL;
>> 
>> NULLing isn't necessary since priv_data is calloc'd
> Yes，I know this, just following the old code behaviour，maybe need to
> refine the old code

On one hand, calloc() isn’t the same as set these pointers to NULL,
since NULL isn’t always all-zero-bits.

On the other hand, NULL is assumed all-zero-bits everywhere.

Both works for me. I don’t want to enforce any style.

>> 
>>> status = vtenc_configure_encoder(avctx);
>>> if (status) return status;
>>> 
>>> @@ -2426,6 +2440,11 @@ static int
>>> create_cv_pixel_buffer(AVCodecContext   *avctx,
>>> if (vtstatus == kVTInvalidSessionErr) {
>>> CFRelease(vtctx->session);
>>> vtctx->session = NULL;
>>> +if (vtctx->supported_props) {
>>> +CFRelease(vtctx->supported_props);
>>> +vtctx->supported_props = NULL;
>>> +}
>>> +
>>> status = vtenc_configure_encoder(avctx);
>>> if (status == 0)
>>> pix_buf_pool =
>>> VTCompressionSessionGetPixelBufferPool(vtctx->session);
>>> @@ -2685,6 +2704,10 @@ pe_cleanup:
>>> CFRelease(vtctx->session);
>>> 
>>> vtctx->session = NULL;
>>> +if (vtctx->supported_props) {
>>> +CFRelease(vtctx->supported_props);
>>> +vtctx->supported_props = NULL;
>>> +}
>>> vtctx->frame_ct_out = 0;
>>> 
>>> av_assert0(status != 0 || (avctx->extradata && avctx-
 extradata_size > 0));
>>> @@ -2709,6 +2732,10 @@ static av_cold int vtenc_close(AVCodecContext
>>> *avctx)
>>> pthread_mutex_destroy(>lock);
>>> CFRelease(vtctx->session);
>>> vtctx->session = NULL;
>>> +if (vtctx->supported_props) {
>>> +CFRelease(vtctx->supported_props);
>>> +vtctx->supported_props = NULL;
>>> +}
>> 
>> Copy-pasting this in three places looks ugly. Moving cleanup of session
>> and supported_props to a small function would reduce the number of
>> lines and look prettier.
>> 
> It makes more sense.
> ___
> 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 2/2] lavc/videotoolboxenc: enable low-latency mode for HEVC

[zhilizhao(赵志立)]

> On Sep 1, 2023, at 09:13, myp...@gmail.com wrote:
> 
> On Fri, Sep 1, 2023 at 2:13 AM Zhao Zhili  wrote:
>> 
>> 
>>> From: ffmpeg-devel  On Behalf Of Jun Zhao
>>> Sent: 2023年8月31日 22:50
>>> To: ffmpeg-devel@ffmpeg.org
>>> Cc: Jun Zhao ; Jun Zhao 
>>> Subject: [FFmpeg-devel] [PATCH 2/2] lavc/videotoolboxenc: enable 
>>> low-latency mode for HEVC
>>> 
>>> Enable the HEVC encoder that supports low-latency mode.
>>> 
>>> Signed-off-by: Jun Zhao 
>>> ---
>>> libavcodec/videotoolboxenc.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>>> index 8e493c4f7a..bfc03787a0 100644
>>> --- a/libavcodec/videotoolboxenc.c
>>> +++ b/libavcodec/videotoolboxenc.c
>>> @@ -1568,7 +1568,8 @@ static int vtenc_configure_encoder(AVCodecContext 
>>> *avctx)
>>> #endif
>>> 
>>> // low-latency mode: eliminate frame reordering, follow a 
>>> one-in-one-out encoding mode
>>> -if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) && avctx->codec_id == 
>>> AV_CODEC_ID_H264) {
>>> +if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) &&
>>> +(avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id == 
>>> AV_CODEC_ID_HEVC)) {
>> 
>> How about just remove the codec_id check?
>> Is there any unwelcome side effects for encoders other than H264/HEVC?
> 
> 1. One reason is that there are now other encoders available, such as
> prores_videotoolbox.
> 
> 2. It may be more appropriate to use a strictly qualified check
> instead of an open condition.

Both HEVC and ProRes failed with low_latency on my machine (with or without 
-allow_sw 1)

[hevc_videotoolbox @ 0x6192a380] Error: cannot create compression session: 
-12902
[prores_videotoolbox @ 0x6192a380] Error: cannot create compression 
session: -12902

kVTParameterErr = 
-12902,

1. FFmpeg users should have an idea whether or not to set 
AV_CODEC_FLAG_LOW_DELAY.
AV_CODEC_FLAG_LOW_DELAY doesn’t make sense for ProRes, but if user wants to 
try, let he/she
do.

2. I can’t find API to query the capability. Only VideoToolBox framework itself 
know how
to handle the argument. There isn’t much protect to provide for users.

Even with H.264, the results is unexpected: the input framerate is 25 but the 
output
framerate is 5, it dropped 80 percent frames silently.

> ___
> 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] avcodec/jpegxl_parser: fix a compile error

[zhilizhao(赵志立)]

> On Aug 28, 2023, at 15:14, Tong Wu  wrote:
> 
> Compiler: MSVC 14.35.32215
> Error type: error C2099: initializer is not a constant
> Related commit: 0c0dd23 avcodec/jpegxl_parser: add JPEG XL parser
> 
> Signed-off-by: Tong Wu 
> ---
> libavcodec/jpegxl_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
> index 66e64b1074..20c8a41a89 100644
> --- a/libavcodec/jpegxl_parser.c
> +++ b/libavcodec/jpegxl_parser.c
> @@ -49,7 +49,7 @@
> #define clog1p(x) (ff_log2(x) + !!(x))
> #define unpack_signed(x) (((x) & 1 ? -(x)-1 : (x))/2)
> #define div_ceil(x, y) (((x) - 1) / (y) + 1)
> -#define vlm(a,b) (VLCElem){.sym = (a), .len = (b)}
> +#define vlm(a,b) {.sym = (a), .len = (b)}

LGTM. GCC complains the same with -pedantic.

> 
> typedef struct JXLHybridUintConf {
> int split_exponent;
> -- 
> 2.41.0.windows.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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] avutil/channel_layout: make pre-defined channel layouts C++ friendly

[zhilizhao(赵志立)]

> On Aug 20, 2023, at 20:53, Tomas Härdin  wrote:
> 
> tor 2023-08-17 klockan 22:03 +0800 skrev zhilizhao(赵志立):
>> 
>> 
>>> On Aug 17, 2023, at 20:57, Tomas Härdin  wrote:
>>> 
>>> ons 2023-08-16 klockan 23:44 +0800 skrev Zhao Zhili:
>>>> From: Zhao Zhili 
>>>> 
>>>> C++ doesn't support designated initializers until C++20. We have
>>>> a bunch of pre-defined channel layouts, the gains to make them
>>>> usable in C++ exceed the losses.
>>>> 
>>>> Signed-off-by: Zhao Zhili 
>>>> ---
>>>>  libavutil/channel_layout.h | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/libavutil/channel_layout.h
>>>> b/libavutil/channel_layout.h
>>>> index f345415c55..817a5ad370 100644
>>>> --- a/libavutil/channel_layout.h
>>>> +++ b/libavutil/channel_layout.h
>>>> @@ -359,7 +359,7 @@ typedef struct AVChannelLayout {
>>>>  } AVChannelLayout;
>>>>  
>>>>  #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
>>>> -{ .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u
>>>> = {
>>>> .mask = (m) }}
>>>> +{ AV_CHANNEL_ORDER_NATIVE, (nb), { m }, NULL }
>>>>  
>>>>  /**
>>>>   * @name Common pre-defined channel layouts
>>>> @@ -397,7 +397,7 @@ typedef struct AVChannelLayout {
>>>>  #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIX   
>>>> AV_CHANNEL_LAYOUT_MASK(2,  AV_CH_LAYOUT_STEREO_DOWNMIX)
>>>>  #define AV_CHANNEL_LAYOUT_22POINT2 
>>>> AV_CHANNEL_LAYOUT_MASK(24, AV_CH_LAYOUT_22POINT2)
>>>>  #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
>>>> -{ .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u
>>>> = {
>>>> .mask = 0 }}
>>>> +{ AV_CHANNEL_ORDER_AMBISONIC, 4, { 0 }, NULL }
>>> 
>>> For C++ compat you could use some constructor magic instead, and
>>> turn
>>> these into proper constants. Hidden behind #ifdef __cplusplus of
>>> course.
>> 
>> I’m trying to avoid more debate to not refer to __cplusplus on
>> purpose.
>> 
>>> 
>>> IMO having untyped #defines like this is mega ugly. At the very
>>> least
>>> it should be (AVChannelLayout){...}. It's likely cargo culted from
>>> when
>>> channel layouts were bitmasks.
>> 
>> (AVChannelLayout){…} can be invalid in C++. AV_TIME_BASE_Q has the
>> problem
>> already.
> 
> We could turn them into proper constants, like so:
> 
> static const AVChannelLayout AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER =
> {...};

I like this style, but it’s API, so we can’t just replace current
implementation by static const variables. And I’m not sure about the
coding style regarding to use static const variables in public headers.  

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


___
ffmpeg-devel 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] avutil/channel_layout: make pre-defined channel layouts C++ friendly

[zhilizhao(赵志立)]

> On Aug 17, 2023, at 20:57, Tomas Härdin  wrote:
> 
> ons 2023-08-16 klockan 23:44 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> C++ doesn't support designated initializers until C++20. We have
>> a bunch of pre-defined channel layouts, the gains to make them
>> usable in C++ exceed the losses.
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>>  libavutil/channel_layout.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
>> index f345415c55..817a5ad370 100644
>> --- a/libavutil/channel_layout.h
>> +++ b/libavutil/channel_layout.h
>> @@ -359,7 +359,7 @@ typedef struct AVChannelLayout {
>>  } AVChannelLayout;
>>  
>>  #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
>> -{ .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u = {
>> .mask = (m) }}
>> +{ AV_CHANNEL_ORDER_NATIVE, (nb), { m }, NULL }
>>  
>>  /**
>>   * @name Common pre-defined channel layouts
>> @@ -397,7 +397,7 @@ typedef struct AVChannelLayout {
>>  #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIX   
>> AV_CHANNEL_LAYOUT_MASK(2,  AV_CH_LAYOUT_STEREO_DOWNMIX)
>>  #define AV_CHANNEL_LAYOUT_22POINT2 
>> AV_CHANNEL_LAYOUT_MASK(24, AV_CH_LAYOUT_22POINT2)
>>  #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
>> -{ .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u = {
>> .mask = 0 }}
>> +{ AV_CHANNEL_ORDER_AMBISONIC, 4, { 0 }, NULL }
> 
> For C++ compat you could use some constructor magic instead, and turn
> these into proper constants. Hidden behind #ifdef __cplusplus of
> course.

I’m trying to avoid more debate to not refer to __cplusplus on purpose.

> 
> IMO having untyped #defines like this is mega ugly. At the very least
> it should be (AVChannelLayout){...}. It's likely cargo culted from when
> channel layouts were bitmasks.

(AVChannelLayout){…} can be invalid in C++. AV_TIME_BASE_Q has the problem
already.

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


___
ffmpeg-devel 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] avformat/libsrt: Decode URL parameter strings

[zhilizhao(赵志立)]

> On Aug 11, 2023, at 00:13, Armin Hasitzka  wrote:
> 
> Hi again,
> 
> we found this the other day when using a stream ID containing "%2F",
> expecting this to be resolved to "/". While "%2F" could obviously be sent
> decoded, "&" (decoded) would currently end the value and not be used, "+"
> (decoded) would be overwritten with " ", and "=" (decoded) could cause
> entirely unexpected outcomes (albeit all these characters being allowed by
> SRT for various string inputs).
> 
> As for changing `av_strndup` to `ff_urldecode` (which removes a length
> check); I don't think that this particular length check added any
> protection (`av_find_info_tag` adds a trailing `\0` if found). This
> thinking is also evident at the two other places where `ff_urldecode`
> replaced `av_strdup`.
> 
> It would be amazing if we could get this merged upstream :)
> 

Thanks for the contribution, but the issue is kind of complex.

1. The format of streamid isn’t take URL into consideration

"#!::u=admin,r=foo”

2. Obviously some implementation and usecases depend on these fields to
be passed directly without URL encoding/decoding.

The same issue has been filed to srt again and again, ref.

https://github.com/Haivision/srt/issues/2749

and #1871, #1173, #2015.

I think we shouldn’t put these fields into URL at the first place.
Now doing any change, even if it’s technically correct, will make
regression issues.

I have no idea to improve the code. But it’s easy to solve from the
user’s point of view: don’t set these fields via URL, just use options.
These is no implementation dependent behavior with options.

> ---
>  libavformat/libsrt.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index cd8f5b1e7d..8986616334 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @@ -32,6 +32,7 @@
>  #include "network.h"
>  #include "os_support.h"
>  #include "url.h"
> +#include "urldecode.h"
>  
>  /* This is for MPEG-TS and it's a default SRTO_PAYLOADSIZE for SRTT_LIVE (8 
> TS packets) */
>  #ifndef SRT_LIVE_DEFAULT_PAYLOAD_SIZE
> @@ -547,7 +548,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> int flags)
>  }
>  if (av_find_info_tag(buf, sizeof(buf), "passphrase", p)) {
>  av_freep(>passphrase);
> -s->passphrase = av_strndup(buf, strlen(buf));
> +s->passphrase = ff_urldecode(buf, 0);
>  }
>  #if SRT_VERSION_VALUE >= 0x010302
>  if (av_find_info_tag(buf, sizeof(buf), "enforced_encryption", p)) {
> @@ -632,7 +633,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> int flags)
>  }
>  if (av_find_info_tag(buf, sizeof(buf), "streamid", p)) {
>  av_freep(>streamid);
> -s->streamid = av_strdup(buf);
> +s->streamid = ff_urldecode(buf, 0);
>  if (!s->streamid) {
>  ret = AVERROR(ENOMEM);
>  goto err;
> @@ -640,7 +641,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> int flags)
>  }
>  if (av_find_info_tag(buf, sizeof(buf), "smoother", p)) {
>  av_freep(>smoother);
> -s->smoother = av_strdup(buf);
> +s->smoother = ff_urldecode(buf, 0);
>  if(!s->smoother) {
>  ret = AVERROR(ENOMEM);
>  goto err;
> -- 
> 2.41.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] avformat/movenc: Fix writing a sample size of 0 for PCM in MP4

[zhilizhao(赵志立)]

> On Jul 26, 2023, at 00:28, Raphaël Zumer  wrote:
> 
> Encoding PCM in MP4 currently causes subsequent decoding to fail due to a 
> sample size of 0.

This doesn’t give a context on which case the sample size is 0.

> Use bits per coded sample instead, which are set correctly based on my tests 
> and allow muxed files to be decoded as expected.

Since neither bits_per_raw_sample or bits_per_coded_sample has strong guarantee,
I decided to fall back to av_get_exact_bits_per_sample().

http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312653.html

> 
> Note: PCM in MP4 muxed with versions of FFmpeg 6.0 and prior (before 
> implementation of the pcmC box) will continue to fail decoding due to the 
> sample size not being available. I see that it was assumed to be 16-bit 
> before commit d4ee17.

The assumption is incorrect. We didn’t recognize those samples are
ISO/IEC 23003-5 before.

> 
> Signed-off-by: Raphaël Zumer 
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index f1cc80b1b3..3c44ace5b0 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1237,7 +1237,7 @@ static int mov_write_pcmc_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVTrack *tra
> track->par->codec_id == AV_CODEC_ID_PCM_S24LE ||
> track->par->codec_id == AV_CODEC_ID_PCM_S32LE);
> avio_w8(pb, format_flags);
> -avio_w8(pb, track->par->bits_per_raw_sample);
> +avio_w8(pb, track->par->bits_per_coded_sample);
>  return update_size(pb, pos);
> }
> -- 
> 2.41.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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] use bits_per_coded_sample if bits_per_raw_sample equal to 0 in pcmc tag, fix bug #10433

[zhilizhao(赵志立)]

> On Jul 24, 2023, at 10:41, hung kuishing  wrote:
> 
> Signed-off-by: clarkh 
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index f1cc80b1b3..d08c056438 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1237,7 +1237,7 @@ static int mov_write_pcmc_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVTrack *tra
> track->par->codec_id == AV_CODEC_ID_PCM_S24LE ||
> track->par->codec_id == AV_CODEC_ID_PCM_S32LE);
> avio_w8(pb, format_flags);
> -avio_w8(pb, track->par->bits_per_raw_sample);
> +avio_w8(pb, track->par->bits_per_raw_sample ? 
> track->par->bits_per_raw_sample : track->par->bits_per_coded_sample);

Thanks for the bug report. I didn’t notice bits_per_raw_sample isn’t available
when remux raw PCM. It looks like a defect but I’m not sure.

Since both bits_per_raw_sample and bits_per_coded_sample can be 0 as the
comments in codec_par.h says, I decided to fallback to
av_get_exact_bits_per_sample().

http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312653.html

PS: Please follow the commit message format next time:

2.10 Writing a commit message
https://ffmpeg.org/git-howto.html#Writing-a-commit-message

> 
> return update_size(pb, pos);
> }
> -- 
> 2.39.2 (Apple Git-143)
> 
> ___
> 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] [Internet][PATCH 1/3] avcodec/videotoolboxenc: use color parameters conversion from avutil

[zhilizhao(赵志立)]

> On Jul 16, 2023, at 17:13, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> ---
> libavcodec/videotoolboxenc.c | 137 ---
> 1 file changed, 13 insertions(+), 124 deletions(-)
> 

Patchset applied.

___
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/33] fftools/ffmpeg_mux_init: return errors from of_open() instead of aborting

[zhilizhao(赵志立)]

> On Jul 13, 2023, at 18:55, Anton Khirnov  wrote:
> 
> ---
> fftools/ffmpeg_mux_init.c | 16 
> 1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
> index 6ab541d7c5..8a3e7b98cf 100644
> --- a/fftools/ffmpeg_mux_init.c
> +++ b/fftools/ffmpeg_mux_init.c
> @@ -2380,7 +2380,7 @@ int of_open(const OptionsContext *o, const char 
> *filename)
> int64_t start_time = o->start_time == AV_NOPTS_VALUE ? 0 : 
> o->start_time;
> if (stop_time <= start_time) {
> av_log(mux, AV_LOG_ERROR, "-to value smaller than -ss; 
> aborting.\n");
> -exit_program(1);
> +return AVERROR(EINVAL);

The log message still says ‘aborting’.

> } else {
> recording_time = stop_time - start_time;
> }
> @@ -2401,7 +2401,7 @@ int of_open(const OptionsContext *o, const char 
> *filename)
> if (!oc) {
> av_log(mux, AV_LOG_FATAL, "Error initializing the muxer for %s: %s\n",
>filename, av_err2str(err));
> -exit_program(1);
> +return err;
> }
> mux->fc = oc;
> 
> @@ -2437,7 +2437,7 @@ int of_open(const OptionsContext *o, const char 
> *filename)
>"Output filename '%s' does not contain a numeric pattern like "
>"'%%d', which is required by output format '%s'.\n",
>oc->url, oc->oformat->name);
> -exit_program(1);
> +return AVERROR(EINVAL);
> }
> 
> if (!(oc->oformat->flags & AVFMT_NOFILE)) {
> @@ -2450,7 +2450,7 @@ int of_open(const OptionsContext *o, const char 
> *filename)
>   >opts)) < 0) {
> av_log(mux, AV_LOG_FATAL, "Error opening output %s: %s\n",
>filename, av_err2str(err));
> -exit_program(1);
> +return err;
> }
> } else if (strcmp(oc->oformat->name, "image2")==0 && 
> !av_filename_number_test(filename))
> assert_file_overwrite(filename);
> @@ -2469,7 +2469,7 @@ int of_open(const OptionsContext *o, const char 
> *filename)
> err = set_dispositions(mux, o);
> if (err < 0) {
> av_log(mux, AV_LOG_FATAL, "Error setting output stream 
> dispositions\n");
> -exit_program(1);
> +return err;
> }
> 
> // parse forced keyframe specifications;
> @@ -2477,13 +2477,13 @@ int of_open(const OptionsContext *o, const char 
> *filename)
> err = process_forced_keyframes(mux, o);
> if (err < 0) {
> av_log(mux, AV_LOG_FATAL, "Error processing forced keyframes\n");
> -exit_program(1);
> +return err;
> }
> 
> err = setup_sync_queues(mux, oc, o->shortest_buf_duration * AV_TIME_BASE);
> if (err < 0) {
> av_log(mux, AV_LOG_FATAL, "Error setting up output sync queues\n");
> -exit_program(1);
> +return err;
> }
> 
> of->url= filename;
> @@ -2500,7 +2500,7 @@ int of_open(const OptionsContext *o, const char 
> *filename)
> 
> err = init_output_stream_nofilter(ost);
> if (err < 0)
> -report_and_exit(err);
> +return err;
> }
> 
> /* write the header for files with no streams */
> -- 
> 2.40.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: fix intraRefreshPeriod setting

[zhilizhao(赵志立)]

> On Jul 6, 2023, at 18:23, Timo Rothenpieler  wrote:
> 
> On 06/07/2023 14:00, Zhao Zhili wrote:
>> From: Zhao Zhili 
>> Regression since 99dfdb45. intraRefreshPeriod access cc->gopLength,
>> which has been overwritten to NVENC_INFINITE_GOPLENGTH before.
>> Fixes #10445.
>> ---
>>  libavcodec/nvenc.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
>> index 06579a502b..13fafcd246 100644
>> --- a/libavcodec/nvenc.c
>> +++ b/libavcodec/nvenc.c
>> @@ -1173,6 +1173,7 @@ static av_cold int 
>> nvenc_setup_h264_config(AVCodecContext *avctx)
>>  h264->enableIntraRefresh = 1;
>>  h264->intraRefreshPeriod = cc->gopLength;
>>  h264->intraRefreshCnt = cc->gopLength - 1;
>> +cc->gopLength = NVENC_INFINITE_GOPLENGTH;
>>  #ifdef NVENC_HAVE_SINGLE_SLICE_INTRA_REFRESH
>>  h264->singleSliceIntraRefresh = ctx->single_slice_intra_refresh;
>>  #endif
>> @@ -1297,6 +1298,7 @@ static av_cold int 
>> nvenc_setup_hevc_config(AVCodecContext *avctx)
>>  hevc->enableIntraRefresh = 1;
>>  hevc->intraRefreshPeriod = cc->gopLength;
>>  hevc->intraRefreshCnt = cc->gopLength - 1;
>> +cc->gopLength = NVENC_INFINITE_GOPLENGTH;
>>  #ifdef NVENC_HAVE_SINGLE_SLICE_INTRA_REFRESH
>>  hevc->singleSliceIntraRefresh = ctx->single_slice_intra_refresh;
>>  #endif
>> @@ -1415,6 +1417,7 @@ static av_cold int 
>> nvenc_setup_av1_config(AVCodecContext *avctx)
>>  av1->enableIntraRefresh = 1;
>>  av1->intraRefreshPeriod = cc->gopLength;
>>  av1->intraRefreshCnt = cc->gopLength - 1;
>> +cc->gopLength = NVENC_INFINITE_GOPLENGTH;
>>av1->idrPeriod = NVENC_INFINITE_GOPLENGTH;
>>  } else if (cc->gopLength > 0) {
>> @@ -1619,9 +1622,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  if(ctx->single_slice_intra_refresh)
>>  ctx->intra_refresh = 1;
>>  -if (ctx->intra_refresh)
>> -ctx->encode_config.gopLength = NVENC_INFINITE_GOPLENGTH;
>> -
>>  nvenc_recalc_surfaces(avctx);
>>nvenc_setup_rate_control(avctx);
> 
> Shouldn't it be enough to move this block down a bit, below 
> nvenc_setup_codec_config?
> That way the codec specific configs can still access the value, and the logic 
> of setting it to infinite for intra refresh mode doesn't have to be 
> duplicated everywhere.

Then people lost the context and hard to get why it should be put after
nvenc_setup_codec_config(), and might move it before by accident.

Another benefit to set cc->gopLength at here is idrPeriod can be set
to gopLength unconditionally:

http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/311694.html

To reduce code duplication, the codec specific intra_refresh configure
can be replaced by a macro, but it doesn’t looks good IMO.

> 
> Though I'm not sure which way I prefer. Having it in the intra_refresh 
> specific block in each codec definitely also has its advantage of keeping 
> that logic in one place.
> ___
> 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 2/3] avformat/tee: use av_dict_pop

[zhilizhao(赵志立)]

> On May 1, 2023, at 19:44, Marvin Scholz  wrote:
> 
> This is a well-defined way to "steal" the value of the dict entry.
> ---
> libavformat/tee.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index cb555f52fd..70f3f2eb29 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -157,6 +157,7 @@ static int open_slave(AVFormatContext *avf, char *slave, 
> TeeSlave *tee_slave)
> {
> int i, ret;
> AVDictionary *options = NULL, *bsf_options = NULL;
> +char *entry_val = NULL;
> AVDictionaryEntry *entry;
> char *filename;
> char *format = NULL, *select = NULL, *on_fail = NULL;
> @@ -171,15 +172,15 @@ static int open_slave(AVFormatContext *avf, char 
> *slave, TeeSlave *tee_slave)
> return ret;
> 
> #define CONSUME_OPTION(option, field, action) do {  \
> -if ((entry = av_dict_get(options, option, NULL, 0))) {  \
> -field = entry->value;   \
> +if ((!av_dict_pop(, option, NULL, _val, 0))) {\
> +field = entry_val;  \

Nit: You can remove the extra level of parentheses now.

> { action }  \
> -av_dict_set(, option, NULL, 0); \
> +av_freep(_val);   \
> }   \
> } while (0)
> #define STEAL_OPTION(option, field) \
> CONSUME_OPTION(option, field,   \
> -   entry->value = NULL; /* prevent it from being freed */)
> +   entry_val = NULL; /* prevent it from being freed */)
> #define PROCESS_OPTION(option, field, function, on_error)   \
> CONSUME_OPTION(option, field, if ((ret = function) < 0) { { on_error } 
> goto end; })
> 
> -- 
> 2.37.0 (Apple Git-136)
> 
> ___
> 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 2/3] avcodec/videotoolboxenc: remove AUTO_PROFILE define

[zhilizhao(赵志立)]

> On Jun 24, 2023, at 17:21, Tomas Härdin  wrote:
> 
> fre 2023-06-09 klockan 19:14 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> Use FF_PROFILE_UNKNOWN as auto mode.
> 
> Won't this break code that relies on AUTO_PROFILE? On the other hand

If you mean that setting profile via the integer number is broken, I had
the same consideration. Rick said "Only the string representation of the
profiles are documented. The mapping from integer to profile isn’t.”
I agree on this simple case.

http://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/310074.html

> zero refers to profiles that actually exist such as profile0 for vp9,
> so the old behavior is kinda bad.
> 
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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/21 v2] tests/fate: add a test for -streamloop with transcoding video+audio

[zhilizhao(赵志立)]

> On Jun 19, 2023, at 20:29, James Almer  wrote:
> 
> On 6/16/2023 3:01 AM, Anton Khirnov wrote:
>> ---
>> Now using aacdec_fixed with s32le output
>> ---
>>  tests/fate/ffmpeg.mak |   4 +
>>  tests/ref/fate/ffmpeg-streamloop-transcode-av | 151 ++
>>  2 files changed, 155 insertions(+)
>>  create mode 100644 tests/ref/fate/ffmpeg-streamloop-transcode-av
>> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
>> index c26c748934..87cd0b46d0 100644
>> --- a/tests/fate/ffmpeg.mak
>> +++ b/tests/fate/ffmpeg.mak
>> @@ -132,6 +132,10 @@ fate-ffmpeg-fix_sub_duration_heartbeat: CMD = fmtstdout 
>> srt -fix_sub_duration \
>>-c:s srt \
>>-f null -
>>  +FATE_SAMPLES_FFMPEG-$(call FRAMECRC, MATROSKA, H264 AAC_FIXED, 
>> PCM_S32LE_ENCODER) += fate-ffmpeg-streamloop-transcode-av
>> +fate-ffmpeg-streamloop-transcode-av: CMD = \
>> + framecrc -auto_conversion_filters -stream_loop 3 -i 
>> $(TARGET_SAMPLES)/mkv/1242-small.mkv -c:a pcm_s32le
> 
> I think this is missing -c:a ac3_fixed before the -i

You mean aac_fixed? I have tried, but the result on two processor don't match 
neither.

> 
>> +
>>  FATE_STREAMCOPY-$(call REMUX, MP4 MOV, EAC3_DEMUXER) += fate-copy-trac3074
>>  fate-copy-trac3074: CMD = transcode eac3 
>> $(TARGET_SAMPLES)/eac3/csi_miami_stereo_128_spx.eac3\
>>   mp4 "-codec copy -map 0" "-codec copy"
>> diff --git a/tests/ref/fate/ffmpeg-streamloop-transcode-av 
>> b/tests/ref/fate/ffmpeg-streamloop-transcode-av
>> new file mode 100644
>> index 00..50a626b281
>> --- /dev/null
>> +++ b/tests/ref/fate/ffmpeg-streamloop-transcode-av
>> @@ -0,0 +1,151 @@
>> +#tb 0: 125/2997
>> +#media_type 0: video
>> +#codec_id 0: rawvideo
>> +#dimensions 0: 1280x718
>> +#sar 0: 1/1
>> +#tb 1: 1/48000
>> +#media_type 1: audio
>> +#codec_id 1: pcm_s32le
>> +#sample_rate 1: 48000
>> +#channel_layout_name 1: stereo
>> +0,  0,  0,1,  1378560, 0xbaf121ba
>> +1,  0,  0, 1024, 8192, 0x
>> +1,   1024,   1024, 1024, 8192, 0x
>> +0,  1,  1,1,  1378560, 0xbaf121ba
>> +1,   2040,   2040, 1024, 8192, 0x
>> +1,   3048,   3048, 1024, 8192, 0x
>> +0,  2,  2,1,  1378560, 0x6579d31a
>> +1,   4072,   4072, 1024, 8192, 0x
>> +1,   5096,   5096, 1024, 8192, 0x
>> +0,  3,  3,1,  1378560, 0xca1deba8
>> +1,   6120,   6120, 1024, 8192, 0x687330d2
>> +1,   7128,   7128, 1024, 8192, 0x9131462c
>> +0,  4,  4,1,  1378560, 0xd4eed467
>> +1,   8208,   8208, 1024, 8192, 0x48c01c32
>> +1,   9232,   9232, 1024, 8192, 0x0ccd8d5f
>> +0,  5,  5,1,  1378560, 0xd6e1d5b7
>> +1,  10248,  10248, 1024, 8192, 0xd50cbe9f
>> +1,  11256,  11256, 1024, 8192, 0xbe069303
>> +0,  6,  6,1,  1378560, 0x0b574d39
>> +1,  12280,  12280, 1024, 8192, 0x85fccf5b
>> +1,  13304,  13304, 1024, 8192, 0x4180de71
>> +0,  7,  7,1,  1378560, 0x1bdd4d61
>> +1,  14328,  14328, 1024, 8192, 0x0e9b6ac3
>> +1,  15336,  15336, 1024, 8192, 0x5c33f724
>> +0,  8,  8,1,  1378560, 0x3b28f549
>> +1,  16360,  16360, 1024, 8192, 0x668aaaec
>> +1,  17384,  17384, 1024, 8192, 0xd137d412
>> +0,  9,  9,1,  1378560, 0x45b2f57b
>> +1,  18408,  18408, 1024, 8192, 0x08e1fbf6
>> +1,  19416,  19416, 1024, 8192, 0xbf3fb4f6
>> +0, 10, 10,1,  1378560, 0x8955570e
>> +1,  20440,  20440, 1024, 8192, 0x69cd08a4
>> +1,  21464,  21464, 1024, 8192, 0xe0fe6297
>> +1,  22488,  22488, 1024, 8192, 0x172867ad
>> +1,  23496,  23496, 1024, 8192, 0xcbcc1461
>> +0, 12, 12,1,  1378560, 0x9c598000
>> +1,  25488,  25488, 1024, 8192, 0x
>> +0, 13, 13,1,  1378560, 0xbaf121ba
>> +1,  26512,  26512, 1024, 8192, 0x
>> +1,  27528,  27528, 1024, 8192, 0x
>> +0, 14, 14,1,  1378560, 0xbaf121ba
>> +1,  28552,  28552, 1024, 8192, 0x
>> +1,  29576,  29576, 1024, 8192, 0x
>> +0, 15, 15,1,  1378560, 0x6579d31a
>> +1,  30600,  30600, 1024, 8192, 0x687330d2
>> +1,  31608,  31608, 1024, 8192, 0x9131462c
>> +0, 16, 16,1,  1378560, 0xca1deba8
>> +1,  32688,  32688, 1024, 8192, 0x48c01c32
>> +1,  33712,  33712, 1024, 8192, 0x0ccd8d5f
>> +0, 17, 17,1,  1378560, 

Re: [FFmpeg-devel] [PATCH 04/21 v2] tests/fate: add a test for -streamloop with transcoding video+audio

[zhilizhao(赵志立)]

> On Jun 16, 2023, at 14:01, Anton Khirnov  wrote:
> 
> ---
> Now using aacdec_fixed with s32le output
> ---
> tests/fate/ffmpeg.mak |   4 +
> tests/ref/fate/ffmpeg-streamloop-transcode-av | 151 ++
> 2 files changed, 155 insertions(+)
> create mode 100644 tests/ref/fate/ffmpeg-streamloop-transcode-av
> 
> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
> index c26c748934..87cd0b46d0 100644
> --- a/tests/fate/ffmpeg.mak
> +++ b/tests/fate/ffmpeg.mak
> @@ -132,6 +132,10 @@ fate-ffmpeg-fix_sub_duration_heartbeat: CMD = fmtstdout 
> srt -fix_sub_duration \
>   -c:s srt \
>   -f null -
> 
> +FATE_SAMPLES_FFMPEG-$(call FRAMECRC, MATROSKA, H264 AAC_FIXED, 
> PCM_S32LE_ENCODER) += fate-ffmpeg-streamloop-transcode-av
> +fate-ffmpeg-streamloop-transcode-av: CMD = \
> + framecrc -auto_conversion_filters -stream_loop 3 -i 
> $(TARGET_SAMPLES)/mkv/1242-small.mkv -c:a pcm_s32le
> +

This test success on Intel(R) Core(TM) i7-10700 but failed on AMD EPYC 7K62.

--- /home/ubuntu/work/ffmpeg/tests/ref/fate/ffmpeg-streamloop-transcode-av  
2023-06-19 18:49:26.666355000 +0800
+++ tests/data/fate/ffmpeg-streamloop-transcode-av  2023-06-19 
18:49:40.674355000 +0800
@@ -19,30 +19,30 @@   

 1,   5096,   5096, 1024, 8192, 0x
 0,  3,  3,1,  1378560, 0xca1deba8
 1,   6120,   6120, 1024, 8192, 0x687330d2
-1,   7128,   7128, 1024, 8192, 0x9131462c
+1,   7128,   7128, 1024, 8192, 0x039b4628
 0,  4,  4,1,  1378560, 0xd4eed467
-1,   8208,   8208, 1024, 8192, 0x48c01c32
-1,   9232,   9232, 1024, 8192, 0x0ccd8d5f
+1,   8208,   8208, 1024, 8192, 0x4cbe1c62
+1,   9232,   9232, 1024, 8192, 0x1d8b8ad3

…


> FATE_STREAMCOPY-$(call REMUX, MP4 MOV, EAC3_DEMUXER) += fate-copy-trac3074
> fate-copy-trac3074: CMD = transcode eac3 
> $(TARGET_SAMPLES)/eac3/csi_miami_stereo_128_spx.eac3\
>  mp4 "-codec copy -map 0" "-codec copy"
> diff --git a/tests/ref/fate/ffmpeg-streamloop-transcode-av 
> b/tests/ref/fate/ffmpeg-streamloop-transcode-av
> new file mode 100644
> index 00..50a626b281
> --- /dev/null
> +++ b/tests/ref/fate/ffmpeg-streamloop-transcode-av
> @@ -0,0 +1,151 @@
> +#tb 0: 125/2997
> +#media_type 0: video
> +#codec_id 0: rawvideo
> +#dimensions 0: 1280x718
> +#sar 0: 1/1
> +#tb 1: 1/48000
> +#media_type 1: audio
> +#codec_id 1: pcm_s32le
> +#sample_rate 1: 48000
> +#channel_layout_name 1: stereo
> +0,  0,  0,1,  1378560, 0xbaf121ba
> +1,  0,  0, 1024, 8192, 0x
> +1,   1024,   1024, 1024, 8192, 0x
> +0,  1,  1,1,  1378560, 0xbaf121ba
> +1,   2040,   2040, 1024, 8192, 0x
> +1,   3048,   3048, 1024, 8192, 0x
> +0,  2,  2,1,  1378560, 0x6579d31a
> +1,   4072,   4072, 1024, 8192, 0x
> +1,   5096,   5096, 1024, 8192, 0x
> +0,  3,  3,1,  1378560, 0xca1deba8
> +1,   6120,   6120, 1024, 8192, 0x687330d2
> +1,   7128,   7128, 1024, 8192, 0x9131462c
> +0,  4,  4,1,  1378560, 0xd4eed467
> +1,   8208,   8208, 1024, 8192, 0x48c01c32
> +1,   9232,   9232, 1024, 8192, 0x0ccd8d5f
> +0,  5,  5,1,  1378560, 0xd6e1d5b7
> +1,  10248,  10248, 1024, 8192, 0xd50cbe9f
> +1,  11256,  11256, 1024, 8192, 0xbe069303
> +0,  6,  6,1,  1378560, 0x0b574d39
> +1,  12280,  12280, 1024, 8192, 0x85fccf5b
> +1,  13304,  13304, 1024, 8192, 0x4180de71
> +0,  7,  7,1,  1378560, 0x1bdd4d61
> +1,  14328,  14328, 1024, 8192, 0x0e9b6ac3
> +1,  15336,  15336, 1024, 8192, 0x5c33f724
> +0,  8,  8,1,  1378560, 0x3b28f549
> +1,  16360,  16360, 1024, 8192, 0x668aaaec
> +1,  17384,  17384, 1024, 8192, 0xd137d412
> +0,  9,  9,1,  1378560, 0x45b2f57b
> +1,  18408,  18408, 1024, 8192, 0x08e1fbf6
> +1,  19416,  19416, 1024, 8192, 0xbf3fb4f6
> +0, 10, 10,1,  1378560, 0x8955570e
> +1,  20440,  20440, 1024, 8192, 0x69cd08a4
> +1,  21464,  21464, 1024, 8192, 0xe0fe6297
> +1,  22488,  22488, 1024, 8192, 0x172867ad
> +1,  23496,  23496, 1024, 8192, 0xcbcc1461
> +0, 12, 12,1,  1378560, 0x9c598000
> +1,  25488,  25488, 1024, 8192, 0x
> +0, 13, 13,1,  1378560, 0xbaf121ba
> +1,  26512,  26512, 1024, 8192, 0x
> +1, 

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix overallocation when reading pssh/saiz

[zhilizhao(赵志立)]

> On Jun 12, 2023, at 20:06, Marvin Scholz (ePirat)  wrote:
> 
> Hi,
> 
>> On 12. Jun 2023, at 13:56, Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> mov_try_read_block() allocates 1MB at least, which can be more than
>> enough. It was called when reading saiz box, which can appear
>> periodically inside fmp4. This consumes a lot of memory.
>> 
>> We can fix mov_try_read_block() by clamp 'block_size' with 'size'.
>> However, the function is harmful than helpful. It avoids allocating
>> large memory when the real data is small. Even in that case, if
>> allocating large memory directly failed, it's fine to return ENOMEM;
>> if allocating success and reading doesn't match the given size, it's
>> fine to free and return AVERROR_INVALIDDATA. In other cases, it's a
>> waste of CPU and memory.
>> 
>> So I decided to remove the function, and replace it by call
>> av_malloc() and avio_read() directly.
>> 
>> mov_read_saiz() and mov_read_pssh() need more check, but they don't
>> belong to this patch.
>> 
>> Fixes #7641 and #9243.
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> libavformat/mov.c | 63 +++
>> 1 file changed, 25 insertions(+), 38 deletions(-)
>> 
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index a8d004e02b..3d0969545a 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -6649,38 +6649,6 @@ finish:
>>return ret;
>> }
>> 
>> -/**
>> - * Tries to read the given number of bytes from the stream and puts it in a
>> - * newly allocated buffer.  This reads in small chunks to avoid allocating 
>> large
>> - * memory if the file contains an invalid/malicious size value.
> 
> I fail to see how your replacement code addresses the malicious size value 
> case that this function mitigated, see in more detail what I mean below…
> 
>> - */
>> -static int mov_try_read_block(AVIOContext *pb, size_t size, uint8_t **data)
>> -{
>> -const unsigned int block_size = 1024 * 1024;
>> -uint8_t *buffer = NULL;
>> -unsigned int alloc_size = 0, offset = 0;
>> -while (offset < size) {
>> -unsigned int new_size =
>> -alloc_size >= INT_MAX - block_size ? INT_MAX : alloc_size + 
>> block_size;
>> -uint8_t *new_buffer = av_fast_realloc(buffer, _size, 
>> new_size);
>> -unsigned int to_read = FFMIN(size, alloc_size) - offset;
>> -if (!new_buffer) {
>> -av_free(buffer);
>> -return AVERROR(ENOMEM);
>> -}
>> -buffer = new_buffer;
>> -
>> -if (avio_read(pb, buffer + offset, to_read) != to_read) {
>> -av_free(buffer);
>> -return AVERROR_INVALIDDATA;
>> -}
>> -offset += to_read;
>> -}
>> -
>> -*data = buffer;
>> -return 0;
>> -}
>> -
>> static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> {
>>MOVEncryptionIndex *encryption_index;
>> @@ -6736,15 +6704,24 @@ static int mov_read_saiz(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>> 
>>encryption_index->auxiliary_info_default_size = avio_r8(pb);
>>sample_count = avio_rb32(pb);
>> -encryption_index->auxiliary_info_sample_count = sample_count;
>> 
>>if (encryption_index->auxiliary_info_default_size == 0) {
>> -ret = mov_try_read_block(pb, sample_count, 
>> _index->auxiliary_info_sizes);
>> -if (ret < 0) {
>> -av_log(c->fc, AV_LOG_ERROR, "Failed to read the auxiliary 
>> info\n");
>> +encryption_index->auxiliary_info_sizes = av_malloc(sample_count);
>> +if (!encryption_index->auxiliary_info_sizes)
>> +return AVERROR(ENOMEM);
>> +
>> +ret = avio_read(pb, encryption_index->auxiliary_info_sizes, 
>> sample_count);
>> +if (ret != sample_count) {
>> +av_freep(_index->auxiliary_info_sizes);
>> +
>> +if (ret >= 0)
>> +ret = AVERROR_INVALIDDATA;
>> +av_log(c->fc, AV_LOG_ERROR, "Failed to read the auxiliary info, 
>> %s\n",
>> +   av_err2str(ret));
>>return ret;
>>}
>>}
>> +encryption_index->auxiliary_info_sample_count = sample_count;
>> 
>>if (encryption_index->auxiliary_offsets_count) {
>>return mov_parse_auxiliary_info(c, sc, pb, encryption_index);
>> @@ -6913,9 +6890,19 @@ static int mov_read_pssh(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>>}
>> 
>>extra_data_size = avio_rb32(pb);
>> -ret = mov_try_read_block(pb, extra_data_size, _data);
>> -if (ret < 0)
>> +extra_data = av_malloc(extra_data_size);
> 
> If I understand correctly you are now effectively passing a potentially 
> malicious size value directly to malloc, allowing an attacker to exhaust 
> memory with a crafted file.

1. If malloc failed, it doesn’t exhaust memory.

2. If malloc success and the real data is less than extra_data_size, the memory 
will be freed immediately.

3. Almost every box with undetermined length of entries have this issue.

4. We can check 

Re: [FFmpeg-devel] [Internet][PATCH 1/6] avcodec/cbs: add API to discard units by AVDiscard

[zhilizhao(赵志立)]

> On May 29, 2023, at 20:32, zhilizhao(赵志立)  wrote:
> 
> Ping. Any comments on the idea?
> 
>> On May 18, 2023, at 05:23, Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> ---
>> libavcodec/cbs.c  | 21 +
>> libavcodec/cbs.h  | 17 +
>> libavcodec/cbs_internal.h |  6 ++
>> 3 files changed, 44 insertions(+)
>> 

Ping again. I’m planning to push this week if no objection.

___
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] avformat/mov: Don't allocate unnecessarily large blocks of memory

[zhilizhao(赵志立)]

> On Jun 9, 2023, at 07:51, Hendi  wrote:
> 
> mov_try_read_block is regularly called with sizes such as 48 bytes,
> but would allocate 1 MiB each time, hogging more and more memory
> until playback ends.
> 
> Fixes #7641 and #9243.

It’s a quick fix, but I’m afraid the two tickets are caused by more deep
pitfalls.

It would be helpful if someone can provide a sample for test.

> 
> Signed-off-by: Hendi 
> ---
> libavformat/mov.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a8d004e02b..2e4df42256 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6662,6 +6662,9 @@ static int mov_try_read_block(AVIOContext *pb, size_t 
> size, uint8_t **data)
> while (offset < size) {
> unsigned int new_size =
> alloc_size >= INT_MAX - block_size ? INT_MAX : alloc_size + 
> block_size;
> +if (size < new_size) {
> +new_size = size;
> +}
> uint8_t *new_buffer = av_fast_realloc(buffer, _size, new_size);
> unsigned int to_read = FFMIN(size, alloc_size) - offset;
> if (!new_buffer) {
> -- 
> 2.40.0.windows.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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] lavc/qsvdec: respect AVCodecContext->{width, height}

[zhilizhao(赵志立)]

> On Jun 8, 2023, at 13:47, Xiang, Haihao 
>  wrote:
> 
> From: Haihao Xiang 
> 
> width and height may be known from the container
> 
> Signed-off-by: Haihao Xiang 
> ---
> libavcodec/qsvdec.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index da700f25e9..5325030ea1 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -910,6 +910,7 @@ static int qsv_process_data(AVCodecContext *avctx, 
> QSVContext *q,
> }
> 
> if (q->reinit_flag || !q->session || !q->initialized) {
> +int reset_crop = !q->session;
> mfxFrameAllocRequest request;
> memset(, 0, sizeof(request));
> 
> @@ -929,6 +930,11 @@ static int qsv_process_data(AVCodecContext *avctx, 
> QSVContext *q,
> avctx->coded_width  = param.mfx.FrameInfo.Width;
> avctx->coded_height = param.mfx.FrameInfo.Height;
> 
> +if (reset_crop && avctx->width && avctx->height) {
> +param.mfx.FrameInfo.CropW = avctx->width;
> +param.mfx.FrameInfo.CropH = avctx->height;
> +}
> +

I can see two issues here:

1. Reset CropW/CropH from container without reset CropX/CropY might create some
mismatch.

2. Width/Height from container can be larger than coded_width/coded_height. For
example, mp4 container can apply a scaling after decoding. So decoder should 
only
care about ES, while user can apply the info from container after decoding, 
like 
rotation, scaling and cropping. But it’s complex in practice.

I don’t have idea for these issues.

> ret = MFXVideoDECODE_QueryIOSurf(q->session, , );
> if (ret < 0)
> return ff_qsv_print_error(avctx, ret, "Error querying IO 
> surface");
> -- 
> 2.34.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS attribute of H.264

[zhilizhao(赵志立)]

> On May 30, 2023, at 12:44, Lance Wang  wrote:
> 
> On Tue, May 30, 2023 at 11:09 AM "zhilizhao(赵志立)" 
> wrote:
> 
>> 
>> 
>>> On May 30, 2023, at 09:03, Lance Wang  wrote:
>>> 
>>> On Mon, May 29, 2023 at 10:16 PM Zhao Zhili 
>> wrote:
>>> 
>>>> From: Zhao Zhili 
>>>> 
>>>> Signed-off-by: Zhao Zhili 
>>>> ---
>>>> libavformat/hlsenc.c | 14 --
>>>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>>> index 871afb571b..1e0848ce3d 100644
>>>> --- a/libavformat/hlsenc.c
>>>> +++ b/libavformat/hlsenc.c
>>>> @@ -355,9 +355,19 @@ static void write_codec_attr(AVStream *st,
>>>> VariantStream *vs)
>>>> 
>>>>if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>>>>uint8_t *data = st->codecpar->extradata;
>>>> -if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1
>> &&
>>>> (data[4] & 0x1F) == 7) {
>>>> +if (data) {
>>>> +const uint8_t *p;
>>>> +
>>>> +if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
>>>> +p = [5];
>>>> +else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
>>>> +p = [4];
>>>> +else if (data[0] == 0x01)  /* avcC */
>>>> +p = [1];
>>>> +else
>>>> +goto fail;
>>>> 
>>> 
>>> how to reproduce the issue? I recall mpegts is annex b format and sps/pps
>>> start code is 4 byte always.
>> 
>> For example:
>> 
>> ffmpeg -i foo.mp4 -c copy -hls_playlist_type vod -master_pl_name bar.m3u8
>> test.m3u8
>> 
>> 1. The input of hls muxer can be avcc
>> 
>> 2. The output of hls muxer can be avcc too, with fmp4 segments.
>> 
>> 
> Yes, this is the case. I had to add mp4toannexb bsf after the copy for avcc
> input.  If we
> don't add the format conversion, hevc may  have the same issue I guess.

Use mp4toannexb for TS segments is a good practice, but not for
fmp4.

No comments on hevc.

> Also we should
> check the size of extradata.

extradata has a AV_INPUT_BUFFER_PADDING_SIZE, so not necessary.

> 
> 
> 
>> 3. Start code of SPS/PPS should be 0 0 0 1, however, 0 0 1 exist in wild.
>> ff_isom_write_avcc() does the same:
>> 
>>/* check for H.264 start code */
>>if (AV_RB32(data) != 0x0001 &&
>>AV_RB24(data) != 0x01) {
>>avio_write(pb, data, len);
>>return 0;
>>}
>> 
>> ff_isom_write_avcc() can be used here, and get/create CODECS attribute can
>> be
>> shared by multiple muxers. I won't go that further by now.
>> 
>> 
> The next NALU checking is for SPS only, so one more byte is zero_byte. It's
> required by specs:
> 
> zero_byte is a single byte equal to 0x00.
> 
> When any of the following conditions are true, the zero_byte syntax element
> shall be present:
> 
>   -
> 
>   –  the nal_unit_type within the nal_unit( ) is equal to 7 (sequence
>   parameter set) or 8 (picture parameter set),
>   -
> 
>   –  the byte stream NAL unit syntax structure contains the first NAL unit
>   of an access unit in decoding order, as specified in clause 7.4.1.2.3.

Yes, but it’s not the first time people don’t follow spec.


> 
> 
> 
>> 
>>> 
>>> 
>>>>snprintf(attr, sizeof(attr),
>>>> - "avc1.%02x%02x%02x", data[5], data[6], data[7]);
>>>> + "avc1.%02x%02x%02x", p[0], p[1], p[2]);
>>>>} else {
>>>>goto fail;
>>>>}
>>>> --
>>>> 2.25.1
>>>> 
>>>> ___
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>> 
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> 
>> ___
>> 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] avformat/hlsenc: fix CODECS attribute of H.264

[zhilizhao(赵志立)]

> On May 30, 2023, at 09:03, Lance Wang  wrote:
> 
> On Mon, May 29, 2023 at 10:16 PM Zhao Zhili  wrote:
> 
>> From: Zhao Zhili 
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> libavformat/hlsenc.c | 14 --
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 871afb571b..1e0848ce3d 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -355,9 +355,19 @@ static void write_codec_attr(AVStream *st,
>> VariantStream *vs)
>> 
>> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> uint8_t *data = st->codecpar->extradata;
>> -if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 &&
>> (data[4] & 0x1F) == 7) {
>> +if (data) {
>> +const uint8_t *p;
>> +
>> +if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
>> +p = [5];
>> +else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
>> +p = [4];
>> +else if (data[0] == 0x01)  /* avcC */
>> +p = [1];
>> +else
>> +goto fail;
>> 
> 
> how to reproduce the issue? I recall mpegts is annex b format and sps/pps
> start code is 4 byte always.

For example:

ffmpeg -i foo.mp4 -c copy -hls_playlist_type vod -master_pl_name bar.m3u8 
test.m3u8

1. The input of hls muxer can be avcc

2. The output of hls muxer can be avcc too, with fmp4 segments.

3. Start code of SPS/PPS should be 0 0 0 1, however, 0 0 1 exist in wild.
ff_isom_write_avcc() does the same:

/* check for H.264 start code */
if (AV_RB32(data) != 0x0001 &&
AV_RB24(data) != 0x01) {
avio_write(pb, data, len);
return 0;
}

ff_isom_write_avcc() can be used here, and get/create CODECS attribute can be
shared by multiple muxers. I won't go that further by now.


> 
> 
>> snprintf(attr, sizeof(attr),
>> - "avc1.%02x%02x%02x", data[5], data[6], data[7]);
>> + "avc1.%02x%02x%02x", p[0], p[1], p[2]);
>> } else {
>> goto fail;
>> }
>> --
>> 2.25.1
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
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/5] avcodec/h264_mp4toannexb_bsf: refactor start_code_size handling

[zhilizhao(赵志立)]

> On May 29, 2023, at 23:54, myp...@gmail.com wrote:
> 
> On Fri, May 19, 2023 at 4:41 PM Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> start_code_size depends on whether PS comes from out-of-band or
>> in-band. Make the code more readable.
>> ---
>> libavcodec/h264_mp4toannexb_bsf.c | 34 ---
>> 1 file changed, 27 insertions(+), 7 deletions(-)
>> 
>> diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
>> b/libavcodec/h264_mp4toannexb_bsf.c
>> index d11be455c2..7dce1ae9b6 100644
>> --- a/libavcodec/h264_mp4toannexb_bsf.c
>> +++ b/libavcodec/h264_mp4toannexb_bsf.c
>> @@ -43,10 +43,26 @@ typedef struct H264BSFContext {
>> int  extradata_parsed;
>> } H264BSFContext;
>> 
>> +enum PsSource {
>> +PS_OUT_OF_BAND = -1,
>> +PS_NONE = 0,
>> +PS_IN_BAND = 1,
>> +};
>> +
>> static void count_or_copy(uint8_t **out, uint64_t *out_size,
>> -  const uint8_t *in, int in_size, int ps, int copy)
>> +  const uint8_t *in, int in_size, enum PsSource ps, 
>> int copy)
>> {
>> -uint8_t start_code_size = ps < 0 ? 0 : *out_size == 0 || ps ? 4 : 3;
>> +uint8_t start_code_size;
>> +
>> +if (ps == PS_OUT_OF_BAND)
>> +/* start code already present in out-of-band ps data, so don't need 
>> to
>> + * add it manually again
>> + */
>> +start_code_size = 0;
>> +else if (ps == PS_IN_BAND || *out_size == 0)
>> +start_code_size = 4;
>> +else
>> +start_code_size = 3;
> I prefer the original style, they are shorter and more concise

It takes a little time to figure out what two ternary do in a
single statement, it takes more time to figure out why, and
multiple ternaries is hard to write comments properly.

Multiple ternaries in a single statement works in simple cases.
For current situation, I prefer ‘if-else’.

>> 
>> if (copy) {
>> memcpy(*out + start_code_size, in, in_size);
>> @@ -202,6 +218,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
>> AVPacket *opkt)
>> 
>> do {
>> uint32_t nal_size = 0;
>> +enum PsSource ps;
>> 
>> /* possible overread ok due to padding */
>> for (int i = 0; i < s->length_size; i++)
>> @@ -230,7 +247,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
>> AVPacket *opkt)
>> if (!s->sps_size) {
>> LOG_ONCE(ctx, AV_LOG_WARNING, "SPS not present in 
>> the stream, nor in AVCC, stream may be unreadable\n");
>> } else {
>> -count_or_copy(, _size, s->sps, s->sps_size, 
>> -1, j);
>> +count_or_copy(, _size, s->sps, s->sps_size, 
>> PS_OUT_OF_BAND, j);
>> sps_seen = 1;
>> }
>> }
>> @@ -246,19 +263,22 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
>> AVPacket *opkt)
>> if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen && 
>> !pps_seen) {
>> if (ctx->par_out->extradata)
>> count_or_copy(, _size, ctx->par_out->extradata,
>> -  ctx->par_out->extradata_size, -1, j);
>> +  ctx->par_out->extradata_size, 
>> PS_OUT_OF_BAND, j);
>> new_idr = 0;
>> /* if only SPS has been seen, also insert PPS */
>> } else if (new_idr && unit_type == H264_NAL_IDR_SLICE && 
>> sps_seen && !pps_seen) {
>> if (!s->pps_size) {
>> LOG_ONCE(ctx, AV_LOG_WARNING, "PPS not present in the 
>> stream, nor in AVCC, stream may be unreadable\n");
>> } else {
>> -count_or_copy(, _size, s->pps, s->pps_size, -1, 
>> j);
>> +count_or_copy(, _size, s->pps, s->pps_size, 
>> PS_OUT_OF_BAND, j);
>> }
>> }
>> 
>> -count_or_copy(, _size, buf, nal_size,
>> -  unit_type == H264_NAL_SPS || unit_type == 
>> H264_NAL_PPS, j);
>> +if (unit_type == H264_NAL_SPS || unit_type == H264_NAL_PPS)
>> +ps = PS_IN_BAND;
>> +else
>> +ps = PS_NONE;
>> +count_or_copy(, _size, buf, nal_size, ps, j);
>> if (!new_idr && unit_type == H264_NAL_SLICE) {
>> new_idr  = 1;
>> sps_seen = 0;
>> --
>> 2.25.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".
> 
> 
> 
> -- 
> ===
> Jun zhao/赵军
> +++
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To 

Re: [FFmpeg-devel] [Internet][PATCH 1/6] avcodec/cbs: add API to discard units by AVDiscard

[zhilizhao(赵志立)]

Ping. Any comments on the idea?

> On May 18, 2023, at 05:23, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> ---
> libavcodec/cbs.c  | 21 +
> libavcodec/cbs.h  | 17 +
> libavcodec/cbs_internal.h |  6 ++
> 3 files changed, 44 insertions(+)
> 
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index 504197e06d..cf5211249b 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -1026,3 +1026,24 @@ int ff_cbs_make_unit_writable(CodedBitstreamContext 
> *ctx,
> av_buffer_unref();
> return 0;
> }
> +
> +void ff_cbs_discard_units(CodedBitstreamContext *ctx,
> +  CodedBitstreamFragment *frag,
> +  enum AVDiscard skip,
> +  int flags)
> +{
> +if (!ctx->codec->discarded_unit)
> +return;
> +
> +for (int i = frag->nb_units - 1; i >= 0; i--) {
> +if (ctx->codec->discarded_unit(ctx, >units[i], skip)) {
> +// discard all units
> +if (!(flags & DISCARD_FLAG_KEEP_NON_VCL)) {
> +ff_cbs_fragment_free(frag);
> +return;
> +}
> +
> +ff_cbs_delete_unit(frag, i);
> +}
> +}
> +}
> diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
> index ee21623dac..b4131db5fe 100644
> --- a/libavcodec/cbs.h
> +++ b/libavcodec/cbs.h
> @@ -26,6 +26,7 @@
> 
> #include "codec_id.h"
> #include "codec_par.h"
> +#include "defs.h"
> #include "packet.h"
> 
> 
> @@ -432,5 +433,21 @@ int ff_cbs_make_unit_refcounted(CodedBitstreamContext 
> *ctx,
> int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
>   CodedBitstreamUnit *unit);
> 
> +enum CbsDiscardFlags {
> +DISCARD_FLAG_NONE = 0,
> +
> +/**
> + * keep non-vcl units even if the picture has been dropped.
> + */
> +DISCARD_FLAG_KEEP_NON_VCL = 0x01,
> +};
> +
> +/**
> + * Discard units accroding to 'skip'.
> + */
> +void ff_cbs_discard_units(CodedBitstreamContext *ctx,
> +  CodedBitstreamFragment *frag,
> +  enum AVDiscard skip,
> +  int flags);
> 
> #endif /* AVCODEC_CBS_H */
> diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
> index e585c77934..077954eee5 100644
> --- a/libavcodec/cbs_internal.h
> +++ b/libavcodec/cbs_internal.h
> @@ -133,6 +133,12 @@ typedef struct CodedBitstreamType {
>   CodedBitstreamUnit *unit,
>   PutBitContext *pbc);
> 
> +// Return 1 when the unit should be dropped according to 'skip',
> +// 0 otherwise.
> +int (*discarded_unit)(CodedBitstreamContext *ctx,
> +  const CodedBitstreamUnit *unit,
> +  enum AVDiscard skip);
> +
> // Read the data from all of frag->units and assemble it into
> // a bitstream for the whole fragment.
> int (*assemble_fragment)(CodedBitstreamContext *ctx,
> -- 
> 2.25.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 1/5] avcodec/h264_mp4toannexb_bsf: refactor start_code_size handling

[zhilizhao(赵志立)]

Ping for the patchset.

> On May 20, 2023, at 00:41, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> start_code_size depends on whether PS comes from out-of-band or
> in-band. Make the code more readable.
> ---
> libavcodec/h264_mp4toannexb_bsf.c | 34 ---
> 1 file changed, 27 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
> b/libavcodec/h264_mp4toannexb_bsf.c
> index d11be455c2..7dce1ae9b6 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -43,10 +43,26 @@ typedef struct H264BSFContext {
> int  extradata_parsed;
> } H264BSFContext;
> 
> +enum PsSource {
> +PS_OUT_OF_BAND = -1,
> +PS_NONE = 0,
> +PS_IN_BAND = 1,
> +};
> +
> static void count_or_copy(uint8_t **out, uint64_t *out_size,
> -  const uint8_t *in, int in_size, int ps, int copy)
> +  const uint8_t *in, int in_size, enum PsSource ps, 
> int copy)
> {
> -uint8_t start_code_size = ps < 0 ? 0 : *out_size == 0 || ps ? 4 : 3;
> +uint8_t start_code_size;
> +
> +if (ps == PS_OUT_OF_BAND)
> +/* start code already present in out-of-band ps data, so don't need 
> to
> + * add it manually again
> + */
> +start_code_size = 0;
> +else if (ps == PS_IN_BAND || *out_size == 0)
> +start_code_size = 4;
> +else
> +start_code_size = 3;
> 
> if (copy) {
> memcpy(*out + start_code_size, in, in_size);
> @@ -202,6 +218,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *opkt)
> 
> do {
> uint32_t nal_size = 0;
> +enum PsSource ps;
> 
> /* possible overread ok due to padding */
> for (int i = 0; i < s->length_size; i++)
> @@ -230,7 +247,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *opkt)
> if (!s->sps_size) {
> LOG_ONCE(ctx, AV_LOG_WARNING, "SPS not present in the 
> stream, nor in AVCC, stream may be unreadable\n");
> } else {
> -count_or_copy(, _size, s->sps, s->sps_size, 
> -1, j);
> +count_or_copy(, _size, s->sps, s->sps_size, 
> PS_OUT_OF_BAND, j);
> sps_seen = 1;
> }
> }
> @@ -246,19 +263,22 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *opkt)
> if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen && 
> !pps_seen) {
> if (ctx->par_out->extradata)
> count_or_copy(, _size, ctx->par_out->extradata,
> -  ctx->par_out->extradata_size, -1, j);
> +  ctx->par_out->extradata_size, 
> PS_OUT_OF_BAND, j);
> new_idr = 0;
> /* if only SPS has been seen, also insert PPS */
> } else if (new_idr && unit_type == H264_NAL_IDR_SLICE && sps_seen 
> && !pps_seen) {
> if (!s->pps_size) {
> LOG_ONCE(ctx, AV_LOG_WARNING, "PPS not present in the 
> stream, nor in AVCC, stream may be unreadable\n");
> } else {
> -count_or_copy(, _size, s->pps, s->pps_size, -1, 
> j);
> +count_or_copy(, _size, s->pps, s->pps_size, 
> PS_OUT_OF_BAND, j);
> }
> }
> 
> -count_or_copy(, _size, buf, nal_size,
> -  unit_type == H264_NAL_SPS || unit_type == 
> H264_NAL_PPS, j);
> +if (unit_type == H264_NAL_SPS || unit_type == H264_NAL_PPS)
> +ps = PS_IN_BAND;
> +else
> +ps = PS_NONE;
> +count_or_copy(, _size, buf, nal_size, ps, j);
> if (!new_idr && unit_type == H264_NAL_SLICE) {
> new_idr  = 1;
> sps_seen = 0;
> -- 
> 2.25.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] Request: consider use codec id "sowt" instead of "ipcm" for LPCM_S16LE in mp4 muxer

[zhilizhao(赵志立)]

> On May 24, 2023, at 08:45, Joseph Chris  wrote:
> 
> Hello,
> 
> I am writing this mail for request consider use codec id "sowt" instead of 
> "ipcm" for AV_CODEC_ID_PCM_S16LE in mp4 muxer, and AV_CODEC_ID_PCM_S16BE 
> accordingly. This only needs a minor change on code:
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index a9c8e104f0..2b984789f5 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -7816,6 +7816,9 @@ static const AVCodecTag codec_mp4_tags[] = {
>  { AV_CODEC_ID_TTML,MOV_MP4_TTML_TAG  },
>  { AV_CODEC_ID_TTML,MOV_ISMV_TTML_TAG },
> 
> +// To improve compatibility
> +{ AV_CODEC_ID_PCM_S16BE,   MKTAG('t', 'w', 'o', 's') },
> +{ AV_CODEC_ID_PCM_S16LE,   MKTAG('s', 'o', 'w', 't') },
>  /* ISO/IEC 23003-5 integer formats */
>  { AV_CODEC_ID_PCM_S16BE,   MOV_MP4_IPCM_TAG  },
>  { AV_CODEC_ID_PCM_S16LE,   MOV_MP4_IPCM_TAG  },
> 

Nope, they are tags of quicktime format, not ISO base media file format.

> 
> Many players like VLC and potplayer, can recognize "sowt", but they can not 
> recognize "ipcm" or "lpcm" (lpcm is defined on mp4ra). Even ffmpeg it self 
> (current git master, d81558) can't recognize it. So this change can improve 
> compatibility and interoperability of ffmpeg.

I can’t find d81558.

> 
> This change is related to #9219 and #10185.

They have been fixed. I will update the status.

> 
> This change fails fate-mov-mp4-pcm but passes all other tests. 
> fate-mov-mp4-pcm checks the MD5 of output file, as the codec id changes also 
> makes the MD5 change. So we have to rewrite the test while changing the code.
> ___
> 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 v2] avfilter/vf_subtitles: add wrap_unicode option

[zhilizhao(赵志立)]

> On May 22, 2023, at 19:03, Lance Wang  wrote:
> 
> On Mon, May 22, 2023 at 12:05 PM Zhao Zhili  wrote:
> 
>> From: Zhao Zhili 
>> 
>> So CJK can be wrapped automatically.
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> v2: Don't overwrite wrap automatically for native ASS
>> 
>> libavfilter/version.h  |  2 +-
>> libavfilter/vf_subtitles.c | 14 ++
>> 2 files changed, 15 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavfilter/version.h b/libavfilter/version.h
>> index ba8a6fdab2..08779130f5 100644
>> --- a/libavfilter/version.h
>> +++ b/libavfilter/version.h
>> @@ -32,7 +32,7 @@
>> #include "version_major.h"
>> 
>> #define LIBAVFILTER_VERSION_MINOR   8
>> -#define LIBAVFILTER_VERSION_MICRO 100
>> +#define LIBAVFILTER_VERSION_MICRO 101
>> 
>> 
>> #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR,
>> \
>> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
>> index 82e140e986..48038cde23 100644
>> --- a/libavfilter/vf_subtitles.c
>> +++ b/libavfilter/vf_subtitles.c
>> @@ -61,6 +61,7 @@ typedef struct AssContext {
>> int original_w, original_h;
>> int shaping;
>> FFDrawContext draw;
>> +int wrap_unicode;
>> } AssContext;
>> 
>> #define OFFSET(x) offsetof(AssContext, x)
>> @@ -271,6 +272,9 @@ static const AVOption subtitles_options[] = {
>> {"stream_index", "set stream index",
>> OFFSET(stream_index), AV_OPT_TYPE_INT,{ .i64 = -1 }, -1,
>> INT_MAX,  FLAGS},
>> {"si",   "set stream index",
>> OFFSET(stream_index), AV_OPT_TYPE_INT,{ .i64 = -1 }, -1,
>> INT_MAX,  FLAGS},
>> {"force_style",  "force subtitle style",
>> OFFSET(force_style),  AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS},
>> +#if (LIBASS_VERSION >= 0x01600010)
>> +{"wrap_unicode", "break lines according to the Unicode Line Breaking
>> Algorithm", OFFSET(wrap_unicode), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1,
>> FLAGS },
>> +#endif
> 
> {NULL},
>> };
>> 
>> @@ -432,6 +436,16 @@ static av_cold int init_subtitles(AVFilterContext
>> *ctx)
>> if (ret < 0)
>> goto end;
>> 
>> +/* Don't overwrite wrap automatically for native ASS */
>> +if (ass->wrap_unicode == -1)
>> +ass->wrap_unicode = st->codecpar->codec_id != AV_CODEC_ID_ASS;
>> +if (ass->wrap_unicode) {
>> +ret = ass_track_set_feature(ass->track, ASS_FEATURE_WRAP_UNICODE,
>> 1);
>> 
> 
> ASS_FEATURE_WRAP_UNICODE  is defined if  LIBASS_VERSION < 0x01600010?

Oops, I should just remove the #else branch but keep the #if in patch v1.

Will fixed it in v3.

> 
> 
>> +if (ret < 0)
>> +av_log(ctx, AV_LOG_WARNING,
>> +   "libass wasn't built with ASS_FEATURE_WRAP_UNICODE
>> support\n");
>> +}
>> +
>> if (ass->force_style) {
>> char **list = NULL;
>> char *temp = NULL;
>> --
>> 2.25.1
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
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] avcodec/mediacodecdec: add low latency decoding

[zhilizhao(赵志立)]

> On May 22, 2023, at 14:52, xufuji456 <839789...@qq.com> wrote:
> 
> The low-latency decoding mode has available in Android api 30.
> See 
> https://developer.android.google.cn/reference/android/media/MediaCodec?hl=en#PARAMETER_KEY_LOW_LATENCY
> 
> Signed-off-by: xufuji456 <839789...@qq.com>
> ---
> libavcodec/mediacodecdec.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 21464900d1..52c30e1173 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -395,6 +395,12 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
> *avctx)
> ff_AMediaFormat_setInt32(format, "width", avctx->width);
> ff_AMediaFormat_setInt32(format, "height", avctx->height);
> 
> +sdk_int = ff_Build_SDK_INT(avctx);
> +// low-latency mode: available in Android api 30
> +if (sdk_int >= 30 && (avctx->flags & AV_CODEC_FLAG_LOW_DELAY)) {
> +ff_AMediaFormat_setInt32(format, "low-latency", 1);
> +}
> +

Please remove the check on api level. ff_Build_SDK_INT() can fail,
and set an unknown option for api level < 30 should be fine.

> s->ctx = av_mallocz(sizeof(*s->ctx));
> if (!s->ctx) {
> av_log(avctx, AV_LOG_ERROR, "Failed to allocate 
> MediaCodecDecContext\n");
> @@ -414,7 +420,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
> *avctx)
>"MediaCodec started successfully: codec = %s, ret = %d\n",
>s->ctx->codec_name, ret);
> 
> -sdk_int = ff_Build_SDK_INT(avctx);
> /* ff_Build_SDK_INT can fail when target API < 24 and JVM isn't available.
>  * If we don't check sdk_int > 0, the workaround might be enabled by
>  * mistake.
> -- 
> 2.32.0 (Apple Git-132)
> 
> ___
> 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] avcodec/videotoolboxenc: replace VT_H264Profile with avctx profile

[zhilizhao(赵志立)]

> On May 21, 2023, at 22:41, xufuji456 <839789...@qq.com> wrote:
> 
> For compatibility with constrained_baseline in the future,
> replace VT_H264Profile/VT_HEVCProfile with avctx->profile.
> 
> Signed-off-by: xufuji456 <839789...@qq.com>
> ---
> libavcodec/videotoolboxenc.c | 55 +++-
> 1 file changed, 16 insertions(+), 39 deletions(-)
> 
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index b017c90c36..4966ab36ae 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -190,28 +190,12 @@ static void loadVTEncSymbols(void){
> "EnableLowLatencyRateControl");
> }
> 
> -typedef enum VT_H264Profile {
> -H264_PROF_AUTO,
> -H264_PROF_BASELINE,
> -H264_PROF_MAIN,
> -H264_PROF_HIGH,
> -H264_PROF_EXTENDED,
> -H264_PROF_COUNT
> -} VT_H264Profile;
> -
> typedef enum VTH264Entropy{
> VT_ENTROPY_NOT_SET,
> VT_CAVLC,
> VT_CABAC
> } VTH264Entropy;
> 
> -typedef enum VT_HEVCProfile {
> -HEVC_PROF_AUTO,
> -HEVC_PROF_MAIN,
> -HEVC_PROF_MAIN10,
> -HEVC_PROF_COUNT
> -} VT_HEVCProfile;
> -
> static const uint8_t start_code[] = { 0, 0, 0, 1 };
> 
> typedef struct ExtraSEI {
> @@ -730,18 +714,13 @@ static bool get_vt_h264_profile_level(AVCodecContext 
> *avctx,
> VTEncContext *vtctx = avctx->priv_data;
> int64_t profile = vtctx->profile;
> 
> -if (profile == H264_PROF_AUTO && vtctx->level) {
> -//Need to pick a profile if level is not auto-selected.
> -profile = vtctx->has_b_frames ? H264_PROF_MAIN : H264_PROF_BASELINE;
> -}
> -
> *profile_level_val = NULL;
> 
> switch (profile) {
> case H264_PROF_AUTO:
> return true;
> 
> -case H264_PROF_BASELINE:
> +case FF_PROFILE_H264_BASELINE:
> switch (vtctx->level) {
> case  0: *profile_level_val =
>   
> compat_keys.kVTProfileLevel_H264_Baseline_AutoLevel; break;
> @@ -763,7 +742,7 @@ static bool get_vt_h264_profile_level(AVCodecContext 
> *avctx,
> }
> break;
> 
> -case H264_PROF_MAIN:
> +case FF_PROFILE_H264_MAIN:
> switch (vtctx->level) {
> case  0: *profile_level_val =
>   
> compat_keys.kVTProfileLevel_H264_Main_AutoLevel; break;
> @@ -782,7 +761,7 @@ static bool get_vt_h264_profile_level(AVCodecContext 
> *avctx,
> }
> break;
> 
> -case H264_PROF_HIGH:
> +case FF_PROFILE_H264_HIGH:
> switch (vtctx->level) {
> case  0: *profile_level_val =
>   
> compat_keys.kVTProfileLevel_H264_High_AutoLevel; break;
> @@ -805,7 +784,7 @@ static bool get_vt_h264_profile_level(AVCodecContext 
> *avctx,
>   compat_keys.kVTProfileLevel_H264_High_5_2;  
>  break;
> }
> break;
> -case H264_PROF_EXTENDED:
> +case FF_PROFILE_H264_EXTENDED:
> switch (vtctx->level) {
> case  0: *profile_level_val =
>   
> compat_keys.kVTProfileLevel_H264_Extended_AutoLevel; break;
> @@ -838,13 +817,11 @@ static bool get_vt_hevc_profile_level(AVCodecContext 
> *avctx,
> *profile_level_val = NULL;
> 
> switch (profile) {
> -case HEVC_PROF_AUTO:
> -return true;
> -case HEVC_PROF_MAIN:
> +case FF_PROFILE_HEVC_MAIN:
> *profile_level_val =
> compat_keys.kVTProfileLevel_HEVC_Main_AutoLevel;
> break;
> -case HEVC_PROF_MAIN10:
> +case FF_PROFILE_HEVC_MAIN_10:
> *profile_level_val =
> compat_keys.kVTProfileLevel_HEVC_Main10_AutoLevel;
> break;
> @@ -1515,12 +1492,12 @@ static int vtenc_configure_encoder(AVCodecContext 
> *avctx)
> vtctx->get_param_set_func = 
> CMVideoFormatDescriptionGetH264ParameterSetAtIndex;
> 
> vtctx->has_b_frames = avctx->max_b_frames > 0;
> -if(vtctx->has_b_frames && vtctx->profile == H264_PROF_BASELINE){
> +if(vtctx->has_b_frames && vtctx->profile == 
> FF_PROFILE_H264_BASELINE) {
> av_log(avctx, AV_LOG_WARNING, "Cannot use B-frames with baseline 
> profile. Output will not contain B-frames.\n");
> vtctx->has_b_frames = 0;
> }
> 
> -if (vtctx->entropy == VT_CABAC && vtctx->profile == 
> H264_PROF_BASELINE) {
> +if (vtctx->entropy == VT_CABAC && vtctx->profile == 
> FF_PROFILE_H264_BASELINE) {
> av_log(avctx, AV_LOG_WARNING, "CABAC entropy requires 'main' or 
> 'high' profile, but baseline was requested. Encode will not use CABAC 
> entropy.\n");
> vtctx->entropy = VT_ENTROPY_NOT_SET;
> }
> @@ -2756,11 +2733,11 @@ static const enum AVPixelFormat prores_pix_fmts[] = {
> 
> #define OFFSET(x) offsetof(VTEncContext, x)
> static const AVOption 

Re: [FFmpeg-devel] [PATCH] avcodec/videotoolboxenc: replace VT_H264Profile with avctx profile

[zhilizhao(赵志立)]

> On May 22, 2023, at 11:05, zhilizhao(赵志立)  wrote:
> 
>> On May 21, 2023, at 22:41, xufuji456 <839789...@qq.com> wrote:
>> 
>> For compatibility with constrained_baseline in the future,
>> replace VT_H264Profile/VT_HEVCProfile with avctx->profile.
>> 
>> Signed-off-by: xufuji456 <839789...@qq.com>
>> ---
>> libavcodec/videotoolboxenc.c | 55 +++-
>> 1 file changed, 16 insertions(+), 39 deletions(-)
>> 
>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>> index b017c90c36..4966ab36ae 100644
>> --- a/libavcodec/videotoolboxenc.c
>> +++ b/libavcodec/videotoolboxenc.c
>> @@ -190,28 +190,12 @@ static void loadVTEncSymbols(void){
>>"EnableLowLatencyRateControl");
>> }
>> 
>> -typedef enum VT_H264Profile {
>> -H264_PROF_AUTO,
>> -H264_PROF_BASELINE,
>> -H264_PROF_MAIN,
>> -H264_PROF_HIGH,
>> -H264_PROF_EXTENDED,
>> -H264_PROF_COUNT
>> -} VT_H264Profile;
>> -
>> typedef enum VTH264Entropy{
>>VT_ENTROPY_NOT_SET,
>>VT_CAVLC,
>>VT_CABAC
>> } VTH264Entropy;
>> 
>> -typedef enum VT_HEVCProfile {
>> -HEVC_PROF_AUTO,
>> -HEVC_PROF_MAIN,
>> -HEVC_PROF_MAIN10,
>> -HEVC_PROF_COUNT
>> -} VT_HEVCProfile;
>> -
>> static const uint8_t start_code[] = { 0, 0, 0, 1 };
>> 
>> typedef struct ExtraSEI {
>> @@ -730,18 +714,13 @@ static bool get_vt_h264_profile_level(AVCodecContext 
>> *avctx,
>>VTEncContext *vtctx = avctx->priv_data;
>>int64_t profile = vtctx->profile;
>> 
>> -if (profile == H264_PROF_AUTO && vtctx->level) {
>> -//Need to pick a profile if level is not auto-selected.
>> -profile = vtctx->has_b_frames ? H264_PROF_MAIN : H264_PROF_BASELINE;
>> -}
>> -
>>*profile_level_val = NULL;
>> 
>>switch (profile) {
>>case H264_PROF_AUTO:
>>return true;

Isn’t it failed to build since H264_PROF_AUTO isn’t defined?

>> 
>> -case H264_PROF_BASELINE:
>> +case FF_PROFILE_H264_BASELINE:
>>switch (vtctx->level) {
>>case  0: *profile_level_val =
>>  
>> compat_keys.kVTProfileLevel_H264_Baseline_AutoLevel; break;
>> @@ -763,7 +742,7 @@ static bool get_vt_h264_profile_level(AVCodecContext 
>> *avctx,
>>}
>>break;
>> 
>> -case H264_PROF_MAIN:
>> +case FF_PROFILE_H264_MAIN:
>>switch (vtctx->level) {
>>case  0: *profile_level_val =
>>  
>> compat_keys.kVTProfileLevel_H264_Main_AutoLevel; break;
>> @@ -782,7 +761,7 @@ static bool get_vt_h264_profile_level(AVCodecContext 
>> *avctx,
>>}
>>break;
>> 
>> -case H264_PROF_HIGH:
>> +case FF_PROFILE_H264_HIGH:
>>switch (vtctx->level) {
>>case  0: *profile_level_val =
>>  
>> compat_keys.kVTProfileLevel_H264_High_AutoLevel; break;
>> @@ -805,7 +784,7 @@ static bool get_vt_h264_profile_level(AVCodecContext 
>> *avctx,
>>  compat_keys.kVTProfileLevel_H264_High_5_2;  
>>  break;
>>}
>>break;
>> -case H264_PROF_EXTENDED:
>> +case FF_PROFILE_H264_EXTENDED:
>>switch (vtctx->level) {
>>case  0: *profile_level_val =
>>  
>> compat_keys.kVTProfileLevel_H264_Extended_AutoLevel; break;
>> @@ -838,13 +817,11 @@ static bool get_vt_hevc_profile_level(AVCodecContext 
>> *avctx,
>>*profile_level_val = NULL;
>> 
>>switch (profile) {
>> -case HEVC_PROF_AUTO:
>> -return true;
>> -case HEVC_PROF_MAIN:
>> +case FF_PROFILE_HEVC_MAIN:
>>*profile_level_val =
>>compat_keys.kVTProfileLevel_HEVC_Main_AutoLevel;
>>break;
>> -case HEVC_PROF_MAIN10:
>> +case FF_PROFILE_HEVC_MAIN_10:
>>*profile_level_val =
>>compat_keys.kVTProfileLevel_HEVC_Main10_AutoLevel;
>>break;
>> @@ -1515,12 +1492,12 @@ static int vtenc_configure_encoder(AVCodecContext 
>> *avctx)
>>vtctx->get_param_set_func = 
>> CMVideoFormatDescriptionGetH26

Re: [FFmpeg-devel] [PATCH] avformat/tests/imf: fix memleak

[zhilizhao(赵志立)]

> On May 20, 2023, at 01:40, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> It breaks fate test with asan.
> 
> Signed-off-by: Zhao Zhili 
> ---
> libavformat/tests/imf.c | 2 ++
> 1 file changed, 2 insertions(+)
> 

It has already been fixed. Please drop the patch.

___
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] avcodec/videotoolboxenc: add low-latency encoding

[zhilizhao(赵志立)]

> On May 19, 2023, at 11:17, xufuji456 <839789...@qq.com> wrote:
> 
> When using low-latency mode, it eliminates frame reordering
> and follows a one-in-one-out encoding mode
> 
> Signed-off-by: xufuji456 <839789...@qq.com>
> ---
> libavcodec/videotoolboxenc.c | 11 +++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index c6f22723d6..ae1ef32b2d 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -1441,6 +1441,17 @@ static int vtenc_create_encoder(AVCodecContext   
> *avctx,
> }
> }
> 
> +// low-latency mode: eliminate frame reordering, follow a one-in-one-out 
> encoding mode
> +if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) && avctx->codec_id == 
> AV_CODEC_ID_H264) {
> +status = VTSessionSetProperty(vtctx->session,
> +  
> kVTVideoEncoderSpecification_EnableLowLatencyRateControl,
> +  kCFBooleanTrue);

Please use compat_keys in case of 
kVTVideoEncoderSpecification_EnableLowLatencyRateControl
isn’t available.

> +
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error setting low latency property: 
> %d\n", status);
> +}
> +}
> +
> status = VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
> if (status) {
> av_log(avctx, AV_LOG_ERROR, "Error: cannot prepare encoder: %d\n", 
> status);
> -- 
> 2.32.0 (Apple Git-132)
> 
> ___
> 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 v2] avcodec/mediacodec: Add VP8 encoder

[zhilizhao(赵志立)]

Failed to build since missing 

+DECLARE_MEDIACODEC_ENCODER(vp8, "VP8", AV_CODEC_ID_VP8)

Fixed locally and pushed as 416fd1b.

> On May 17, 2023, at 01:34, Samuel Raposo Vieira Mira  
> wrote:
> 
> 
> 
> <0001-avcodec-mediacodec-Add-VP8-encoder.patch.b64><0001-avcodec-mediacodec-Add-VP8-encoder.patch>___
> 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 v2] avcodec/mediacodec: Add AV1 encoder

[zhilizhao(赵志立)]

Pushed as acd37fd.

> On May 17, 2023, at 00:26, Samuel Raposo Vieira Mira  
> wrote:
> 
> 
> 
> <0001-avcodec-mediacodec-Add-AV1-encoder.patch><0001-avcodec-mediacodec-Add-AV1-encoder.patch.b64>___
> 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 1/3] lavu/frame: add av_frame_get_buffer2

[zhilizhao(赵志立)]

> On May 16, 2023, at 15:52, Hendrik Leppkes  wrote:
> 
> On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao
>  wrote:
>> 
>> From: Haihao Xiang 
>> 
>> Intel MediaSDK and oneVPL expect contiguous allocation for data[i],
>> however there are mandatory padding bytes between data[i] and data[i+1].
>> when calling av_frame_get_buffer. So adding av_frame_get_buffer2 to
>> allow caller to specify the length of padding bytes.
>> 
> 
> get_video_buffer will also pad the height to a multiple of 32, won't
> that again cause issues?
> I don't think the API even necessarily guarantees that its going to be
> one contiguous buffer, it just happens to be the way its made right
> now.
> 
> If a new API is introduced, maybe it should be very tailor designed to
> offer these guarantees, and named appropriate, not introducing any
> padding - padded height or extra padding, or otherwise.

If there is more use cases, the new API should be more general.
Current use case isn’t a strong reason for the new API.

It looks like the internal implementation of hwcontext_qsv and
qsvenc use AVFrame as temporary variables for convenience. They
can be replaced by internal defined struct or POD, and copy data
by av_image_copy. Although it’s more code to change.

> 
> - Hendrik
> ___
> 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 v1] libavfi/dnn: add Paddle Inference as one of DNN backend

[zhilizhao(赵志立)]

> On May 10, 2023, at 10:25, WenzheWang  wrote:
> 
> Dear Madam or Sir,
> 
> 
> Hope this email finds you well.
> 
> 
> I am writing this email since i recently found FFmepg remove DNN native  
> backend, and i will be really grateful if you let me know if there is  any 
> new plan on libavfilter/dnn.
> 
> 
> I would like to explain to you again about the addition of dnn paddle backend.
> 
> At  present, ffmpeg only supports openvino and tensorflow backend. Among  the 
> current deep learning frameworks, TensorFlow is the most active in  
> development. TensorFlow has 174k stars and pytorch has 66.5k. openvino  is 
> 4.2k, and the models that openvino can implement are relatively few.  But in 
> terms of attention on GitHub, there's no doubt that TensorFlow  and pytorch 
> are more promising. Currently, the paddle framework has  reached 20.2k stars 
> on github, which is much more widely used and active  than frameworks such as 
> mxnet and caffe.

Stars don't matter much here.

Just for reference, there is a thread before:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220523092918.9548-2-ting...@intel.com/

> 
> Tensoflow has a very  rich ecosystem. The TensorFlow models library updates 
> very quickly and  has existing examples of deep learning applications for 
> image  classification, object detection, image generation text, and 
> generation  of adversus-network models. The dnn libavfilter module is 
> undoubtedly very necessary for tensorflow  backend to support. But the 
> complexity of the TensorFlow API and the  complexity of the training are 
> almost prohibitive, making it a love-hate  framework.
> 
> PyTorch framework tends to be applied to academic  fast implementation, and 
> its industrial application performance is not  good. For example, Pytorch 
> framework makes a model to run on a server,  Android phone or embedded 
> system, and its performance is poor compared  with other deep learning 
> frameworks.
> 
> 
> PaddlePadddle  is an open source framework of Baidu, which is also used by 
> many people  in China. It is very consistent with the usage habits of 
> developers,  but the practicability of the API still needs to be further 
> strengthened. However, Paddle is the only deep learning framework I  have 
> ever used, which does not configure any third-party libraries and  can be 
> used directly by cloning make. Besides, Paddle occupies a small  amount of 
> memory and is fast. It also serves a considerable number of  projects inside 
> Baidu, which is very strong in industrial application.  And PaddlePaddle 
> supports multiple machine and multiple card training.
> 
> 
> Users'  choice of different deep learning frameworks is a personal choice, 
> and  the reason why most of us chose paddle is because of its better support  
> for embedded development and different hardware platforms and because  the 
> community is very active and has proposed industrial improvements  and 
> implementations for some advanced models. Especially for the GPU, it  
> supports cuda and opencl, which means we can optimize the model no  matter 
> what kind of graphics card is used. In my opinion, more backend  support can 
> better improve dnn libavfilter modules.
> 
> If there are any  new changes in dnn libavfilter module, I will be very 
> willing to adjust our  implementation with the new planning and provide 
> continuous maintenance.
> 
> 
> 
> 
> Best Regards,
> Wenzhe Wang
> 
> 
> 
> 
> 
> 
> WenzheWang
> wong...@foxmail.com
> 
> 
> 
> 
> 
> 
> 
> --Original--
> From: "WenzheWang"
>  Date:Tue, Apr 11, 2023 11:03 PM
> To:"ffmpeg-devel" 
> Subject:Re: [FFmpeg-devel] [PATCH v1] libavfi/dnn: add Paddle Inference 
> as one of DNN backend
> 
> 
> 
> 
> Could you please briefly introduce the reason why not adding any dnn 
> backend?
> 
> 
> 
> 
> Do you have any plan for the maintenance and development of the dnn backend 
> in the future? From my understanding, the current backend of dnn has 
> tensoflow, openvino and native, but this cannot meet the needs of users.
> 
> 
> 
> 
> Thus, I believe adding other dnn backends will be great for user experience, 
> user growth, and industrial applications. In particular, various dnn backend 
> can be adapted to different application environments, and there are some 
> emerging inference engines that are faster and stronger, such as Pytorch and 
> Paddle. In addition, from the practical point of view, it is not difficult 
> for a deep learning practitioner to learn and use this framework, but how to 
> choose a framework and apply it in practice, people pay more attention to the 
> effect (recall and precision), and easy deployment, that is, high reasoning 
> performance efficiency. The main reason why Paddle is relatively mainstream 
> and why I want to add paddle backend is that it has a very high efficiency 
> and performance. There 

Re: [FFmpeg-devel] [PATCH] avformat/demux: in case of no timestamps, calculate dts based on previous dts and duration

[zhilizhao(赵志立)]

> On May 5, 2023, at 19:31, Jan Ekström  wrote:
> 
> From: Martin Machalek 
> 
> Adds DTS to packets which would otherwise break tbr calculation
> within libavformat, as well as packet rate calculation in ffmpeg.
> 
> An example of such input would be an MPEG-TS stream where a whole
> GOP is put into a single PES packet.
> 
> Co-authored-by: Jan Ekström 
> 
> Signed-off-by: Jan Ekström 
> ---
> libavformat/demux.c | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index 06de71cd6e..9a4ab28679 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -1098,6 +1098,11 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
> if (!onein_oneout)
> // This should happen on the first packet
> update_initial_timestamps(s, pkt->stream_index, pkt->dts, pkt->pts, 
> pkt);
> +
> +if (pkt->dts == AV_NOPTS_VALUE && !is_relative(sti->cur_dts) &&
> +sti->cur_dts != AV_NOPTS_VALUE && pkt->duration > 0)
> +pkt->dts = sti->cur_dts + pkt->duration;
> +

It’s possible that the next dts < pkt->dts, how to prevent non-monotonic 
increasing?

> if (pkt->dts > sti->cur_dts)
> sti->cur_dts = pkt->dts;
> 
> -- 
> 2.40.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [Internet]Re: [PATCH] avcodec/options_table: reorder nokey after nointra

[zhilizhao(赵志立)]

> On Apr 26, 2023, at 15:41, Steven Liu  wrote:
> 
> Zhao Zhili  于2023年4月26日周三 10:49写道：
>> 
>> From: Zhao Zhili 
>> 
>> So the values are in ascending order.
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> libavcodec/options_table.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
>> index f331ce2861..4f5918c7f6 100644
>> --- a/libavcodec/options_table.h
>> +++ b/libavcodec/options_table.h
>> @@ -259,8 +259,8 @@ static const AVOption avcodec_options[] = {
>> {"default" , "discard useless frames",  0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_DEFAULT }, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> {"noref"   , "discard all non-reference frames",0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONREF  }, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> {"bidir"   , "discard all bidirectional frames",0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_BIDIR   }, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> -{"nokey"   , "discard all frames except keyframes", 0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY  }, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> {"nointra" , "discard all frames except I frames",  0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONINTRA}, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> +{"nokey"   , "discard all frames except keyframes", 0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY  }, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> {"all" , "discard all frames",  0, 
>> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_ALL }, INT_MIN, INT_MAX, V|D, 
>> "avdiscard"},
>> {"bidir_refine", "refine the two motion vectors used in bidirectional 
>> macroblocks", OFFSET(bidir_refine), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, 4, V|E},
>> {"keyint_min", "minimum interval between IDR-frames", OFFSET(keyint_min), 
>> AV_OPT_TYPE_INT, {.i64 = 25 }, INT_MIN, INT_MAX, V|E},
>> --
>> 2.25.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".
> 
> 
> LGTM

Applied as 4006c71d, thanks!

> 
> 
> Thanks
> Steven
> 

___
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] avcodec/avcodec: fix UB NULL+0

[zhilizhao(赵志立)]

> On Apr 26, 2023, at 20:49, zhilizhao(赵志立)  wrote:
> 
>> On Apr 12, 2023, at 01:49, Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> ---
>> libavcodec/avcodec.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
>> index fb1362290f..5a96899d50 100644
>> --- a/libavcodec/avcodec.c
>> +++ b/libavcodec/avcodec.c
>> @@ -44,10 +44,11 @@
>> 
>> int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext 
>> *c2, void *arg2), void *arg, int *ret, int count, int size)
>> {
>> -int i;
>> +size_t i;
>> 
>>for (i = 0; i < count; i++) {
>> -int r = func(c, (char *)arg + i * size);
>> +size_t offset = i * size;
>> +int r = func(c, FF_PTR_ADD((char *)arg, offset));
>>if (ret)
>>ret[i] = r;
>>}
>> -- 
>> 2.25.1
>> 
> 
> Will apply soon unless there is objection.

Applied as 36a56d3c and 0d40711f.

> ___
> 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 1/2] avcodec/avcodec: fix UB NULL+0

[zhilizhao(赵志立)]

> On Apr 12, 2023, at 01:49, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> ---
> libavcodec/avcodec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index fb1362290f..5a96899d50 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -44,10 +44,11 @@
> 
> int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext 
> *c2, void *arg2), void *arg, int *ret, int count, int size)
> {
> -int i;
> +size_t i;
> 
> for (i = 0; i < count; i++) {
> -int r = func(c, (char *)arg + i * size);
> +size_t offset = i * size;
> +int r = func(c, FF_PTR_ADD((char *)arg, offset));
> if (ret)
> ret[i] = r;
> }
> -- 
> 2.25.1
> 

Will apply soon unless there is objection.
___
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] fftools/ffmpeg_mux: fix reporting muxer EOF as error

[zhilizhao(赵志立)]

> On Apr 23, 2023, at 17:42, Marton Balint  wrote:
> 
> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> 
>> Quoting Marton Balint (2023-04-23 11:12:38)
>>> 
>>> 
>>> On Sat, 22 Apr 2023, Anton Khirnov wrote:
>>> 
 Quoting Zhao Zhili (2023-04-22 14:56:34)
> From: Zhao Zhili 
> 
> Fix #10327.
> 
> Signed-off-by: Zhao Zhili 
> ---
> fftools/ffmpeg_mux.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
> index a2e8873ad2..0e1a5d7dc5 100644
> --- a/fftools/ffmpeg_mux.c
> +++ b/fftools/ffmpeg_mux.c
> @@ -214,9 +214,15 @@ static void *muxer_thread(void *arg)
> ost = of->streams[stream_idx];
> ret = sync_queue_process(mux, ost, ret < 0 ? NULL : pkt, 
> _eof);
> av_packet_unref(pkt);
> -if (ret == AVERROR_EOF && stream_eof)
> -tq_receive_finish(mux->tq, stream_idx);
> -else if (ret < 0) {
> +if (ret == AVERROR_EOF) {
> +if (stream_eof) {
> +tq_receive_finish(mux->tq, stream_idx);
> +} else {
> +av_log(mux, AV_LOG_VERBOSE, "Muxer %s\n", 
> av_err2str(ret));
 
 That seems unnecesarily convoluted, given that we _know_ the error to be
 EOF here. Also, please make it "Muxer returned EOF" to make it clear
 what exactly is the source of EOF.
 
 Otherwise ok, feel free to push with this change.
>>> 
>>> This seems like yet another clash of AVERROR_EOF error codes coming from
>>> different places with different semantics. For
>>> av_interleaved_write_frame(), AVERROR_EOF is an error condition, so
>>> file encoding should fail,
>> 
>> Why should it fail? I'd think a muxer returning EOF is the way to signal
>> non-error muxer-side termination.
> 
> That would be an API change. AVERROR_EOF is not special in any way from other 
> error codes for av_interleaved_write_frame. A muxer cannot signal non-error 
> muxer side termination with existing API.

Sorry I have pushed before seeing your comments.

It can happen in theory, but I’m not sure in which case muxer can return
EOF and should be treated as a real error condition.

A simple grep shows:

$ grep 'AVERROR_EOF'  libavformat/*enc.c

libavformat/hlsenc.c:if (ret >= 0 || ret == AVERROR_EOF) <--- It 
changed ret to 0 afterwards.
libavformat/webmdashenc.c:return AVERROR_EOF;<—-- More like 
a bug on the caller side than a real error.

> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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/libopenh264: Support full range videos in transcoding

[zhilizhao(赵志立)]

> On Apr 18, 2023, at 23:33, Jun Zhao  wrote:
> 
> Support full range videos when transcoding, enabled the
> YUVJ420P to avoid auto scale from YUVJ420P to YUV420P


According to "Towards YUVJ removal"
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-December/304718.html

> So, as was discussed at the last meeting, we should move towards
removing YUVJ.

However, it looks like there is no much progress since then.

> 
> Signed-off-by: Jun Zhao 
> ---
> libavcodec/libopenh264enc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index 8b4755f5ba..11fbb7 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -311,10 +311,12 @@ static av_cold int svc_encode_init(AVCodecContext 
> *avctx)
> 
> #if OPENH264_VER_AT_LEAST(1, 6)
> param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
> +
> if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED) {
> param.sSpatialLayers[0].bVideoSignalTypePresent = true;
> param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
> AVCOL_RANGE_JPEG);
> -}
> +}  else if (avctx->pix_fmt == AV_PIX_FMT_YUVJ420P)
> +param.sSpatialLayers[0].bFullRange = 1;
> 
> if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED  ||
> avctx->color_primaries != AVCOL_PRI_UNSPECIFIED ||
> @@ -443,6 +445,7 @@ const FFCodec ff_libopenh264_encoder = {
> .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP |
>   FF_CODEC_CAP_AUTO_THREADS,
> .p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_YUVJ420P,
> AV_PIX_FMT_NONE },
> .defaults   = svc_enc_defaults,
> .p.priv_class   = ,
> -- 
> 2.25.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH v2] avformat/mov: fix 2 compile errors

[zhilizhao(赵志立)]

> On Mar 16, 2023, at 13:48, Xiang, Haihao 
>  wrote:
> 
> On Do, 2023-03-16 at 13:32 +0800, Tong Wu wrote:
>> Compiler: MSVC 14.35.32215
>> Error type: error C2059: syntax error: '}'
>> Related commit: 9e1ffed fate/mov: add PCM in mp4 test
>> d7e8643 avformat/mov: parse ISO-14496-12 ChannelLayout
>> 
>> Signed-off-by: Tong Wu 
>> ---
>>  libavformat/mov_chan.c | 2 +-
>>  libavformat/movenc.c   | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
>> index df17976e59..f3d51899e1 100644
>> --- a/libavformat/mov_chan.c
>> +++ b/libavformat/mov_chan.c
>> @@ -555,7 +555,7 @@ int ff_mov_read_chan(AVFormatContext *s, AVIOContext *pb,
>> AVStream *st,
>>  /* ISO/IEC 23001-8, 8.2 */
>>  static const AVChannelLayout iso_channel_configuration[] = {
>>  // 0: any setup
>> -{},
>> +{0},
>>  
>>  // 1: centre front
>>  AV_CHANNEL_LAYOUT_MONO,
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index 2ec575c954..68e7f8222b 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -1194,7 +1194,7 @@ static int mov_write_chnl_tag(AVFormatContext *s,
>> AVIOContext *pb, MOVTrack *tra
>>  ret = ff_mov_get_channel_positions_from_layout(layout,
>>  speaker_pos, layout->nb_channels);
>>  if (ret) {
>> -char buf[128] = {};
>> +char buf[128] = {0};
>>  
>>  av_freep(_pos);
>>  av_channel_layout_describe(layout, buf, sizeof(buf));
> 
> LGTM.
> 
> - Haihao

Applied as c3a79990. Thanks for the fix and patch review. Didn’t notice
it’s GNU extension until C23.

> 
> 
> ___
> 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 v3 4/5] avformat/movenc: add PCM in mp4 support

[zhilizhao(赵志立)]

> On Mar 6, 2023, at 20:28, Tomas Härdin  wrote:
> 
>> +static int mov_write_chnl_tag(AVFormatContext *s, AVIOContext *pb,
>> MOVTrack *track)
>> +{
>> +int64_t pos = avio_tell(pb);
>> +int config = 0;
>> +int ret;
>> +uint8_t *speaker_pos = NULL;
>> +const AVChannelLayout *layout = >par->ch_layout;
>> +
>> +ret = ff_mov_get_channel_config_from_layout(layout, );
>> +if (ret || !config) {
> 
> ret is always 0..

That implementation details. It’s robust for caller to not depending
on that.

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

___
ffmpeg-devel 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 v3 3/5] avformat/mov: parse ISO-14496-12 ChannelLayout

[zhilizhao(赵志立)]

> On Mar 6, 2023, at 20:26, Tomas Härdin  wrote:
> 
>> +int ff_mov_get_channel_config_from_layout(const AVChannelLayout
>> *layout, int *config)
>> +{
>> +// Set default value which means any setup in 23001-8
>> +*config = 0;
>> +for (int i = 0; i < FF_ARRAY_ELEMS(iso_channel_configuration);
>> i++) {
>> +if (!av_channel_layout_compare(layout,
>> iso_channel_configuration + i)) {
>> +*config = i;
>> +break;
>> +}
>> +}
>> +
>> +return 0;
> 
> Is always returning 0 intended? If so then what is the point?
> ff_mov_get_channel_positions_from_layout() returns non-zero on error..

As the comments says, ChannelConfiguration 0 means “any setup”. If no
iso_channel_configuration item match layout, *config get 0 as a valid
value.

Current implementation of the function doesn’t fail, but it might in
future.

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

___
ffmpeg-devel 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/ffmpeg: reset pointer, which could be reused by Android and iOS

[zhilizhao(赵志立)]

> On Mar 3, 2023, at 14:51, xufuji456 <839789...@qq.com> wrote:
> 
> ---
> fftools/ffmpeg.c | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 743bc0c6b6..0ce9531235 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -569,6 +569,13 @@ static void ffmpeg_cleanup(int ret)
> av_freep(_files);
> av_freep(_files);
> 
> +nb_input_files= 0;
> +nb_output_files   = 0;
> +nb_filtergraphs   = 0;
> +input_files   = NULL;
> +output_files  = NULL;
> +filtergraphs  = NULL;
> +

Until we decided to make ffmpeg cmd works as a library,
it doesn’t matter. I’m interested on the idea to make fftools
work like a library. But it depends on the community.

https://patchwork.ffmpeg.org/project/ffmpeg/patch/tencent_929f62ab2f4e5e70082de99ae040769a1...@qq.com/

> uninit_opts();
> 
> avformat_network_deinit();
> -- 
> 2.32.0 (Apple Git-132)
> 
> ___
> 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 v2 0/4] Add hevc alpha layer decoding basic support

[zhilizhao(赵志立)]

> On Mar 2, 2023, at 18:11, Anton Khirnov  wrote:
> 
> Quoting zhilizhao(赵志立) (2023-02-28 10:00:15)
>> 
>>> On Jan 6, 2023, at 23:52, Zhao Zhili  wrote:
>>> 
>>> From: Zhao Zhili 
>>> 
>>> v2:
>>> 1. Check vps_max_layers and vps_max_layer_id inside hevc decoder
>>> 2. Add hevc_extract_layer bsf to do the job rather than modifing 
>>> hevc_metadata,
>>> 3. Check vps_max_layers_minus1 and vps_max_layer_id inside bsf
>>> 4. Update vps_max_layers_minus1 and vps_max_layer_id when rewrite as base 
>>> layer
>>> 5. vps_extension should be updated rather than drop entirely, add a TODO
>> 
>> Will push soon if there's no objections.
> 
> Can't we do this without weird bitstream filtes and obscure options
> leaking to the user? It's all signalled in the bitstream in a rather
> straightforward way. Just extend hevcdec to decode it.

Yes we could.

1. Add support to our software decoder is possible, with a big refactor.
2. Add support to hwaccel decoders like videotoolbox requires a refactor of
hevcdec too.

I have asked in the RFC:

"Is there any plan/interesting to add fullly support inside our hevc
decoder? If the answer is yes, then the patchset is less useful."

http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305342.html

I indeed tried to refactor hevcdec first. But the mixing of long term
states and temporary states inside HEVCContext makes it not easy to do.
I’m glad to work on it (together) if someone has a clear idea.

By the way, other decoders which doesn’t support layered decoding could
still benefit from the 'weird bitstream filter'.

> 
> -- 
> 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 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] lavc/avcodec.h: extend documentation for avcodec_open2()

[zhilizhao(赵志立)]

> On Mar 1, 2023, at 06:40, Stefano Sabatini  wrote:
> 
> On date Tuesday 2023-02-28 23:28:56 +0100, Stefano Sabatini wrote:
>> In particular, clarify how to set options in the codec context, and mention 
>> when to use
>> avcodec_parameters_to_context().
>> 
>> Fix trac issue http://trac.ffmpeg.org/ticket/5781.
>> ---
>> libavcodec/avcodec.h | 29 -
>> 1 file changed, 24 insertions(+), 5 deletions(-)
> 

> In particular, clarify how to set options in the codec context, and mention 
> when to use
> avcodec_parameters_to_context().
> 
> Fix trac issues:
> http://trac.ffmpeg.org/ticket/5781
> http://trac.ffmpeg.org/ticket/5838
> ---
>  libavcodec/avcodec.h | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 9a0fe97cad..fbf1d3d83c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2418,8 +2418,14 @@ int avcodec_parameters_to_context(AVCodecContext 
> *codec,
>   * avcodec_find_decoder() and avcodec_find_encoder() provide an easy way for
>   * retrieving a codec.
>   *
> - * @note Always call this function before using decoding routines (such as
> - * @ref avcodec_receive_frame()).
> + * Depending on the codec, you might need to set options in the codec context
> + * also for decoding (e.g. width, height, or the pixel or audio sample 
> format in
> + * case the information is not is not available in the bitstream, e.g. as in

'is not is not'

> + * case of decoding raw audio or video).

in ’the’ case of.

> + *
> + * Options on the codec context can be either set by providing the options
> + * specified in an AVDictionary, or by setting the values on the context 
> itself,
> + * directly or by using the av_opt_set() API.
>   *
>   * @code
>   * av_dict_set(, "b", "2.5M", 0);
> @@ -2433,17 +2439,35 @@ int avcodec_parameters_to_context(AVCodecContext 
> *codec,
>   * exit(1);
>   * @endcode
>   *
> + * In case AVCodecParameters are available (e.g. when demuxing a stream using
> + * libavformat, and accessing the AVStream contained in the demuxer), the 
> codec
> + * parameters can be copied to the codec context using
> + * avcodec_parameters_to_context(), as in the following code:
> + *
> + * @code
> + * context = avcodec_alloc_context3(codec);
> + * if (avcodec_parameters_to_context(*dec_ctx, codecpar) < 0)
> + * exit(1);
> + * if (avcodec_open2(context, codec, NULL) < 0)
> + * exit(1);

What’s the dec_ctx?

> + * @endcode
> + *
> + * @note Always call this function before using decoding routines (such as
> + * @ref avcodec_receive_frame()).
> + *
>   * @param avctx The context to initialize.
>   * @param codec The codec to open this context for. If a non-NULL codec has 
> been
>   *  previously passed to avcodec_alloc_context3() or
>   *  for this context, then this parameter MUST be either NULL or
>   *  equal to the previously passed codec.
> - * @param options A dictionary filled with AVCodecContext and codec-private 
> options.
> - *On return this object will be filled with options that 
> were not found.
> + * @param options A dictionary filled with AVCodecContext and codec-private
> + *options, which are set on top of the options already set in
> + *avctx, can be NULL. On return this object will be filled 
> with
> + *options that were not found in avctx.
>   *
>   * @return zero on success, a negative value on error
>   * @see avcodec_alloc_context3(), avcodec_find_decoder(), 
> avcodec_find_encoder(),
> - *  av_dict_set(), av_opt_find().
> + *  av_dict_set(), av_opt_set(), av_opt_find(), 
> avcodec_parameters_to_context()
>   */
>  int avcodec_open2(AVCodecContext *avctx, const AVCodec *codec, AVDictionary 
> **options);
>  
> -- 
> 2.25.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 4/4] lavc/mediacodecenc: List supported pixel formats on configuration error

[zhilizhao(赵志立)]

> This patch has been released by Epic Games' legal department.
> ---
>  libavcodec/mediacodecenc.c | 46 ++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
> index 03c80cbf99..1b8a2837c4 100644
> --- a/libavcodec/mediacodecenc.c
> +++ b/libavcodec/mediacodecenc.c
> @@ -97,6 +97,12 @@ static const enum AVPixelFormat avc_pix_fmts[] = {
>  AV_PIX_FMT_NONE
>  };
>  
> +static const int in_formats[] = {
> +COLOR_FormatYUV420Planar,
> +COLOR_FormatYUV420SemiPlanar,
> +COLOR_FormatSurface,
> +};
> +
>  static void mediacodec_output_format(AVCodecContext *avctx)
>  {
>  MediaCodecEncContext *s = avctx->priv_data;
> @@ -131,6 +137,45 @@ static enum AVPixelFormat color2pix_fmt(AVCodecContext 
> *avctx, int color_format)
>  av_assert0(0);
>  }
>  
> +// list pixel formats if the user tried to use one that isn't supported on 
> this device
> +static void list_pix_fmts(AVCodecContext *avctx, const char *mime)
> +{
> +MediaCodecEncContext *s = avctx->priv_data;
> +int out_formats[FF_ARRAY_ELEMS(in_formats)], n;
> +char *name = ff_AMediaCodec_getName(s->codec);
> +
> +if (!name) {
> +// API level likely below 28
> +return;
> +}
> +
> +if ((n = ff_AMediaCodec_color_formats_intersect(name, mime, in_formats,
> +
> FF_ARRAY_ELEMS(in_formats),
> +out_formats, avctx)) < 
> 0) {
> +goto done;
> +}
> +
> +for (int i = 0; i < n; i++) {
> +if (color2pix_fmt(avctx, out_formats[i]) == avctx->pix_fmt) {
> +// user specified a pixel format that is actually supported,
> +// no need to print anything
> +goto done;
> +}
> +}
> +
> +AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);

Missing ‘const’ and triggered -Wdeclaration-after-statement.

> +av_log(avctx, AV_LOG_ERROR, "pixel format %s not supported by MediaCodec 
> %s\n", desc->name, name);
> +av_log(avctx, AV_LOG_INFO, "supported formats are:");
> +for (int i = 0; i < n; i++) {
> +desc = av_pix_fmt_desc_get(color2pix_fmt(avctx, out_formats[i]));
> +av_log(avctx, AV_LOG_INFO, " %s", desc->name);
> +}
> +av_log(avctx, AV_LOG_INFO, "\n");

It’s not thread safe, it can be interrupted by other threads' log message.

> +
> +done:
> +av_free(name);
> +}
> +
>  static int mediacodec_init_bsf(AVCodecContext *avctx)
>  {
>  MediaCodecEncContext *s = avctx->priv_data;
> @@ -308,6 +353,7 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
>  ret = ff_AMediaCodec_configure(s->codec, format, s->window, NULL, ret);
>  if (ret) {
>  av_log(avctx, AV_LOG_ERROR, "MediaCodec configure failed, %s\n", 
> av_err2str(ret));
> +list_pix_fmts(avctx, codec_mime);
>  goto bailout;
>  }
>  
> -- 
> 2.30.2
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/4] lavc/mediacodec_wrapper: Add function for probing supported color formats

[zhilizhao(赵志立)]

> This patch has been released by Epic Games' legal department.

This patch has the same -Wdeclaration-after-statement issue as patch 2/4.

PS: I’m not sure whether the legal statement is appropriate as commit
message. It should be self-evident for patches sending to the mailing
list :)

> ---
>  libavcodec/mediacodec_wrapper.c | 112 
>  libavcodec/mediacodec_wrapper.h |  15 +
>  2 files changed, 127 insertions(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 82eead2833..9d2560205f 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -532,6 +532,118 @@ done:
>  return name;
>  }
>  
___
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/4] lavc/mediacodec_wrapper: Refactor ff_AMediaCodecList_getCodecNameByType()

[zhilizhao(赵志立)]

> 
> A lot shorter, nested variables and keeps going in case of exceptions.
> Makes use of C99 declarations.
> 
> This patch has been released by Epic Games' legal department.

This patch triggered multiple warning:

warning: mixing declarations and code is incompatible with standards before C99 
[-Wdeclaration-after-statement]

C99 allows declaration-after-statement, but it’s not allowed by our
coding style. -Wdeclaration-after-statement is enabled explicitly in
configure.

> ---
>  libavcodec/mediacodec_wrapper.c | 162 +---
>  1 file changed, 45 insertions(+), 117 deletions(-)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 34ec2134aa..82eead2833 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -2,6 +2,7 @@
>   * Android MediaCodec Wrapper
>   *
>   * Copyright (c) 2015-2016 Matthieu Bouron 
> + * Modifications by Epic Games, Inc., 2023.
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -365,26 +366,13 @@ int 
> ff_AMediaCodecProfile_getProfileFromAVCodecContext(AVCodecContext *avctx)
>  char *ff_AMediaCodecList_getCodecNameByType(const char *mime, int profile, 
> int encoder, void *log_ctx)
>  {
>  int ret;
> -int i;
> -int codec_count;
>  int found_codec = 0;
>  char *name = NULL;
> -char *supported_type = NULL;
>  
>  JNIEnv *env = NULL;
>  struct JNIAMediaCodecListFields jfields = { 0 };
>  struct JNIAMediaFormatFields mediaformat_jfields = { 0 };
>  
> -jobject codec_name = NULL;
> -
> -jobject info = NULL;
> -jobject type = NULL;
> -jobjectArray types = NULL;
> -
> -jobject capabilities = NULL;
> -jobject profile_level = NULL;
> -jobjectArray profile_levels = NULL;
> -
>  JNI_GET_ENV_OR_RETURN(env, log_ctx, NULL);
>  
>  if ((ret = ff_jni_init_jfields(env, , 
> jni_amediacodeclist_mapping, 0, log_ctx)) < 0) {
> @@ -395,29 +383,26 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  goto done;
>  }
>  
> -codec_count = (*env)->CallStaticIntMethod(env, 
> jfields.mediacodec_list_class, jfields.get_codec_count_id);
> +int codec_count = (*env)->CallStaticIntMethod(env, 
> jfields.mediacodec_list_class, jfields.get_codec_count_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
>  goto done;
>  }
>  
> -for(i = 0; i < codec_count; i++) {
> -int j;
> -int type_count;
> -int is_encoder;
> -
> -info = (*env)->CallStaticObjectMethod(env, 
> jfields.mediacodec_list_class, jfields.get_codec_info_at_id, i);
> +for (int i = 0; i < codec_count && !found_codec; i++) {
> +jobject info = (*env)->CallStaticObjectMethod(env, 
> jfields.mediacodec_list_class, jfields.get_codec_info_at_id, i);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> +continue;
>  }
>  
> -types = (*env)->CallObjectMethod(env, info, 
> jfields.get_supported_types_id);
> +jobject codec_name = NULL;
> +jobjectArray types = (*env)->CallObjectMethod(env, info, 
> jfields.get_supported_types_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> +goto done_with_info;
>  }
>  
> -is_encoder = (*env)->CallBooleanMethod(env, info, 
> jfields.is_encoder_id);
> +int is_encoder = (*env)->CallBooleanMethod(env, info, 
> jfields.is_encoder_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> +goto done_with_info;
>  }
>  
>  if (is_encoder != encoder) {
> @@ -427,7 +412,7 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  if (jfields.is_software_only_id) {
>  int is_software_only = (*env)->CallBooleanMethod(env, info, 
> jfields.is_software_only_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> +goto done_with_info;
>  }
>  
>  if (is_software_only) {
> @@ -437,17 +422,12 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  
>  codec_name = (*env)->CallObjectMethod(env, info, 
> jfields.get_name_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> +goto done_with_info;
>  }
>  
>  name = ff_jni_jstring_to_utf_chars(env, codec_name, log_ctx);
>  if (!name) {
> -goto done;
> -}
> -
> -if (codec_name) {
> -(*env)->DeleteLocalRef(env, codec_name);
> -codec_name = NULL;
> +goto done_with_info;
>  }
>  
>  /* Skip software decoders */
> @@ -459,141 +439,89 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  goto done_with_info;

Re: [FFmpeg-devel] [PATCH 1/4] lavc/mediacodecenc: Add pix2color_fmt() and color2pix_fmt()

[zhilizhao(赵志立)]

> +static int pix2color_fmt(AVCodecContext *avctx, enum AVPixelFormat pix_fmt)
> +{
> +for (int i = 0; i < FF_ARRAY_ELEMS(color_formats); i++) {
> +if (pix_fmt == color_formats[i].pix_fmt) {
> +return color_formats[i].color_format;
> +}
> +}
> +av_assert0(0);
> +}

After extracting to a general function, there is no hint that pix_fmt comes
from avctx->pix_fmt. So I prefer return error code here.

> +
> +static enum AVPixelFormat color2pix_fmt(AVCodecContext *avctx, int 
> color_format)
> +{
> +for (int i = 0; i < FF_ARRAY_ELEMS(color_formats); i++) {
> +if (color_format == color_formats[i].color_format) {
> +return color_formats[i].pix_fmt;
> +}
> +}
> +av_assert0(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 0/4] Add hevc alpha layer decoding basic support

[zhilizhao(赵志立)]

> On Jan 6, 2023, at 23:52, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> v2:
> 1. Check vps_max_layers and vps_max_layer_id inside hevc decoder
> 2. Add hevc_extract_layer bsf to do the job rather than modifing 
> hevc_metadata,
> 3. Check vps_max_layers_minus1 and vps_max_layer_id inside bsf
> 4. Update vps_max_layers_minus1 and vps_max_layer_id when rewrite as base 
> layer
> 5. vps_extension should be updated rather than drop entirely, add a TODO

Will push soon if there's no objections.

> 
> -
> 1. Don't drop nal->nuh_layer_id > 0 until decoder.
> 2. Make hevcdec able to decode a selected layer.
> 3. Add hevc_extract_layer bsf to extract a selected layer.
> 
> Partially fix #7965. There is a sample in ticket #7965 which can be used to 
> test
> the patchset. Or use videotoolbox encoder to create a sample (FFmpeg needs to 
> be
> patched first, "avutil/hwcontext_videotoolbox: BGRA should be full range"
> http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305252.html), e.g.,
> 
> ./ffmpeg -i cctv.mp4 \
>-i pig.mp4 \
>-c:v hevc_videotoolbox \
>-alpha_quality 0.75 \
>-filter_complex '[1:v]scale=640x480[v1];[0:v][v1]alphamerge[v2]' \
>-map [v2] -an -t 60 \
>-pix_fmt bgra \
>-b:v 4M \
>-tag:v hvc1 \
>alpha.mp4 -y
> 
> 
> Now it's able to use two decoders to decode the base layer and alpha
> layer, and then combine the results, e.g.,
> 
> ./ffmpeg -i alpha.mp4 \
>   -strict -2  -nuh_layer_id 1 -i alpha.mp4 \
>   -frames 60 \
>   -filter_complex '[0:v][1:v]alphamerge[vout]' \
>   -map '[vout]' -an test-%d.png
> 
> It only works with software decoder.
> 
> hevc_extract_layer can be used together with hardware decoder. The following
> example is how to extract the alpha layer and rewrite as base layer:
> 
> ./ffmpeg -i alpha.mp4 \
>   -an -c:v copy \
>   -bsf:v hevc_extract_layer=nuh_layer_id=1 \
>   test.mp4
> 
> Zhao Zhili (4):
>  avcodec/hevc_parse: keep nal->nuh_layer_id > 0
>  avcodec/cbs_h2645: keep nal->nuh_layer_id > 0
>  avcodec/hevcdec: add nuh_layer_id option
>  avcodec: add hevc_extract_layer bsf
> 
> configure   |   1 +
> doc/bitstream_filters.texi  |  12 +++
> libavcodec/Makefile |   1 +
> libavcodec/bitstream_filters.c  |   1 +
> libavcodec/cbs_h2645.c  |   3 -
> libavcodec/hevc_extract_layer_bsf.c | 126 
> libavcodec/hevc_parse.c |   2 -
> libavcodec/hevcdec.c|  56 -
> libavcodec/version.h|   2 +-
> 9 files changed, 197 insertions(+), 7 deletions(-)
> create mode 100644 libavcodec/hevc_extract_layer_bsf.c
> 
> -- 
> 2.25.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH v2 1/8] avformat/movenc: add PCM in mp4 support

[zhilizhao(赵志立)]

> On Feb 28, 2023, at 04:24, Jan Ekström  wrote:
> 
> On Fri, Feb 24, 2023 at 8:29 PM Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> It's defined by ISO/IEC 23003-5.
>> 
>> Fixes ticket #10185
>> 
>> Signed-off-by: Zhao Zhili 
> 
> Technically if you wanted to split these commits, then this
> implementation would have to be limited to one audio channel streams,
> as 23003-5:2020
> says as follows:
> 
> - The ChannelLayout as defined in ISO/IEC 14496-12 is mandatory if the
> PCM channel count is larger than one.

OK. Will do a ping-pong with v3.

> 
>> ---
>> libavformat/movenc.c | 60 +++-
>> 1 file changed, 59 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index c4fcb5f8b1..3315057b88 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -1179,6 +1179,47 @@ static int mov_write_btrt_tag(AVIOContext *pb, 
>> MOVTrack *track)
>> return update_size(pb, pos);
>> }
>> 
>> +static int is_mp4_pcm_codec(enum AVCodecID codec)
>> +{
>> +switch (codec) {
>> +case AV_CODEC_ID_PCM_S16BE:
>> +case AV_CODEC_ID_PCM_S16LE:
>> +case AV_CODEC_ID_PCM_S24BE:
>> +case AV_CODEC_ID_PCM_S24LE:
>> +case AV_CODEC_ID_PCM_S32BE:
>> +case AV_CODEC_ID_PCM_S32LE:
>> +
>> +case AV_CODEC_ID_PCM_F32BE:
>> +case AV_CODEC_ID_PCM_F32LE:
>> +case AV_CODEC_ID_PCM_F64BE:
>> +case AV_CODEC_ID_PCM_F64LE:
>> +return 1;
>> +default:
>> +return 0;
>> +}
>> +}
> 
> This should be unnecessary if the check is switched to the codec_tags
> in mov_write_audio_tag.

> 
>> +
>> +static int mov_write_pcmc_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
>> *track)
>> +{
>> +int64_t pos = avio_tell(pb);
>> +int format_flags;
>> +
>> +avio_wb32(pb, 0); /* size */
>> +ffio_wfourcc(pb, "pcmC");
>> +avio_wb32(pb, 0); /* version & flags */
>> +
>> +/* 0x01: indicates little-endian format */
>> +format_flags = (track->par->codec_id == AV_CODEC_ID_PCM_F32LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_F64LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_S16LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_S24LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_S32LE);
>> +avio_w8(pb, format_flags);
>> +avio_w8(pb, track->par->bits_per_raw_sample);
>> +
>> +return update_size(pb, pos);
>> +}
> 
> Generally looks good. I utilized av_get_exact_bits_per_sample, but
> since mov_write_audio_tag also writes down bits_per_raw_sample, so I
> think being consistent should be OK :)
> 
>> +
>> static int mov_write_audio_tag(AVFormatContext *s, AVIOContext *pb, 
>> MOVMuxContext *mov, MOVTrack *track)
>> {
>> int64_t pos = avio_tell(pb);
>> @@ -1243,7 +1284,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
>> AVIOContext *pb, MOVMuxContex
>> } else { /* reserved for mp4/3gp */
>> avio_wb16(pb, track->par->ch_layout.nb_channels);
>> if (track->par->codec_id == AV_CODEC_ID_FLAC ||
>> -track->par->codec_id == AV_CODEC_ID_ALAC) {
>> +track->par->codec_id == AV_CODEC_ID_ALAC ||
>> +is_mp4_pcm_codec(track->par->codec_id)) {
> 
> I know why you think you should be doing this, but:
> 
> 1. 14496-12:2022 still defines AudioSampleEntry::samplesize as
> "template unsigned int(16) samplesize = 16;", so ISOBMFF itself only
> lets you set 16 here.
> 2.  23003-5:2020 does not allow other values to be written (the
> downstream spec should explicitly allow writing of non-template
> values). This is probably because pcmC itself contains PCM_sample_size
> for this same use.
> 
> So writing samplesize here is technically incorrect, even though I
> know that most likely some implementations do this (technically
> against these specs).

Technically it’s against spec. However:

1. It lets old version of libavformat able to demux PCM in mp4.
samplesize is used inside mov_parse_stsd_audio for AV_CODEC_ID_PCM.

2. samplesize is a fixed value in spec. If other mp4 demuxer implementations
ignore this field, it’s fine. If they use samplesize, it’s better to
set the real value. It’s a problem only if they reject samplesize != 16,
which is unlikely.

What do you think?

> 
> Why channelcount was made non-template yet samplesize was not? A very
> good question. Most likely the channel layout v1 and DRC boxes'
> changes started requiring the former, but not the latter?
> 
>> avio_wb16(pb, track->par->bits_per_raw_sample);
>> } else {
>> avio_wb16(pb, 16);
>> @@ -1307,6 +1349,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
>> AVIOContext *pb, MOVMuxContex
>> ret = mov_write_dmlp_tag(s, pb, track);
>> else if (track->vos_len > 0)
>> ret = mov_write_glbl_tag(pb, track);
>> +else if (track->mode == MODE_MP4 && 
>> 

Re: [FFmpeg-devel] [PATCH] Fix broken build on Android due to broken asm-generic/termbits.h include

[zhilizhao(赵志立)]

> On Feb 23, 2023, at 23:01, Hendrik Leppkes  wrote:
> 
> On Thu, Feb 23, 2023 at 3:37 PM copypaste  wrote:
>> It gets included because this platform does indeed have Video4Linux so some 
>> of the aarch64 stuff is relevant. Furthermore I think that the HEVC stuff 
>> includes it.
>> 
> 
> If its relevant for V4L or other hardware integration is fine and all
> ... but the real question is, how does it end up in aaccoder.c and
> other files entirely unrelated to video or hardware? And can we just
> get it out of those?

I know this issue exists for a long time. But I can’t reproduce it
these days.

https://github.com/android/ndk/issues/630
https://trac.ffmpeg.org/ticket/7130

The ‘B0’ macro comes from , which is defined by
asm-generic/termbits.h.  is included by libavutil/timer.h.
Thanks to the cleanup work done by Andreas Rheinhardt, the conflicts
has been reduced a lot, I think that’s why I didn’t get build errors.

Google suggests FFmpeg to fix the code problem, while NDK has
break more than one projects, see

https://github.com/jupyter-xeus/cpp-terminal/issues/35 

You can reproduce the build error with:

$ cat foo.c 
#include 

int main()
{
int B0 = 123;
}

$ make foo
cc foo.c   -o foo
foo.c:5:9: error: expected identifier or '('
int B0 = 123;
^
/data/data/com.termux/files/usr/include/asm-generic/termbits.h:118:12: note: 
expanded from macro 'B0'
#define B0 000
   ^
1 error generated.
make: *** [: foo] Error 1

> 
> - Hendrik
> ___
> 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] Bump major version of swresample

[zhilizhao(赵志立)]

> On Feb 27, 2023, at 18:03, Michael Niedermayer  wrote:
> 
> essOn Sat, Feb 25, 2023 at 12:03:02AM +0800, Wang Bin wrote:
>> 
> 
>> version_major.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> a87056c2fe65d68b2cf5d1de06be28ea40c69b73  
>> 0001-Bump-major-version-of-swresample.patch
>> From e3e6a3833f2fba743ee9c05962e804e9e570dd75 Mon Sep 17 00:00:00 2001
>> From: wang-bin 
>> Date: Fri, 24 Feb 2023 23:54:51 +0800
>> Subject: [PATCH] Bump major version of swresample
>> 
>> ---
>> libswresample/version_major.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libswresample/version_major.h b/libswresample/version_major.h
>> index 7f265c2073..dd13f2bbe3 100644
>> --- a/libswresample/version_major.h
>> +++ b/libswresample/version_major.h
>> @@ -26,6 +26,6 @@
>>  * Libswresample version macros
>>  */
>> 
>> -#define LIBSWRESAMPLE_VERSION_MAJOR   4
>> +#define LIBSWRESAMPLE_VERSION_MAJOR   5
> 
> No oppinion if this should be changed now before 6.0 or not
> but if its done it should be done on master and release/6.0 at the same time
> and LIBSWRESAMPLE_VERSION_MINOR needs to be reset too while
> LIBSWRESAMPLE_VERSION_MINOR needs to be +1 on master compared to release/6.0
> 
> oppinon from others is welcome here. Iam not a user of the releases so its
> hard for me to really guess which way is better. Its a little messy to
> change now

There is no major changes since last bump. Is it an option to keep current
major version?

> 
> thx
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> than the original author, trying to rewrite it will not make it better.
> 
> ___
> 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 v1] lavu/hwcontext_vaapi: sync surface before export its DRM handle

[zhilizhao(赵志立)]

> On Feb 24, 2023, at 13:45, Fei Wang  
> wrote:
> 
> According to description of vaExportSurfaceHandle in libva, vaSyncSurface
> must be called if the contents of the surface will be read.
> 
> Fixes ticket #9967.
> 
> Signed-off-by: Fei Wang 
> ---
> libavutil/hwcontext_vaapi.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 938bd5447d..90c2c191d9 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -1319,8 +1319,17 @@ static int vaapi_map_to_drm_esh(AVHWFramesContext 
> *hwfc, AVFrame *dst,
> surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> 
> export_flags = VA_EXPORT_SURFACE_SEPARATE_LAYERS;
> -if (flags & AV_HWFRAME_MAP_READ)
> +if (flags & AV_HWFRAME_MAP_READ) {
> export_flags |= VA_EXPORT_SURFACE_READ_ONLY;
> +
> +vas = vaSyncSurface(hwctx->display, surface_id);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(hwfc, AV_LOG_ERROR, "Failed to sync surface "
> +   "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
> +return AVERROR(EIO);
> +}
> +}
> +
> if (flags & AV_HWFRAME_MAP_WRITE)
> export_flags |= VA_EXPORT_SURFACE_WRITE_ONLY;

LGTM.

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

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

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

Re: [FFmpeg-devel] [PATCH major bump 1/6] libavutil/hdr_dynamic_vivid_metadata: fix AVHDRVividColorToneMappingParams

[zhilizhao(赵志立)]

> On Feb 2, 2023, at 16:16, Anton Khirnov  wrote:
> 
> Quoting Zhao Zhili (2023-02-02 08:02:03)
>> From: Zhao Zhili 
>> 
>> There are two group of three_Spline params. Fix the struct
>> definition and usecases inside libavcodec, libavfilter and ffprobe.
>> 
>> Co-Author: Houxiang ZHU 
>> Signed-off-by: Zhao Zhili 
>> ---
>> diff --git a/libavutil/hdr_dynamic_vivid_metadata.h 
>> b/libavutil/hdr_dynamic_vivid_metadata.h
>> index a34f83072c..4ceddc539d 100644
>> --- a/libavutil/hdr_dynamic_vivid_metadata.h
>> +++ b/libavutil/hdr_dynamic_vivid_metadata.h
>> @@ -126,42 +126,42 @@ typedef struct AVHDRVividColorToneMappingParams {
>>  * The mode of three Spline. the value shall be in the range
>>  * of 0 to 3, inclusive.
>>  */
>> -int three_Spline_TH_mode;
>> +int three_Spline_TH_mode[2];
>> 
>> /**
>>  * three_Spline_TH_enable_MB is in the range of 0.0 to 1.0, inclusive
>>  * and in multiples of 1.0/255.
>>  *
>>  */
>> -AVRational three_Spline_TH_enable_MB;
>> +AVRational three_Spline_TH_enable_MB[2];
>> 
>> /**
>>  * 3Spline_TH_enable of three Spline.
>>  * The value shall be in the range of 0.0 to 1.0, inclusive.
>>  * and in multiples of 1.0/4095.
>>  */
>> -AVRational three_Spline_TH_enable;
>> +AVRational three_Spline_TH_enable[2];
>> 
>> /**
>>  * 3Spline_TH_Delta1 of three Spline.
>>  * The value shall be in the range of 0.0 to 0.25, inclusive,
>>  * and in multiples of 0.25/1023.
>>  */
>> -AVRational three_Spline_TH_Delta1;
>> +AVRational three_Spline_TH_Delta1[2];
>> 
>> /**
>>  * 3Spline_TH_Delta2 of three Spline.
>>  * The value shall be in the range of 0.0 to 0.25, inclusive,
>>  * and in multiples of 0.25/1023.
>>  */
>> -AVRational three_Spline_TH_Delta2;
>> +AVRational three_Spline_TH_Delta2[2];
>> 
>> /**
>>  * 3Spline_enable_Strength of three Spline.
>>  * The value shall be in the range of 0.0 to 1.0, inclusive,
>>  * and in multiples of 1.0/255.
>>  */
>> -AVRational three_Spline_enable_Strength;
>> +AVRational three_Spline_enable_Strength[2];
>> } AVHDRVividColorToneMappingParams;
> 
> A major bump is not for breaking APIs however you like, only for things
> that were scheduled in advance that our callers could have prepared for.
> You should add new fields, not change existing ones.
> Also, the documentation and doc/APIchanges need to be updated.

Adding new fields works, but very ugly.

The code never work if three_Spline_num > 1. Breaking API to let user
notice that may not be a bad thing in this specific situation.

> 
> -- 
> 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 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 v5 04/10] avcodec: add MP4 to annexb support for H266/VVC

[赵志立]

> On Jan 3, 2023, at 21:40, Thomas Siedel  wrote:
> 
> Add parser for VVC MP4 to Annex B byte stream format.
> 
> Co-authored-by: Nuo Mi 
> ---
> configure|   1 +
> libavcodec/Makefile  |   2 +
> libavcodec/bitstream_filters.c   |   2 +
> libavcodec/h266_metadata_bsf.c   | 146 ++
> libavcodec/vvc_mp4toannexb_bsf.c | 329 +++

Please add these bsfs in separate patches.

> 5 files changed, 480 insertions(+)
> create mode 100644 libavcodec/h266_metadata_bsf.c
> create mode 100644 libavcodec/vvc_mp4toannexb_bsf.c

I don’t know the reason behind h265_metadata_bsf/hevc_mp4toannexb_bsf,
but I prefer use the same prefix unless there are technical reasons.
Such alias is annoying when browsing and searching the source code.

> 
> diff --git a/configure b/configure
> index 2408dca0f5..776a972663 100755
> --- a/configure
> +++ b/configure
> @@ -3286,6 +3286,7 @@ mjpeg2jpeg_bsf_select="jpegtables"
> mpeg2_metadata_bsf_select="cbs_mpeg2"
> trace_headers_bsf_select="cbs"
> vp9_metadata_bsf_select="cbs_vp9"
> +vvc_metadata_bsf_select="cbs_h266"
> 
> # external libraries
> aac_at_decoder_deps="audiotoolbox"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3e858b200b..2dee099f25 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1236,6 +1236,8 @@ OBJS-$(CONFIG_VP9_METADATA_BSF)   += 
> vp9_metadata_bsf.o
> OBJS-$(CONFIG_VP9_RAW_REORDER_BSF)+= vp9_raw_reorder_bsf.o
> OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
> OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
> +OBJS-$(CONFIG_VVC_METADATA_BSF)   += h266_metadata_bsf.o
> +OBJS-$(CONFIG_VVC_MP4TOANNEXB_BSF)+= vvc_mp4toannexb_bsf.o
> 
> # thread libraries
> OBJS-$(HAVE_LIBC_MSVCRT)   += file_open.o
> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
> index a3bebefe5f..403884f3d7 100644
> --- a/libavcodec/bitstream_filters.c
> +++ b/libavcodec/bitstream_filters.c
> @@ -64,6 +64,8 @@ extern const FFBitStreamFilter ff_vp9_metadata_bsf;
> extern const FFBitStreamFilter ff_vp9_raw_reorder_bsf;
> extern const FFBitStreamFilter ff_vp9_superframe_bsf;
> extern const FFBitStreamFilter ff_vp9_superframe_split_bsf;
> +extern const FFBitStreamFilter ff_vvc_mp4toannexb_bsf;
> +extern const FFBitStreamFilter ff_vvc_metadata_bsf;

Please sort by alphabetical order.

> 
> #include "libavcodec/bsf_list.c"
> 
> diff --git a/libavcodec/h266_metadata_bsf.c b/libavcodec/h266_metadata_bsf.c
> new file mode 100644
> index 00..f2bd2f31f3
> --- /dev/null
> +++ b/libavcodec/h266_metadata_bsf.c
> @@ -0,0 +1,146 @@
> +/*
> + * 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/common.h"
> +#include "libavutil/opt.h"
> +
> +#include "bsf.h"
> +#include "bsf_internal.h"
> +#include "cbs.h"
> +#include "cbs_bsf.h"
> +#include "cbs_h266.h"
> +#include "vvc.h"
> +
> +#define IS_SLICE(nut) (nut <= VVC_RASL_NUT || (nut >= VVC_IDR_W_RADL && nut 
> <= VVC_GDR_NUT))
> +#define IS_PH(nut) (nut == VVC_PH_NUT)

They are duplicated inside vvc_parser.c. How about add a prefix and share these 
macros?

> +
> +typedef struct VVCMetadataContext {
> +CBSBSFContext common;
> +
> +H266RawAUD aud_nal;
> +
> +int aud;
> +} VVCMetadataContext;
> +
> +static int h266_metadata_update_fragment(AVBSFContext *bsf, AVPacket *pkt,
> + CodedBitstreamFragment *pu)
> +{
> +VVCMetadataContext *ctx = bsf->priv_data;
> +int err, i;
> +
> +// If an AUD is present, it must be the first NAL unit.
> +if (pu->units[0].type == VVC_AUD_NUT) {
> +if (ctx->aud == BSF_ELEMENT_REMOVE)
> +ff_cbs_delete_unit(pu, 0);
> +} else {
> +if (ctx->aud == BSF_ELEMENT_INSERT) {

Should check pkt != NULL here.

`else if` can save one level of indentation.

> +const H266RawSlice *first_slice = NULL;
> +const H266RawPH *ph = NULL;
> +H266RawAUD *aud = >aud_nal;
> +int pic_type = 0, temporal_id = 8, layer_id = 0;
> +for (i = 0; i < pu->nb_units; i++) {
> +const H266RawNALUnitHeader *nal = 

Re: [FFmpeg-devel] [PATCH] avformat/assenc: fix incorrect copy of null terminator

[zhilizhao(赵志立)]

> On Jan 18, 2023, at 22:31, Tim Angus  wrote:
> 
> When writing a subtitle SSA/ASS subtitle file, the
> AVCodecParameters::extradata buffer is written directly to the output,
> potentially including a null terminating character, which is sometimes
> present. The result is the output having a null character in the middle;
> this is addressed here by avoiding copying it.
> 
> Signed-off-by: Tim Angus 
> ---
> libavformat/assenc.c | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/assenc.c b/libavformat/assenc.c
> index 1600f0a02b..5e74b84575 100644
> --- a/libavformat/assenc.c
> +++ b/libavformat/assenc.c
> @@ -69,6 +69,11 @@ static int write_header(AVFormatContext *s)
> ass->trailer = trailer;
> }
> 
> +/* extradata may or may not be null terminated; in the case where
> + * it is, avoid copying a null into the middle of the buffer */
> +while (header_size > 0 && par->extradata[header_size - 1] == '\0')
> +header_size--;
> +

The comment is misleading. extradata is always null terminated, although
those paddings don’t count in extradata_size.

> avio_write(s->pb, par->extradata, header_size);
> if (par->extradata[header_size - 1] != '\n')
> avio_write(s->pb, "\r\n", 2);
> -- 
> 2.25.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH v2] avutil/{color_utils, csp}: merge color_utils into csp and expose API

[zhilizhao(赵志立)]

> On Jan 31, 2023, at 02:22, Leo Izen  wrote:
> 
> On 1/30/23 12:08, Zhao Zhili wrote:
>>> -Original Message-
>>> From: ffmpeg-devel  On Behalf Of Leo Izen
>>> Sent: 2023年1月31日 0:50
>>> To: ffmpeg-devel@ffmpeg.org
>>> Cc: Leo Izen 
>>> Subject: [FFmpeg-devel] [PATCH v2] avutil/{color_utils, csp}: merge 
>>> color_utils into csp and expose API
>>> 
>>> libavutil/color_utils contains some avpriv_ symbols that map
>>> enum AVTransferCharacteristic values to gamma-curve approximations and
>>> to the actual transfer functions to invert them (i.e. -> linear).
>>> 
>>> There's two issues with this:
>>> (1) avpriv is evil and should be avoided whenever possible
>>> (2) libavutil/csp.h exposes a public API for handling color that
>>> already handles primaries and matricies
>>> 
>>> I don't see any reason this API has to be private, so this commit takes
>>> the functionality from avutil/color_utils and merges it into avutil/csp
>>> with an exposed av_ API rather than the previous avpriv_ API.
>>> 
>>> Every reference to the previous API has been updated to point to the
>>> new one. color_utils.h has been deleted as well. This should not break
>>> any applications as it only contained avpriv_ symbols in the first
>>> place, so nothing in that header could be referenced by other
>>> applications.
>> Isn't it break old libavcodec which linked to the new libavutil?
> 
> That's why it's in the major version bump thread.

OK then. Didn’t notice that because email client didn’t show thread correctly.

> 
> - Leo Izen (thebombzen)
> 
> 
> ___
> 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] ffprobe: use pkt->dts to compute interval ts when pts is missing

[zhilizhao(赵志立)]

> On Jan 17, 2023, at 07:41, Stefano Sabatini  wrote:
> 
> On date Monday 2023-01-16 11:01:51 +0800, "zhilizhao(赵志立)" wrote:
>> 
>>> On Jan 1, 2023, at 03:26, Stefano Sabatini  wrote:
>>> 
>>> On date Wednesday 2022-07-13 02:02:17 +0200, Stefano Sabatini wrote:
>>>> For some samples the pkt->pts is always missing, use the pkt->dts
>>>> instead.
>> 
>> If some pkt->pts is missing but isn’t always missing, isn’t it mixed
>> the use of pts and dts? I don’t have a particular case in mind yet.
> 
> In the ticket sample, it was missing all the PTSs, so the only time
> reference was provided by the DTSs (note that this only affects the
> -read_intervals option). I have no better ideas.

Looks like there is no better choices, patch LGTM.

> 
>>>> 
>>>> Fix trac issue http://trac.ffmpeg.org/ticket/4427.
> ___
> 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] [Internet][PATCH 1/5] avcodec/videotoolbox: fix NULL pointer dereference

[zhilizhao(赵志立)]

> On Jan 9, 2023, at 20:50, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> In the code path of av_videotoolbox_default_init/init2(),
> avctx->internal->hwaccel_priv_data is NULL and passed to
> decoder_cb.decompressionOutputRefCon. Then it will be dereferenced
> inside videotoolbox_decoder_callback().
> 
> Delay videotoolbox_star() until ff_videotoolbox_common_init() to
> fix the bug.
> ---
> libavcodec/videotoolbox.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 1b1be8ddb4..a18b49007d 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -1181,9 +1181,8 @@ int ff_videotoolbox_common_init(AVCodecContext *avctx)
> 
> vtctx->logctx = avctx;
> 
> -// Old API - do nothing.
> if (avctx->hwaccel_context)
> -return 0;
> +return videotoolbox_start(avctx);
> 
> if (!avctx->hw_frames_ctx && !avctx->hw_device_ctx) {
> av_log(avctx, AV_LOG_ERROR,
> @@ -1404,7 +1403,7 @@ int av_videotoolbox_default_init2(AVCodecContext 
> *avctx, AVVideotoolboxContext *
> avctx->hwaccel_context = vtctx ?: 
> av_videotoolbox_alloc_context_with_pix_fmt(pix_fmt, full_range);
> if (!avctx->hwaccel_context)
> return AVERROR(ENOMEM);
> -return videotoolbox_start(avctx);
> +return 0;
> }
> 
> void av_videotoolbox_default_free(AVCodecContext *avctx)
> -- 
> 2.35.3

Ping for the patchset.
___
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] avcodec/h264_mp4toannexb: fix missing SPS/PPS to IDR frames

[zhilizhao(赵志立)]

> On Jan 10, 2023, at 23:31, Zhao Zhili  wrote:
> 
> On Tue, 2023-01-10 at 07:41 +0100, Andreas Rheinhardt wrote:
>> Zhao Zhili:
>>> From: Zhao Zhili 
>>> 
>>> If there is a single group of SPS/PPS before an IDR frame, but no
>>> SPS/PPS after that, we will miss the chance to reset
>>> idr_sps_seen/idr_pps_seen. The result is missing SPS/PPS for all
>>> IDR frames except the first one.
>>> 
>>> Signed-off-by: Zhao Zhili 
>>> ---
>>> libavcodec/h264_mp4toannexb_bsf.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/libavcodec/h264_mp4toannexb_bsf.c
>>> b/libavcodec/h264_mp4toannexb_bsf.c
>>> index d11be455c2..bbdeca9c44 100644
>>> --- a/libavcodec/h264_mp4toannexb_bsf.c
>>> +++ b/libavcodec/h264_mp4toannexb_bsf.c
>>> @@ -259,7 +259,7 @@ static int h264_mp4toannexb_filter(AVBSFContext
>>> *ctx, AVPacket *opkt)
>>> 
>>> count_or_copy(, _size, buf, nal_size,
>>>   unit_type == H264_NAL_SPS || unit_type
>>> == H264_NAL_PPS, j);
>>> -if (!new_idr && unit_type == H264_NAL_SLICE) {
>>> +if (unit_type == H264_NAL_SLICE) {
>>> new_idr  = 1;
>>> sps_seen = 0;
>>> pps_seen = 0;
>> 
>> If I understand you correctly, you want that to include the parameter
>> sets from the extradata to every IDR frame without extradata if said
>> IDR
>> frame follows a non-IDR frame after in-band parameter sets. There is
>> just one problem with this: Said in-band parameter sets might
>> overwrite
>> parameter sets from extradata and inserting the outdated parameter
>> sets
>> from extradata lateron might make the stream undecodable.
> 
> It's a good question. Current code works when an IDR has in-band
> parameter set, which is different than the out-of-band parameter set,
> and the decoder doesn't miss the in-band parameter set. But there is a
> high chance the decoder will miss the in-band parameter set for annexb
> bitstream, e.g., playback at the middle of a live mpegts streams. It's
> a serious issue of missing periodic in-band parameter set for annexb
> for a lot of usecases. Handle new parameter set isn't as common as the
> need of periodic in-band parameter set (I guess).
> 
> It's not a new issue that this bitstream failed to update the parameter
> set, for example, it doesn't handle AV_PKT_DATA_NEW_EXTRADATA. I can
> add support for
> 1. handling AV_PKT_DATA_NEW_EXTRADATA
> 2. handling in-band sps/pps
> 
> But it won't be soon.

Ping.

> 
>> 
>> - Andreas
>> 
>> ___
>> 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] ffprobe: use pkt->dts to compute interval ts when pts is missing

[zhilizhao(赵志立)]

> On Jan 1, 2023, at 03:26, Stefano Sabatini  wrote:
> 
> On date Wednesday 2022-07-13 02:02:17 +0200, Stefano Sabatini wrote:
>> For some samples the pkt->pts is always missing, use the pkt->dts
>> instead.

If some pkt->pts is missing but isn’t always missing, isn’t it mixed
the use of pts and dts? I don’t have a particular case in mind yet.

>> 
>> Fix trac issue http://trac.ffmpeg.org/ticket/4427.
>> ---
>> fftools/ffprobe.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Updated.
> <0001-ffprobe-use-pkt-dts-to-compute-interval-ts-when-pts-.patch>___
> 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 2/2] avformat/movenc: Add loop parameter to animated AVIF

[zhilizhao(赵志立)]

> On Jan 13, 2023, at 04:45, Vignesh Venkatasubramanian 
>  wrote:
> 
> The HEIF specification permits specifying the looping behavior of
> animated sequences by using the EditList (elst) box. The track
> duration will be set to the total duration of all the loops (or
> infinite) and the duration of a single loop will be set in the edit
> list box.
> 
> The default behavior is to loop infinitely.
> 
> Compliance verification:
> * This was added in libavif recently [1] and the files produced by
>  ffmpeg after this change have EditList boxes similar to the ones
>  produced by libavif (and avifdec is able to parse the loop count as
>  intended).
> * ComplianceWarden is ok with the produced files.
> * Chrome is able to play back the produced files.
> 
> [1] 
> https://github.com/AOMediaCodec/libavif/commit/4d2776a3af53ae1aefdaed463b75ba12fd9cf8c2

Pushed.

Please use [PATCH v2] next time. It isn’t clear whether it’s the same
version as another patch or not, until diffed manually.

> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
> libavformat/movenc.c | 35 +++
> libavformat/movenc.h |  1 +
> 2 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 36c76f7f60..8d31317838 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -3287,7 +3287,7 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> int64_t duration = av_rescale_rnd(calc_pts_duration(mov, track),
>   mov->movie_timescale, track->timescale,
>   AV_ROUND_UP);
> -int version = duration < INT32_MAX ? 0 : 1;
> +int version;
> int flags   = MOV_TKHD_FLAG_IN_MOVIE;
> int group   = 0;
> 
> @@ -3295,6 +3295,14 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> size_t display_matrix_size;
> int   i;
> 
> +if (mov->mode == MODE_AVIF)
> +if (!mov->avif_loop_count)
> +duration = INT64_MAX;
> +else
> +duration *= mov->avif_loop_count;
> +
> + version = duration < INT32_MAX ? 0 : 1;
> +
> if (st) {
> if (mov->per_stream_grouping)
> group = st->index;
> @@ -3414,7 +3422,10 @@ static int mov_write_tapt_tag(AVIOContext *pb, 
> MOVTrack *track)
> return update_size(pb, pos);
> }
> 
> -// This box seems important for the psp playback ... without it the movie 
> seems to hang
> +// This box is written in the following cases:
> +//   * Seems important for the psp playback. Without it the movie seems to 
> hang.
> +//   * Used for specifying the looping behavior of animated AVIF (as 
> specified
> +//   in Section 9.6 of the HEIF specification ISO/IEC 23008-12).
> static int mov_write_edts_tag(AVIOContext *pb, MOVMuxContext *mov,
>   MOVTrack *track)
> {
> @@ -3425,6 +3436,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> int entry_size, entry_count, size;
> int64_t delay, start_ct = track->start_cts;
> int64_t start_dts = track->start_dts;
> +int flags = 0;
> 
> if (track->entry) {
> if (start_dts != track->cluster[0].dts || start_ct != 
> track->cluster[0].cts) {
> @@ -3440,6 +3452,17 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> 
> delay = av_rescale_rnd(start_dts + start_ct, mov->movie_timescale,
>track->timescale, AV_ROUND_DOWN);
> +
> +if (mov->mode == MODE_AVIF) {
> +delay = 0;
> +// Section 9.6.3 of ISO/IEC 23008-12: flags specifies repetition of 
> the
> +// edit list as follows: (flags & 1) equal to 0 specifies that the 
> edit
> +// list is not repeated, while (flags & 1) equal to 1 specifies that 
> the
> +// edit list is repeated.
> +flags = mov->avif_loop_count != 1;
> +start_ct = 0;
> +}
> +
> version |= delay < INT32_MAX ? 0 : 1;
> 
> entry_size = (version == 1) ? 20 : 12;
> @@ -3452,7 +3475,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> avio_wb32(pb, size - 8);
> ffio_wfourcc(pb, "elst");
> avio_w8(pb, version);
> -avio_wb24(pb, 0); /* flags */
> +avio_wb24(pb, flags); /* flags */
> 
> avio_wb32(pb, entry_count);
> if (delay > 0) { /* add an empty edit to delay presentation */
> @@ -3469,7 +3492,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> avio_wb32(pb, -1);
> }
> avio_wb32(pb, 0x0001);
> -} else {
> +} else if (mov->mode != MODE_AVIF) {
> /* Avoid accidentally ending up with start_ct = -1 which has got a
>  * special meaning. Normally start_ct should end up positive or zero
>  * here, but use FFMIN in case dts is a small positive integer
> @@ -3670,6 +3693,9 @@ static int mov_write_trak_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVMuxContext
>   

Re: [FFmpeg-devel] [PATCH v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Jan 13, 2023, at 03:13, Rémi Denis-Courmont  wrote:
> 
> Le keskiviikkona 11. tammikuuta 2023, 10.52.08 EET Paul B Mahol a écrit :
>>> Sorry for the break, I’m trying to figure out how to make it compatible
>>> with Windows.
>> 
>> Is this even portable?
> 
> If you build FFmpeg correctly, so that all the FFmpeg libraries and the 
> application code share the same instance of the same CRT, yes. That is to 
> say, 
> you can use POSIX-style file descriptors.
> 
> Whether it is of any practical usefulness is more questionable, as those file 
> descriptors are not passed from parent to child processes

When an app requests a media file, Android system provides it as a file 
descriptor
over IPC for security. Users may find other usecases.

> 
> -- 
> Реми Дёни-Курмон
> 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 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 v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Jan 12, 2023, at 09:26, Xiang, Haihao 
>  wrote:
> 
> On Wo, 2023-01-11 at 17:10 +0800, zhilizhao(赵志立) wrote:
>>> On Jan 11, 2023, at 16:52, Paul B Mahol  wrote:
>>> 
>>> On 1/11/23, "zhilizhao(赵志立)"  wrote:
>>>> 
>>>>> On Jan 11, 2023, at 15:53, Xiang, Haihao
>>>>>  wrote:
>>>>> 
>>>>> On Wo, 2023-01-11 at 11:18 +0800, zhilizhao(赵志立) wrote:
>>>>>>> On Jan 9, 2023, at 11:17, zhilizhao(赵志立) 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> On Dec 15, 2022, at 01:10, Zhao Zhili 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> From: Zhao Zhili 
>>>>>>>> 
>>>>>>>> v2:
>>>>>>>> 1. Forbid pass file descriptor via fd:{num}, instead of -fd option
>>>>>>>> 2. Set CLOEXEC
>>>>>>>> 3. Prefer fd over pipe for fftools
>>>>>>>> 
>>>>>>>> v1: dup file descriptor
>>>>>>>> 
>>>>>>>> Zhao Zhili (8):
>>>>>>>> avformat/file: add fd option for pipe
>>>>>>>> avformat/file: reindent after the previous commit
>>>>>>>> avformat/file: dup file descriptor for pipe
>>>>>>>> avformat/file: add fd protocol
>>>>>>>> fftools/ffmpeg_demux: disable stdin interaction for fd protocol
>>>>>>>> fftools/ffplay: prefer fd over pipe for seek support
>>>>>>>> fftools/ffprobe: prefer fd over pipe for seek support
>>>>>>>> fftools/ffmpeg_demux: prefer fd over pipe for seek support
>>>>>>>> 
>>>>>>>> doc/protocols.texi  |  31 +++-
>>>>>>>> fftools/ffmpeg_demux.c  |   3 +-
>>>>>>>> fftools/ffplay.c|   2 +-
>>>>>>>> fftools/ffprobe.c   |   4 +-
>>>>>>>> libavformat/Makefile|   1 +
>>>>>>>> libavformat/file.c  | 152 +++-
>>>>>>>> 
>>>>>>>> libavformat/protocols.c |   1 +
>>>>>>>> libavformat/version.h   |   4 +-
>>>>>>>> 8 files changed, 156 insertions(+), 42 deletions(-)
>>>>>>> 
>>>>>>> Will apply soon unless there are objections.
>>>>>> 
>>>>>> Pushed.
>>>>> 
>>>>> It caused link error on Windows
>>>>> 
>>>>> INFO  - LDlibavformat/avformat-59.dll
>>>>> INFO  -Creating library libavformat/avformat.lib and object
>>>>> libavformat/avformat.exp
>>>>> INFO  - file.o : error LNK2019: unresolved external symbol S_ISREG
>>>>> referenced in
>>>>> function fd_open
>>>>> INFO  - file.o : error LNK2019: unresolved external symbol S_ISBLK
>>>>> referenced in
>>>>> function fd_open
>>>>> INFO  - libavformat\avformat-59.dll : fatal error LNK1120: 2 unresolved
>>>>> externals
>>>> 
>>>> Sorry for the break, I’m trying to figure out how to make it compatible
>>>> with Windows.
>>> 
>>> Is this even portable?
>> 
>> fstat and the macros are defined by POSIX. Windows doesn’t provide S_ISREG
>> or S_ISBLK, but it does provide S_IFREG. So the compatability macro S_ISREG()
>> should work. For S_ISBLK(), it’s always false on Windows which shouldn’t be
>> an issue.
>> 
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305545.html
> 
> Thanks for your quick fix, the error went away after applying this patch.

Thanks for the report and test, pushed as 
e30bf5acee1ae07724196c44b6b457cd9f8c94f3

> 
> - Haihao
> 
>> 
>>>>> Thanks
>>>>> Haihao
>>>>> 
>>>>>>> ___
>>>>>>> ffmpeg-devel mailing list
>>>>>>> ffmpeg-devel@ffmpeg.org
>>>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>>> 
>>>>>>> To unsubscribe, visit link above, or email
>>>>>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>>>>> 
>>>>>> ___
>>>>>> ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Jan 11, 2023, at 16:52, Paul B Mahol  wrote:
> 
> On 1/11/23, "zhilizhao(赵志立)"  wrote:
>> 
>> 
>>> On Jan 11, 2023, at 15:53, Xiang, Haihao
>>>  wrote:
>>> 
>>> On Wo, 2023-01-11 at 11:18 +0800, zhilizhao(赵志立) wrote:
>>>>> On Jan 9, 2023, at 11:17, zhilizhao(赵志立)  wrote:
>>>>> 
>>>>>> On Dec 15, 2022, at 01:10, Zhao Zhili  wrote:
>>>>>> 
>>>>>> From: Zhao Zhili 
>>>>>> 
>>>>>> v2:
>>>>>> 1. Forbid pass file descriptor via fd:{num}, instead of -fd option
>>>>>> 2. Set CLOEXEC
>>>>>> 3. Prefer fd over pipe for fftools
>>>>>> 
>>>>>> v1: dup file descriptor
>>>>>> 
>>>>>> Zhao Zhili (8):
>>>>>> avformat/file: add fd option for pipe
>>>>>> avformat/file: reindent after the previous commit
>>>>>> avformat/file: dup file descriptor for pipe
>>>>>> avformat/file: add fd protocol
>>>>>> fftools/ffmpeg_demux: disable stdin interaction for fd protocol
>>>>>> fftools/ffplay: prefer fd over pipe for seek support
>>>>>> fftools/ffprobe: prefer fd over pipe for seek support
>>>>>> fftools/ffmpeg_demux: prefer fd over pipe for seek support
>>>>>> 
>>>>>> doc/protocols.texi  |  31 +++-
>>>>>> fftools/ffmpeg_demux.c  |   3 +-
>>>>>> fftools/ffplay.c|   2 +-
>>>>>> fftools/ffprobe.c   |   4 +-
>>>>>> libavformat/Makefile|   1 +
>>>>>> libavformat/file.c  | 152 +++-
>>>>>> libavformat/protocols.c |   1 +
>>>>>> libavformat/version.h   |   4 +-
>>>>>> 8 files changed, 156 insertions(+), 42 deletions(-)
>>>>> 
>>>>> Will apply soon unless there are objections.
>>>> 
>>>> Pushed.
>>> 
>>> It caused link error on Windows
>>> 
>>> INFO  - LDlibavformat/avformat-59.dll
>>> INFO  -Creating library libavformat/avformat.lib and object
>>> libavformat/avformat.exp
>>> INFO  - file.o : error LNK2019: unresolved external symbol S_ISREG
>>> referenced in
>>> function fd_open
>>> INFO  - file.o : error LNK2019: unresolved external symbol S_ISBLK
>>> referenced in
>>> function fd_open
>>> INFO  - libavformat\avformat-59.dll : fatal error LNK1120: 2 unresolved
>>> externals
>> 
>> Sorry for the break, I’m trying to figure out how to make it compatible
>> with Windows.
> 
> Is this even portable?

fstat and the macros are defined by POSIX. Windows doesn’t provide S_ISREG
or S_ISBLK, but it does provide S_IFREG. So the compatability macro S_ISREG()
should work. For S_ISBLK(), it’s always false on Windows which shouldn’t be
an issue.

http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305545.html

> 
>> 
>>> 
>>> Thanks
>>> Haihao
>>> 
>>>> 
>>>>> ___
>>>>> ffmpeg-devel mailing list
>>>>> ffmpeg-devel@ffmpeg.org
>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>> 
>>>>> To unsubscribe, visit link above, or email
>>>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>>> 
>>>> ___
>>>> ffmpeg-devel 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 v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Jan 11, 2023, at 16:31, zhilizhao(赵志立)  wrote:
> 
> 
> 
>> On Jan 11, 2023, at 15:53, Xiang, Haihao 
>>  wrote:
>> 
>> On Wo, 2023-01-11 at 11:18 +0800, zhilizhao(赵志立) wrote:
>>>> On Jan 9, 2023, at 11:17, zhilizhao(赵志立)  wrote:
>>>> 
>>>>> On Dec 15, 2022, at 01:10, Zhao Zhili  wrote:
>>>>> 
>>>>> From: Zhao Zhili 
>>>>> 
>>>>> v2:
>>>>> 1. Forbid pass file descriptor via fd:{num}, instead of -fd option
>>>>> 2. Set CLOEXEC
>>>>> 3. Prefer fd over pipe for fftools
>>>>> 
>>>>> v1: dup file descriptor
>>>>> 
>>>>> Zhao Zhili (8):
>>>>> avformat/file: add fd option for pipe
>>>>> avformat/file: reindent after the previous commit
>>>>> avformat/file: dup file descriptor for pipe
>>>>> avformat/file: add fd protocol
>>>>> fftools/ffmpeg_demux: disable stdin interaction for fd protocol
>>>>> fftools/ffplay: prefer fd over pipe for seek support
>>>>> fftools/ffprobe: prefer fd over pipe for seek support
>>>>> fftools/ffmpeg_demux: prefer fd over pipe for seek support
>>>>> 
>>>>> doc/protocols.texi  |  31 +++-
>>>>> fftools/ffmpeg_demux.c  |   3 +-
>>>>> fftools/ffplay.c|   2 +-
>>>>> fftools/ffprobe.c   |   4 +-
>>>>> libavformat/Makefile|   1 +
>>>>> libavformat/file.c  | 152 +++-
>>>>> libavformat/protocols.c |   1 +
>>>>> libavformat/version.h   |   4 +-
>>>>> 8 files changed, 156 insertions(+), 42 deletions(-)
>>>> 
>>>> Will apply soon unless there are objections.
>>> 
>>> Pushed.
>> 
>> It caused link error on Windows
>> 
>> INFO  - LDlibavformat/avformat-59.dll
>> INFO  -Creating library libavformat/avformat.lib and object
>> libavformat/avformat.exp
>> INFO  - file.o : error LNK2019: unresolved external symbol S_ISREG 
>> referenced in
>> function fd_open
>> INFO  - file.o : error LNK2019: unresolved external symbol S_ISBLK 
>> referenced in
>> function fd_open
>> INFO  - libavformat\avformat-59.dll : fatal error LNK1120: 2 unresolved
>> externals
> 
> Sorry for the break, I’m trying to figure out how to make it compatible
> with Windows.

Should be fixed by 
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305545.html

> 
>> 
>> Thanks
>> Haihao
>> 
>>> 
>>>> ___
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>> 
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>> 
>>> ___
>>> ffmpeg-devel 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 v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Jan 11, 2023, at 15:53, Xiang, Haihao 
>  wrote:
> 
> On Wo, 2023-01-11 at 11:18 +0800, zhilizhao(赵志立) wrote:
>>> On Jan 9, 2023, at 11:17, zhilizhao(赵志立)  wrote:
>>> 
>>>> On Dec 15, 2022, at 01:10, Zhao Zhili  wrote:
>>>> 
>>>> From: Zhao Zhili 
>>>> 
>>>> v2:
>>>> 1. Forbid pass file descriptor via fd:{num}, instead of -fd option
>>>> 2. Set CLOEXEC
>>>> 3. Prefer fd over pipe for fftools
>>>> 
>>>> v1: dup file descriptor
>>>> 
>>>> Zhao Zhili (8):
>>>> avformat/file: add fd option for pipe
>>>> avformat/file: reindent after the previous commit
>>>> avformat/file: dup file descriptor for pipe
>>>> avformat/file: add fd protocol
>>>> fftools/ffmpeg_demux: disable stdin interaction for fd protocol
>>>> fftools/ffplay: prefer fd over pipe for seek support
>>>> fftools/ffprobe: prefer fd over pipe for seek support
>>>> fftools/ffmpeg_demux: prefer fd over pipe for seek support
>>>> 
>>>> doc/protocols.texi  |  31 +++-
>>>> fftools/ffmpeg_demux.c  |   3 +-
>>>> fftools/ffplay.c|   2 +-
>>>> fftools/ffprobe.c   |   4 +-
>>>> libavformat/Makefile|   1 +
>>>> libavformat/file.c  | 152 +++-
>>>> libavformat/protocols.c |   1 +
>>>> libavformat/version.h   |   4 +-
>>>> 8 files changed, 156 insertions(+), 42 deletions(-)
>>> 
>>> Will apply soon unless there are objections.
>> 
>> Pushed.
> 
> It caused link error on Windows
> 
> INFO  - LDlibavformat/avformat-59.dll
> INFO  -Creating library libavformat/avformat.lib and object
> libavformat/avformat.exp
> INFO  - file.o : error LNK2019: unresolved external symbol S_ISREG referenced 
> in
> function fd_open
> INFO  - file.o : error LNK2019: unresolved external symbol S_ISBLK referenced 
> in
> function fd_open
> INFO  - libavformat\avformat-59.dll : fatal error LNK1120: 2 unresolved
> externals

Sorry for the break, I’m trying to figure out how to make it compatible
with Windows.

> 
> Thanks
> Haihao
> 
>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> 
>> ___
>> ffmpeg-devel 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 v3 2/2] avcodec/mediacodecdec: check ff_Build_SDK_INT return value

[zhilizhao(赵志立)]

> On Jan 10, 2023, at 21:37, Tomas Härdin  wrote:
> 
> tis 2023-01-10 klockan 19:35 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> ---
>> v3: when target API <= 24 ==> when target API < 24
>> v2: add comments
>> 
>>  libavcodec/mediacodecdec.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
>> index 11f655a9aa..21464900d1 100644
>> --- a/libavcodec/mediacodecdec.c
>> +++ b/libavcodec/mediacodecdec.c
>> @@ -415,7 +415,13 @@ static av_cold int
>> mediacodec_decode_init(AVCodecContext *avctx)
>> s->ctx->codec_name, ret);
>>  
>>  sdk_int = ff_Build_SDK_INT(avctx);
>> -if (sdk_int <= 23 &&
>> +/* ff_Build_SDK_INT can fail when target API < 24 and JVM isn't
>> available.
>> + * If we don't check sdk_int > 0, the workaround might be
>> enabled by
>> + * mistake.
>> + * JVM is required to make the workaround works reliably. On the
>> other hand,
>> + * missing a workaround should not be a serious issue, we do as
>> best we can.
>> + */
>> +if (sdk_int > 0 && sdk_int <= 23 &&
>>  strcmp(s->ctx->codec_name,
>> "OMX.amlogic.mpeg2.decoder.awesome") == 0) {
>>  av_log(avctx, AV_LOG_INFO, "Enabling workaround for %s on
>> API=%d\n",
>> s->ctx->codec_name, sdk_int);
> 
> Looks OK

Patchset pushed, thanks for the review.

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

___
ffmpeg-devel 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 4/4] avcodec/videotoolboxenc: fix error code

[zhilizhao(赵志立)]

> On Jan 4, 2023, at 10:38, Steven Liu  wrote:
> 
> Zhao Zhili  于2023年1月4日周三 10:35写道：
>> 
>> From: Zhao Zhili 
>> 
>> 1. Fix return 0 on success.
>> 2. Fix return OS error code passthrough.
>> ---
>> libavcodec/videotoolboxenc.c | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>> index 3b00e542cb..56971471e4 100644
>> --- a/libavcodec/videotoolboxenc.c
>> +++ b/libavcodec/videotoolboxenc.c
>> @@ -2555,6 +2555,7 @@ static int vtenc_populate_extradata(AVCodecContext   
>> *avctx,
>> pool = VTCompressionSessionGetPixelBufferPool(vtctx->session);
>> if(!pool){
>> av_log(avctx, AV_LOG_ERROR, "Error getting pixel buffer pool.\n");
>> +status = AVERROR_EXTERNAL;
>> goto pe_cleanup;
>> }
>> 
>> @@ -2564,6 +2565,7 @@ static int vtenc_populate_extradata(AVCodecContext   
>> *avctx,
>> 
>> if(status != kCVReturnSuccess){
>> av_log(avctx, AV_LOG_ERROR, "Error creating frame from pool: %d\n", 
>> status);
>> +status = AVERROR_EXTERNAL;
>> goto pe_cleanup;
>> }
>> 
>> @@ -2581,7 +2583,7 @@ static int vtenc_populate_extradata(AVCodecContext   
>> *avctx,
>>AV_LOG_ERROR,
>>"Error sending frame for extradata: %d\n",
>>status);
>> -
>> +status = AVERROR_EXTERNAL;
>> goto pe_cleanup;
>> }
>> 
>> @@ -2589,8 +2591,10 @@ static int vtenc_populate_extradata(AVCodecContext   
>> *avctx,
>> status = VTCompressionSessionCompleteFrames(vtctx->session,
>> kCMTimeIndefinite);
>> 
>> -if (status)
>> +if (status) {
>> +status = AVERROR_EXTERNAL;
>> goto pe_cleanup;
>> +}
>> 
>> status = vtenc_q_pop(vtctx, 0, , NULL);
>> if (status) {
>> --
>> 2.35.3
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> 
> LGTM

Pushed patch v2 with minor change of commit message, thanks for the review.

> 
> Thanks
> Steven
> 
> 
> 

___
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/3] avcodec/videotoolboxenc: pass error code through

[zhilizhao(赵志立)]

> On Jan 4, 2023, at 10:35, zhilizhao(赵志立)  wrote:
> 
> 
> 
>> On Jan 4, 2023, at 02:11, Tomas Härdin  wrote:
>> 
>> tis 2023-01-03 klockan 18:18 +0800 skrev Zhao Zhili:
>>> From: Zhao Zhili 
>>> 
>>> Signed-off-by: Zhao Zhili 
>>> ---
>>> libavcodec/videotoolboxenc.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/libavcodec/videotoolboxenc.c
>>> b/libavcodec/videotoolboxenc.c
>>> index 27db4e0d5e..3b00e542cb 100644
>>> --- a/libavcodec/videotoolboxenc.c
>>> +++ b/libavcodec/videotoolboxenc.c
>>> @@ -2156,7 +2156,7 @@ static int get_cv_pixel_info(
>>> 
>>> status = get_cv_pixel_format(avctx, av_format, av_color_range,
>>> color, _guessed);
>>> if (status)
>>> -return AVERROR(EINVAL);
>>> +return status;
>>> 
>>> if (range_guessed) {
>>> if (!vtctx->warned_color_range) {
>>> @@ -2338,7 +2338,7 @@ static int
>>> create_cv_pixel_buffer(AVCodecContext   *avctx,
>>> status
>>> );
>>> 
>>> -return AVERROR_EXTERNAL;
>>> +return status;
>> 
>> Are these guaranteed to always be negative?
> 
> Yes.

Patchset applied, thanks for the review.

> 
>> 
>> /Tomas
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> ___
> ffmpeg-devel 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 v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Jan 9, 2023, at 11:17, zhilizhao(赵志立)  wrote:
> 
>> On Dec 15, 2022, at 01:10, Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> v2:
>> 1. Forbid pass file descriptor via fd:{num}, instead of -fd option
>> 2. Set CLOEXEC
>> 3. Prefer fd over pipe for fftools
>> 
>> v1: dup file descriptor
>> 
>> Zhao Zhili (8):
>> avformat/file: add fd option for pipe
>> avformat/file: reindent after the previous commit
>> avformat/file: dup file descriptor for pipe
>> avformat/file: add fd protocol
>> fftools/ffmpeg_demux: disable stdin interaction for fd protocol
>> fftools/ffplay: prefer fd over pipe for seek support
>> fftools/ffprobe: prefer fd over pipe for seek support
>> fftools/ffmpeg_demux: prefer fd over pipe for seek support
>> 
>> doc/protocols.texi  |  31 +++-
>> fftools/ffmpeg_demux.c  |   3 +-
>> fftools/ffplay.c|   2 +-
>> fftools/ffprobe.c   |   4 +-
>> libavformat/Makefile|   1 +
>> libavformat/file.c  | 152 +++-
>> libavformat/protocols.c |   1 +
>> libavformat/version.h   |   4 +-
>> 8 files changed, 156 insertions(+), 42 deletions(-)
> 
> Will apply soon unless there are objections.

Pushed.

> ___
> 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 v2 2/2] ibavformat/mov: Add support for exporting poster time.

[zhilizhao(赵志立)]

> On Oct 5, 2022, at 22:25, Bryce Chester Newman  wrote:
> 
> From: Bryce Chester Newman 
> 
> Change demuxer option name from
> poster_time_location
> to export_poster_time_location.
> 
> Export the poster_time_location if available.
> The poster_time_location is calculated using
> the poster_time / time_scale = X seconds.
> The value of poster_time_location indicates
> where in the video the poster frame is.
> 
> Addresses feedback
> from https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg138122.html.
> 
> Signed-off-by: Bryce Chester Newman bryce.new...@gettyimages.com
> ---
> doc/demuxers.texi  | 4 ++--
> libavformat/isom.h | 2 +-
> libavformat/mov.c  | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index b1f4926c40..447287357d 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -750,10 +750,10 @@ cast to int32 are used to adjust onward dts.
> Unit is the track time scale. Range is 0 to UINT_MAX. Default is 
> @code{UINT_MAX - 48000*10} which allows upto
> a 10 second dts correction for 48 kHz audio streams while accommodating 99.9% 
> of @code{uint32} range.
> 
> -@item poster_time_location
> +@item export_poster_time_location
> Export the poster_time_location if available.
> The poster_time_location is calculated using the poster_time / time_scale = X 
> seconds.
> -The value of poster_time_location indicates where in the video the poster 
> frame is.
> +The value of the poster_time_location key indicates where in the video the 
> poster frame is.
> Default is false.
> @end table
> 
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index fb3d8d5618..f621abec76 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -326,7 +326,7 @@ typedef struct MOVContext {
> int64_t extent_offset;
> } *avif_info;
> int avif_info_size;
> -int poster_time_location;
> +int export_poster_time_location;
> } MOVContext;
> 
> int ff_mp4_read_descr_len(AVIOContext *pb);
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b914bbc96a..be939f6cc2 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1542,7 +1542,7 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> avio_rb32(pb); /* current time */
> avio_rb32(pb); /* next track ID */
> 
> -if(c->poster_time_location && poster_time && c->time_scale && 
> c->time_scale > 0) {
> +if(c->export_poster_time_location && poster_time && c->time_scale && 
> c->time_scale > 0) {
> av_log(c->fc, AV_LOG_TRACE, "poster_time = %i, time_scale = %i\n", 
> poster_time, c->time_scale);
> char buffer[32];
> int poster_time_location = poster_time / c->time_scale;
> @@ -9123,7 +9123,7 @@ static const AVOption mov_options[] = {
> { "enable_drefs", "Enable external track support.", OFFSET(enable_drefs), 
> AV_OPT_TYPE_BOOL,
> {.i64 = 0}, 0, 1, FLAGS },
> { "max_stts_delta", "treat offsets above this value as invalid", 
> OFFSET(max_stts_delta), AV_OPT_TYPE_INT, {.i64 = UINT_MAX-48000*10 }, 0, 
> UINT_MAX, .flags = AV_OPT_FLAG_DECODING_PARAM },
> -{ "poster_time_location", "Export the poster time location.", 
> OFFSET(poster_time_location), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS | 
> AV_OPT_FLAG_EXPORT },
> +{ "export_poster_time_location", "Export the poster time location.", 
> OFFSET(export_poster_time_location), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> FLAGS | AV_OPT_FLAG_EXPORT },
> { NULL },
> };
> 

Firstly, the patch should be based on master.

Secondly, it’s too ad hoc. I don’t see a strong reason to export such 
information.
Those fields only defined by quicktime, not defined by ISO base media file 
format.
___
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/mediacodecdec: check ff_Build_SDK_INT return value

[zhilizhao(赵志立)]

> On Jan 9, 2023, at 20:34, Tomas Härdin  wrote:
> 
> tis 2023-01-10 klockan 00:36 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>>  libavcodec/mediacodecdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
>> index 11f655a9aa..6ef23d7369 100644
>> --- a/libavcodec/mediacodecdec.c
>> +++ b/libavcodec/mediacodecdec.c
>> @@ -415,7 +415,7 @@ static av_cold int
>> mediacodec_decode_init(AVCodecContext *avctx)
>> s->ctx->codec_name, ret);
>>  
>>  sdk_int = ff_Build_SDK_INT(avctx);
>> -if (sdk_int <= 23 &&
>> +if (sdk_int > 0 && sdk_int <= 23 &&
>>  strcmp(s->ctx->codec_name,
>> "OMX.amlogic.mpeg2.decoder.awesome") == 0) {
>>  av_log(avctx, AV_LOG_INFO, "Enabling workaround for %s on
>> API=%d\n",
>> s->ctx->codec_name, sdk_int);
> 
> Maybe it should bail out if it can't figure out the SDK level?

ff_Build_SDK_INT always fail when JVM isn’t available and target
api level < 24. If there are more usecases of ff_Build_SDK_INT(),
we might make it more robust.

For current use case:
1. If JVM is available, ff_Build_SDK_INT() should success, nothing changed.
2. If JVM is unavailable, sdk_int > 0 && sdk_int <= 23 should always be false,
since android_get_device_api_level() only available after API >= 24. Then
amlogic_mpeg2_api23_workaround doesn’t work. Even if we can make 
ff_Build_SDK_INT()
works when API < 24, get codec name doesn’t work, then 
amlogic_mpeg2_api23_workaround
doesn’t work neither. I don’t think it’s a serious issue. Old usecase with JNI
works, and this special workaround might not necessary now. 

The patch fixed a hypothetical case when the codec is 
OMX.amlogic.mpeg2.decoder.awesome
and the device api level >= 28 (get codec name works after API >= 28),
amlogic_mpeg2_api23_workaround is enabled (which shouldn’t).

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

___
ffmpeg-devel 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 v3 0/8] add fd protocol

[zhilizhao(赵志立)]

> On Dec 15, 2022, at 01:10, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> v2:
> 1. Forbid pass file descriptor via fd:{num}, instead of -fd option
> 2. Set CLOEXEC
> 3. Prefer fd over pipe for fftools
> 
> v1: dup file descriptor
> 
> Zhao Zhili (8):
>  avformat/file: add fd option for pipe
>  avformat/file: reindent after the previous commit
>  avformat/file: dup file descriptor for pipe
>  avformat/file: add fd protocol
>  fftools/ffmpeg_demux: disable stdin interaction for fd protocol
>  fftools/ffplay: prefer fd over pipe for seek support
>  fftools/ffprobe: prefer fd over pipe for seek support
>  fftools/ffmpeg_demux: prefer fd over pipe for seek support
> 
> doc/protocols.texi  |  31 +++-
> fftools/ffmpeg_demux.c  |   3 +-
> fftools/ffplay.c|   2 +-
> fftools/ffprobe.c   |   4 +-
> libavformat/Makefile|   1 +
> libavformat/file.c  | 152 +++-
> libavformat/protocols.c |   1 +
> libavformat/version.h   |   4 +-
> 8 files changed, 156 insertions(+), 42 deletions(-)

Will apply soon unless there are objections.
___
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] avformat/movenc: Add loop parameter to animated AVIF

[zhilizhao(赵志立)]

> On Jan 6, 2023, at 01:34, Vignesh Venkatasubramanian 
>  wrote:
> 
> On Thu, Jan 5, 2023 at 1:45 AM "zhilizhao(赵志立)"  
> wrote:
>> 
>> 
>> 
>>> On Jan 5, 2023, at 06:16, Vignesh Venkatasubramanian 
>>>  wrote:
>>> 
>>> The HEIF specification permits specifying the looping behavior of
>>> animated sequences by using the EditList (elst) box. The track
>>> duration will be set to the total duration of all the loops (or
>>> infinite) and the duration of a single loop will be set in the edit
>>> list box.
>>> 
>>> The default behavior is to loop infinitely.
>>> 
>>> Compliance verification:
>>> * This was added in libavif recently [1] and the files produced by
>>> ffmpeg after this change have EditList boxes similar to the ones
>>> produced by libavif (and avifdec is able to parse the loop count as
>>> intended).
>>> * ComplianceWarden is ok with the produced files.
>>> * Chrome is able to play back the produced files.
>>> 
>>> Signed-off-by: Vignesh Venkatasubramanian 
>>> ---
>>> libavformat/movenc.c | 35 +++
>>> libavformat/movenc.h |  1 +
>>> 2 files changed, 32 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> index 36c76f7f60..8d31317838 100644
>>> --- a/libavformat/movenc.c
>>> +++ b/libavformat/movenc.c
>>> @@ -3287,7 +3287,7 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
>>> MOVMuxContext *mov,
>>>int64_t duration = av_rescale_rnd(calc_pts_duration(mov, track),
>>>  mov->movie_timescale, track->timescale,
>>>  AV_ROUND_UP);
>>> -int version = duration < INT32_MAX ? 0 : 1;
>>> +int version;
>>>int flags   = MOV_TKHD_FLAG_IN_MOVIE;
>>>int group   = 0;
>>> 
>>> @@ -3295,6 +3295,14 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
>>> MOVMuxContext *mov,
>>>size_t display_matrix_size;
>>>int   i;
>>> 
>>> +if (mov->mode == MODE_AVIF)
>>> +if (!mov->avif_loop_count)
>>> +duration = INT64_MAX;
>>> +else
>>> +duration *= mov->avif_loop_count;
>>> +
>>> + version = duration < INT32_MAX ? 0 : 1;
>>> +
>>>if (st) {
>>>if (mov->per_stream_grouping)
>>>group = st->index;
>>> @@ -3414,7 +3422,10 @@ static int mov_write_tapt_tag(AVIOContext *pb, 
>>> MOVTrack *track)
>>>return update_size(pb, pos);
>>> }
>>> 
>>> -// This box seems important for the psp playback ... without it the movie 
>>> seems to hang
>>> +// This box is written in the following cases:
>>> +//   * Seems important for the psp playback. Without it the movie seems to 
>>> hang.
>>> +//   * Used for specifying the looping behavior of animated AVIF (as 
>>> specified
>>> +//   in Section 9.6 of the HEIF specification ISO/IEC 23008-12).
>>> static int mov_write_edts_tag(AVIOContext *pb, MOVMuxContext *mov,
>>>  MOVTrack *track)
>>> {
>>> @@ -3425,6 +3436,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
>>> MOVMuxContext *mov,
>>>int entry_size, entry_count, size;
>>>int64_t delay, start_ct = track->start_cts;
>>>int64_t start_dts = track->start_dts;
>>> +int flags = 0;
>>> 
>>>if (track->entry) {
>>>if (start_dts != track->cluster[0].dts || start_ct != 
>>> track->cluster[0].cts) {
>>> @@ -3440,6 +3452,17 @@ static int mov_write_edts_tag(AVIOContext *pb, 
>>> MOVMuxContext *mov,
>>> 
>>>delay = av_rescale_rnd(start_dts + start_ct, mov->movie_timescale,
>>>   track->timescale, AV_ROUND_DOWN);
>>> +
>>> +if (mov->mode == MODE_AVIF) {
>>> +delay = 0;
>>> +// Section 9.6.3 of ISO/IEC 23008-12: flags specifies repetition 
>>> of the
>>> +// edit list as follows: (flags & 1) equal to 0 specifies that the 
>>> edit
>>> +// list is not repeated, while (flags & 1) equal to 1 specifies 
>>> that the
>>> +// edit list is repeated.
>>> +flags = mov->avif_loop_count != 1;
>>> +st

Re: [FFmpeg-devel] [RFC PATCH 2/4] avcodec/cbs_h2645: keep nal->nuh_layer_id > 0

[zhilizhao(赵志立)]

> On Jan 5, 2023, at 19:18, James Almer  wrote:
> 
> On 1/5/2023 1:14 PM, Zhao Zhili wrote:
>> From: Zhao Zhili 
>> ---
>>  libavcodec/cbs_h2645.c | 3 ---
>>  1 file changed, 3 deletions(-)
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index 4ee06003c3..b12abede29 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -477,9 +477,6 @@ static int 
>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>>  AVBufferRef *ref;
>>  size_t size = nal->size;
>>  -if (nal->nuh_layer_id > 0)
>> -continue;
> 
> Have you tested samples with NALUs with a layer > 0? How does CBS handle them 
> in both reading and writing?

Yes, only with hevc alpha layer encoding. Both reading and writing work
fine. What is missing is parse VPS extension, SEI alpha channel info and
so on.

Patch 4/4 rewrite nuh_layer_id from non-zero to zero, and it works from
my test (for independent non-base layer).

> 
>> -
>>  // Remove trailing zeroes.
>>  while (size > 0 && nal->data[size - 1] == 0)
>>  --size;
> ___
> 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] [RFC PATCH 3/4] avcodec/hevcdec: add nuh_layer_id option

[zhilizhao(赵志立)]

> On Jan 5, 2023, at 19:21, James Almer  wrote:
> 
> On 1/5/2023 1:14 PM, Zhao Zhili wrote:
>> From: Zhao Zhili 
>> It can be used to decode selected independent non-base layer. One
>> use case is alpha layer decoding.
>> Signed-off-by: Zhao Zhili 
>> ---
>>  libavcodec/hevcdec.c | 20 +++-
>>  libavcodec/version.h |  2 +-
>>  2 files changed, 20 insertions(+), 2 deletions(-)
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 567e8d81d4..9641922834 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -3216,7 +3216,8 @@ static int decode_nal_units(HEVCContext *s, const 
>> uint8_t *buf, int length)
>>if (s->avctx->skip_frame >= AVDISCARD_ALL ||
>>  (s->avctx->skip_frame >= AVDISCARD_NONREF
>> -&& ff_hevc_nal_is_nonref(nal->type)) || nal->nuh_layer_id > 0)
>> +&& ff_hevc_nal_is_nonref(nal->type)) ||
>> +nal->nuh_layer_id != s->nuh_layer_id)
>>  continue;
>>ret = decode_nal_unit(s, nal);
>> @@ -3637,6 +3638,21 @@ static av_cold int hevc_decode_init(AVCodecContext 
>> *avctx)
>>  HEVCContext *s = avctx->priv_data;
>>  int ret;
>>  +if (s->nuh_layer_id > 0) {
>> +if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
>> +av_log(avctx, AV_LOG_ERROR,
>> +"Decode selected nuh_layer_id is undef development. "
>> +"Use -strict -2 to use it anyway.\n");
> 
> "Undef development"? Does decoding of these non-base layers work or not? One 
> thing is something being experimental (thus known to be working in at least 
> some cases, even if not spec compliant), and another is enabling something we 
> don't know if it's going to work or not at all.

Undef -> Under.

It works for INBL (independent non-base layer) bitstream, which is coded
without using inter-layer prediction and conforms to a single layer profile.
Apple’s "HEVC Video with Alpha Interoperability Profile” is this case from
my test, although Apple doesn’t specify it clear.

https://developer.apple.com/av-foundation/HEVC-Video-with-Alpha-Interoperability-Profile.pdf

Whether it’s INBL can be checked from vps_extension, which doesn’t get parsed
yet.

There are at least three ways to add multi-layer extension support:
1. Fully support inside hevc soft decoder, with inter-layer prediction support,
multiview and spatial scalability and so on.

2. A decoder wrapper, which has two or multi hevc decoder instances inside.
Only works for INBL streams.

3. Let user handle multiple decoder instances. Only works from INBL streams.

> 
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +if (avctx->hwaccel) {
>> +av_log(avctx, AV_LOG_ERROR,
>> +"Decode selected nuh_layer_id doesn't work with 
>> hwaccel.\n");
>> +return AVERROR(EINVAL);
>> +}
>> +}
>> +
>>  if (avctx->active_thread_type & FF_THREAD_SLICE) {
>>  s->threads_number = avctx->thread_count;
>>  ret = ff_slice_thread_init_progress(avctx);
>> @@ -3691,6 +3707,8 @@ static const AVOption options[] = {
>>  AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, PAR },
>>  { "strict-displaywin", "stricly apply default display window size", 
>> OFFSET(apply_defdispwin),
>>  AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, PAR },
>> +{ "nuh_layer_id", "Select which nuh_layer_id to decode (only works with 
>> INBL)", OFFSET(nuh_layer_id),
>> +AV_OPT_TYPE_INT,  {.i64 = 0}, 0, 62, PAR },
>>  { NULL },
>>  };
>>  diff --git a/libavcodec/version.h b/libavcodec/version.h
>> index 6b8a1dbb79..15f7c3fe3d 100644
>> --- a/libavcodec/version.h
>> +++ b/libavcodec/version.h
>> @@ -30,7 +30,7 @@
>>  #include "version_major.h"
>>#define LIBAVCODEC_VERSION_MINOR  56
>> -#define LIBAVCODEC_VERSION_MICRO 100
>> +#define LIBAVCODEC_VERSION_MICRO 101
>>#define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
>> LIBAVCODEC_VERSION_MINOR, \
> ___
> 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 2/2] avformat/movenc: Add loop parameter to animated AVIF

[zhilizhao(赵志立)]

> On Jan 5, 2023, at 06:16, Vignesh Venkatasubramanian 
>  wrote:
> 
> The HEIF specification permits specifying the looping behavior of
> animated sequences by using the EditList (elst) box. The track
> duration will be set to the total duration of all the loops (or
> infinite) and the duration of a single loop will be set in the edit
> list box.
> 
> The default behavior is to loop infinitely.
> 
> Compliance verification:
> * This was added in libavif recently [1] and the files produced by
>  ffmpeg after this change have EditList boxes similar to the ones
>  produced by libavif (and avifdec is able to parse the loop count as
>  intended).
> * ComplianceWarden is ok with the produced files.
> * Chrome is able to play back the produced files.
> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
> libavformat/movenc.c | 35 +++
> libavformat/movenc.h |  1 +
> 2 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 36c76f7f60..8d31317838 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -3287,7 +3287,7 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> int64_t duration = av_rescale_rnd(calc_pts_duration(mov, track),
>   mov->movie_timescale, track->timescale,
>   AV_ROUND_UP);
> -int version = duration < INT32_MAX ? 0 : 1;
> +int version;
> int flags   = MOV_TKHD_FLAG_IN_MOVIE;
> int group   = 0;
> 
> @@ -3295,6 +3295,14 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> size_t display_matrix_size;
> int   i;
> 
> +if (mov->mode == MODE_AVIF)
> +if (!mov->avif_loop_count)
> +duration = INT64_MAX;
> +else
> +duration *= mov->avif_loop_count;
> +
> + version = duration < INT32_MAX ? 0 : 1;
> +
> if (st) {
> if (mov->per_stream_grouping)
> group = st->index;
> @@ -3414,7 +3422,10 @@ static int mov_write_tapt_tag(AVIOContext *pb, 
> MOVTrack *track)
> return update_size(pb, pos);
> }
> 
> -// This box seems important for the psp playback ... without it the movie 
> seems to hang
> +// This box is written in the following cases:
> +//   * Seems important for the psp playback. Without it the movie seems to 
> hang.
> +//   * Used for specifying the looping behavior of animated AVIF (as 
> specified
> +//   in Section 9.6 of the HEIF specification ISO/IEC 23008-12).
> static int mov_write_edts_tag(AVIOContext *pb, MOVMuxContext *mov,
>   MOVTrack *track)
> {
> @@ -3425,6 +3436,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> int entry_size, entry_count, size;
> int64_t delay, start_ct = track->start_cts;
> int64_t start_dts = track->start_dts;
> +int flags = 0;
> 
> if (track->entry) {
> if (start_dts != track->cluster[0].dts || start_ct != 
> track->cluster[0].cts) {
> @@ -3440,6 +3452,17 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> 
> delay = av_rescale_rnd(start_dts + start_ct, mov->movie_timescale,
>track->timescale, AV_ROUND_DOWN);
> +
> +if (mov->mode == MODE_AVIF) {
> +delay = 0;
> +// Section 9.6.3 of ISO/IEC 23008-12: flags specifies repetition of 
> the
> +// edit list as follows: (flags & 1) equal to 0 specifies that the 
> edit
> +// list is not repeated, while (flags & 1) equal to 1 specifies that 
> the
> +// edit list is repeated.
> +flags = mov->avif_loop_count != 1;
> +start_ct = 0;
> +}
> +
> version |= delay < INT32_MAX ? 0 : 1;
> 
> entry_size = (version == 1) ? 20 : 12;
> @@ -3452,7 +3475,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> avio_wb32(pb, size - 8);
> ffio_wfourcc(pb, "elst");
> avio_w8(pb, version);
> -avio_wb24(pb, 0); /* flags */
> +avio_wb24(pb, flags); /* flags */
> 
> avio_wb32(pb, entry_count);
> if (delay > 0) { /* add an empty edit to delay presentation */
> @@ -3469,7 +3492,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
> avio_wb32(pb, -1);
> }
> avio_wb32(pb, 0x0001);
> -} else {
> +} else if (mov->mode != MODE_AVIF) {
> /* Avoid accidentally ending up with start_ct = -1 which has got a
>  * special meaning. Normally start_ct should end up positive or zero
>  * here, but use FFMIN in case dts is a small positive integer
> @@ -3670,6 +3693,9 @@ static int mov_write_trak_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVMuxContext
>"Not writing any edit list even though one would have been 
> required\n");
> }
> 
> +if (mov->is_animated_avif)
> +mov_write_edts_tag(pb, mov, track);
> +
> if (track->tref_tag)
> 

Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: Add movie_timescale option to AVIF

[zhilizhao(赵志立)]

> On Jan 5, 2023, at 06:16, Vignesh Venkatasubramanian 
>  wrote:
> 
> Allow specifying the movie_timescale options to AVIF ouptut.
> 
> This also makes sure that when movie_timescale is not specified,
> the default value of 1000 is used instead of 0. Animated AVIF
> files which don't specify the movie_timescale will have the
> correct duration written in the track and movie headers after this
> change (instead of writing 0).
> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
> libavformat/movenc.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 7d49892283..36c76f7f60 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -7758,6 +7758,11 @@ static const AVCodecTag codec_f4v_tags[] = {
> };
> 
> #if CONFIG_AVIF_MUXER
> +
> +static const AVOption avif_options[] = {
> +{ "movie_timescale", "set movie timescale", offsetof(MOVMuxContext, 
> movie_timescale), AV_OPT_TYPE_INT, {.i64 = MOV_TIMESCALE}, 1, INT_MAX, 
> AV_OPT_FLAG_ENCODING_PARAM},
> +{ NULL },
> +};

If there is a chance to add more options which is shared with
mov_isobmff_muxer_class, define a common option to avoid
duplication. Otherwise keep it as this.

> static const AVCodecTag codec_avif_tags[] = {
> { AV_CODEC_ID_AV1, MKTAG('a','v','0','1') },
> { AV_CODEC_ID_NONE, 0 },
> @@ -7767,6 +7772,7 @@ static const AVCodecTag *const codec_avif_tags_list[] = 
> { codec_avif_tags, NULL
> static const AVClass mov_avif_muxer_class = {
> .class_name = "avif muxer",
> .item_name  = av_default_item_name,
> +.option = avif_options,
> .version= LIBAVUTIL_VERSION_INT,
> };
> #endif
> -- 
> 2.39.0.314.g84b9a713c41-goog
> 
> ___
> 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] [Internet]Re: [PATCH v2 5/7] avcodec/mediacodecenc: remove the strategy to create DTS

[zhilizhao(赵志立)]

> On Jan 4, 2023, at 18:16, Anton Khirnov  wrote:
> 
> Does this mean the encoder will produce packets with dts=AV_NOPTS_VALUE?

MediaCodec should not encode B frames by default, so dts = pts by default.
B frames can be enabled explicitly, in that case dts is AV_NOPTS_VALUE.

Android system’s MP4 muxer works very hard to recreate dts to workaround
the limitation of MediaCodec API. It create ‘valid’ but almost useless
files with a lot of jitters.

> 
> -- 
> 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 2/3] avcodec/videotoolboxenc: pass error code through

[zhilizhao(赵志立)]

> On Jan 4, 2023, at 02:11, Tomas Härdin  wrote:
> 
> tis 2023-01-03 klockan 18:18 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>>  libavcodec/videotoolboxenc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavcodec/videotoolboxenc.c
>> b/libavcodec/videotoolboxenc.c
>> index 27db4e0d5e..3b00e542cb 100644
>> --- a/libavcodec/videotoolboxenc.c
>> +++ b/libavcodec/videotoolboxenc.c
>> @@ -2156,7 +2156,7 @@ static int get_cv_pixel_info(
>>  
>>  status = get_cv_pixel_format(avctx, av_format, av_color_range,
>> color, _guessed);
>>  if (status)
>> -return AVERROR(EINVAL);
>> +return status;
>>  
>>  if (range_guessed) {
>>  if (!vtctx->warned_color_range) {
>> @@ -2338,7 +2338,7 @@ static int
>> create_cv_pixel_buffer(AVCodecContext   *avctx,
>>  status
>>  );
>>  
>> -return AVERROR_EXTERNAL;
>> +return status;
> 
> Are these guaranteed to always be negative?

Yes.

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

___
ffmpeg-devel 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] libavformat/rtspdec.c: flush pes buffer while rtsp seek

[zhilizhao(赵志立)]

> On Dec 29, 2022, at 11:43, tanwei (D)  wrote:
> 
>>> 
>>> +if (rt->cur_transport_priv && rt->transport == 
>>> + RTSP_TRANSPORT_RTP) {
>>> 
>>> +ff_rtp_seek_flush(rt->cur_transport_priv);
>>> 
>>> +} else if (CONFIG_RTPDEC && rt->ts) {
>>> 
>>> +av_freep(>recvbuf);
> 
>> Is it necessary to free rt->recvbuf? 
> The recvbuf must be released. Otherwise, data before seek may be read in the 
> RTSP+TS scenario.

Read from recvbuf with recvbuf_len = 0 ? How is it possible?

>>> 
>>> +rt->recvbuf_pos = 0;
>>> 
>>> +rt->recvbuf_len = 0;
>>> 
>>> +ff_mpegts_seek_flush(rt->ts);
>>> 
>>> +}
> 
> 
> 
> -邮件原件-
> 发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 "zhilizhao(赵志立)"
> 发送时间: 2022年12月23日 10:34
> 收件人: FFmpeg development discussions and patches 
> 抄送: Wujian(Chin) ; Lingzezhi 
> 主题: Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec.c: flush pes buffer while 
> rtsp seek
> 
> 
> 
>> On Dec 22, 2022, at 11:32, tanwei (D)  wrote:
>> 
>> Fixes ticket #9949.
>> 
>> 
>> Signed-off-by: t00660896 
>> 
>> ---
>> 
>> libavformat/mpegts.c| 20 
>> 
>> libavformat/mpegts.h|  1 +
>> 
>> libavformat/rtpdec.c|  7 +++
>> 
>> libavformat/rtpdec.h|  2 ++
>> 
>> libavformat/rtpdec_mpegts.c | 11 +++
>> 
>> libavformat/rtspdec.c   | 11 +++
>> 
>> 6 files changed, 52 insertions(+)
>> 
>> 
> 
> Please check the patch format (a lot of empty lines).
> 
>> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>> 
>> index d97702fcd7..c82971af87 100644
>> 
>> --- a/libavformat/mpegts.c
>> 
>> +++ b/libavformat/mpegts.c
>> 
>> @@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext 
>> *ts, AVPacket *pkt,
>> 
>>return len1 - len;
>> 
>> }
>> 
>> +void ff_mpegts_seek_flush(MpegTSContext *ts)
>> 
>> +{
>> 
>> +int i;
>> 
>> +/* flush pes buffer */
>> 
>> +for (i = 0; i < NB_PID_MAX; i++) {
>> 
>> +if (ts->pids[i]) {
>> 
>> +if (ts->pids[i]->type == MPEGTS_PES) {
>> 
>> +PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
>> 
>> +av_buffer_unref(>buffer);
>> 
>> +pes->data_index = 0;
>> 
>> +pes->state = MPEGTS_SKIP; /* skip until pes header */
>> 
>> +} else if (ts->pids[i]->type == MPEGTS_SECTION) {
>> 
>> +ts->pids[i]->u.section_filter.last_ver = -1;
>> 
>> +}
>> 
>> +ts->pids[i]->last_cc = -1;
>> 
>> +ts->pids[i]->last_pcr = -1;
>> 
>> +}
>> 
>> +}
>> 
>> +}
>> 
>> +
> 
> Please don’t just duplicate the source code.
> 
>> 
>> void avpriv_mpegts_parse_close(MpegTSContext *ts)
>> 
>> {
>> 
>>mpegts_free(ts);
>> 
>> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
>> 
>> index a48f14e768..ea6b5106a4 100644
>> 
>> --- a/libavformat/mpegts.h
>> 
>> +++ b/libavformat/mpegts.h
>> 
>> @@ -170,6 +170,7 @@ MpegTSContext 
>> *avpriv_mpegts_parse_open(AVFormatContext *s);
>> 
>> int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
>> 
>>   const uint8_t *buf, int len);
>> 
>> void avpriv_mpegts_parse_close(MpegTSContext *ts);
>> 
>> +void ff_mpegts_seek_flush(MpegTSContext *ts);
>> 
>> typedef struct SLConfigDescr {
>> 
>>int use_au_start;
>> 
>> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
>> 
>> index fa7544cc07..d688afd1c1 100644
>> 
>> --- a/libavformat/rtpdec.c
>> 
>> +++ b/libavformat/rtpdec.c
>> 
>> @@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, 
>> AVPacket *pkt,
>> 
>>return rv ? rv : has_next_packet(s);
>> 
>> }
>> 
>> +void ff_rtp_seek_flush(RTPDemuxContext *s)
>> 
>> +{
>> 
>> +ff_rtp_reset_packet_queue(s);
>> 
>> +if (s->handler && s->handler->seek_flush)
>> 
>> +s->handler-

Re: [FFmpeg-devel] [PATCH] avformat/rtpproto: add support for RTP/UDP socket reuse

[zhilizhao(赵志立)]

> On Dec 27, 2022, at 05:47, Nicolas George  wrote:
> 
> "zhilizhao(赵志立)" (12022-12-26):
>> Just use the same socket file descriptor. Don’t use OS dependent hack to
>> implement a feature.
> 
> SO_REUSEADDR is absolutely not a hack. I agree that it is not the
> correct way of implementing the feature evoked in this thread, but I
> insist it is not a hack.

I know what SO_REUSEADDR does. Use SO_REUSEADDR to implement the feature
is a hack, not SO_REUSEADDR itself.

> 
> -- 
>  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] avformat/rtpproto: add support for RTP/UDP socket reuse

[zhilizhao(赵志立)]

> On Dec 26, 2022, at 07:52, Camille Oudot  
> wrote:
> 
> On Sun, 2022-12-25 at 11:00 +0100, Rémi Denis-Courmont wrote:
> 
> 
>> Again, there is also REUSEPORT, which is what you'd want on Linux in
>> this case, but behaves differently on BSD and doesn't exist at all on
>> Windows (IIRC).
> 
> That option is indeed preferable for security. It works equally good
> for the muxing use case, on Linux, with UDP sockets. I don't see why
> not using it instead, will do it in a new version of the patch.
> 
>> So even for sending, I don't think this patch really works.
> 
> REUSEADDR and thus this patch _are_ working well on Linux, with sockets
> that only send datagrams. It might behave differently on other systems
> though: I've read it is impossible to open two sockets having the same
> proto/src IP/src port/dst IP/dst port on BSD systems, but I don't have
> one handy. I will try it ASAP.
> 
> What is the project's policy on options that are incompatible with some
> systems, or that behave differently?

Just use the same socket file descriptor. Don’t use OS dependent hack to
implement a feature.

> 
> Regards
> 
> -- 
> Camille
> 
> 
> ___
> 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] libavformat/rtspdec.c: flush pes buffer while rtsp seek

[zhilizhao(赵志立)]

> On Dec 22, 2022, at 11:32, tanwei (D)  wrote:
> 
> Fixes ticket #9949.
> 
> 
> Signed-off-by: t00660896 
> 
> ---
> 
> libavformat/mpegts.c| 20 
> 
> libavformat/mpegts.h|  1 +
> 
> libavformat/rtpdec.c|  7 +++
> 
> libavformat/rtpdec.h|  2 ++
> 
> libavformat/rtpdec_mpegts.c | 11 +++
> 
> libavformat/rtspdec.c   | 11 +++
> 
> 6 files changed, 52 insertions(+)
> 
> 

Please check the patch format (a lot of empty lines).

> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> 
> index d97702fcd7..c82971af87 100644
> 
> --- a/libavformat/mpegts.c
> 
> +++ b/libavformat/mpegts.c
> 
> @@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext *ts, 
> AVPacket *pkt,
> 
> return len1 - len;
> 
> }
> 
> +void ff_mpegts_seek_flush(MpegTSContext *ts)
> 
> +{
> 
> +int i;
> 
> +/* flush pes buffer */
> 
> +for (i = 0; i < NB_PID_MAX; i++) {
> 
> +if (ts->pids[i]) {
> 
> +if (ts->pids[i]->type == MPEGTS_PES) {
> 
> +PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
> 
> +av_buffer_unref(>buffer);
> 
> +pes->data_index = 0;
> 
> +pes->state = MPEGTS_SKIP; /* skip until pes header */
> 
> +} else if (ts->pids[i]->type == MPEGTS_SECTION) {
> 
> +ts->pids[i]->u.section_filter.last_ver = -1;
> 
> +}
> 
> +ts->pids[i]->last_cc = -1;
> 
> +ts->pids[i]->last_pcr = -1;
> 
> +}
> 
> +}
> 
> +}
> 
> +

Please don’t just duplicate the source code.

> 
> void avpriv_mpegts_parse_close(MpegTSContext *ts)
> 
> {
> 
> mpegts_free(ts);
> 
> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> 
> index a48f14e768..ea6b5106a4 100644
> 
> --- a/libavformat/mpegts.h
> 
> +++ b/libavformat/mpegts.h
> 
> @@ -170,6 +170,7 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext 
> *s);
> 
> int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
> 
>const uint8_t *buf, int len);
> 
> void avpriv_mpegts_parse_close(MpegTSContext *ts);
> 
> +void ff_mpegts_seek_flush(MpegTSContext *ts);
> 
> typedef struct SLConfigDescr {
> 
> int use_au_start;
> 
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> 
> index fa7544cc07..d688afd1c1 100644
> 
> --- a/libavformat/rtpdec.c
> 
> +++ b/libavformat/rtpdec.c
> 
> @@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket 
> *pkt,
> 
> return rv ? rv : has_next_packet(s);
> 
> }
> 
> +void ff_rtp_seek_flush(RTPDemuxContext *s)
> 
> +{
> 
> +ff_rtp_reset_packet_queue(s);
> 
> +if (s->handler && s->handler->seek_flush)
> 
> +s->handler->seek_flush(s->dynamic_protocol_context);
> 
> +}
> 
> +
> 
> void ff_rtp_parse_close(RTPDemuxContext *s)
> 
> {
> 
> ff_rtp_reset_packet_queue(s);
> 
> diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
> 
> index 5a02e72dc2..8d6d857e28 100644
> 
> --- a/libavformat/rtpdec.h
> 
> +++ b/libavformat/rtpdec.h
> 
> @@ -52,6 +52,7 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
> 
> void ff_rtp_parse_close(RTPDemuxContext *s);
> 
> int64_t ff_rtp_queued_packet_time(RTPDemuxContext *s);
> 
> void ff_rtp_reset_packet_queue(RTPDemuxContext *s);
> 
> +void ff_rtp_seek_flush(RTPDemuxContext *s);
> 
> /**
> 
>  * Send a dummy packet on both port pairs to set up the connection
> 
> @@ -135,6 +136,7 @@ struct RTPDynamicProtocolHandler {
> 
> /** Parse handler for this dynamic packet */
> 
> DynamicPayloadPacketHandlerProc parse_packet;
> 
> int (*need_keyframe)(PayloadContext *context);
> 
> +void (*seek_flush)(PayloadContext *protocol_data);
> 
> };
> 
> typedef struct RTPPacket {
> 
> diff --git a/libavformat/rtpdec_mpegts.c b/libavformat/rtpdec_mpegts.c
> 
> index 405271f744..46c1d36021 100644
> 
> --- a/libavformat/rtpdec_mpegts.c
> 
> +++ b/libavformat/rtpdec_mpegts.c
> 
> @@ -47,6 +47,16 @@ static av_cold int mpegts_init(AVFormatContext *ctx, int 
> st_index,
> 
> return 0;
> 
> }
> 
> +static void mpegts_seek_flush(PayloadContext *data)
> 
> +{
> 
> +if (!data)
> 
> +return;

Is it possible for data being NULL? It’s better to depends on a clear
lifecycle management rather than NULL pointer check everywhere.

> 
> +memset(data->buf, 0, data->read_buf_size);
> 
> +data->read_buf_size = 0;

What about data->read_buf_index ?

> 
> +if (data->ts)
> 
> +ff_mpegts_seek_flush(data->ts);
> 
> +}
> 
> +
> 
> static int mpegts_handle_packet(AVFormatContext *ctx, PayloadContext *data,
> 
> AVStream *st, AVPacket *pkt, uint32_t 
> *timestamp,
> 
> const uint8_t *buf, int len, uint16_t seq,
> 
> @@ -94,6 +104,7 @@ const RTPDynamicProtocolHandler ff_mpegts_dynamic_handler 
> = {
> 
> .priv_data_size= sizeof(PayloadContext),
> 
> .parse_packet  = mpegts_handle_packet,
> 
> 

Re: [FFmpeg-devel] [PATCH v3 3/7] avcodec/mediacodecenc: use bsf to handle crop

[zhilizhao(赵志立)]

> On Dec 21, 2022, at 02:24, Tomas Härdin  wrote:
> 
> tor 2022-12-15 klockan 01:37 +0800 skrev Zhao Zhili:
>> On Wed, 2022-12-14 at 18:08 +0100, Tomas Härdin wrote:
>> 
>>> 
>>> I think we might want something for this inside lavf somewhere, so
>>> that
>>> encoders can signal dimension alignment requirements. Some
>>> containers
>>> (MXF, MOV) support such cropping in a codec-agnostic manner.
>> 
>> From my own experience, dimension mismatch between codec and
>> container
>> makes a lot of trouble. ISO base format specification specified how
>> to
>> crop/scale after decoding clear, however, I don't think it has been
>> widely supported, including FFmpeg. We can fix that inside of FFmpeg,
>> but we should avoid such cases as much as we can.
> 
> This is the difference between stored, sampled and display dimensions
> in MXF. For example 1080i video has StoredHeight = 544, SampledHeight =
> 540 and DisplayHeight = 540 (see AS-10). When you add VBLANK and HBLANK
> to the mix then all three dimensions are typically different.
> 
> Anyway specifying at the NAL level whenever the essence isn't a
> multiple of 16x16 is obviously normal. The only complication I can
> think of is 4:2:2 and 4:4:4. Does MC require 16x16 also in those cases?
> I'd expect 16x8 and 8x8 respectively.

It’s still 16x16. From H.264 specification:

macroblock: A 16x16 block of luma samples and two corresponding blocks of
chroma samples of a picture that has three sample arrays, or a 16x16 block
of samples of a monochrome picture or a picture that is coded using three
separate colour planes.

Macroblock has been replaced by coding tree unit with H.265, which can be
between 16×16 pixels and 64×64 pixels in size.

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

___
ffmpeg-devel 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/ffmpeg_ffplay_ffprobe_cmdutils: add -mask_url to replace the protocol address in the command with the asterisk (*)

[zhilizhao(赵志立)]

> On Dec 19, 2022, at 21:40, Marvin Scholz  wrote:
> 
> 
> On 19 Dec 2022, at 14:37, Nicolas George wrote:
> 
>> Marvin Scholz (12022-12-19):
>>> IIUC this means the `-mask_url` option has to be the first option passed,
>>> which seems a bit of an unfortunate requirement and is not documented at
>>> all, as far as I can see. So at least this should be clearly documented
>>> to prevent users being confused why the get an unrecognised option error
>>> when they do not pass it as the first option.
>> 
>> Indeed. And I see no reason to have this option processed specially like
>> that; it requires at least an explanation.
>> 
>>> I am a bit confused how this helps for the issue it tries to solve, as
>>> for some amount of time, until this is done, it would expose the full
>>> plaintext URL still, no?
>> 
>> This is unavoidable. Still, having sensitive information visible for a
>> fraction of a second is better than having sensitive information visible
>> for the length of a playback or transcoding process.
> 
> I agree, but then the docs should probably mention that to not give a false
> sense of absolute security here. And maybe note that it might
> be a better option to pass the password via stdin or hide the process
> from other users to completely avoid leaking the password.

We have options like ‘-password', ‘-key’, ‘-cryptokey' and so on. I prefer 
hide the entire argument lists if we accept this solution. I don’t know about
system administration, hidepid looks like a neat solution.
https://linux-audit.com/linux-system-hardening-adding-hidepid-to-proc/

> 
>> 
>> 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".
> ___
> 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] fftools/ffmpeg_ffplay_ffprobe_cmdutils: add -safe to replace the user name and password in the protocol address

[zhilizhao(赵志立)]

> On Dec 19, 2022, at 14:50, Wujian(Chin)  wrote:
> 
> 
>>> On Dec 17, 2022, at 15:36, Wujian(Chin)  wrote:
>>> 
>>> The Protocol address may contain the user name and password. The ps -ef 
>>> command may expose the plaintext.
>>> The -safe parameter option is added to replace the user name and password 
>>> in the command line with the asterisk (*).
> 
>> The patch reduced the risk to a low level, but I don’t think it fixed the 
>> security issue totally. It’s still there with a small time window. The 
>> usecase itself is unsafe.
> 
> It's still there with a small time window, too short for people to capture.
> Do you have any other better way, if not, this way prevents 99% of the scenes 
> better than not doing it at all.
> 
> 
>> There is an -safe option in concat demuxer, please make sure there is no 
>> conflict.
>> concat demuxer AVOptions:
>> -safe  .D. enable safe mode (default true)
> 
> There is no conflict because -safe is identified by the second parameter 
> after ffmpeg/ffprobe/ffplay.

Isn’t it break the following use case?

ffmpeg -safe 0 -f concat -i abc -c copy /tmp/test.mp4

> 
> 
>>> Signed-off-by: wujian_nanjing 
>>> ---
>>> doc/ffmpeg.texi|  7 +++
>>> doc/ffplay.texi|  8 
>>> doc/ffprobe.texi   |  7 +++
>>> fftools/cmdutils.c | 47 
>>> +++
>>> fftools/cmdutils.h | 15 +++
>>> fftools/ffmpeg.c   | 16 +---
>>> fftools/ffplay.c   | 15 +--
>>> fftools/ffprobe.c  | 18 ++
>>> 8 files changed, 120 insertions(+), 13 deletions(-)
>>> 
>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index 0367930..e905542 
>>> 100644
>>> --- a/doc/ffmpeg.texi
>>> +++ b/doc/ffmpeg.texi
>>> @@ -50,6 +50,13 @@ output files. Also do not mix options which belong 
>>> to different files. All options apply ONLY to the next input or output file 
>>> and are reset between files.
>>> 
>>> @itemize
>>> +@item -safe
>>> +The Protocol address may contain the user name and password. The ps -ef 
>>> command may expose the plaintext.
>>> +The -safe parameter option is added to replace the user name and password 
>>> in the command line with the asterisk (*).
>>> +@example
>>> +ffmpeg -safe -i rtsp://usern...@password..com @end example
>>> +
>>> @item
>>> To set the video bitrate of the output file to 64 kbit/s:
>>> @example
>>> diff --git a/doc/ffplay.texi b/doc/ffplay.texi index 5dd860b..f46ca91 
>>> 100644
>>> --- a/doc/ffplay.texi
>>> +++ b/doc/ffplay.texi
>>> @@ -122,6 +122,14 @@ Read @var{input_url}.
>>> 
>>> @section Advanced options
>>> @table @option
>>> +
>>> +@item -safe
>>> +The Protocol address may contain the user name and password. The ps -ef 
>>> command may expose the plaintext.
>>> +The -safe parameter option is added to replace the user name and password 
>>> in the command line with the asterisk (*).
>>> +@example
>>> +ffplay -safe -i rtsp://usern...@password..com @end example
>>> +
>>> @item -stats
>>> Print several playback statistics, in particular show the stream 
>>> duration, the codec parameters, the current position in the stream and 
>>> diff --git a/doc/ffprobe.texi b/doc/ffprobe.texi index 
>>> 4dc9f57..92b13cf 100644
>>> --- a/doc/ffprobe.texi
>>> +++ b/doc/ffprobe.texi
>>> @@ -89,6 +89,13 @@ Set the output printing format.
>>> @var{writer_name} specifies the name of the writer, and 
>>> @var{writer_options} specifies the options to be passed to the writer.
>>> 
>>> +@item -safe
>>> +The Protocol address may contain the user name and password. The ps -ef 
>>> command may expose the plaintext.
>>> +The -safe parameter option is added to replace the user name and password 
>>> in the command line with the asterisk (*).
>>> +@example
>>> +ffprobe -safe -i rtsp://usern...@password..com @end example
>>> +
>>> For example for printing the output in JSON format, specify:
>>> @example
>>> -print_format json
>>> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c index 
>>> a1de621..22407f8 100644
>>> --- a/fftools/cmdutils.c
>>> +++ b/fftools/cmdutils.c
>>> @@ -61,6 +61,40 @@ AVDictionary *format_opts, *codec_opts;
>>> 
>>> int hide_banner = 0;
>>> 
>>> +void param_masking(int argc, char **argv) {
>>> +int i, j;
>>> +for (i = 1; i < argc; i++) {
>>> +char *match = strstr(argv[i], "://");
>>> +if (match) {
>>> +int total = strlen(argv[i]);
>>> +for (j = 0; j < total; j++) {
>>> +argv[i][j] = '*';
>>> +}
>>> +}
>>> +}
>>> +}
>>> +
>>> +char **copy_argv(int argc, char **argv) {
>>> +char **argv2;
>>> +argv2 = av_mallocz(argc * sizeof(char *));
>>> +if (!argv2)
>>> +exit_program(1);
>>> +
>>> +for (int i = 0; i < argc; i++) {
>>> +int length = strlen(argv[i]) + 1;
>>> +argv2[i] = av_mallocz(length * sizeof(char *));
>>> +if (!argv2[i])
>>> +exit_program(1);
>>> +memcpy(argv2[i], argv[i], length 

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix buffering issue on playing HTTP(s)/mp4.

[zhilizhao(赵志立)]

> On Dec 19, 2022, at 15:04, Chen, Jinkai  wrote:
> 
> So. I apply this strategy when it’s on HTTP/HTTPs, and it’s not affect local 
> normal files.
> 
> Could you please show me a bad case on this solution ? I appreciated and try 
> to fix it. Thanks.

It will download the same file twice.

> 
>> 2022年12月19日 下午2:18，zhilizhao(赵志立)  写道：
>> 
>> [你通常不会收到来自 quinkbl...@foxmail.com 的电子邮件。请访问 
>> https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
>> 
>>> On Dec 19, 2022, at 12:24, Chen, Jinkai  wrote:
>>> 
>>> Using separated HTTP connection for each stream,
>>> prevent from reading audio and video in long distance,
>>> which cause seeking(http request) repeatedly.
>>> Storing the user options when open input,
>>> and make sure that can be passed to demuxer context.
>> 
>> The patch is harmful for normal files, and the implementation isn’t clean, 
>> so NAK.
>> 
>>> 
>>> Some source can reproducing the issue:
>>> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fali-sprite-video.yyouwang.com%2Fvideo%2Fworks%2F202211%2F1667997073624_73.mp4=05%7C01%7Cchenjinkai%40agora.io%7Cb9e67445d035449f081608dae188efd6%7C602753743eaa49c283c3cc189d126981%7C0%7C0%7C638070275515676009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Zkr9rHCQncaiW9OmzDzzlWXkTZdlUQSz%2FnDRs2m7fzg%3D=0
>>> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimages.voghion.com%2FproductImages%2F04_01_C_30011_2020220106GiuseppeFanara0012.mp4=05%7C01%7Cchenjinkai%40agora.io%7Cb9e67445d035449f081608dae188efd6%7C602753743eaa49c283c3cc189d126981%7C0%7C0%7C638070275515676009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=N5fGtmMWY5t2SZ3QkNCFCRAxq2XPCPKimmn5QS5jZyU%3D=0
>>> 
>>> Signed-off-by: CJK mailto:chenjin...@agora.io>>
>>> ---
>>> libavformat/avformat.c |  1 +
>>> libavformat/demux.c|  5 -
>>> libavformat/internal.h |  5 +
>>> libavformat/mov.c  | 16 
>>> 4 files changed, 26 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
>>> index 19c7219471..4453727f34 100644
>>> --- a/libavformat/avformat.c
>>> +++ b/libavformat/avformat.c
>>> @@ -129,6 +129,7 @@ void avformat_free_context(AVFormatContext *s)
>>>  av_freep(>chapters);
>>>  av_dict_free(>metadata);
>>>  av_dict_free(>id3v2_meta);
>>> +av_dict_free(>options);
>>>  av_packet_free(>pkt);
>>>  av_packet_free(>parse_pkt);
>>>  av_freep(>streams);
>>> diff --git a/libavformat/demux.c b/libavformat/demux.c
>>> index 2dfd82a63c..2377bfdab0 100644
>>> --- a/libavformat/demux.c
>>> +++ b/libavformat/demux.c
>>> @@ -237,8 +237,11 @@ int avformat_open_input(AVFormatContext **ps, const 
>>> char *filename,
>>>  if (fmt)
>>>  s->iformat = fmt;
>>> 
>>> -if (options)
>>> +if (options) {
>>>  av_dict_copy(, *options, 0);
>>> +si->options = NULL;
>>> +av_dict_copy(>options, *options, 0);
>>> +}
>>> 
>>>  if (s->pb) // must be before any goto fail
>>>  s->flags |= AVFMT_FLAG_CUSTOM_IO;
>>> diff --git a/libavformat/internal.h b/libavformat/internal.h
>>> index ce837fefc7..7caae8b93e 100644
>>> --- a/libavformat/internal.h
>>> +++ b/libavformat/internal.h
>>> @@ -186,6 +186,11 @@ typedef struct FFFormatContext {
>>>   * Contexts and child contexts do not contain a metadata option
>>>   */
>>>  int metafree;
>>> +
>>> +/**
>>> + * options from avformat_open_input
>>> + */
>>> +AVDictionary *options;
>>> } FFFormatContext;
>>> 
>>> static av_always_inline FFFormatContext *ffformatcontext(AVFormatContext *s)
>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>>> index 29bd3103e3..1e1a7c2f7f 100644
>>> --- a/libavformat/mov.c
>>> +++ b/libavformat/mov.c
>>> @@ -4456,6 +4456,7 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
>>> *pb, MOVAtom atom)
>>> {
>>>  AVStream *st;
>>>  MOVStreamContext *sc;
>>> +URLContext *url_context;
>>>  int ret;
>>> 
>>>  st = avformat_new_stream(c->fc, NULL);
>>> @@ -4501,6 +4502,8 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
>>>

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix buffering issue on playing HTTP(s)/mp4.

[zhilizhao(赵志立)]

> On Dec 19, 2022, at 12:24, Chen, Jinkai  wrote:
> 
> Using separated HTTP connection for each stream,
> prevent from reading audio and video in long distance,
> which cause seeking(http request) repeatedly.
> Storing the user options when open input,
> and make sure that can be passed to demuxer context.

The patch is harmful for normal files, and the implementation isn’t clean, so 
NAK.

> 
> Some source can reproducing the issue:
> https://ali-sprite-video.yyouwang.com/video/works/202211/1667997073624_73.mp4
> https://images.voghion.com/productImages/04_01_C_30011_2020220106GiuseppeFanara0012.mp4
> 
> Signed-off-by: CJK mailto:chenjin...@agora.io>>
> ---
> libavformat/avformat.c |  1 +
> libavformat/demux.c|  5 -
> libavformat/internal.h |  5 +
> libavformat/mov.c  | 16 
> 4 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> index 19c7219471..4453727f34 100644
> --- a/libavformat/avformat.c
> +++ b/libavformat/avformat.c
> @@ -129,6 +129,7 @@ void avformat_free_context(AVFormatContext *s)
>av_freep(>chapters);
>av_dict_free(>metadata);
>av_dict_free(>id3v2_meta);
> +av_dict_free(>options);
>av_packet_free(>pkt);
>av_packet_free(>parse_pkt);
>av_freep(>streams);
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index 2dfd82a63c..2377bfdab0 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -237,8 +237,11 @@ int avformat_open_input(AVFormatContext **ps, const char 
> *filename,
>if (fmt)
>s->iformat = fmt;
> 
> -if (options)
> +if (options) {
>av_dict_copy(, *options, 0);
> +si->options = NULL;
> +av_dict_copy(>options, *options, 0);
> +}
> 
>if (s->pb) // must be before any goto fail
>s->flags |= AVFMT_FLAG_CUSTOM_IO;
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index ce837fefc7..7caae8b93e 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -186,6 +186,11 @@ typedef struct FFFormatContext {
> * Contexts and child contexts do not contain a metadata option
> */
>int metafree;
> +
> +/**
> + * options from avformat_open_input
> + */
> +AVDictionary *options;
> } FFFormatContext;
> 
> static av_always_inline FFFormatContext *ffformatcontext(AVFormatContext *s)
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 29bd3103e3..1e1a7c2f7f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4456,6 +4456,7 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> {
>AVStream *st;
>MOVStreamContext *sc;
> +URLContext *url_context;
>int ret;
> 
>st = avformat_new_stream(c->fc, NULL);
> @@ -4501,6 +4502,8 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> 
>mov_build_index(c, st);
> 
> +url_context = ffio_geturlcontext(c->fc->pb);
> +av_assert0(url_context);
>if (sc->dref_id-1 < sc->drefs_count && sc->drefs[sc->dref_id-1].path) {
>MOVDref *dref = >drefs[sc->dref_id - 1];
>if (c->enable_drefs) {
> @@ -4510,6 +4513,19 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>   "filename='%s', volume='%s', nlvl_from=%d, 
> nlvl_to=%d\n",
>   st->index, dref->path, dref->dir, dref->filename,
>   dref->volume, dref->nlvl_from, dref->nlvl_to);
> +} else if (strcmp(url_context->prot->name, "http") == 0 ||
> +   strcmp(url_context->prot->name, "https") == 0) {
> +FFFormatContext *const si = ffformatcontext(c->fc);
> +AVDictionary *opts = NULL;
> +av_dict_copy(, si->options, 0);
> +ret = c->fc->io_open(c->fc, >pb, c->fc->url, AVIO_FLAG_READ, 
> );
> +av_dict_free();
> +if (ret < 0) {
> +av_log(c->fc, AV_LOG_ERROR,
> +"mov/http(s) stream %d, error opening url %s.\n",
> +st->index, c->fc->url);
> +return ret;
> +}
>} else {
>av_log(c->fc, AV_LOG_WARNING,
>   "Skipped opening external track: "
> --
> 2.24.3 (Apple Git-128)
> ___
> 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] fftools/ffmpeg_ffplay_ffprobe_cmdutils: add -safe to replace the user name and password in the protocol address

[zhilizhao(赵志立)]

> On Dec 17, 2022, at 15:36, Wujian(Chin)  wrote:
> 
> The Protocol address may contain the user name and password. The ps -ef 
> command may expose the plaintext.
> The -safe parameter option is added to replace the user name and password in 
> the command line with the asterisk (*).

The patch reduced the risk to a low level, but I don’t think it
fixed the security issue totally. It’s still there with a small
time window. The usecase itself is unsafe.

There is an -safe option in concat demuxer, please make sure there
is no conflict.

concat demuxer AVOptions:
  -safe  .D. enable safe mode (default true)

> 
> Signed-off-by: wujian_nanjing 
> ---
> doc/ffmpeg.texi|  7 +++
> doc/ffplay.texi|  8 
> doc/ffprobe.texi   |  7 +++
> fftools/cmdutils.c | 47 +++
> fftools/cmdutils.h | 15 +++
> fftools/ffmpeg.c   | 16 +---
> fftools/ffplay.c   | 15 +--
> fftools/ffprobe.c  | 18 ++
> 8 files changed, 120 insertions(+), 13 deletions(-)
> 
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 0367930..e905542 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -50,6 +50,13 @@ output files. Also do not mix options which belong to 
> different files. All
> options apply ONLY to the next input or output file and are reset between 
> files.
> 
> @itemize
> +@item -safe
> +The Protocol address may contain the user name and password. The ps -ef 
> command may expose the plaintext.
> +The -safe parameter option is added to replace the user name and password in 
> the command line with the asterisk (*).
> +@example
> +ffmpeg -safe -i rtsp://usern...@password..com
> +@end example
> +
> @item
> To set the video bitrate of the output file to 64 kbit/s:
> @example
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index 5dd860b..f46ca91 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -122,6 +122,14 @@ Read @var{input_url}.
> 
> @section Advanced options
> @table @option
> +
> +@item -safe
> +The Protocol address may contain the user name and password. The ps -ef 
> command may expose the plaintext.
> +The -safe parameter option is added to replace the user name and password in 
> the command line with the asterisk (*).
> +@example
> +ffplay -safe -i rtsp://usern...@password..com
> +@end example
> +
> @item -stats
> Print several playback statistics, in particular show the stream
> duration, the codec parameters, the current position in the stream and
> diff --git a/doc/ffprobe.texi b/doc/ffprobe.texi
> index 4dc9f57..92b13cf 100644
> --- a/doc/ffprobe.texi
> +++ b/doc/ffprobe.texi
> @@ -89,6 +89,13 @@ Set the output printing format.
> @var{writer_name} specifies the name of the writer, and
> @var{writer_options} specifies the options to be passed to the writer.
> 
> +@item -safe
> +The Protocol address may contain the user name and password. The ps -ef 
> command may expose the plaintext.
> +The -safe parameter option is added to replace the user name and password in 
> the command line with the asterisk (*).
> +@example
> +ffprobe -safe -i rtsp://usern...@password..com
> +@end example
> +
> For example for printing the output in JSON format, specify:
> @example
> -print_format json
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index a1de621..22407f8 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -61,6 +61,40 @@ AVDictionary *format_opts, *codec_opts;
> 
> int hide_banner = 0;
> 
> +void param_masking(int argc, char **argv) {
> +int i, j;
> +for (i = 1; i < argc; i++) {
> +char *match = strstr(argv[i], "://");
> +if (match) {
> +int total = strlen(argv[i]);
> +for (j = 0; j < total; j++) {
> +argv[i][j] = '*';
> +}
> +}
> +}
> +}
> +
> +char **copy_argv(int argc, char **argv) {
> +char **argv2;
> +argv2 = av_mallocz(argc * sizeof(char *));
> +if (!argv2)
> +exit_program(1);
> +
> +for (int i = 0; i < argc; i++) {
> +int length = strlen(argv[i]) + 1;
> +argv2[i] = av_mallocz(length * sizeof(char *));
> +if (!argv2[i])
> +exit_program(1);
> +memcpy(argv2[i], argv[i], length - 1);
> +}
> +return argv2;
> +}
> +
> +void free_pp(int argc, char **argv) {
> +for (int i = 0; i < argc; i++)
> +av_free(argv[i]);
> +av_free(argv);
> +}
> void uninit_opts(void)
> {
> av_dict_free(_opts);
> @@ -215,13 +249,13 @@ static void prepare_app_arguments(int *argc_ptr, char 
> ***argv_ptr)
> if (win32_argv_utf8) {
> *argc_ptr = win32_argc;
> *argv_ptr = win32_argv_utf8;
> -return;
> +goto end;
> }
> 
> win32_argc = 0;
> argv_w = CommandLineToArgvW(GetCommandLineW(), _argc);
> if (win32_argc <= 0 || !argv_w)
> -return;
> +goto end;
> 
> /* determine the UTF-8 buffer size (including 

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: include stdbool.h

[zhilizhao(赵志立)]

> On Dec 16, 2022, at 11:39, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> Since NDK failed to do that:
> https://github.com/android/ndk/issues/1281
> ---
> libavcodec/mediacodec_wrapper.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 7ddf93ccc7..4d6e9487b8 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -22,6 +22,7 @@
> 
> #include 
> #include 
> +#include 
> #include 
> #include 
> #include 
> -- 

Pushed as 48d5aecfc4386be096dfb5d4c021af247ef0d803.

___
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/7] MediaCodec encoder: Fix width/height alignment issue and add more options

[zhilizhao(赵志立)]

> On Dec 15, 2022, at 23:25, Zhao Zhili  wrote:
> 
> On Wed, 2022-12-07 at 17:31 +0800, Zhao Zhili wrote:
>> From: Zhao Zhili 
>> 
>> v2:
>> Reorder 1/7 and 2/7.
>> 
>> Zhao Zhili (7):
>>  avcodec/mediacodecenc: make each encoder has its own option
>>  avcodec/mediacodecenc: add bitrate_mode option
>>  avcodec/mediacodecenc: add level option
>>  avcodec/mediacodecenc: use bsf to handle crop
>>  avcodec/mediacodecenc: remove the strategy to create DTS
>>  avcodec/mediacodecenc: add max-bframes support
>>  avcodec/mediacodecenc: add pts_as_dts option
>> 
>> configure  |   2 +
>> libavcodec/mediacodecenc.c | 294 +++--
>> 
>> libavcodec/version.h   |   2 +-
>> 3 files changed, 256 insertions(+), 42 deletions(-)
>> 
> 
> Will apply tomorrow.

Pushed.

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