Re: [FFmpeg-devel] [PATCH 1/3] lavc/vp8dsp: R-V V put_bilin_h
Hi, Le 24 février 2024 03:07:36 GMT+02:00, flow gg a écrit : > .ifc \len,4 >-vsetivlizero, 5, e8, mf2, ta, ma >+vsetivlizero, 5, e8, m1, ta, ma > .elseif \len == 8 > vsetivlizero, 9, e8, m1, ta, ma > .else >@@ -112,9 +112,9 @@ endfunc > vslide1down.vx v2, \dst, t5 > > .ifc \len,4 >-vsetivlizero, 4, e8, mf4, ta, ma >+vsetivlizero, 4, e8, m1, ta, ma > .elseif \len == 8 >-vsetivlizero, 8, e8, mf2, ta, ma >+vsetivlizero, 8, e8, m1, ta, ma > >What are the benefits of not using fractional multipliers here? Insofar as E8/MF4 is guaranteed to work for Zve32x, there are no benefits per se. However fractional multipliers were added to the specification to enable addressing invididual vectors whilst the effective multiplier is larger than one. This can only happen with mixed widths. Fractions were not intended to make vector shorter - there is the vector length for that already. That's why "E64/MF2" doesn't work, even though it's the same vector bit size as "E8/MF2". > Making this >change would result in a 10%-20% slowdown. That's kind of odd. This may be caused by the slides, but it's strange to go out of the way for hardware to optimise a case that's not even intended. > mf2/4 m1 >vp8_put_bilin4_h_rvv_i32: 158.7 193.7 >vp8_put_bilin4_hv_rvv_i32: 255.7 302.7 >vp8_put_bilin8_h_rvv_i32: 318.7 358.7 >vp8_put_bilin8_hv_rvv_i32: 528.7 569.7 > >Rémi Denis-Courmont 于2024年2月24日周六 01:18写道： > >> Hi, >> >> + >> +.macro bilin_h_load dst len >> +.ifc \len,4 >> +vsetivlizero, 5, e8, mf2, ta, ma >> >> Don't use fractional multipliers if you don't mix element widths. >> >> +.elseif \len == 8 >> +vsetivlizero, 9, e8, m1, ta, ma >> +.else >> +vsetivlizero, 17, e8, m2, ta, ma >> +.endif >> + >> +vle8.v \dst, (a2) >> +vslide1down.vx v2, \dst, t5 >> + >> >> +.ifc \len,4 >> +vsetivlizero, 4, e8, mf4, ta, ma >> >> Same as above. >> >> +.elseif \len == 8 >> +vsetivlizero, 8, e8, mf2, ta, ma >> >> Also. >> >> +.else >> +vsetivlizero, 16, e8, m1, ta, ma >> +.endif >> >> +vwmulu.vx v28, \dst, t1 >> +vwmaccu.vx v28, a5, v2 >> +vwaddu.wx v24, v28, t4 >> +vnsra.wi\dst, v24, 3 >> +.endm >> + >> +.macro put_vp8_bilin_h len >> +li t1, 8 >> +li t4, 4 >> +li t5, 1 >> +sub t1, t1, a5 >> +1: >> +addia4, a4, -1 >> +bilin_h_loadv0, \len >> +vse8.v v0, (a0) >> +add a2, a2, a3 >> +add a0, a0, a1 >> +bneza4, 1b >> + >> +ret >> +.endm >> + >> +func ff_put_vp8_bilin16_h_rvv, zve32x >> +put_vp8_bilin_h 16 >> +endfunc >> + >> +func ff_put_vp8_bilin8_h_rvv, zve32x >> +put_vp8_bilin_h 8 >> +endfunc >> + >> +func ff_put_vp8_bilin4_h_rvv, zve32x >> +put_vp8_bilin_h 4 >> +endfunc >> >> -- >> レミ・デニ-クールモン >> 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". ___ 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/4] fftools/ffprobe: Don't cast const away needlessly
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> fftools/ffprobe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index aa1153e709..95643f9a23 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -789,7 +789,7 @@ static inline int validate_string(WriterContext *wctx,
> char **dstp, const char *
> av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
>
> endp = src + strlen(src);
> -for (p = (uint8_t *)src; *p;) {
> +for (p = src; *p;) {
> uint32_t code;
> int invalid = 0;
> const uint8_t *p0 = p;
Will apply this patchset tomorrow unless there are objections.
- 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cbs_h266_syntax_template: Don't omit unused function parameter
Andreas Rheinhardt:
> The calls to the sei_decoded_picture_hash read and write functions
> are performed with four pointer arguments; just because one
> of them is unused by the callees does not mean that they
> can be omitted: This is undefined behaviour.
> (This was not recognized because the SEI_MESSAGE_RW macro
> contains casts.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I found this via UBSan test failures with Clang 17,
> but actually there are compiler warnings for this:
> -Wcast-function-type for GCC and old Clang
> and -Wcast-function-type in conjunction with
> -Wno-cast-function-type-strict (without the latter,
> Clang warns about conversions with different pointer
> types, like int (*)(void*)->int (*)(struct Foo*);
> the latter typically lead to UB (when used in a call),
> but are actually common).
>
> libavcodec/cbs_h266_syntax_template.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index 26ee7a420b..e75f2f6971 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -3430,7 +3430,7 @@ static int FUNC(slice_header) (CodedBitstreamContext
> *ctx, RWContext *rw,
> static int FUNC(sei_decoded_picture_hash) (CodedBitstreamContext *ctx,
> RWContext *rw,
> H266RawSEIDecodedPictureHash *
> - current)
> + current, SEIMessageState *unused)
> {
> int err, c_idx, i;
>
Will apply this patchset tomorrow unless there are objections.
- 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".
Re: [FFmpeg-devel] [PATCH 1/3] lavc/vp8dsp: R-V V put_bilin_h
.ifc \len,4 -vsetivlizero, 5, e8, mf2, ta, ma +vsetivlizero, 5, e8, m1, ta, ma .elseif \len == 8 vsetivlizero, 9, e8, m1, ta, ma .else @@ -112,9 +112,9 @@ endfunc vslide1down.vx v2, \dst, t5 .ifc \len,4 -vsetivlizero, 4, e8, mf4, ta, ma +vsetivlizero, 4, e8, m1, ta, ma .elseif \len == 8 -vsetivlizero, 8, e8, mf2, ta, ma +vsetivlizero, 8, e8, m1, ta, ma What are the benefits of not using fractional multipliers here? Making this change would result in a 10%-20% slowdown. mf2/4 m1 vp8_put_bilin4_h_rvv_i32: 158.7 193.7 vp8_put_bilin4_hv_rvv_i32: 255.7 302.7 vp8_put_bilin8_h_rvv_i32: 318.7 358.7 vp8_put_bilin8_hv_rvv_i32: 528.7 569.7 Rémi Denis-Courmont 于2024年2月24日周六 01:18写道： > Hi, > > + > +.macro bilin_h_load dst len > +.ifc \len,4 > +vsetivlizero, 5, e8, mf2, ta, ma > > Don't use fractional multipliers if you don't mix element widths. > > +.elseif \len == 8 > +vsetivlizero, 9, e8, m1, ta, ma > +.else > +vsetivlizero, 17, e8, m2, ta, ma > +.endif > + > +vle8.v \dst, (a2) > +vslide1down.vx v2, \dst, t5 > + > > +.ifc \len,4 > +vsetivlizero, 4, e8, mf4, ta, ma > > Same as above. > > +.elseif \len == 8 > +vsetivlizero, 8, e8, mf2, ta, ma > > Also. > > +.else > +vsetivlizero, 16, e8, m1, ta, ma > +.endif > > +vwmulu.vx v28, \dst, t1 > +vwmaccu.vx v28, a5, v2 > +vwaddu.wx v24, v28, t4 > +vnsra.wi\dst, v24, 3 > +.endm > + > +.macro put_vp8_bilin_h len > +li t1, 8 > +li t4, 4 > +li t5, 1 > +sub t1, t1, a5 > +1: > +addia4, a4, -1 > +bilin_h_loadv0, \len > +vse8.v v0, (a0) > +add a2, a2, a3 > +add a0, a0, a1 > +bneza4, 1b > + > +ret > +.endm > + > +func ff_put_vp8_bilin16_h_rvv, zve32x > +put_vp8_bilin_h 16 > +endfunc > + > +func ff_put_vp8_bilin8_h_rvv, zve32x > +put_vp8_bilin_h 8 > +endfunc > + > +func ff_put_vp8_bilin4_h_rvv, zve32x > +put_vp8_bilin_h 4 > +endfunc > > -- > レミ・デニ-クールモン > 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] Set native order for wav channel layouts up until 8 channels.
On 2/23/2024 7:32 PM, Romain Beauxis wrote:
Le ven. 23 févr. 2024 à 15:11, Marton Balint a écrit :
On Fri, 23 Feb 2024, Romain Beauxis wrote:
The new default channel layout for the various RIFF/WAV decoders is not
backward compatible.
Historically, most decoders will expect the channel layouts to follow
the native layout up-to a reasonable number of channels.
Additionally, non-native layouts are causing troubles with filters
chaining.
This PR changes the default channel layout reported by RIFF/WAV decoders
to default to the native layout when the number of channels is up-to 8.
The logic for these changes is the same as the logic for the vorbis/opus
decoders.
For Vorbis the channel layout is in the actual Vorbis specification. So
you should follow the specification, simple guessing in the demuxer likely
won't be acceptable.
I would argue that even though there is no official specification on
channel layout for wav/riff, the de-facto assumption that _most_ users
of the library would expect is the native layout.
Typically, 1 and 2 channels would be assumed to be mono and stereo by
most users.
It's great that the API does provide flexibility but the default
should be set to satisfy most users and, in that regard, it seems that
assuming a native layout is what the vast majority of library's users
will expect.
This choice also implies at least two ABI breakage for applications
using the deprecated API but running on a the new ABI:
1: With the updated API, the library is not able to provide a backward
compatible `channel_layout` for AVFrame when the new channel order is
AV_CHANNEL_ORDER_UNSPEC which breaks ABI compatibility as the field is
reported as `0`.
2. AV_CHANNEL_ORDER_UNSPEC channel order also breaks filters chaining.
The issue appears to be that the unspec channel order implicitly sets
the the filter to accept all channel order, which breaks compatibility
here:
if (link->incfg.channel_layouts->all_layouts) {
av_log(link->src, AV_LOG_ERROR, "Cannot select channel layout for"
" the link between filters %s and %s.\n", link->src->name,
link->dst->name);
if (!link->incfg.channel_layouts->all_counts)
av_log(link->src, AV_LOG_ERROR, "Unknown channel layouts not "
"supported, try specifying a channel layout using "
"'aformat=channel_layouts=something'.\n");
return AVERROR(EINVAL);
}
It's not the demuxer's job to guess what the caller would like or
expect. It's meant to export what the input contains.
If you want to fix the CLI behavior, then you need to do it in the CLI.
Remember that ffmpeg.c is not the only lavf user.
___
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] clarifying the TC conflict of interest rule
On Thu, Feb 22, 2024 at 10:14:20PM +0100, Anton Khirnov wrote: > Quoting Niklas Haas (2024-02-20 21:50:33) > > On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov wrote: > > > + Each TC member must vote on such decision according to what is, in their > > > + view, best for the project. If a TC member is affected by a conflict of > > > + interest with regards to the case, they must announce it and recuse > > > + themselves from the TC discussion and vote. A conflict of interest is > > > + presumed to occur when a TC member has a personal interest (e.g. > > > + financial) in a specific outcome of the case. > > > > My preferred wording would change "If a TC member is" to "If a TC member > > feels they are" and "must" to "should". > > > > I read it as a common sense recommendation, not a legalese text. It is > > ultimately up to the individual to judge whether they are acting in good > > faith or not. > > Okay, that makes sense to me. I am then changing my proposal to: > > Each TC member must vote on such decision according to what is, in their > view, best for the project. If a TC member feels they are affected by a > conflict of interest with regards to the case, they should announce it > and recuse themselves from the TC discussion and vote. A conflict of > interest is presumed to occur when a TC member has a personal interest > (e.g. financial) in a specific outcome of the case. > > > If someone wants a "stronger" version of this among the voting options, > feel welcome to propose one. Lets take a look at "the line" "If the disagreement involves a member of the TC, that member should recuse themselves from the decision." There are 3 obvious choices here: 1: (unchanged) "If the disagreement involves a member of the TC, that member should recuse themselves from the decision." 2: (must) "If the disagreement involves a member of the TC, that member must recuse themselves from the decision." 3: (remove it) "" Thats what the vote should be about IMO. Then seperately, theres the question about the (unrelated) text you want to add That too has 3 choices 1. (unchanged) "" 2. (should)"conflict of interest ... they should announce it and recuse themselves ..." 3. (must) "conflict of interest ... they must announce it and recuse themselves ..." Thats what a 2nd independant vote should be _IF_ we dont already have a unanimous agreement about this. Now honestly why this uses a "should" after apparently this very dissussion here showed that "should" is interpreted differently by different people, i dont know. I mean either we want people to recuse themselves or we dont if specific circumstances apply. It cannot be in the per persons free choice if they recuse themselves in a conflict of interrest. This just makes no sense. ... Ohh i have a financial interrest in the outcome, i dont have to recuse myself, i only "should" ahh ok ... The "Each TC member must vote on such decision according to what is, in their view, best for the project." I suspect you can just propose adding this and without any vote. There may be unanimous agreement for this Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode
From: Cosmin Stejerean
Co-authored-by: Amir Naghdinezhad
Signed-off-by: Cosmin Stejerean
---
libavcodec/libsvtav1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -539,6 +539,14 @@ static int eb_receive_packet(AVCodecContext *avctx,
AVPacket *pkt)
if (svt_ret == EB_NoErrorEmptyQueue)
return AVERROR(EAGAIN);
+#if SVT_AV1_CHECK_VERSION(2, 0, 0)
+if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
+ svt_enc->eos_flag = EOS_RECEIVED;
+ svt_av1_enc_release_out_buffer();
+ return AVERROR_EOF;
+}
+#endif
+
ref = get_output_ref(avctx, svt_enc, headerPtr->n_filled_len);
if (!ref) {
av_log(avctx, AV_LOG_ERROR, "Failed to allocate output packet.\n");
@@ -573,8 +581,10 @@ static int eb_receive_packet(AVCodecContext *avctx,
AVPacket *pkt)
if (headerPtr->pic_type == EB_AV1_NON_REF_PICTURE)
pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
+#if !(SVT_AV1_CHECK_VERSION(2, 0, 0))
if (headerPtr->flags & EB_BUFFERFLAG_EOS)
svt_enc->eos_flag = EOS_RECEIVED;
+#endif
ff_side_data_set_encoder_stats(pkt, headerPtr->qp * FF_QP2LAMBDA, NULL, 0,
pict_type);
--
2.42.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Set native order for wav channel layouts up until 8 channels.
On Fri, 23 Feb 2024, Romain Beauxis wrote:
Le ven. 23 févr. 2024 à 15:11, Marton Balint a écrit :
On Fri, 23 Feb 2024, Romain Beauxis wrote:
> The new default channel layout for the various RIFF/WAV decoders is not
> backward compatible.
>
> Historically, most decoders will expect the channel layouts to follow
> the native layout up-to a reasonable number of channels.
>
> Additionally, non-native layouts are causing troubles with filters
> chaining.
>
> This PR changes the default channel layout reported by RIFF/WAV decoders
> to default to the native layout when the number of channels is up-to 8.
>
> The logic for these changes is the same as the logic for the vorbis/opus
> decoders.
For Vorbis the channel layout is in the actual Vorbis specification. So
you should follow the specification, simple guessing in the demuxer likely
won't be acceptable.
I would argue that even though there is no official specification on
channel layout for wav/riff, the de-facto assumption that _most_ users
of the library would expect is the native layout.
I think this a good starting point:
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
Typically, 1 and 2 channels would be assumed to be mono and stereo by
most users.
It's great that the API does provide flexibility but the default
should be set to satisfy most users and, in that regard, it seems that
assuming a native layout is what the vast majority of library's users
will expect.
Actually ffmpeg.c used to have some channel layout guessing code for
exactly this purpose. Maybe you should check why that does not kick in.
This choice also implies at least two ABI breakage for applications
using the deprecated API but running on a the new ABI:
1: With the updated API, the library is not able to provide a backward
compatible `channel_layout` for AVFrame when the new channel order is
AV_CHANNEL_ORDER_UNSPEC which breaks ABI compatibility as the field is
reported as `0`.
I believe this was valid even before the new channel layout API for
unknown channel layouts, so I don't quite see the API break.
2. AV_CHANNEL_ORDER_UNSPEC channel order also breaks filters chaining.
The issue appears to be that the unspec channel order implicitly sets
the the filter to accept all channel order, which breaks compatibility
here:
if (link->incfg.channel_layouts->all_layouts) {
av_log(link->src, AV_LOG_ERROR, "Cannot select channel layout for"
" the link between filters %s and %s.\n", link->src->name,
link->dst->name);
if (!link->incfg.channel_layouts->all_counts)
av_log(link->src, AV_LOG_ERROR, "Unknown channel layouts not "
"supported, try specifying a channel layout using "
"'aformat=channel_layouts=something'.\n");
return AVERROR(EINVAL);
}
A specific ffmpeg command line which shows this error would be useful.
Maybe this can be fixed, if this is a regression.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 14/38] lavu/opt: factor per-type dispatch out of av_opt_set()
Hi Anton On Fri, Feb 23, 2024 at 02:58:36PM +0100, Anton Khirnov wrote: > Will be useful in following commits. > --- breaks: ./ffmpeg -y -request_channel_layout 3 -i bug/401/mlp_5point1_downmixof6channel.mlp -bitexact file-2-mlp_5point1_downmixof6channel.wav [mlp @ 0x55690e23ff80] Error setting option request_channel_layout to value 3. [mlp @ 0x55690e23ed00] Failed to open codec in avformat_find_stream_info [mlp @ 0x55690e23ff80] Error setting option request_channel_layout to value 3. Input #0, mlp, from 'bug/401/mlp_5point1_downmixof6channel.mlp': Duration: N/A, start: 0.00, bitrate: N/A Stream #0:0: Audio: mlp, 48000 Hz, 5.1, s32 (24 bit) [mlp @ 0x55690e257900] Error setting option request_channel_layout to value 3. [aist#0:0/mlp @ 0x55690e254dc0] [dec:mlp @ 0x55690e256f40] Error while opening decoder: Invalid argument [aost#0:0/pcm_s16le @ 0x55690e255a80] Error initializing a simple filtergraph Error opening output file file-2-mlp_5point1_downmixof6channel.wav. Error opening output files: Invalid argument i suspect this isnt specific to the file but i can provide it if it doesnt reproduce with a other file thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files
On Fri, 23 Feb 2024, Allan Cady via ffmpeg-devel wrote: [Apologies for the awful mess in the previous email. Trying again with straight text.] On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint wrote: For starters, I'm curious why there are two functions & macros: av_ts2str/av_ts_make_string (which used "%" format specifier) That takes a 64-bit integer timestamp and is actually using "%"PRId64 because that is the correct (portable) format string for an int64_t variable. av_ts2timestr/av_ts_make_time_string (which used "%6g") That takes an integer timestamp and a rational time base. Float timestamps (in seconds) is calculated by multiplying the two, that is what is printed. Do you know the rationale for that? I see that only av_ts2timestr is used in silencedetect.c. And are you suggesting we should fold those two functions into one? No, they have different purpose. The first prints out a timestamps which can be in any time base. The second prints out a timestamp in seconds. Understood, I think I'm up to speed now. av_ts2str prints a 64-bit integer timestamp; av_ts2timestr prints a floating point timestamp in seconds with the timebase applied. In your previous email, you said: I'd rather just to fix av_ts_make_string to not limit the number of significant digits. Something like: 1) Print the number in decimal notation with at most 6 fractional digits. 2) Use less fractional digits if the first format would not fit into AV_TS_MAX_STRING_SIZE. 3) Use scientific notation if the second format would not fit into AV_TS_MAX_STRINT_SIZE. I think you probably meant to say "I'd rather just to fix av_ts_make_time_string" (not av_ts_make_string)? Since it's av_ts_make_time_string() that's formatting floating point. Yes, indeed. So it makes sense to me to make the change to av_ts_make_time_string() for all timestamps, as you suggest. As for how specifically to format them, I'm fine with whatever you think is best, and I'm happy to work on this, but the implementation has me a bit stumped for the moment, and I may need some help with it. My C language skills are rusty to say the least. The simplest way is to try snprintf() with 6 fractional digits, and check the return value to see how long the string would become. Based on this you can either accept snprintf result and truncate trailing zeros and dots, or try snprintf() with less fractional digits and truncate, or fall back to scientific format. It also occurs to me to wonder, would this warrant a formal problem ticket? I haven't looked into how that works for ffmpeg. Opening a ticket for the problem is not required, but if your patch fixes an existing ticket, then you should mention the ticket number in the commit message. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Set native order for wav channel layouts up until 8 channels.
Le ven. 23 févr. 2024 à 15:11, Marton Balint a écrit :
>
>
>
> On Fri, 23 Feb 2024, Romain Beauxis wrote:
>
> > The new default channel layout for the various RIFF/WAV decoders is not
> > backward compatible.
> >
> > Historically, most decoders will expect the channel layouts to follow
> > the native layout up-to a reasonable number of channels.
> >
> > Additionally, non-native layouts are causing troubles with filters
> > chaining.
> >
> > This PR changes the default channel layout reported by RIFF/WAV decoders
> > to default to the native layout when the number of channels is up-to 8.
> >
> > The logic for these changes is the same as the logic for the vorbis/opus
> > decoders.
>
> For Vorbis the channel layout is in the actual Vorbis specification. So
> you should follow the specification, simple guessing in the demuxer likely
> won't be acceptable.
I would argue that even though there is no official specification on
channel layout for wav/riff, the de-facto assumption that _most_ users
of the library would expect is the native layout.
Typically, 1 and 2 channels would be assumed to be mono and stereo by
most users.
It's great that the API does provide flexibility but the default
should be set to satisfy most users and, in that regard, it seems that
assuming a native layout is what the vast majority of library's users
will expect.
This choice also implies at least two ABI breakage for applications
using the deprecated API but running on a the new ABI:
1: With the updated API, the library is not able to provide a backward
compatible `channel_layout` for AVFrame when the new channel order is
AV_CHANNEL_ORDER_UNSPEC which breaks ABI compatibility as the field is
reported as `0`.
2. AV_CHANNEL_ORDER_UNSPEC channel order also breaks filters chaining.
The issue appears to be that the unspec channel order implicitly sets
the the filter to accept all channel order, which breaks compatibility
here:
if (link->incfg.channel_layouts->all_layouts) {
av_log(link->src, AV_LOG_ERROR, "Cannot select channel layout for"
" the link between filters %s and %s.\n", link->src->name,
link->dst->name);
if (!link->incfg.channel_layouts->all_counts)
av_log(link->src, AV_LOG_ERROR, "Unknown channel layouts not "
"supported, try specifying a channel layout using "
"'aformat=channel_layouts=something'.\n");
return AVERROR(EINVAL);
}
-- Romain
___
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] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files
[Apologies for the awful mess in the previous email. Trying again with straight text.] On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint wrote: >> For starters, I'm curious why there are two functions & macros: >> >> av_ts2str/av_ts_make_string (which used "%" format specifier) > > That takes a 64-bit integer timestamp and is actually using "%"PRId64 > because that is the correct (portable) format string for an int64_t > variable. > >> av_ts2timestr/av_ts_make_time_string (which used "%6g") > > That takes an integer timestamp and a rational time base. Float timestamps > (in seconds) is calculated by multiplying the two, that is what is > printed. > >> >> Do you know the rationale for that? I see that only av_ts2timestr is used in >> silencedetect.c. >> >> And are you suggesting we should fold those two functions into one? > > No, they have different purpose. The first prints out a timestamps which > can be in any time base. The second prints out a timestamp in seconds. Understood, I think I'm up to speed now. av_ts2str prints a 64-bit integer timestamp; av_ts2timestr prints a floating point timestamp in seconds with the timebase applied. In your previous email, you said: > I'd rather just to fix av_ts_make_string to not limit the number of > significant digits. Something like: > > 1) Print the number in decimal notation with at most 6 fractional digits. > 2) Use less fractional digits if the first format would not fit into > AV_TS_MAX_STRING_SIZE. > 3) Use scientific notation if the second format would not fit into > AV_TS_MAX_STRINT_SIZE. I think you probably meant to say "I'd rather just to fix av_ts_make_time_string" (not av_ts_make_string)? Since it's av_ts_make_time_string() that's formatting floating point. So it makes sense to me to make the change to av_ts_make_time_string() for all timestamps, as you suggest. As for how specifically to format them, I'm fine with whatever you think is best, and I'm happy to work on this, but the implementation has me a bit stumped for the moment, and I may need some help with it. My C language skills are rusty to say the least. It also occurs to me to wonder, would this warrant a formal problem ticket? I haven't looked into how that works for ffmpeg. Thanks for your help. ___ 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] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files
On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint wrote: >> For starters, I'm curious why there are two functions & macros: >> av_ts2str/av_ts_make_string (which used "%" format specifier)> > That takes >> a 64-bit integer timestamp and is actually using "%"PRId64 > because that is >> the correct (portable) format string for an int64_t > variable.> >> >> av_ts2timestr/av_ts_make_time_string (which used "%6g")> > That takes an >> integer timestamp and a rational time base. Float timestamps > (in seconds) >> is calculated by multiplying the two, that is what is > printed.> Do >> you know the rationale for that? I see that only av_ts2timestr is used in >> silencedetect.c. And are you suggesting we should fold those two >> functions into one?> > No, they have different purpose. The first prints out >> a timestamps which > can be in any time base. The second prints out a >> timestamp in seconds. Understood, I think I'm up to speed now. av_ts2str prints a 64-bit integer timestamp;av_ts2timestr prints a floating point timestamp in seconds with the timebase applied. In your previous email, you said: > I'd rather just to fix av_ts_make_string to not limit the number of > > significant digits. Something like:>> 1) Print the number in decimal notation > with at most 6 fractional digits. > 2) Use less fractional digits if the > first format would not fit into > AV_TS_MAX_STRING_SIZE.> 3) Use scientific > notation if the second format would not fit into > AV_TS_MAX_STRINT_SIZE. I think you probably meant to say "I'd rather just to fixav_ts_make_time_string" (not av_ts_make_string)?Since it's av_ts_make_time_string() that's formatting floating point. So it makes sense to me to make the change to av_ts_make_time_string()for all timestamps, as you suggest. As for how specifically to format them, I'm fine with whatever you think is best, and I'm happy to work on this, but theimplementation has me a bit stumped for the moment, and I may need somehelp with it. My C language skills are rusty to say the least. It also occurs to me to wonder, would this warrant a formal problem ticket? I haven't looked into how that works for ffmpeg. Thanks for your help. ___ 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] Set native order for wav channel layouts up until 8 channels.
On Fri, 23 Feb 2024, Romain Beauxis wrote: The new default channel layout for the various RIFF/WAV decoders is not backward compatible. Historically, most decoders will expect the channel layouts to follow the native layout up-to a reasonable number of channels. Additionally, non-native layouts are causing troubles with filters chaining. This PR changes the default channel layout reported by RIFF/WAV decoders to default to the native layout when the number of channels is up-to 8. The logic for these changes is the same as the logic for the vorbis/opus decoders. For Vorbis the channel layout is in the actual Vorbis specification. So you should follow the specification, simple guessing in the demuxer likely won't be acceptable. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Set native order for wav channel layouts up until 8 channels.
The new default channel layout for the various RIFF/WAV decoders is not
backward compatible.
Historically, most decoders will expect the channel layouts to follow
the native layout up-to a reasonable number of channels.
Additionally, non-native layouts are causing troubles with filters
chaining.
This PR changes the default channel layout reported by RIFF/WAV decoders
to default to the native layout when the number of channels is up-to 8.
The logic for these changes is the same as the logic for the vorbis/opus
decoders.
Romain
---
libavformat/riff.h| 1 +
libavformat/riffdec.c | 31 ---
libavformat/wavdec.c | 4 +---
3 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/libavformat/riff.h b/libavformat/riff.h
index a93eadfeca..f474efdce9 100644
--- a/libavformat/riff.h
+++ b/libavformat/riff.h
@@ -67,6 +67,7 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par, int for_asf, int
int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb, AVCodecParameters
*par, int flags);
enum AVCodecID ff_wav_codec_get_id(unsigned int tag, int bps);
+void ff_get_wav_ch_layout(AVChannelLayout *ch_layout, int channels);
int ff_get_wav_header(void *logctx, AVIOContext *pb, AVCodecParameters *par,
int size, int big_endian);
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 0fe4e02b7b..bb7c01c5f5 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -90,6 +90,33 @@ static void parse_waveformatex(void *logctx, AVIOContext
*pb, AVCodecParameters
}
}
+const AVChannelLayout ff_wav_demux_ch_layouts[9] = {
+AV_CHANNEL_LAYOUT_MONO,
+AV_CHANNEL_LAYOUT_STEREO,
+AV_CHANNEL_LAYOUT_SURROUND,
+AV_CHANNEL_LAYOUT_QUAD,
+AV_CHANNEL_LAYOUT_5POINT0_BACK,
+AV_CHANNEL_LAYOUT_5POINT1_BACK,
+{
+.nb_channels = 7,
+.order = AV_CHANNEL_ORDER_NATIVE,
+.u.mask = AV_CH_LAYOUT_5POINT1 | AV_CH_BACK_CENTER,
+},
+AV_CHANNEL_LAYOUT_7POINT1,
+{ 0 }
+};
+
+void ff_get_wav_ch_layout(AVChannelLayout *ch_layout, int channels)
+{
+av_channel_layout_uninit(ch_layout);
+if (channels > 8) {
+ch_layout->order = AV_CHANNEL_ORDER_UNSPEC;
+ch_layout->nb_channels = channels;
+} else {
+av_channel_layout_copy(ch_layout, _wav_demux_ch_layouts[channels -
1]);
+}
+}
+
/* "big_endian" values are needed for RIFX file format */
int ff_get_wav_header(void *logctx, AVIOContext *pb,
AVCodecParameters *par, int size, int big_endian)
@@ -195,9 +222,7 @@ int ff_get_wav_header(void *logctx, AVIOContext *pb,
/* ignore WAVEFORMATEXTENSIBLE layout if different from channel count */
if (channels != par->ch_layout.nb_channels) {
-av_channel_layout_uninit(>ch_layout);
-par->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
-par->ch_layout.nb_channels = channels;
+ff_get_wav_ch_layout(>ch_layout, channels);
}
return 0;
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 0c6629b157..282e1ae017 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -222,9 +222,7 @@ static int wav_parse_xma2_tag(AVFormatContext *s, int64_t
size, AVStream *st)
channels += avio_r8(pb);
avio_skip(pb, 3);
}
-av_channel_layout_uninit(>codecpar->ch_layout);
-st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
-st->codecpar->ch_layout.nb_channels = channels;
+ff_get_wav_ch_layout(>codecpar->ch_layout, channels);
if (st->codecpar->ch_layout.nb_channels <= 0 || st->codecpar->sample_rate
<= 0)
return AVERROR_INVALIDDATA;
--
2.39.3 (Apple Git-145)
___
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] [REFUND-REQUEST] FOSDEM 2024
Il ven 23 feb 2024, 11:00 J. Dekker ha scritto: > Hi, > > I attended FOSDEM for ffmpeg and would like to request travel > reimbursement. > > Flight | 162,46 EUR > === > Total | 162,46 EUR > Looks good on my side, but keep in mind you can also ask accomodation expenses refund if you want to add that (you should). Please check the other refund requests for the spi form link and other details. ___ 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/mxfenc: add h264_mp4toannexb bitstream filter if needed when muxing h264
On Fri, 23 Feb 2024, Andreas Rheinhardt wrote:
Marton Balint:
Partially fixes ticket #10395.
Signed-off-by: Marton Balint
---
libavformat/mxfenc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 61ed6fc3db..adc31c1cf4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -3542,6 +3542,16 @@ static int mxf_interleave(AVFormatContext *s, AVPacket
*pkt,
return mxf_interleave_get_packet(s, pkt, flush);
}
+static int mxf_check_bitstream(AVFormatContext *s, AVStream *st, const
AVPacket *pkt)
+{
+if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ AV_RB24(pkt->data) != 0x01)
+return ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
NULL);
+}
+return 1;
+}
+
#define MXF_COMMON_OPTIONS \
{ "signal_standard", "Force/set Signal Standard",\
offsetof(MXFContext, signal_standard), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 7,
AV_OPT_FLAG_ENCODING_PARAM, .unit = "signal_standard"},\
@@ -3623,6 +3633,7 @@ const FFOutputFormat ff_mxf_muxer = {
.p.flags = AVFMT_NOTIMESTAMPS,
.interleave_packet = mxf_interleave,
.p.priv_class = _muxer_class,
+.check_bitstream = mxf_check_bitstream,
};
const FFOutputFormat ff_mxf_d10_muxer = {
@@ -3656,4 +3667,5 @@ const FFOutputFormat ff_mxf_opatom_muxer = {
.p.flags = AVFMT_NOTIMESTAMPS,
.interleave_packet = mxf_interleave,
.p.priv_class = _opatom_muxer_class,
+.check_bitstream = mxf_check_bitstream,
};
I sent the very same patch long ago [1]. Tomas Härdin opposed it [2],
[3], because he sees stuff like this as hack.
- Andreas
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-November/287638.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-November/287702.html
[3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-November/287703.html
Maybe we should discuss this again, define what is missing
exactly, considering that we both think this is a step in the right
direction.
The specs says this:
The Picture Element Values shall be the AVC NAL unit stream or the AVC
byte stream. The bit streams carried in the Value field shall contain
complete NAL units including their relevant parameter sets, other
Supplemental Enhancement Information (SEI) and padding zeroes.
(https://pub.smpte.org/doc/st381-3/20170830-pub/)
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
Hi Nicolas On Fri, Feb 23, 2024 at 2:56 AM Nicolas George wrote: > Anton Khirnov (12024-02-22): > > In my updated proposal, based on comments by Niklas and Rémi, I'm > > leaving it up to the TC member in question, based on the assumption that > > TC members are honest. > > > > A "stronger" version could conceivably leave it to CC to decide > > ambiguous cases. Feel free to propose such a version if you prefer it. > > Your version does nothing to address the issue of the current situation, > where the contributor who has to raise an issue in front of the TC does > not trust one member of the TC to be unbiased on this issue. > > I therefore maintain my alternate proposition as is. > I think you and Anton are trying to fix different issues. I would propose to run independent votes over Anton's proposal and your proposal, in no particular order. For your proposal, if you want the GA to vote on it, would it be possible to please more specifically define "soon"? Does it mean "ever"? Or within what time period? Or is the period irrelevant and is the intention of desiring to work at the company at the point the conflict takes place more relevant? Thanks, Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] configure: Disable linker warnings for common symbols
Common symbols are not part of ISO-C and therefore not used by FFmpeg at all. Yet linker warnings to ensure it stays that way are nevertheless wrong, because the existence of common symbols does not imply that there is a bug in our code. More precisely, Clang's ASAN implementation uses a common symbol ___asan_globals_registered when used on Elf targets with the -fsanitize-address-globals-dead-stripping option; said option is the default since Clang 17 [1]. This leads to 1883 warnings about ___asan_globals_registered when linking here. (Even without that option there were warnings like _ZN14__interception10real_vforkE being overridden.) Said warning is also unnecessary: The proper way to ensure that our code is free of common symbols is to let the compiler enforce this. But this is already the default since GCC 10 and Clang 11, so there is no risk of introducing our own common symbols. [1]: https://reviews.llvm.org/D152604 Signed-off-by: Andreas Rheinhardt --- There is btw a second incompatibility between our configure script and Clang ASAN: Since version 16 it defaults to -fsanitize-address-use-odr-indicator and with this option set, it creates a __odr_asan_gen_FOO symbol for every object FOO in addition to the symbol FOO itself; configure therefore sets extern_prefix (used for ASM name mangling) to "__odr_asan_gen_". configure | 1 - 1 file changed, 1 deletion(-) diff --git a/configure b/configure index 197f762b58..108816bd1e 100755 --- a/configure +++ b/configure @@ -7337,7 +7337,6 @@ void (^block)(void); EOF # add some linker flags -check_ldflags -Wl,--warn-common check_ldflags -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil enabled rpath && add_ldexeflags -Wl,-rpath,$libdir && add_ldsoflags -Wl,-rpath,$libdir test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic -- 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".
Re: [FFmpeg-devel] [PATCH 23/38] avcodec/hevcdec: respect side data preference
On Fri, 23 Feb 2024, Anton Khirnov wrote: From: Niklas Haas If the time code side data is overridden by the packet level, we also make sure not to update `out->metadata` to a mismatched timecode. For HDR side data, we unfortunately need to omit a return check because the new function does not distinguish between OOM and overridden side data. I don't think this is acceptable. If the API is not capable of differentiating between OOM and overridden side data, then the API should be fixed. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavu/hashtable: create generic robin hood hash table
On Wed, Feb 21, 2024 at 05:09:21PM -0800, Connor Worley wrote: > Signed-off-by: Connor Worley > --- > libavutil/Makefile | 2 + > libavutil/hashtable.c | 192 > libavutil/hashtable.h | 40 > libavutil/tests/hashtable.c | 108 > 4 files changed, 342 insertions(+) > create mode 100644 libavutil/hashtable.c > create mode 100644 libavutil/hashtable.h > create mode 100644 libavutil/tests/hashtable.c breaks make testprogs CC libavutil/tests/hashtable.o libavutil/tests/hashtable.c: In function ‘main’: libavutil/tests/hashtable.c:28:5: error: unknown type name ‘uint8_t’; did you mean ‘u_int8_t’? uint8_t k; ^~~ u_int8_t libavutil/tests/hashtable.c:29:5: error: unknown type name ‘uint64_t’; did you mean ‘u_int64_t’? uint64_t v; ^~~~ u_int64_t ffbuild/common.mak:81: recipe for target 'libavutil/tests/hashtable.o' failed make: *** [libavutil/tests/hashtable.o] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 15/38] lavu/opt: add array options
On Fri, 23 Feb 2024, Anton Khirnov wrote:
AVOption.array_max_size is added before AVOption.unit to avoid
increasing sizeof(AVOption).
---
doc/APIchanges| 3 +
libavutil/opt.c | 344 --
libavutil/opt.h | 26
libavutil/tests/opt.c | 34 +
tests/ref/fate/opt| 23 ++-
5 files changed, 385 insertions(+), 45 deletions(-)
[...]
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -288,6 +288,16 @@ enum AVOptionType{
*/
#define AV_OPT_FLAG_CHILD_CONSTS(1 << 18)
+/**
+ * The option is an array.
+ *
+ * When adding array options to an object, @ref AVOption.offset should refer to
+ * a pointer corresponding to the option type. The pointer should be
immediately
+ * followed by an unsigned int that will store the number of elements in the
+ * array.
+ */
+#define AV_OPT_FLAG_ARRAY (1 << 19)
+
/**
* AVOption
*/
@@ -313,6 +323,16 @@ typedef struct AVOption {
union {
int64_t i64;
double dbl;
+
+/**
+ * This member is always used for AV_OPT_FLAG_ARRAY options. When
+ * non-NULL, the first character of the string must be the separator to
+ * be used for (de)serializing lists to/from strings with av_opt_get(),
This is quite ugly. Also it breaks the assumption that if the user sets an
option value to the default value of the option, than it will work. So
let's just remove this feature for now.
Eventually I think some new struct should be introduced, e.g.
AVOptionExtension, which can be used to specify additional option
settings, such as array min/max size, and maybe separator. It would be a
lot more clean and future proof than filling the holes in AVOption.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 16/38] lavc: add a decoder option for configuring side data preference
On 2/23/2024 2:53 PM, James Almer wrote:
On 2/23/2024 2:51 PM, Marton Balint wrote:
On Fri, 23 Feb 2024, Anton Khirnov wrote:
This and the following commits fix #10857
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 20
libavcodec/decode.c | 36
libavcodec/options_table.h | 12
4 files changed, 71 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 371fd2f465..78744a674a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on
2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavc 60.xx.100 - avcodec.h
+ Add AVCodecContext.[nb_]side_data_prefer_global.
+
2024-02-xx - xx - lavu 58.xx.100 - opt.h
Add AV_OPT_FLAG_ARRAY and AVOption.array_max_size.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..307a3e99db 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2120,6 +2120,26 @@ typedef struct AVCodecContext {
* an error.
*/
int64_t frame_num;
+
+ /**
+ * Decoding only. May be set by the caller before
avcodec_open2() to an
+ * av_malloc()'ed array (or via AVOptions). Owned and freed by
the decoder
+ * afterwards.
+ *
+ * By default, when some side data type is present both in global
+ * user-supplied coded_side_data and inside the coded bitstream,
avcodec
+ * will propagate the latter to the decoded frame.
+ *
+ * This array contains a list of AVPacketSideDataType for which
this
+ * preference should be switched, i.e. avcodec will prefer
global side data
+ * over those in stored in the bytestream. It may also contain a
single -1,
+ * in which case the preference is switched for all side data
types.
+ */
+ int *side_data_prefer_global;
Why is this a list and AV_OPT_FLAG_ARRAY? This simply should be a
mask, so AV_OPT_TYPE_FLAGS.
That would effectively limit side data element types to 64.
Actually no, it'd be 32 since _FLAGS expects an unsigned int.
___
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 16/38] lavc: add a decoder option for configuring side data preference
On 2/23/2024 2:51 PM, Marton Balint wrote:
On Fri, 23 Feb 2024, Anton Khirnov wrote:
This and the following commits fix #10857
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 20
libavcodec/decode.c | 36
libavcodec/options_table.h | 12
4 files changed, 71 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 371fd2f465..78744a674a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on
2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavc 60.xx.100 - avcodec.h
+ Add AVCodecContext.[nb_]side_data_prefer_global.
+
2024-02-xx - xx - lavu 58.xx.100 - opt.h
Add AV_OPT_FLAG_ARRAY and AVOption.array_max_size.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..307a3e99db 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2120,6 +2120,26 @@ typedef struct AVCodecContext {
* an error.
*/
int64_t frame_num;
+
+ /**
+ * Decoding only. May be set by the caller before avcodec_open2()
to an
+ * av_malloc()'ed array (or via AVOptions). Owned and freed by
the decoder
+ * afterwards.
+ *
+ * By default, when some side data type is present both in global
+ * user-supplied coded_side_data and inside the coded bitstream,
avcodec
+ * will propagate the latter to the decoded frame.
+ *
+ * This array contains a list of AVPacketSideDataType for which this
+ * preference should be switched, i.e. avcodec will prefer global
side data
+ * over those in stored in the bytestream. It may also contain a
single -1,
+ * in which case the preference is switched for all side data types.
+ */
+ int *side_data_prefer_global;
Why is this a list and AV_OPT_FLAG_ARRAY? This simply should be a mask,
so AV_OPT_TYPE_FLAGS.
That would effectively limit side data element types to 64.
___
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 16/38] lavc: add a decoder option for configuring side data preference
On Fri, 23 Feb 2024, Anton Khirnov wrote:
This and the following commits fix #10857
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 20
libavcodec/decode.c| 36
libavcodec/options_table.h | 12
4 files changed, 71 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 371fd2f465..78744a674a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavc 60.xx.100 - avcodec.h
+ Add AVCodecContext.[nb_]side_data_prefer_global.
+
2024-02-xx - xx - lavu 58.xx.100 - opt.h
Add AV_OPT_FLAG_ARRAY and AVOption.array_max_size.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..307a3e99db 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2120,6 +2120,26 @@ typedef struct AVCodecContext {
* an error.
*/
int64_t frame_num;
+
+/**
+ * Decoding only. May be set by the caller before avcodec_open2() to an
+ * av_malloc()'ed array (or via AVOptions). Owned and freed by the decoder
+ * afterwards.
+ *
+ * By default, when some side data type is present both in global
+ * user-supplied coded_side_data and inside the coded bitstream, avcodec
+ * will propagate the latter to the decoded frame.
+ *
+ * This array contains a list of AVPacketSideDataType for which this
+ * preference should be switched, i.e. avcodec will prefer global side data
+ * over those in stored in the bytestream. It may also contain a single -1,
+ * in which case the preference is switched for all side data types.
+ */
+int*side_data_prefer_global;
Why is this a list and AV_OPT_FLAG_ARRAY? This simply should be a mask, so
AV_OPT_TYPE_FLAGS.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] hwcontext_videotoolbox: add vt_device_derive
I’ve tested and confirmed to work, and `reverse=1` also works for chaining to other videotoolbox filters. > On Feb 23, 2024, at 22:25, Zhao Zhili wrote: > > ___ > 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] lavc/vp8dsp: R-V V put_bilin_h
Hi, + +.macro bilin_h_load dst len +.ifc \len,4 +vsetivlizero, 5, e8, mf2, ta, ma Don't use fractional multipliers if you don't mix element widths. +.elseif \len == 8 +vsetivlizero, 9, e8, m1, ta, ma +.else +vsetivlizero, 17, e8, m2, ta, ma +.endif + +vle8.v \dst, (a2) +vslide1down.vx v2, \dst, t5 + +.ifc \len,4 +vsetivlizero, 4, e8, mf4, ta, ma Same as above. +.elseif \len == 8 +vsetivlizero, 8, e8, mf2, ta, ma Also. +.else +vsetivlizero, 16, e8, m1, ta, ma +.endif +vwmulu.vx v28, \dst, t1 +vwmaccu.vx v28, a5, v2 +vwaddu.wx v24, v28, t4 +vnsra.wi\dst, v24, 3 +.endm + +.macro put_vp8_bilin_h len +li t1, 8 +li t4, 4 +li t5, 1 +sub t1, t1, a5 +1: +addia4, a4, -1 +bilin_h_loadv0, \len +vse8.v v0, (a0) +add a2, a2, a3 +add a0, a0, a1 +bneza4, 1b + +ret +.endm + +func ff_put_vp8_bilin16_h_rvv, zve32x +put_vp8_bilin_h 16 +endfunc + +func ff_put_vp8_bilin8_h_rvv, zve32x +put_vp8_bilin_h 8 +endfunc + +func ff_put_vp8_bilin4_h_rvv, zve32x +put_vp8_bilin_h 4 +endfunc -- レミ・デニ-クールモン 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".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
Quoting Michael Niedermayer (2024-02-23 15:00:24) > On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote: > > Hi, > > in the 'avcodec/s302m: enable non-PCM decoding' thread it became > > apparent that there is wide disagreement about the interpretation of > > this line in the TC rules: > > > > > If the disagreement involves a member of the TC, that member should > > > recuse themselves from the decision. > > > > The word 'involves' in it can be intepreted a variety of very different > > ways, to apply to TC members who e.g.: > > 1) authored the changes that are being objected to > > 2) are objecting to the changes > > 3) have any opinion on the changes, either positive or negative > > 4) have previously voiced an opinion that would apply to the changes > > 5) authored the code that is being modified > > 6) have a financial or other similar interest in a specific outcome of > >the disagreement > > > > I believe the best way to address this is to make the rule more > > explicit, so I propose that people with an opinion on the matter submit > > their preferred wording, and then we can have the GA vote on it. > > For the actual vote about changing the rules and the discussion of it. > Each option should provide a patch. > Otherwise you could have a whole new discussion after the vote how > to turn it into a change to the rules My proposal is an excerpt from a patch, just trimmed down to make it easier to read. And I don't see what could be ambiguous about it, you just remove one specific line and replace it with other text as proposed. -- 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] [RFC] clarifying the TC conflict of interest rule
Quoting Zhao Zhili (2024-02-23 15:52:50) > > > 在 2024年2月23日，下午7:26，Gyan Doshi 写道： > > > > > > > >> On 2024-02-23 01:26 pm, Nicolas George wrote: > >> Anton Khirnov (12024-02-22): > >>> In my updated proposal, based on comments by Niklas and Rémi, I'm > >>> leaving it up to the TC member in question, based on the assumption that > >>> TC members are honest. > >>> > >>> A "stronger" version could conceivably leave it to CC to decide > >>> ambiguous cases. Feel free to propose such a version if you prefer it. > >> Your version does nothing to address the issue of the current situation, > >> where the contributor who has to raise an issue in front of the TC does > >> not trust one member of the TC to be unbiased on this issue. > > > > Just to be clear, that's not my basis. > > > > I said, > > > > "As a TC member who is part of the disagreement, I believe your > > participation is recused." > > > > based on the existing rule, > > > > "If the disagreement involves a member of the TC, that member should recuse > > themselves from the decision" > > I propose a new method that, instead of recuse TC members, let the author > take part in the vote, to make it symmetric. What if the TC member is the author? Also, if you want it to be made a voting option, please formulate it as actual text that should replace the disputed line in doc/community.texi. -- 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 38/38] tests/fate/matroska: add tests for side data preference
On 2/23/2024 12:02 PM, Anton Khirnov wrote: Quoting Anton Khirnov (2024-02-23 14:59:00) +fate-matroska-side-data-pref-codec: CMD = run ffprobe$(PROGSSUF)$(EXESUF) $(TARGET_SAMPLES)/mkv/hdr10tags-both.mkv \ Please upload https://ups.khirnov.net/92f7f28810e0d34af917dba853a5056d1d8001182f5ffb70c7d14fb72ec58fa4/hdr10tags-both.mkv to mkv/hdr10tags-both.mkv Thanks, Done. ___ 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 3/5] avutil/hwcontext_vulkan: Fix leaks when semaphore creation fails
Feb 22, 2024, 15:43 by quinkbl...@foxmail.com: > From: Zhao Zhili > > --- > libavutil/hwcontext_vulkan.c | 27 +-- > 1 file changed, 17 insertions(+), 10 deletions(-) > LGTM on all Vulkan patches you posted. ___ 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 38/38] tests/fate/matroska: add tests for side data preference
Quoting Anton Khirnov (2024-02-23 14:59:00) > +fate-matroska-side-data-pref-codec: CMD = run ffprobe$(PROGSSUF)$(EXESUF) > $(TARGET_SAMPLES)/mkv/hdr10tags-both.mkv \ Please upload https://ups.khirnov.net/92f7f28810e0d34af917dba853a5056d1d8001182f5ffb70c7d14fb72ec58fa4/hdr10tags-both.mkv to mkv/hdr10tags-both.mkv Thanks, -- 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] [RFC] clarifying the TC conflict of interest rule
> 在 2024年2月23日，下午7:26，Gyan Doshi 写道： > > > >> On 2024-02-23 01:26 pm, Nicolas George wrote: >> Anton Khirnov (12024-02-22): >>> In my updated proposal, based on comments by Niklas and Rémi, I'm >>> leaving it up to the TC member in question, based on the assumption that >>> TC members are honest. >>> >>> A "stronger" version could conceivably leave it to CC to decide >>> ambiguous cases. Feel free to propose such a version if you prefer it. >> Your version does nothing to address the issue of the current situation, >> where the contributor who has to raise an issue in front of the TC does >> not trust one member of the TC to be unbiased on this issue. > > Just to be clear, that's not my basis. > > I said, > > "As a TC member who is part of the disagreement, I believe your participation > is recused." > > based on the existing rule, > > "If the disagreement involves a member of the TC, that member should recuse > themselves from the decision" I propose a new method that, instead of recuse TC members, let the author take part in the vote, to make it symmetric. > > Disagreement implies the existence of opposing sides, so discussion members > from both sides are barred from the TC proceedings. > The wiggle room in interpretation is over whether 'involves' captures all > participants, including minor ones, or just the principal interlocutors. > Note that the rule says nothing about patch authorship or asymmetry in its > application. > > Anton's original disagreement, as I understand it, is about the propriety of > the rule i.e. he believes that pre-existing public opposition (or agreement) > on the issue should not bar a TC member. That's a disagreement with the rule, > not with its interpretation. > > Regards, > Gyan > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subje ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] lavc/vp8dsp: R-V V put_bilin_hv
From e1a01b1e0a365935868d7825d53c7cc64e2c1787 Mon Sep 17 00:00:00 2001 From: sunyuechi Date: Fri, 23 Feb 2024 22:35:23 +0800 Subject: [PATCH 3/3] lavc/vp8dsp: R-V V put_bilin_hv C908: vp8_put_bilin4_hv_c: 567.7 vp8_put_bilin4_hv_rvv_i32: 255.7 vp8_put_bilin8_hv_c: 2169.5 vp8_put_bilin8_hv_rvv_i32: 528.7 vp8_put_bilin16_hv_c: 4777.5 vp8_put_bilin16_hv_rvv_i32: 587.7 --- libavcodec/riscv/vp8dsp_init.c | 13 + libavcodec/riscv/vp8dsp_rvv.S | 35 ++ 2 files changed, 48 insertions(+) diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c index 10e1498d01..02dbda979e 100644 --- a/libavcodec/riscv/vp8dsp_init.c +++ b/libavcodec/riscv/vp8dsp_init.c @@ -65,6 +65,19 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c) c->put_vp8_bilinear_pixels_tab[1][2][0] = ff_put_vp8_bilin8_v_rvv; c->put_vp8_bilinear_pixels_tab[2][1][0] = ff_put_vp8_bilin4_v_rvv; c->put_vp8_bilinear_pixels_tab[2][2][0] = ff_put_vp8_bilin4_v_rvv; + +c->put_vp8_bilinear_pixels_tab[0][1][1] = ff_put_vp8_bilin16_hv_rvv; +c->put_vp8_bilinear_pixels_tab[0][1][2] = ff_put_vp8_bilin16_hv_rvv; +c->put_vp8_bilinear_pixels_tab[0][2][1] = ff_put_vp8_bilin16_hv_rvv; +c->put_vp8_bilinear_pixels_tab[0][2][2] = ff_put_vp8_bilin16_hv_rvv; +c->put_vp8_bilinear_pixels_tab[1][1][1] = ff_put_vp8_bilin8_hv_rvv; +c->put_vp8_bilinear_pixels_tab[1][1][2] = ff_put_vp8_bilin8_hv_rvv; +c->put_vp8_bilinear_pixels_tab[1][2][1] = ff_put_vp8_bilin8_hv_rvv; +c->put_vp8_bilinear_pixels_tab[1][2][2] = ff_put_vp8_bilin8_hv_rvv; +c->put_vp8_bilinear_pixels_tab[2][1][1] = ff_put_vp8_bilin4_hv_rvv; +c->put_vp8_bilinear_pixels_tab[2][1][2] = ff_put_vp8_bilin4_hv_rvv; +c->put_vp8_bilinear_pixels_tab[2][2][1] = ff_put_vp8_bilin4_hv_rvv; +c->put_vp8_bilinear_pixels_tab[2][2][2] = ff_put_vp8_bilin4_hv_rvv; } #endif } diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S index a58c197ba1..9d4ffed255 100644 --- a/libavcodec/riscv/vp8dsp_rvv.S +++ b/libavcodec/riscv/vp8dsp_rvv.S @@ -188,3 +188,38 @@ func ff_put_vp8_bilin4_v_rvv, zve32x vsetivlizero, 4, e8, mf4, ta, ma put_vp8_bilin_v endfunc + +.macro put_vp8_bilin_hv len +li t3, 8 +sub t1, t3, a5 +sub t2, t3, a6 +li t4, 4 +li t5, 1 +bilin_h_loadv4, \len +add a2, a2, a3 +1: +addia4, a4, -1 +vwmulu.vx v20, v4, t2 +bilin_h_loadv4, \len +vwmaccu.vx v20, a6, v4 +vwaddu.wx v24, v20, t4 +vnsra.wiv0, v24, 3 +vse8.v v0, (a0) +add a2, a2, a3 +add a0, a0, a1 +bneza4, 1b + +ret +.endm + +func ff_put_vp8_bilin16_hv_rvv, zve32x +put_vp8_bilin_hv 16 +endfunc + +func ff_put_vp8_bilin8_hv_rvv, zve32x +put_vp8_bilin_hv 8 +endfunc + +func ff_put_vp8_bilin4_hv_rvv, zve32x +put_vp8_bilin_hv 4 +endfunc -- 2.43.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] lavc/vp8dsp: R-V V put_bilin_v
From 488d0cd6645b2c6936c3298e010615facb6d0bd0 Mon Sep 17 00:00:00 2001 From: sunyuechi Date: Fri, 23 Feb 2024 22:35:01 +0800 Subject: [PATCH 2/3] lavc/vp8dsp: R-V V put_bilin_v C908: vp8_put_bilin4_v_c: 383.5 vp8_put_bilin4_v_rvv_i32: 139.7 vp8_put_bilin8_v_c: 1455.7 vp8_put_bilin8_v_rvv_i32: 299.7 vp8_put_bilin16_v_c: 2863.7 vp8_put_bilin16_v_rvv_i32: 347.7 --- libavcodec/riscv/vp8dsp_init.c | 7 +++ libavcodec/riscv/vp8dsp_rvv.S | 36 ++ 2 files changed, 43 insertions(+) diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c index 32cb4893a4..10e1498d01 100644 --- a/libavcodec/riscv/vp8dsp_init.c +++ b/libavcodec/riscv/vp8dsp_init.c @@ -58,6 +58,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c) c->put_vp8_bilinear_pixels_tab[1][0][2] = ff_put_vp8_bilin8_h_rvv; c->put_vp8_bilinear_pixels_tab[2][0][1] = ff_put_vp8_bilin4_h_rvv; c->put_vp8_bilinear_pixels_tab[2][0][2] = ff_put_vp8_bilin4_h_rvv; + +c->put_vp8_bilinear_pixels_tab[0][1][0] = ff_put_vp8_bilin16_v_rvv; +c->put_vp8_bilinear_pixels_tab[0][2][0] = ff_put_vp8_bilin16_v_rvv; +c->put_vp8_bilinear_pixels_tab[1][1][0] = ff_put_vp8_bilin8_v_rvv; +c->put_vp8_bilinear_pixels_tab[1][2][0] = ff_put_vp8_bilin8_v_rvv; +c->put_vp8_bilinear_pixels_tab[2][1][0] = ff_put_vp8_bilin4_v_rvv; +c->put_vp8_bilinear_pixels_tab[2][2][0] = ff_put_vp8_bilin4_v_rvv; } #endif } diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S index c8d265e516..a58c197ba1 100644 --- a/libavcodec/riscv/vp8dsp_rvv.S +++ b/libavcodec/riscv/vp8dsp_rvv.S @@ -152,3 +152,39 @@ endfunc func ff_put_vp8_bilin4_h_rvv, zve32x put_vp8_bilin_h 4 endfunc + +.macro put_vp8_bilin_v +li t1, 8 +li t4, 4 +sub t1, t1, a6 +1: +add t2, a2, a3 +addia4, a4, -1 +vle8.v v0, (a2) +vle8.v v2, (t2) +vwmulu.vx v28, v0, t1 +vwmaccu.vx v28, a6, v2 +vwaddu.wx v24, v28, t4 +vnsra.wiv0, v24, 3 +vse8.v v0, (a0) +add a2, a2, a3 +add a0, a0, a1 +bneza4, 1b + +ret +.endm + +func ff_put_vp8_bilin16_v_rvv, zve32x +vsetivlizero, 16, e8, m1, ta, ma +put_vp8_bilin_v +endfunc + +func ff_put_vp8_bilin8_v_rvv, zve32x +vsetivlizero, 8, e8, mf2, ta, ma +put_vp8_bilin_v +endfunc + +func ff_put_vp8_bilin4_v_rvv, zve32x +vsetivlizero, 4, e8, mf4, ta, ma +put_vp8_bilin_v +endfunc -- 2.43.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] lavc/vp8dsp: R-V V put_bilin_h
From b773a2b640ba38a106539da7f3414d6892364c4f Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Fri, 23 Feb 2024 13:27:42 +0800
Subject: [PATCH 1/3] lavc/vp8dsp: R-V V put_bilin_h
C908:
vp8_put_bilin4_h_c: 373.5
vp8_put_bilin4_h_rvv_i32: 158.7
vp8_put_bilin8_h_c: 1437.7
vp8_put_bilin8_h_rvv_i32: 318.7
vp8_put_bilin16_h_c: 2845.7
vp8_put_bilin16_h_rvv_i32: 374.7
---
libavcodec/riscv/vp8dsp_init.c | 11 +++
libavcodec/riscv/vp8dsp_rvv.S | 54 ++
2 files changed, 65 insertions(+)
diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index c364de3dc9..32cb4893a4 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -34,6 +34,10 @@ VP8_EPEL(16, rvv);
VP8_EPEL(8, rvv);
VP8_EPEL(4, rvv);
+VP8_BILIN(16, rvv);
+VP8_BILIN(8, rvv);
+VP8_BILIN(4, rvv);
+
av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
{
#if HAVE_RVV
@@ -47,6 +51,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
c->put_vp8_bilinear_pixels_tab[0][0][0] = ff_put_vp8_pixels16_rvv;
c->put_vp8_bilinear_pixels_tab[1][0][0] = ff_put_vp8_pixels8_rvv;
c->put_vp8_bilinear_pixels_tab[2][0][0] = ff_put_vp8_pixels4_rvv;
+
+c->put_vp8_bilinear_pixels_tab[0][0][1] = ff_put_vp8_bilin16_h_rvv;
+c->put_vp8_bilinear_pixels_tab[0][0][2] = ff_put_vp8_bilin16_h_rvv;
+c->put_vp8_bilinear_pixels_tab[1][0][1] = ff_put_vp8_bilin8_h_rvv;
+c->put_vp8_bilinear_pixels_tab[1][0][2] = ff_put_vp8_bilin8_h_rvv;
+c->put_vp8_bilinear_pixels_tab[2][0][1] = ff_put_vp8_bilin4_h_rvv;
+c->put_vp8_bilinear_pixels_tab[2][0][2] = ff_put_vp8_bilin4_h_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 063ab7110c..c8d265e516 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -98,3 +98,57 @@ func ff_put_vp8_pixels4_rvv, zve32x
vsetivli zero, 4, e8, mf4, ta, ma
put_vp8_pixels
endfunc
+
+.macro bilin_h_load dst len
+.ifc \len,4
+vsetivlizero, 5, e8, mf2, ta, ma
+.elseif \len == 8
+vsetivlizero, 9, e8, m1, ta, ma
+.else
+vsetivlizero, 17, e8, m2, ta, ma
+.endif
+
+vle8.v \dst, (a2)
+vslide1down.vx v2, \dst, t5
+
+.ifc \len,4
+vsetivlizero, 4, e8, mf4, ta, ma
+.elseif \len == 8
+vsetivlizero, 8, e8, mf2, ta, ma
+.else
+vsetivlizero, 16, e8, m1, ta, ma
+.endif
+
+vwmulu.vx v28, \dst, t1
+vwmaccu.vx v28, a5, v2
+vwaddu.wx v24, v28, t4
+vnsra.wi\dst, v24, 3
+.endm
+
+.macro put_vp8_bilin_h len
+li t1, 8
+li t4, 4
+li t5, 1
+sub t1, t1, a5
+1:
+addia4, a4, -1
+bilin_h_loadv0, \len
+vse8.v v0, (a0)
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
+func ff_put_vp8_bilin16_h_rvv, zve32x
+put_vp8_bilin_h 16
+endfunc
+
+func ff_put_vp8_bilin8_h_rvv, zve32x
+put_vp8_bilin_h 8
+endfunc
+
+func ff_put_vp8_bilin4_h_rvv, zve32x
+put_vp8_bilin_h 4
+endfunc
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 04/38] lavu/opt: cosmetics, group (un)init and management functions together
---
libavutil/opt.h | 336 +---
1 file changed, 173 insertions(+), 163 deletions(-)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index d72d65052f..e2b6ba1f35 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -402,15 +402,9 @@ typedef struct AVOptionRanges {
} AVOptionRanges;
/**
- * Show the obj options.
- *
- * @param req_flags requested flags for the options to show. Show only the
- * options for which it is opt->flags & req_flags.
- * @param rej_flags rejected flags for the options to show. Show only the
- * options for which it is !(opt->flags & req_flags).
- * @param av_log_obj log context to use for showing the options
+ * @defgroup opt_mng AVOption (un)initialization and inspection.
+ * @{
*/
-int av_opt_show2(void *obj, void *av_log_obj, int req_flags, int rej_flags);
/**
* Set the values of all AVOption fields to their default values.
@@ -430,161 +424,37 @@ void av_opt_set_defaults(void *s);
*/
void av_opt_set_defaults2(void *s, int mask, int flags);
-/**
- * Parse the key/value pairs list in opts. For each key/value pair
- * found, stores the value in the field in ctx that is named like the
- * key. ctx must be an AVClass context, storing is done using
- * AVOptions.
- *
- * @param opts options string to parse, may be NULL
- * @param key_val_sep a 0-terminated list of characters used to
- * separate key from value
- * @param pairs_sep a 0-terminated list of characters used to separate
- * two pairs from each other
- * @return the number of successfully set key/value pairs, or a negative
- * value corresponding to an AVERROR code in case of error:
- * AVERROR(EINVAL) if opts cannot be parsed,
- * the error code issued by av_opt_set() if a key/value pair
- * cannot be set
- */
-int av_set_options_string(void *ctx, const char *opts,
- const char *key_val_sep, const char *pairs_sep);
-
-/**
- * Parse the key-value pairs list in opts. For each key=value pair found,
- * set the value of the corresponding option in ctx.
- *
- * @param ctx the AVClass object to set options on
- * @param opts the options string, key-value pairs separated by a
- * delimiter
- * @param shorthanda NULL-terminated array of options names for shorthand
- * notation: if the first field in opts has no key part,
- * the key is taken from the first element of shorthand;
- * then again for the second, etc., until either opts is
- * finished, shorthand is finished or a named option is
- * found; after that, all options must be named
- * @param key_val_sep a 0-terminated list of characters used to separate
- * key from value, for example '='
- * @param pairs_sepa 0-terminated list of characters used to separate
- * two pairs from each other, for example ':' or ','
- * @return the number of successfully set key=value pairs, or a negative
- * value corresponding to an AVERROR code in case of error:
- * AVERROR(EINVAL) if opts cannot be parsed,
- * the error code issued by av_set_string3() if a key/value pair
- * cannot be set
- *
- * Options names must use only the following characters: a-z A-Z 0-9 - . / _
- * Separators must use characters distinct from option names and from each
- * other.
- */
-int av_opt_set_from_string(void *ctx, const char *opts,
- const char *const *shorthand,
- const char *key_val_sep, const char *pairs_sep);
/**
* Free all allocated objects in obj.
*/
void av_opt_free(void *obj);
/**
- * Check whether a particular flag is set in a flags field.
+ * Iterate over all AVOptions belonging to obj.
*
- * @param field_name the name of the flag field option
- * @param flag_name the name of the flag to check
- * @return non-zero if the flag is set, zero if the flag isn't set,
- * isn't of the right type, or the flags field doesn't exist.
+ * @param obj an AVOptions-enabled struct or a double pointer to an
+ *AVClass describing it.
+ * @param prev result of the previous call to av_opt_next() on this object
+ * or NULL
+ * @return next AVOption or NULL
*/
-int av_opt_flag_is_set(void *obj, const char *field_name, const char
*flag_name);
+const AVOption *av_opt_next(const void *obj, const AVOption *prev);
/**
- * Set all the options from a given dictionary on an object.
+ * Iterate over AVOptions-enabled children of obj.
*
- * @param obj a struct whose first element is a pointer to AVClass
- * @param options options to process. This dictionary will be freed and
replaced
- *by a new one containing all options not found in obj.
- *Of course this new dictionary needs to be freed by caller
- *with av_dict_free().
- *
- * @return 0 on success, a negative AVERROR if
[FFmpeg-devel] [PATCH 34/38] avcodec/snowdec: use ff_frame_new_side_data
From: Niklas Haas
For consistency, even though this cannot be overriden at the packet
level.
---
libavcodec/snowdec.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 70fbab9a49..97aea748b6 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -787,11 +787,10 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
*picture,
res = av_frame_ref(picture, s->mconly_picture);
if (res >= 0 && s->avmv_index) {
AVFrameSideData *sd;
-
-sd = av_frame_new_side_data(picture, AV_FRAME_DATA_MOTION_VECTORS,
s->avmv_index * sizeof(AVMotionVector));
-if (!sd)
-return AVERROR(ENOMEM);
-memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
+res = ff_frame_new_side_data(s->avctx, picture,
AV_FRAME_DATA_MOTION_VECTORS,
+ s->avmv_index * sizeof(AVMotionVector),
);
+if (sd)
+memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
}
if (res < 0)
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 35/38] avcodec/mjpegdec: use ff_frame_new_side_data
From: Niklas Haas
For consistency, even though this can't (yet) be overriden at the packet
level.
---
libavcodec/mjpegdec.c | 66 ++-
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 43b36d0a8f..4ef565fe2d 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2865,42 +2865,44 @@ the_end:
if (orientation >= 2 && orientation <= 8) {
int32_t *matrix;
-sd = av_frame_new_side_data(frame,
AV_FRAME_DATA_DISPLAYMATRIX, sizeof(int32_t) * 9);
-if (!sd) {
+ret = ff_frame_new_side_data(avctx, frame,
AV_FRAME_DATA_DISPLAYMATRIX, sizeof(int32_t) * 9, );
+if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Could not allocate frame side
data\n");
-return AVERROR(ENOMEM);
+return ret;
}
-matrix = (int32_t *)sd->data;
+if (sd) {
+matrix = (int32_t *)sd->data;
-switch (orientation) {
-case 2:
-av_display_rotation_set(matrix, 0.0);
-av_display_matrix_flip(matrix, 1, 0);
-break;
-case 3:
-av_display_rotation_set(matrix, 180.0);
-break;
-case 4:
-av_display_rotation_set(matrix, 180.0);
-av_display_matrix_flip(matrix, 1, 0);
-break;
-case 5:
-av_display_rotation_set(matrix, 90.0);
-av_display_matrix_flip(matrix, 1, 0);
-break;
-case 6:
-av_display_rotation_set(matrix, 90.0);
-break;
-case 7:
-av_display_rotation_set(matrix, -90.0);
-av_display_matrix_flip(matrix, 1, 0);
-break;
-case 8:
-av_display_rotation_set(matrix, -90.0);
-break;
-default:
-av_assert0(0);
+switch (orientation) {
+case 2:
+av_display_rotation_set(matrix, 0.0);
+av_display_matrix_flip(matrix, 1, 0);
+break;
+case 3:
+av_display_rotation_set(matrix, 180.0);
+break;
+case 4:
+av_display_rotation_set(matrix, 180.0);
+av_display_matrix_flip(matrix, 1, 0);
+break;
+case 5:
+av_display_rotation_set(matrix, 90.0);
+av_display_matrix_flip(matrix, 1, 0);
+break;
+case 6:
+av_display_rotation_set(matrix, 90.0);
+break;
+case 7:
+av_display_rotation_set(matrix, -90.0);
+av_display_matrix_flip(matrix, 1, 0);
+break;
+case 8:
+av_display_rotation_set(matrix, -90.0);
+break;
+default:
+av_assert0(0);
+}
}
}
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 03/38] lavu/opt: document AVOption.flags
---
libavutil/opt.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 36e28249ee..d72d65052f 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -320,6 +320,9 @@ typedef struct AVOption {
double min; ///< minimum valid value for the option
double max; ///< maximum valid value for the option
+/**
+ * A combination of AV_OPT_FLAG_*.
+ */
int flags;
/**
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 07/38] lavu/opt: simplify printing option type in opt_list()
---
libavutil/opt.c | 107 +---
1 file changed, 37 insertions(+), 70 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index d13b1ab504..554916fbaf 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1231,6 +1231,41 @@ static char *get_opt_flags_string(void *obj, const char
*unit, int64_t value)
return NULL;
}
+static void log_type(void *av_log_obj, const AVOption *o,
+ enum AVOptionType parent_type)
+{
+const char *desc[] = {
+[AV_OPT_TYPE_FLAGS] = "",
+[AV_OPT_TYPE_INT] = "",
+[AV_OPT_TYPE_INT64] = "",
+[AV_OPT_TYPE_UINT64]= "",
+[AV_OPT_TYPE_DOUBLE]= "",
+[AV_OPT_TYPE_FLOAT] = "",
+[AV_OPT_TYPE_STRING]= "",
+[AV_OPT_TYPE_RATIONAL] = "",
+[AV_OPT_TYPE_BINARY]= "",
+[AV_OPT_TYPE_DICT] = "",
+[AV_OPT_TYPE_IMAGE_SIZE]= "",
+[AV_OPT_TYPE_VIDEO_RATE]= "",
+[AV_OPT_TYPE_PIXEL_FMT] = "",
+[AV_OPT_TYPE_SAMPLE_FMT]= "",
+[AV_OPT_TYPE_DURATION] = "",
+[AV_OPT_TYPE_COLOR] = "",
+#if FF_API_OLD_CHANNEL_LAYOUT
+[AV_OPT_TYPE_CHANNEL_LAYOUT]= "",
+#endif
+[AV_OPT_TYPE_CHLAYOUT] = "",
+[AV_OPT_TYPE_BOOL] = "",
+};
+
+if (o->type == AV_OPT_TYPE_CONST && parent_type == AV_OPT_TYPE_INT)
+av_log(av_log_obj, AV_LOG_INFO, "%-12"PRId64" ", o->default_val.i64);
+else if (o->type < FF_ARRAY_ELEMS(desc) && desc[o->type])
+av_log(av_log_obj, AV_LOG_INFO, "%-12s ", desc[o->type]);
+else
+av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
+}
+
static void opt_list(void *obj, void *av_log_obj, const char *unit,
int req_flags, int rej_flags, enum AVOptionType
parent_type)
{
@@ -1259,76 +1294,8 @@ static void opt_list(void *obj, void *av_log_obj, const
char *unit,
(opt->flags & AV_OPT_FLAG_FILTERING_PARAM) ? " " : "-",
opt->name);
-switch (opt->type) {
-case AV_OPT_TYPE_FLAGS:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_INT:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_INT64:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_UINT64:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_DOUBLE:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_FLOAT:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_STRING:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_RATIONAL:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_BINARY:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_DICT:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_IMAGE_SIZE:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_VIDEO_RATE:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_PIXEL_FMT:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_SAMPLE_FMT:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_DURATION:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_COLOR:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_CHLAYOUT:
-#if FF_API_OLD_CHANNEL_LAYOUT
-FF_DISABLE_DEPRECATION_WARNINGS
-case AV_OPT_TYPE_CHANNEL_LAYOUT:
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_BOOL:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-case AV_OPT_TYPE_CONST:
-if (parent_type == AV_OPT_TYPE_INT)
-av_log(av_log_obj, AV_LOG_INFO, "%-12"PRId64" ",
opt->default_val.i64);
-else
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-default:
-av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
-break;
-}
+
[FFmpeg-devel] [PATCH 08/38] lavu/opt: factor out printing option default from opt_list()
---
libavutil/opt.c | 150 +---
1 file changed, 78 insertions(+), 72 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 554916fbaf..49b7da7742 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1266,6 +1266,83 @@ static void log_type(void *av_log_obj, const AVOption *o,
av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
}
+static void log_default(void *obj, void *av_log_obj, const AVOption *opt)
+{
+if (opt->type == AV_OPT_TYPE_CONST || opt->type == AV_OPT_TYPE_BINARY)
+return;
+if ((opt->type == AV_OPT_TYPE_COLOR ||
+ opt->type == AV_OPT_TYPE_IMAGE_SIZE ||
+ opt->type == AV_OPT_TYPE_STRING ||
+ opt->type == AV_OPT_TYPE_DICT ||
+ opt->type == AV_OPT_TYPE_CHLAYOUT ||
+ opt->type == AV_OPT_TYPE_VIDEO_RATE) &&
+!opt->default_val.str)
+return;
+
+av_log(av_log_obj, AV_LOG_INFO, " (default ");
+switch (opt->type) {
+case AV_OPT_TYPE_BOOL:
+av_log(av_log_obj, AV_LOG_INFO, "%s", (char
*)av_x_if_null(get_bool_name(opt->default_val.i64), "invalid"));
+break;
+case AV_OPT_TYPE_FLAGS: {
+char *def_flags = get_opt_flags_string(obj, opt->unit,
opt->default_val.i64);
+if (def_flags) {
+av_log(av_log_obj, AV_LOG_INFO, "%s", def_flags);
+av_freep(_flags);
+} else {
+av_log(av_log_obj, AV_LOG_INFO, "%"PRIX64, opt->default_val.i64);
+}
+break;
+}
+case AV_OPT_TYPE_DURATION: {
+char buf[25];
+format_duration(buf, sizeof(buf), opt->default_val.i64);
+av_log(av_log_obj, AV_LOG_INFO, "%s", buf);
+break;
+}
+case AV_OPT_TYPE_INT:
+case AV_OPT_TYPE_UINT64:
+case AV_OPT_TYPE_INT64: {
+const char *def_const = get_opt_const_name(obj, opt->unit,
opt->default_val.i64);
+if (def_const)
+av_log(av_log_obj, AV_LOG_INFO, "%s", def_const);
+else
+log_int_value(av_log_obj, AV_LOG_INFO, opt->default_val.i64);
+break;
+}
+case AV_OPT_TYPE_DOUBLE:
+case AV_OPT_TYPE_FLOAT:
+log_value(av_log_obj, AV_LOG_INFO, opt->default_val.dbl);
+break;
+case AV_OPT_TYPE_RATIONAL: {
+AVRational q = av_d2q(opt->default_val.dbl, INT_MAX);
+av_log(av_log_obj, AV_LOG_INFO, "%d/%d", q.num, q.den); }
+break;
+case AV_OPT_TYPE_PIXEL_FMT:
+av_log(av_log_obj, AV_LOG_INFO, "%s", (char
*)av_x_if_null(av_get_pix_fmt_name(opt->default_val.i64), "none"));
+break;
+case AV_OPT_TYPE_SAMPLE_FMT:
+av_log(av_log_obj, AV_LOG_INFO, "%s", (char
*)av_x_if_null(av_get_sample_fmt_name(opt->default_val.i64), "none"));
+break;
+case AV_OPT_TYPE_COLOR:
+case AV_OPT_TYPE_IMAGE_SIZE:
+case AV_OPT_TYPE_STRING:
+case AV_OPT_TYPE_DICT:
+case AV_OPT_TYPE_VIDEO_RATE:
+case AV_OPT_TYPE_CHLAYOUT:
+av_log(av_log_obj, AV_LOG_INFO, "\"%s\"", opt->default_val.str);
+break;
+#if FF_API_OLD_CHANNEL_LAYOUT
+FF_DISABLE_DEPRECATION_WARNINGS
+case AV_OPT_TYPE_CHANNEL_LAYOUT:
+av_log(av_log_obj, AV_LOG_INFO, "0x%"PRIx64, opt->default_val.i64);
+break;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+}
+av_log(av_log_obj, AV_LOG_INFO, ")");
+}
+
static void opt_list(void *obj, void *av_log_obj, const char *unit,
int req_flags, int rej_flags, enum AVOptionType
parent_type)
{
@@ -1332,78 +1409,7 @@ static void opt_list(void *obj, void *av_log_obj, const
char *unit,
av_opt_freep_ranges();
}
-if (opt->type != AV_OPT_TYPE_CONST &&
-opt->type != AV_OPT_TYPE_BINARY &&
-!((opt->type == AV_OPT_TYPE_COLOR ||
- opt->type == AV_OPT_TYPE_IMAGE_SIZE ||
- opt->type == AV_OPT_TYPE_STRING ||
- opt->type == AV_OPT_TYPE_DICT ||
- opt->type == AV_OPT_TYPE_CHLAYOUT ||
- opt->type == AV_OPT_TYPE_VIDEO_RATE) &&
- !opt->default_val.str)) {
-av_log(av_log_obj, AV_LOG_INFO, " (default ");
-switch (opt->type) {
-case AV_OPT_TYPE_BOOL:
-av_log(av_log_obj, AV_LOG_INFO, "%s", (char
*)av_x_if_null(get_bool_name(opt->default_val.i64), "invalid"));
-break;
-case AV_OPT_TYPE_FLAGS: {
-char *def_flags = get_opt_flags_string(obj, opt->unit,
opt->default_val.i64);
-if (def_flags) {
-av_log(av_log_obj, AV_LOG_INFO, "%s", def_flags);
-av_freep(_flags);
-} else {
-av_log(av_log_obj, AV_LOG_INFO, "%"PRIX64,
opt->default_val.i64);
-}
-break;
-}
-case AV_OPT_TYPE_DURATION: {
-char buf[25];
-format_duration(buf, sizeof(buf),
[FFmpeg-devel] [PATCH 37/38] lavc/*dec: use side data preference for mastering display/content light metadata
---
libavcodec/av1dec.c| 46 +++-
libavcodec/h2645_sei.c | 96 +++---
libavcodec/libdav1d.c | 47 -
libavcodec/pngdec.c| 54 ++--
libavcodec/qsvdec.c| 50 +-
5 files changed, 165 insertions(+), 128 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 4fcfed3c7b..177c25f394 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -990,31 +990,39 @@ static int export_metadata(AVCodecContext *avctx, AVFrame
*frame)
int ret = 0;
if (s->mdcv) {
-AVMasteringDisplayMetadata *mastering =
av_mastering_display_metadata_create_side_data(frame);
-if (!mastering)
-return AVERROR(ENOMEM);
+AVMasteringDisplayMetadata *mastering;
-for (int i = 0; i < 3; i++) {
-mastering->display_primaries[i][0] =
av_make_q(s->mdcv->primary_chromaticity_x[i], 1 << 16);
-mastering->display_primaries[i][1] =
av_make_q(s->mdcv->primary_chromaticity_y[i], 1 << 16);
+ret = ff_decode_mastering_display_new(avctx, frame, );
+if (ret < 0)
+return ret;
+
+if (mastering) {
+for (int i = 0; i < 3; i++) {
+mastering->display_primaries[i][0] =
av_make_q(s->mdcv->primary_chromaticity_x[i], 1 << 16);
+mastering->display_primaries[i][1] =
av_make_q(s->mdcv->primary_chromaticity_y[i], 1 << 16);
+}
+mastering->white_point[0] =
av_make_q(s->mdcv->white_point_chromaticity_x, 1 << 16);
+mastering->white_point[1] =
av_make_q(s->mdcv->white_point_chromaticity_y, 1 << 16);
+
+mastering->max_luminance = av_make_q(s->mdcv->luminance_max, 1 <<
8);
+mastering->min_luminance = av_make_q(s->mdcv->luminance_min, 1 <<
14);
+
+mastering->has_primaries = 1;
+mastering->has_luminance = 1;
}
-mastering->white_point[0] =
av_make_q(s->mdcv->white_point_chromaticity_x, 1 << 16);
-mastering->white_point[1] =
av_make_q(s->mdcv->white_point_chromaticity_y, 1 << 16);
-
-mastering->max_luminance = av_make_q(s->mdcv->luminance_max, 1 << 8);
-mastering->min_luminance = av_make_q(s->mdcv->luminance_min, 1 << 14);
-
-mastering->has_primaries = 1;
-mastering->has_luminance = 1;
}
if (s->cll) {
-AVContentLightMetadata *light =
av_content_light_metadata_create_side_data(frame);
-if (!light)
-return AVERROR(ENOMEM);
+AVContentLightMetadata *light;
-light->MaxCLL = s->cll->max_cll;
-light->MaxFALL = s->cll->max_fall;
+ret = ff_decode_content_light_new(avctx, frame, );
+if (ret < 0)
+return ret;
+
+if (light) {
+light->MaxCLL = s->cll->max_cll;
+light->MaxFALL = s->cll->max_fall;
+}
}
while (av_fifo_read(s->itut_t35_fifo, _t35, 1) >= 0) {
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index f3497d5568..86a4c21820 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -516,6 +516,7 @@ int ff_h2645_sei_to_frame(AVFrame *frame, H2645SEI *sei,
int seed)
{
H2645SEIFramePacking *fp = >frame_packing;
+int ret;
if (fp->present &&
is_frame_packing_type_valid(fp->arrangement_type, codec_id) &&
@@ -711,56 +712,63 @@ int ff_h2645_sei_to_frame(AVFrame *frame, H2645SEI *sei,
const int chroma_den = 5;
const int luma_den = 1;
int i;
-AVMasteringDisplayMetadata *metadata =
-av_mastering_display_metadata_create_side_data(frame);
-if (!metadata)
-return AVERROR(ENOMEM);
+AVMasteringDisplayMetadata *metadata;
-for (i = 0; i < 3; i++) {
-const int j = mapping[i];
-metadata->display_primaries[i][0].num =
sei->mastering_display.display_primaries[j][0];
-metadata->display_primaries[i][0].den = chroma_den;
-metadata->display_primaries[i][1].num =
sei->mastering_display.display_primaries[j][1];
-metadata->display_primaries[i][1].den = chroma_den;
+ret = ff_decode_mastering_display_new(avctx, frame, );
+if (ret < 0)
+return ret;
+
+if (metadata) {
+for (i = 0; i < 3; i++) {
+const int j = mapping[i];
+metadata->display_primaries[i][0].num =
sei->mastering_display.display_primaries[j][0];
+metadata->display_primaries[i][0].den = chroma_den;
+metadata->display_primaries[i][1].num =
sei->mastering_display.display_primaries[j][1];
+metadata->display_primaries[i][1].den = chroma_den;
+}
+metadata->white_point[0].num =
sei->mastering_display.white_point[0];
+metadata->white_point[0].den = chroma_den;
+
[FFmpeg-devel] [PATCH 19/38] avcodec/av1dec: respect side data preference
From: Niklas Haas --- libavcodec/av1dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c index 7debc4deda..4fcfed3c7b 100644 --- a/libavcodec/av1dec.c +++ b/libavcodec/av1dec.c @@ -946,7 +946,7 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame *frame, if (!ret) break; -if (!av_frame_new_side_data_from_buf(frame, AV_FRAME_DATA_A53_CC, buf)) +if (!ff_frame_new_side_data_from_buf(avctx, frame, AV_FRAME_DATA_A53_CC, buf)) av_buffer_unref(); avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS; -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 38/38] tests/fate/matroska: add tests for side data preference
Cf. #10857 --- tests/fate/matroska.mak | 6 + tests/ref/fate/matroska-side-data-pref-codec | 255 ++ tests/ref/fate/matroska-side-data-pref-global | 255 ++ 3 files changed, 516 insertions(+) create mode 100644 tests/ref/fate/matroska-side-data-pref-codec create mode 100644 tests/ref/fate/matroska-side-data-pref-global diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak index 9ab747184a..e9433ce730 100644 --- a/tests/fate/matroska.mak +++ b/tests/fate/matroska.mak @@ -264,6 +264,12 @@ FATE_MATROSKA_FFMPEG_FFPROBE-$(call REMUX, MATROSKA, VP9_PARSER) \ += fate-matroska-hdr10-plus-remux fate-matroska-hdr10-plus-remux: CMD = transcode webm $(TARGET_SAMPLES)/mkv/hdr10_plus_vp9_sample.webm matroska "-map 0 -c:v copy" "-map 0 -c:v copy" "-show_packets" +fate-matroska-side-data-pref-codec: CMD = run ffprobe$(PROGSSUF)$(EXESUF) $(TARGET_SAMPLES)/mkv/hdr10tags-both.mkv \ +-show_streams -show_frames -show_entries stream=stream_side_data:frame=frame_side_data_list +fate-matroska-side-data-pref-global: CMD = run ffprobe$(PROGSSUF)$(EXESUF) $(TARGET_SAMPLES)/mkv/hdr10tags-both.mkv \ +-show_streams -show_frames -show_entries stream=stream_side_data:frame=frame_side_data_list -side_data_prefer_global mastering_display_metadata,content_light_level +FATE_MATROSKA_FFPROBE-$(call ALLYES MATROSKA_DEMUXER HEVC_DECODER) += fate-matroska-side-data-pref-codec fate-matroska-side-data-pref-global + FATE_SAMPLES_AVCONV += $(FATE_MATROSKA-yes) FATE_SAMPLES_FFPROBE += $(FATE_MATROSKA_FFPROBE-yes) FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_MATROSKA_FFMPEG_FFPROBE-yes) diff --git a/tests/ref/fate/matroska-side-data-pref-codec b/tests/ref/fate/matroska-side-data-pref-codec new file mode 100644 index 00..d27134d0c9 --- /dev/null +++ b/tests/ref/fate/matroska-side-data-pref-codec @@ -0,0 +1,255 @@ +[FRAME] +[SIDE_DATA] +side_data_type=H.26[45] User Data Unregistered SEI message +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=300 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=35400/5 +red_y=14599/5 +green_x=8500/5 +green_y=39850/5 +blue_x=6550/5 +blue_y=2300/5 +white_point_x=15634/5 +white_point_y=16450/5 +min_luminance=10/1 +max_luminance=1000/1 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA]
[FFmpeg-devel] [PATCH 27/38] avcodec/pngdec: respect side data preference
From: Niklas Haas
---
libavcodec/pngdec.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 026da30c25..8f409c74b8 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -660,6 +660,7 @@ static int decode_phys_chunk(AVCodecContext *avctx,
PNGDecContext *s,
static int populate_avctx_color_fields(AVCodecContext *avctx, AVFrame *frame)
{
PNGDecContext *s = avctx->priv_data;
+int ret;
if (s->have_cicp) {
if (s->cicp_primaries >= AVCOL_PRI_NB)
@@ -678,11 +679,15 @@ static int populate_avctx_color_fields(AVCodecContext
*avctx, AVFrame *frame)
avctx->color_range = frame->color_range = AVCOL_RANGE_UNSPECIFIED;
}
} else if (s->iccp_data) {
-AVFrameSideData *sd = av_frame_new_side_data(frame,
AV_FRAME_DATA_ICC_PROFILE, s->iccp_data_len);
-if (!sd)
-return AVERROR(ENOMEM);
-memcpy(sd->data, s->iccp_data, s->iccp_data_len);
-av_dict_set(>metadata, "name", s->iccp_name, 0);
+AVFrameSideData *sd;
+ret = ff_frame_new_side_data(avctx, frame, AV_FRAME_DATA_ICC_PROFILE,
+ s->iccp_data_len, );
+if (ret < 0)
+return ret;
+if (sd) {
+memcpy(sd->data, s->iccp_data, s->iccp_data_len);
+av_dict_set(>metadata, "name", s->iccp_name, 0);
+}
} else if (s->have_srgb) {
avctx->color_primaries = frame->color_primaries = AVCOL_PRI_BT709;
avctx->color_trc = frame->color_trc = AVCOL_TRC_IEC61966_2_1;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 28/38] avcodec/tiff: respect side data preference
From: Niklas Haas --- libavcodec/tiff.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index 71cb703821..cb4d378753 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -1706,11 +1706,11 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame) if (bytestream2_get_bytes_left(_temp) < count) return AVERROR_INVALIDDATA; -sd = av_frame_new_side_data(frame, AV_FRAME_DATA_ICC_PROFILE, count); -if (!sd) -return AVERROR(ENOMEM); - -bytestream2_get_bufferu(_temp, sd->data, count); +ret = ff_frame_new_side_data(s->avctx, frame, AV_FRAME_DATA_ICC_PROFILE, count, ); +if (ret < 0) +return ret; +if (sd) +bytestream2_get_bufferu(_temp, sd->data, count); break; case TIFF_ARTIST: ADD_METADATA(count, "artist", NULL); -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 20/38] avcodec/cri: respect side data preference
From: Niklas Haas
This function was already ignoring OOM errors.
---
libavcodec/cri.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cri.c b/libavcodec/cri.c
index c4eb468610..990e52ac99 100644
--- a/libavcodec/cri.c
+++ b/libavcodec/cri.c
@@ -398,8 +398,8 @@ skip:
}
if (hflip || vflip) {
-rotation = av_frame_new_side_data(p, AV_FRAME_DATA_DISPLAYMATRIX,
- sizeof(int32_t) * 9);
+ff_frame_new_side_data(avctx, p, AV_FRAME_DATA_DISPLAYMATRIX,
+ sizeof(int32_t) * 9, );
if (rotation) {
av_display_rotation_set((int32_t *)rotation->data, 0.f);
av_display_matrix_flip((int32_t *)rotation->data, hflip, vflip);
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 31/38] avcodec/dpx: respect side data preference
From: Niklas Haas
If the time code side data is overridden by the packet level, we also
make sure not to update `p->metadata` to a mismatched timecode.
---
libavcodec/dpx.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 31e4a3f82c..80616d98a2 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -287,19 +287,21 @@ static int decode_frame(AVCodecContext *avctx, AVFrame *p,
tc = av_bswap32(read32(, endian));
if (i != 0x) {
-AVFrameSideData *tcside =
-av_frame_new_side_data(p, AV_FRAME_DATA_S12M_TIMECODE,
- sizeof(uint32_t) * 4);
-if (!tcside)
-return AVERROR(ENOMEM);
+AVFrameSideData *tcside;
+ret = ff_frame_new_side_data(avctx, p, AV_FRAME_DATA_S12M_TIMECODE,
+ sizeof(uint32_t) * 4, );
+if (ret < 0)
+return ret;
-tc_sd = (uint32_t*)tcside->data;
-tc_sd[0] = 1;
-tc_sd[1] = tc;
+if (tcside) {
+tc_sd = (uint32_t*)tcside->data;
+tc_sd[0] = 1;
+tc_sd[1] = tc;
-av_timecode_make_smpte_tc_string2(tcbuf, avctx->framerate,
- tc_sd[1], 0, 0);
-av_dict_set(>metadata, "timecode", tcbuf, 0);
+av_timecode_make_smpte_tc_string2(tcbuf, avctx->framerate,
+ tc_sd[1], 0, 0);
+av_dict_set(>metadata, "timecode", tcbuf, 0);
+}
}
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 14/38] lavu/opt: factor per-type dispatch out of av_opt_set()
Will be useful in following commits.
---
libavutil/opt.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 0ca6d4d555..ebc8063dc6 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -484,13 +484,11 @@ static int set_string_channel_layout(void *obj, const
AVOption *o,
return av_channel_layout_from_string(channel_layout, val);
}
-int av_opt_set(void *obj, const char *name, const char *val, int search_flags)
+static int opt_set_elem(void *obj, void *target_obj, const AVOption *o,
+const char *val, void *dst)
{
-int ret = 0;
-void *dst, *target_obj;
-const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
_obj);
-if (!o || !target_obj)
-return AVERROR_OPTION_NOT_FOUND;
+int ret;
+
FF_DISABLE_DEPRECATION_WARNINGS
if (!val && (o->type != AV_OPT_TYPE_STRING &&
o->type != AV_OPT_TYPE_PIXEL_FMT && o->type !=
AV_OPT_TYPE_SAMPLE_FMT &&
@@ -503,13 +501,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
return AVERROR(EINVAL);
FF_ENABLE_DEPRECATION_WARNINGS
-if (o->flags & AV_OPT_FLAG_READONLY)
-return AVERROR(EINVAL);
-
-if (o->flags & AV_OPT_FLAG_DEPRECATED)
-av_log(obj, AV_LOG_WARNING, "The \"%s\" option is deprecated: %s\n",
name, o->help);
-
-dst = ((uint8_t *)target_obj) + o->offset;
switch (o->type) {
case AV_OPT_TYPE_BOOL:
return set_string_bool(obj, o, val, dst);
@@ -589,6 +580,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
return AVERROR(EINVAL);
}
+int av_opt_set(void *obj, const char *name, const char *val, int search_flags)
+{
+void *dst, *target_obj;
+const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
_obj);
+if (!o || !target_obj)
+return AVERROR_OPTION_NOT_FOUND;
+
+if (o->flags & AV_OPT_FLAG_READONLY)
+return AVERROR(EINVAL);
+
+if (o->flags & AV_OPT_FLAG_DEPRECATED)
+av_log(obj, AV_LOG_WARNING, "The \"%s\" option is deprecated: %s\n",
name, o->help);
+
+dst = ((uint8_t *)target_obj) + o->offset;
+
+return opt_set_elem(obj, target_obj, o, val, dst);
+}
+
#define OPT_EVAL_NUMBER(name, opttype, vartype) \
int av_opt_eval_ ## name(void *obj, const AVOption *o, \
const char *val, vartype *name ## _out)\
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 32/38] avcodec/mpeg12dec: use ff_frame_new_side_data
From: Niklas Haas
For consistency, even though this cannot be overriden at the packet
level.
---
libavcodec/mpeg12dec.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 96987f5a8e..1038a08637 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2532,15 +2532,17 @@ static int mpeg_decode_frame(AVCodecContext *avctx,
AVFrame *picture,
if (s->timecode_frame_start != -1 && *got_output) {
char tcbuf[AV_TIMECODE_STR_SIZE];
-AVFrameSideData *tcside = av_frame_new_side_data(picture,
-
AV_FRAME_DATA_GOP_TIMECODE,
- sizeof(int64_t));
-if (!tcside)
-return AVERROR(ENOMEM);
-memcpy(tcside->data, >timecode_frame_start, sizeof(int64_t));
+AVFrameSideData *tcside;
+ret = ff_frame_new_side_data(avctx, picture,
AV_FRAME_DATA_GOP_TIMECODE,
+ sizeof(int64_t), );
+if (ret < 0)
+return ret;
+if (tcside) {
+memcpy(tcside->data, >timecode_frame_start,
sizeof(int64_t));
-av_timecode_make_mpeg_tc_string(tcbuf, s->timecode_frame_start);
-av_dict_set(>metadata, "timecode", tcbuf, 0);
+av_timecode_make_mpeg_tc_string(tcbuf,
s->timecode_frame_start);
+av_dict_set(>metadata, "timecode", tcbuf, 0);
+}
s->timecode_frame_start = -1;
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 29/38] avcodec/webp: respect side data preference
From: Niklas Haas
---
libavcodec/webp.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 54b3fde6dc..9308ea2b69 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1500,11 +1500,16 @@ exif_end:
"VP8X header\n");
s->has_iccp = 1;
-sd = av_frame_new_side_data(p, AV_FRAME_DATA_ICC_PROFILE,
chunk_size);
-if (!sd)
-return AVERROR(ENOMEM);
-bytestream2_get_buffer(, sd->data, chunk_size);
+ret = ff_frame_new_side_data(avctx, p, AV_FRAME_DATA_ICC_PROFILE,
chunk_size, );
+if (ret < 0)
+return ret;
+
+if (sd) {
+bytestream2_get_buffer(, sd->data, chunk_size);
+} else {
+bytestream2_skip(, chunk_size);
+}
break;
}
case MKTAG('A', 'N', 'I', 'M'):
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 22/38] lavc/hevcdec: pass an actual codec context to ff_h2645_sei_to_frame()
Needed by following commit. --- libavcodec/hevcdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c index b5311ae510..17c6a9212f 100644 --- a/libavcodec/hevcdec.c +++ b/libavcodec/hevcdec.c @@ -2778,7 +2778,7 @@ static int set_side_data(HEVCContext *s) s->sei.common.content_light.present--; } -ret = ff_h2645_sei_to_frame(out, >sei.common, AV_CODEC_ID_HEVC, NULL, +ret = ff_h2645_sei_to_frame(out, >sei.common, AV_CODEC_ID_HEVC, s->avctx, >ps.sps->vui.common, s->ps.sps->bit_depth, s->ps.sps->bit_depth_chroma, s->ref->poc /* no poc_offset in HEVC */); -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 30/38] avcodec/libdav1d: respect side data preference
From: Niklas Haas --- libavcodec/libdav1d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c index 78a5c63bf4..f002c994c1 100644 --- a/libavcodec/libdav1d.c +++ b/libavcodec/libdav1d.c @@ -561,7 +561,7 @@ FF_ENABLE_DEPRECATION_WARNINGS if (!res) break; -if (!av_frame_new_side_data_from_buf(frame, AV_FRAME_DATA_A53_CC, buf)) +if (!ff_frame_new_side_data_from_buf(c, frame, AV_FRAME_DATA_A53_CC, buf)) av_buffer_unref(); c->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS; -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 21/38] avcodec/h264_slice: respect side data preference
From: Niklas Haas
If the time code side data is overridden by the packet level, we also
make sure not to update `out->metadata` to a mismatched timecode.
---
libavcodec/h264_slice.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 8464a0b34c..f30ff33188 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1257,26 +1257,27 @@ static int h264_export_frame_props(H264Context *h)
if (h->sei.picture_timing.timecode_cnt > 0) {
uint32_t *tc_sd;
char tcbuf[AV_TIMECODE_STR_SIZE];
+AVFrameSideData *tcside;
+ret = ff_frame_new_side_data(h->avctx, out,
AV_FRAME_DATA_S12M_TIMECODE,
+ sizeof(uint32_t)*4, );
+if (ret < 0)
+return ret;
-AVFrameSideData *tcside = av_frame_new_side_data(out,
-
AV_FRAME_DATA_S12M_TIMECODE,
- sizeof(uint32_t)*4);
-if (!tcside)
-return AVERROR(ENOMEM);
+if (tcside) {
+tc_sd = (uint32_t*)tcside->data;
+tc_sd[0] = h->sei.picture_timing.timecode_cnt;
-tc_sd = (uint32_t*)tcside->data;
-tc_sd[0] = h->sei.picture_timing.timecode_cnt;
+for (int i = 0; i < tc_sd[0]; i++) {
+int drop = h->sei.picture_timing.timecode[i].dropframe;
+int hh = h->sei.picture_timing.timecode[i].hours;
+int mm = h->sei.picture_timing.timecode[i].minutes;
+int ss = h->sei.picture_timing.timecode[i].seconds;
+int ff = h->sei.picture_timing.timecode[i].frame;
-for (int i = 0; i < tc_sd[0]; i++) {
-int drop = h->sei.picture_timing.timecode[i].dropframe;
-int hh = h->sei.picture_timing.timecode[i].hours;
-int mm = h->sei.picture_timing.timecode[i].minutes;
-int ss = h->sei.picture_timing.timecode[i].seconds;
-int ff = h->sei.picture_timing.timecode[i].frame;
-
-tc_sd[i + 1] = av_timecode_get_smpte(h->avctx->framerate, drop,
hh, mm, ss, ff);
-av_timecode_make_smpte_tc_string2(tcbuf, h->avctx->framerate,
tc_sd[i + 1], 0, 0);
-av_dict_set(>metadata, "timecode", tcbuf, 0);
+tc_sd[i + 1] = av_timecode_get_smpte(h->avctx->framerate,
drop, hh, mm, ss, ff);
+av_timecode_make_smpte_tc_string2(tcbuf, h->avctx->framerate,
tc_sd[i + 1], 0, 0);
+av_dict_set(>metadata, "timecode", tcbuf, 0);
+}
}
h->sei.picture_timing.timecode_cnt = 0;
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 17/38] avcodec: add internal side data wrappers
From: Niklas Haas
The signature of ff_frame_new_side_data got more complicated due to
a need to distinguish between "failed allocating side data" and "side
data was already present".
We could do something similar to ff_frame_new_side_data_from_buf, but
most callers ignore the OOM condition on this function, which is merely
re-allocating the side data array. So preserve the return signature to
make it slightly less of a pain to use.
Signed-off-by: Anton Khirnov
---
libavcodec/decode.c | 47 +
libavcodec/decode.h | 20 +++
2 files changed, 67 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 5524e229c2..10946f208a 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1857,6 +1857,53 @@ int ff_decode_preinit(AVCodecContext *avctx)
return 0;
}
+/**
+ * Check side data preference and clear existing side data from frame
+ * if needed.
+ *
+ * @retval 0 side data of this type can be added to frame
+ * @retval 1 side data of this type should not be added to frame
+ */
+static int side_data_pref(const AVCodecContext *avctx, AVFrame *frame,
+ enum AVFrameSideDataType type)
+{
+DecodeContext *dc = decode_ctx(avctx->internal);
+
+// Note: could be skipped for `type` without corresponding packet sd
+if (av_frame_get_side_data(frame, type)) {
+if (dc->side_data_pref_mask & (1ULL << type))
+return 1;
+av_frame_remove_side_data(frame, type);
+}
+
+return 0;
+}
+
+
+int ff_frame_new_side_data(const AVCodecContext *avctx, AVFrame *frame,
+ enum AVFrameSideDataType type, size_t size,
+ AVFrameSideData **sd)
+{
+if (side_data_pref(avctx, frame, type)) {
+*sd = NULL;
+return 0;
+}
+
+*sd = av_frame_new_side_data(frame, type, size);
+return *sd ? 0 : AVERROR(ENOMEM);
+}
+
+AVFrameSideData *ff_frame_new_side_data_from_buf(const AVCodecContext *avctx,
+ AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
+{
+if (side_data_pref(avctx, frame, type))
+return NULL;
+
+return av_frame_new_side_data_from_buf(frame, type, buf);
+}
+
int ff_copy_palette(void *dst, const AVPacket *src, void *logctx)
{
size_t size;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index daf1a67444..a131b9940a 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -155,4 +155,24 @@ int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx,
void **hwaccel_picture_pr
const AVPacketSideData *ff_get_coded_side_data(const AVCodecContext *avctx,
enum AVPacketSideDataType type);
+/**
+ * Wrapper around av_frame_new_side_data, which rejects side data overridden by
+ * the demuxer. Returns 0 on success, and a negative error code otherwise.
+ * If successful, *sd may either be a pointer to the new side data, or NULL
+ * in case the side data was already present.
+ */
+int ff_frame_new_side_data(const AVCodecContext *avctx, AVFrame *frame,
+ enum AVFrameSideDataType type, size_t size,
+ AVFrameSideData **sd);
+
+/**
+ * Similar to `ff_frame_new_side_data`, but using an existing buffer ref.
+ * On success, returns the newly added side data, and passes ownership
+ * of `buf` to the frame.
+ */
+AVFrameSideData *ff_frame_new_side_data_from_buf(const AVCodecContext *avctx,
+ AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
#endif /* AVCODEC_DECODE_H */
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 33/38] avcodec/h2645_sei: use ff_frame_new_side_data_from_buf
From: Niklas Haas
For consistency, even though this cannot be overriden at the packet
level.
Signed-off-by: Anton Khirnov
---
libavcodec/h2645_sei.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index cb6be0594b..f3497d5568 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -35,6 +35,7 @@
#include "atsc_a53.h"
#include "avcodec.h"
+#include "decode.h"
#include "dynamic_hdr_vivid.h"
#include "get_bits.h"
#include "golomb.h"
@@ -607,7 +608,7 @@ int ff_h2645_sei_to_frame(AVFrame *frame, H2645SEI *sei,
H2645SEIUnregistered *unreg = >unregistered;
if (unreg->buf_ref[i]) {
-AVFrameSideData *sd = av_frame_new_side_data_from_buf(frame,
+AVFrameSideData *sd = ff_frame_new_side_data_from_buf(avctx, frame,
AV_FRAME_DATA_SEI_UNREGISTERED,
unreg->buf_ref[i]);
if (!sd)
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 24/38] avcodec/libjxldec: respect side data preference
From: Niklas Haas
Also fixes a memory leak where the side data was previously not properly
cleaned up on OOM, although we now unfortunately don't distinguish
between OOM and overriden side data.
Signed-off-by: Anton Khirnov
---
libavcodec/libjxldec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index b830eee784..e1dda99b73 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -483,9 +483,9 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
/* full image is one frame, even if animated */
av_log(avctx, AV_LOG_DEBUG, "FULL_IMAGE event emitted\n");
if (ctx->iccp) {
-AVFrameSideData *sd =
av_frame_new_side_data_from_buf(ctx->frame, AV_FRAME_DATA_ICC_PROFILE,
ctx->iccp);
+AVFrameSideData *sd = ff_frame_new_side_data_from_buf(avctx,
ctx->frame, AV_FRAME_DATA_ICC_PROFILE, ctx->iccp);
if (!sd)
-return AVERROR(ENOMEM);
+av_buffer_unref(>iccp);
/* ownership is transfered, and it is not ref-ed */
ctx->iccp = NULL;
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 18/38] lavc: add content light/mastering display side data wrappers
---
libavcodec/decode.c | 25 +
libavcodec/decode.h | 21 +
2 files changed, 46 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 10946f208a..ad5525860c 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -35,6 +35,7 @@
#include "libavutil/hwcontext.h"
#include "libavutil/imgutils.h"
#include "libavutil/internal.h"
+#include "libavutil/mastering_display_metadata.h"
#include "avcodec.h"
#include "avcodec_internal.h"
@@ -1904,6 +1905,30 @@ AVFrameSideData *ff_frame_new_side_data_from_buf(const
AVCodecContext *avctx,
return av_frame_new_side_data_from_buf(frame, type, buf);
}
+int ff_decode_mastering_display_new(const AVCodecContext *avctx, AVFrame
*frame,
+AVMasteringDisplayMetadata **mdm)
+{
+if (side_data_pref(avctx, frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA)) {
+*mdm = NULL;
+return 0;
+}
+
+*mdm = av_mastering_display_metadata_create_side_data(frame);
+return *mdm ? 0 : AVERROR(ENOMEM);
+}
+
+int ff_decode_content_light_new(const AVCodecContext *avctx, AVFrame *frame,
+AVContentLightMetadata **clm)
+{
+if (side_data_pref(avctx, frame, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL)) {
+*clm = NULL;
+return 0;
+}
+
+*clm = av_content_light_metadata_create_side_data(frame);
+return *clm ? 0 : AVERROR(ENOMEM);
+}
+
int ff_copy_palette(void *dst, const AVPacket *src, void *logctx)
{
size_t size;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index a131b9940a..b8df095532 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -175,4 +175,25 @@ AVFrameSideData *ff_frame_new_side_data_from_buf(const
AVCodecContext *avctx,
enum AVFrameSideDataType type,
AVBufferRef *buf);
+struct AVMasteringDisplayMetadata;
+struct AVContentLightMetadata;
+
+/**
+ * Wrapper around av_mastering_display_metadata_create_side_data(), which
+ * rejects side data overridden by the demuxer. Returns 0 on success, and a
+ * negative error code otherwise. If successful, *mdm may either be a pointer
to
+ * the new side data, or NULL in case the side data was already present.
+ */
+int ff_decode_mastering_display_new(const AVCodecContext *avctx, AVFrame
*frame,
+struct AVMasteringDisplayMetadata **mdm);
+
+/**
+ * Wrapper around av_content_light_metadata_create_side_data(), which
+ * rejects side data overridden by the demuxer. Returns 0 on success, and a
+ * negative error code otherwise. If successful, *clm may either be a pointer
to
+ * the new side data, or NULL in case the side data was already present.
+ */
+int ff_decode_content_light_new(const AVCodecContext *avctx, AVFrame *frame,
+struct AVContentLightMetadata **clm);
+
#endif /* AVCODEC_DECODE_H */
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 16/38] lavc: add a decoder option for configuring side data preference
This and the following commits fix #10857
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 20
libavcodec/decode.c| 36
libavcodec/options_table.h | 12
4 files changed, 71 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 371fd2f465..78744a674a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavc 60.xx.100 - avcodec.h
+ Add AVCodecContext.[nb_]side_data_prefer_global.
+
2024-02-xx - xx - lavu 58.xx.100 - opt.h
Add AV_OPT_FLAG_ARRAY and AVOption.array_max_size.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..307a3e99db 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2120,6 +2120,26 @@ typedef struct AVCodecContext {
* an error.
*/
int64_t frame_num;
+
+/**
+ * Decoding only. May be set by the caller before avcodec_open2() to an
+ * av_malloc()'ed array (or via AVOptions). Owned and freed by the decoder
+ * afterwards.
+ *
+ * By default, when some side data type is present both in global
+ * user-supplied coded_side_data and inside the coded bitstream, avcodec
+ * will propagate the latter to the decoded frame.
+ *
+ * This array contains a list of AVPacketSideDataType for which this
+ * preference should be switched, i.e. avcodec will prefer global side data
+ * over those in stored in the bytestream. It may also contain a single -1,
+ * in which case the preference is switched for all side data types.
+ */
+int*side_data_prefer_global;
+/**
+ * Number of entries in side_data_prefer_global.
+ */
+unsigned nb_side_data_prefer_global;
} AVCodecContext;
/**
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index da6446d879..5524e229c2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -60,6 +60,12 @@ typedef struct DecodeContext {
* The caller has submitted a NULL packet on input.
*/
int draining_started;
+
+/**
+ * Bitmask indicating for which side data types we prefer global
+ * side data over per-packet.
+ */
+uint64_t side_data_pref_mask;
} DecodeContext;
static DecodeContext *decode_ctx(AVCodecInternal *avci)
@@ -1744,6 +1750,7 @@ int ff_reget_buffer(AVCodecContext *avctx, AVFrame
*frame, int flags)
int ff_decode_preinit(AVCodecContext *avctx)
{
AVCodecInternal *avci = avctx->internal;
+DecodeContext *dc = decode_ctx(avci);
int ret = 0;
/* if the decoder init function was already called previously,
@@ -1804,6 +1811,35 @@ int ff_decode_preinit(AVCodecContext *avctx)
avctx->export_side_data |= AV_CODEC_EXPORT_DATA_MVS;
}
+if (avctx->nb_side_data_prefer_global == 1 &&
+avctx->side_data_prefer_global[0] == -1)
+dc->side_data_pref_mask = ~0ULL;
+else {
+for (unsigned i = 0; i < avctx->nb_side_data_prefer_global; i++) {
+int val = avctx->side_data_prefer_global[i];
+
+if (val < 0 || val >= AV_PKT_DATA_NB) {
+av_log(avctx, AV_LOG_ERROR, "Invalid side data type: %d\n",
val);
+return AVERROR(EINVAL);
+}
+
+for (unsigned j = 0; j < FF_ARRAY_ELEMS(sd_global_map); j++) {
+if (sd_global_map[j].packet == val) {
+val = sd_global_map[j].frame;
+
+// this code will need to be changed when we have more than
+// 64 frame side data types
+if (val >= 64) {
+av_log(avctx, AV_LOG_ERROR, "Side data type too
big\n");
+return AVERROR_BUG;
+}
+
+dc->side_data_pref_mask |= 1ULL << val;
+}
+}
+}
+}
+
avci->in_pkt = av_packet_alloc();
avci->last_pkt_props = av_packet_alloc();
if (!avci->in_pkt || !avci->last_pkt_props)
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index ac32d8928a..2f4f60218c 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -41,6 +41,7 @@
#define E AV_OPT_FLAG_ENCODING_PARAM
#define D AV_OPT_FLAG_DECODING_PARAM
#define CC AV_OPT_FLAG_CHILD_CONSTS
+#define AR AV_OPT_FLAG_ARRAY
#define AV_CODEC_DEFAULT_BITRATE 200*1000
@@ -405,6 +406,17 @@ static const AVOption avcodec_options[] = {
{"unsafe_output", "allow potentially unsafe hwaccel frame output that might
require special care to process successfully", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_HWACCEL_FLAG_UNSAFE_OUTPUT }, INT_MIN, INT_MAX, V | D, .unit =
"hwaccel_flags"},
{"extra_hw_frames", "Number of extra hardware frames to allocate for the
user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
V|D },
[FFmpeg-devel] [PATCH 26/38] avcodec/mpeg12dec: respect side data preference
From: Niklas Haas
We only need to consider side data types that may possibly come from the
packet.
---
libavcodec/mpeg12dec.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index d07eed8744..96987f5a8e 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1306,16 +1306,17 @@ static int mpeg_field_start(MpegEncContext *s, const
uint8_t *buf, int buf_size)
}
}
-pan_scan = av_frame_new_side_data(s->current_picture_ptr->f,
- AV_FRAME_DATA_PANSCAN,
- sizeof(s1->pan_scan));
-if (!pan_scan)
-return AVERROR(ENOMEM);
-memcpy(pan_scan->data, >pan_scan, sizeof(s1->pan_scan));
+ret = ff_frame_new_side_data(s->avctx, s->current_picture_ptr->f,
+ AV_FRAME_DATA_PANSCAN,
sizeof(s1->pan_scan),
+ _scan);
+if (ret < 0)
+return ret;
+if (pan_scan)
+memcpy(pan_scan->data, >pan_scan, sizeof(s1->pan_scan));
if (s1->a53_buf_ref) {
-AVFrameSideData *sd = av_frame_new_side_data_from_buf(
-s->current_picture_ptr->f, AV_FRAME_DATA_A53_CC,
+AVFrameSideData *sd = ff_frame_new_side_data_from_buf(
+s->avctx, s->current_picture_ptr->f, AV_FRAME_DATA_A53_CC,
s1->a53_buf_ref);
if (!sd)
av_buffer_unref(>a53_buf_ref);
@@ -1332,13 +1333,13 @@ static int mpeg_field_start(MpegEncContext *s, const
uint8_t *buf, int buf_size)
}
if (s1->has_afd) {
-AVFrameSideData *sd =
-av_frame_new_side_data(s->current_picture_ptr->f,
- AV_FRAME_DATA_AFD, 1);
-if (!sd)
-return AVERROR(ENOMEM);
-
-*sd->data = s1->afd;
+AVFrameSideData *sd;
+ret = ff_frame_new_side_data(s->avctx, s->current_picture_ptr->f,
+ AV_FRAME_DATA_AFD, 1, );
+if (ret < 0)
+return ret;
+if (sd)
+*sd->data = s1->afd;
s1->has_afd = 0;
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 23/38] avcodec/hevcdec: respect side data preference
From: Niklas Haas
If the time code side data is overridden by the packet level, we also
make sure not to update `out->metadata` to a mismatched timecode.
For HDR side data, we unfortunately need to omit a return check because
the new function does not distinguish between OOM and overridden side
data.
---
libavcodec/hevcdec.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 17c6a9212f..0cb2577b39 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2788,24 +2788,27 @@ static int set_side_data(HEVCContext *s)
if (s->sei.timecode.present) {
uint32_t *tc_sd;
char tcbuf[AV_TIMECODE_STR_SIZE];
-AVFrameSideData *tcside = av_frame_new_side_data(out,
AV_FRAME_DATA_S12M_TIMECODE,
- sizeof(uint32_t) * 4);
-if (!tcside)
-return AVERROR(ENOMEM);
+AVFrameSideData *tcside;
+ret = ff_frame_new_side_data(s->avctx, out,
AV_FRAME_DATA_S12M_TIMECODE,
+ sizeof(uint32_t) * 4, );
+if (ret < 0)
+return ret;
-tc_sd = (uint32_t*)tcside->data;
-tc_sd[0] = s->sei.timecode.num_clock_ts;
+if (tcside) {
+tc_sd = (uint32_t*)tcside->data;
+tc_sd[0] = s->sei.timecode.num_clock_ts;
-for (int i = 0; i < tc_sd[0]; i++) {
-int drop = s->sei.timecode.cnt_dropped_flag[i];
-int hh = s->sei.timecode.hours_value[i];
-int mm = s->sei.timecode.minutes_value[i];
-int ss = s->sei.timecode.seconds_value[i];
-int ff = s->sei.timecode.n_frames[i];
+for (int i = 0; i < tc_sd[0]; i++) {
+int drop = s->sei.timecode.cnt_dropped_flag[i];
+int hh = s->sei.timecode.hours_value[i];
+int mm = s->sei.timecode.minutes_value[i];
+int ss = s->sei.timecode.seconds_value[i];
+int ff = s->sei.timecode.n_frames[i];
-tc_sd[i + 1] = av_timecode_get_smpte(s->avctx->framerate, drop,
hh, mm, ss, ff);
-av_timecode_make_smpte_tc_string2(tcbuf, s->avctx->framerate,
tc_sd[i + 1], 0, 0);
-av_dict_set(>metadata, "timecode", tcbuf, 0);
+tc_sd[i + 1] = av_timecode_get_smpte(s->avctx->framerate,
drop, hh, mm, ss, ff);
+av_timecode_make_smpte_tc_string2(tcbuf, s->avctx->framerate,
tc_sd[i + 1], 0, 0);
+av_dict_set(>metadata, "timecode", tcbuf, 0);
+}
}
s->sei.timecode.num_clock_ts = 0;
@@ -2816,10 +2819,8 @@ static int set_side_data(HEVCContext *s)
if (!info_ref)
return AVERROR(ENOMEM);
-if (!av_frame_new_side_data_from_buf(out,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS, info_ref)) {
+if (!ff_frame_new_side_data_from_buf(s->avctx, out,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS, info_ref))
av_buffer_unref(_ref);
-return AVERROR(ENOMEM);
-}
}
if (s->rpu_buf) {
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 36/38] avcodec/hevcdec: switch to ff_frame_new_side_data_from_buf
From: Niklas Haas
For consistency, even though this cannot be overriden at the packet
level.
---
libavcodec/hevcdec.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 0cb2577b39..e5213aa252 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2824,10 +2824,8 @@ static int set_side_data(HEVCContext *s)
}
if (s->rpu_buf) {
-AVFrameSideData *rpu = av_frame_new_side_data_from_buf(out,
AV_FRAME_DATA_DOVI_RPU_BUFFER, s->rpu_buf);
-if (!rpu)
-return AVERROR(ENOMEM);
-
+if (!ff_frame_new_side_data_from_buf(s->avctx, out,
AV_FRAME_DATA_DOVI_RPU_BUFFER, s->rpu_buf))
+av_buffer_unref(>rpu_buf);
s->rpu_buf = NULL;
}
@@ -2839,10 +2837,8 @@ static int set_side_data(HEVCContext *s)
if (!info_ref)
return AVERROR(ENOMEM);
-if (!av_frame_new_side_data_from_buf(out,
AV_FRAME_DATA_DYNAMIC_HDR_VIVID, info_ref)) {
+if (!ff_frame_new_side_data_from_buf(s->avctx, out,
AV_FRAME_DATA_DYNAMIC_HDR_VIVID, info_ref))
av_buffer_unref(_ref);
-return AVERROR(ENOMEM);
-}
}
return 0;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 13/38] lavu/opt: factor per-type dispatch out of av_opt_get()
Will be useful in following commits.
---
libavutil/opt.c | 220 ++--
1 file changed, 121 insertions(+), 99 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 8ee89237c5..0ca6d4d555 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -834,13 +834,123 @@ static void format_duration(char *buf, size_t size,
int64_t d)
*(--e) = 0;
}
+static int opt_get_elem(const AVOption *o, uint8_t **pbuf, size_t buf_len,
+void *dst, int search_flags)
+{
+int ret;
+
+switch (o->type) {
+case AV_OPT_TYPE_BOOL:
+ret = snprintf(*pbuf, buf_len, "%s", get_bool_name(*(int *)dst));
+break;
+case AV_OPT_TYPE_FLAGS:
+ret = snprintf(*pbuf, buf_len, "0x%08X", *(int *)dst);
+break;
+case AV_OPT_TYPE_INT:
+ret = snprintf(*pbuf, buf_len, "%d", *(int *)dst);
+break;
+case AV_OPT_TYPE_INT64:
+ret = snprintf(*pbuf, buf_len, "%"PRId64, *(int64_t *)dst);
+break;
+case AV_OPT_TYPE_UINT64:
+ret = snprintf(*pbuf, buf_len, "%"PRIu64, *(uint64_t *)dst);
+break;
+case AV_OPT_TYPE_FLOAT:
+ret = snprintf(*pbuf, buf_len, "%f", *(float *)dst);
+break;
+case AV_OPT_TYPE_DOUBLE:
+ret = snprintf(*pbuf, buf_len, "%f", *(double *)dst);
+break;
+case AV_OPT_TYPE_VIDEO_RATE:
+case AV_OPT_TYPE_RATIONAL:
+ret = snprintf(*pbuf, buf_len, "%d/%d", ((AVRational *)dst)->num,
((AVRational *)dst)->den);
+break;
+case AV_OPT_TYPE_CONST:
+ret = snprintf(*pbuf, buf_len, "%"PRId64, o->default_val.i64);
+break;
+case AV_OPT_TYPE_STRING:
+if (*(uint8_t **)dst) {
+*pbuf = av_strdup(*(uint8_t **)dst);
+} else if (search_flags & AV_OPT_ALLOW_NULL) {
+*pbuf = NULL;
+return 0;
+} else {
+*pbuf = av_strdup("");
+}
+return *pbuf ? 0 : AVERROR(ENOMEM);
+case AV_OPT_TYPE_BINARY: {
+const uint8_t *bin;
+int len;
+
+if (!*(uint8_t **)dst && (search_flags & AV_OPT_ALLOW_NULL)) {
+*pbuf = NULL;
+return 0;
+}
+len = *(int *)(((uint8_t *)dst) + sizeof(uint8_t *));
+if ((uint64_t)len * 2 + 1 > INT_MAX)
+return AVERROR(EINVAL);
+if (!(*pbuf = av_malloc(len * 2 + 1)))
+return AVERROR(ENOMEM);
+if (!len) {
+*pbuf[0] = '\0';
+return 0;
+}
+bin = *(uint8_t **)dst;
+for (int i = 0; i < len; i++)
+snprintf(*pbuf + i * 2, 3, "%02X", bin[i]);
+return 0;
+}
+case AV_OPT_TYPE_IMAGE_SIZE:
+ret = snprintf(*pbuf, buf_len, "%dx%d", ((int *)dst)[0], ((int
*)dst)[1]);
+break;
+case AV_OPT_TYPE_PIXEL_FMT:
+ret = snprintf(*pbuf, buf_len, "%s", (char
*)av_x_if_null(av_get_pix_fmt_name(*(enum AVPixelFormat *)dst), "none"));
+break;
+case AV_OPT_TYPE_SAMPLE_FMT:
+ret = snprintf(*pbuf, buf_len, "%s", (char
*)av_x_if_null(av_get_sample_fmt_name(*(enum AVSampleFormat *)dst), "none"));
+break;
+case AV_OPT_TYPE_DURATION: {
+int64_t i64 = *(int64_t *)dst;
+format_duration(*pbuf, buf_len, i64);
+ret = strlen(*pbuf); // no overflow possible, checked by an assert
+break;
+}
+case AV_OPT_TYPE_COLOR:
+ret = snprintf(*pbuf, buf_len, "0x%02x%02x%02x%02x",
+ (int)((uint8_t *)dst)[0], (int)((uint8_t *)dst)[1],
+ (int)((uint8_t *)dst)[2], (int)((uint8_t *)dst)[3]);
+break;
+#if FF_API_OLD_CHANNEL_LAYOUT
+FF_DISABLE_DEPRECATION_WARNINGS
+case AV_OPT_TYPE_CHANNEL_LAYOUT: {
+int64_t i64 = *(int64_t *)dst;
+ret = snprintf(*pbuf, buf_len, "0x%"PRIx64, i64);
+break;
+}
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+case AV_OPT_TYPE_CHLAYOUT:
+ret = av_channel_layout_describe(dst, *pbuf, buf_len);
+break;
+case AV_OPT_TYPE_DICT:
+if (!*(AVDictionary **)dst && (search_flags & AV_OPT_ALLOW_NULL)) {
+*pbuf = NULL;
+return 0;
+}
+return av_dict_get_string(*(AVDictionary **)dst, (char **)pbuf, '=',
':');
+default:
+return AVERROR(EINVAL);
+}
+
+return ret;
+}
+
int av_opt_get(void *obj, const char *name, int search_flags, uint8_t
**out_val)
{
void *dst, *target_obj;
const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
_obj);
-uint8_t *bin, buf[128];
-int len, i, ret;
-int64_t i64;
+uint8_t *out, buf[128];
+int ret;
if (!o || !target_obj || (o->offset<=0 && o->type != AV_OPT_TYPE_CONST))
return AVERROR_OPTION_NOT_FOUND;
@@ -851,107 +961,19 @@ int av_opt_get(void *obj, const char *name, int
search_flags, uint8_t **out_val)
dst = (uint8_t *)target_obj + o->offset;
buf[0] = 0;
-switch (o->type) {
-case
[FFmpeg-devel] [PATCH 25/38] avcodec/mjpegdec: respect side data preference
From: Niklas Haas
---
libavcodec/mjpegdec.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 81f724d230..43b36d0a8f 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2840,16 +2840,18 @@ the_end:
for (i = 0; i < s->iccnum; i++)
total_size += s->iccentries[i].length;
-sd = av_frame_new_side_data(frame, AV_FRAME_DATA_ICC_PROFILE,
total_size);
-if (!sd) {
+ret = ff_frame_new_side_data(avctx, frame, AV_FRAME_DATA_ICC_PROFILE,
total_size, );
+if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Could not allocate frame side
data\n");
-return AVERROR(ENOMEM);
+return ret;
}
-/* Reassemble the parts, which are now in-order. */
-for (i = 0; i < s->iccnum; i++) {
-memcpy(sd->data + offset, s->iccentries[i].data,
s->iccentries[i].length);
-offset += s->iccentries[i].length;
+if (sd) {
+/* Reassemble the parts, which are now in-order. */
+for (i = 0; i < s->iccnum; i++) {
+memcpy(sd->data + offset, s->iccentries[i].data,
s->iccentries[i].length);
+offset += s->iccentries[i].length;
+}
}
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 12/38] lavu/opt: get rid of useless read_number() calls
The option type is known and fixed for all these, so reading the value
directly is simpler and more clear.
---
libavutil/opt.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 75a27c4d9b..8ee89237c5 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -313,7 +313,7 @@ static int set_string_number(void *obj, void *target_obj,
const AVOption *o, con
}
}
if (o->type == AV_OPT_TYPE_FLAGS) {
-read_number(o, dst, NULL, NULL, );
+intnum = *(unsigned int*)dst;
if (cmd == '+')
d = intnum | (int64_t)d;
else if (cmd == '-')
@@ -2025,8 +2025,7 @@ void av_opt_freep_ranges(AVOptionRanges **rangesp)
int av_opt_is_set_to_default(void *obj, const AVOption *o)
{
int64_t i64;
-double d, d2;
-float f;
+double d;
AVRational q;
int ret, w, h;
char *str;
@@ -2071,13 +2070,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
return 0;
return !strcmp(str, o->default_val.str);
case AV_OPT_TYPE_DOUBLE:
-read_number(o, dst, , NULL, NULL);
+d = *(double *)dst;
return o->default_val.dbl == d;
case AV_OPT_TYPE_FLOAT:
-read_number(o, dst, , NULL, NULL);
-f = o->default_val.dbl;
-d2 = f;
-return d2 == d;
+d = *(float *)dst;
+return (float)o->default_val.dbl == d;
case AV_OPT_TYPE_RATIONAL:
q = av_d2q(o->default_val.dbl, INT_MAX);
return !av_cmp_q(*(AVRational*)dst, q);
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 06/38] lavu/opt: cosmetics, group option reading function together
---
libavutil/opt.h | 82 +++--
1 file changed, 46 insertions(+), 36 deletions(-)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 6ed19888a5..e34b8506f8 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -755,6 +755,11 @@ int av_opt_set_dict_val(void *obj, const char *name, const
AVDictionary *val, in
* @}
*/
+/**
+ * @defgroup opt_read Reading option values
+ * @{
+ */
+
/**
* @defgroup opt_get_funcs Option getting functions
* @{
@@ -831,42 +836,6 @@ int av_opt_eval_q (void *obj, const AVOption *o, const
char *val, AVRational
*/
void *av_opt_ptr(const AVClass *avclass, void *obj, const char *name);
-/**
- * Free an AVOptionRanges struct and set it to NULL.
- */
-void av_opt_freep_ranges(AVOptionRanges **ranges);
-
-/**
- * Get a list of allowed ranges for the given option.
- *
- * The returned list may depend on other fields in obj like for example
profile.
- *
- * @param flags is a bitmask of flags, undefined flags should not be set and
should be ignored
- * AV_OPT_SEARCH_FAKE_OBJ indicates that the obj is a double
pointer to a AVClass instead of a full instance
- * AV_OPT_MULTI_COMPONENT_RANGE indicates that function may
return more than one component, @see AVOptionRanges
- *
- * The result must be freed with av_opt_freep_ranges.
- *
- * @return number of compontents returned on success, a negative errro code
otherwise
- */
-int av_opt_query_ranges(AVOptionRanges **, void *obj, const char *key, int
flags);
-
-/**
- * Get a default list of allowed ranges for the given option.
- *
- * This list is constructed without using the AVClass.query_ranges() callback
- * and can be used as fallback from within the callback.
- *
- * @param flags is a bitmask of flags, undefined flags should not be set and
should be ignored
- * AV_OPT_SEARCH_FAKE_OBJ indicates that the obj is a double
pointer to a AVClass instead of a full instance
- * AV_OPT_MULTI_COMPONENT_RANGE indicates that function may
return more than one component, @see AVOptionRanges
- *
- * The result must be freed with av_opt_free_ranges.
- *
- * @return number of compontents returned on success, a negative errro code
otherwise
- */
-int av_opt_query_ranges_default(AVOptionRanges **, void *obj, const char *key,
int flags);
-
/**
* Check if given option is set to its default value.
*
@@ -926,6 +895,47 @@ int av_opt_flag_is_set(void *obj, const char *field_name,
const char *flag_name)
*/
int av_opt_serialize(void *obj, int opt_flags, int flags, char **buffer,
const char key_val_sep, const char pairs_sep);
+
+/**
+ * @}
+ */
+
+/**
+ * Free an AVOptionRanges struct and set it to NULL.
+ */
+void av_opt_freep_ranges(AVOptionRanges **ranges);
+
+/**
+ * Get a list of allowed ranges for the given option.
+ *
+ * The returned list may depend on other fields in obj like for example
profile.
+ *
+ * @param flags is a bitmask of flags, undefined flags should not be set and
should be ignored
+ * AV_OPT_SEARCH_FAKE_OBJ indicates that the obj is a double
pointer to a AVClass instead of a full instance
+ * AV_OPT_MULTI_COMPONENT_RANGE indicates that function may
return more than one component, @see AVOptionRanges
+ *
+ * The result must be freed with av_opt_freep_ranges.
+ *
+ * @return number of compontents returned on success, a negative errro code
otherwise
+ */
+int av_opt_query_ranges(AVOptionRanges **, void *obj, const char *key, int
flags);
+
+/**
+ * Get a default list of allowed ranges for the given option.
+ *
+ * This list is constructed without using the AVClass.query_ranges() callback
+ * and can be used as fallback from within the callback.
+ *
+ * @param flags is a bitmask of flags, undefined flags should not be set and
should be ignored
+ * AV_OPT_SEARCH_FAKE_OBJ indicates that the obj is a double
pointer to a AVClass instead of a full instance
+ * AV_OPT_MULTI_COMPONENT_RANGE indicates that function may
return more than one component, @see AVOptionRanges
+ *
+ * The result must be freed with av_opt_free_ranges.
+ *
+ * @return number of compontents returned on success, a negative errro code
otherwise
+ */
+int av_opt_query_ranges_default(AVOptionRanges **, void *obj, const char *key,
int flags);
+
/**
* @}
*/
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 09/38] lavu/opt: drop useless handling of NULL return from get_bool_name()
That function always returns an actual string.
---
libavutil/opt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 49b7da7742..0ffdfc9a1e 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -853,7 +853,7 @@ int av_opt_get(void *obj, const char *name, int
search_flags, uint8_t **out_val)
buf[0] = 0;
switch (o->type) {
case AV_OPT_TYPE_BOOL:
-ret = snprintf(buf, sizeof(buf), "%s", (char
*)av_x_if_null(get_bool_name(*(int *)dst), "invalid"));
+ret = snprintf(buf, sizeof(buf), "%s", get_bool_name(*(int *)dst));
break;
case AV_OPT_TYPE_FLAGS:
ret = snprintf(buf, sizeof(buf), "0x%08X", *(int *)dst);
@@ -1282,7 +1282,7 @@ static void log_default(void *obj, void *av_log_obj,
const AVOption *opt)
av_log(av_log_obj, AV_LOG_INFO, " (default ");
switch (opt->type) {
case AV_OPT_TYPE_BOOL:
-av_log(av_log_obj, AV_LOG_INFO, "%s", (char
*)av_x_if_null(get_bool_name(opt->default_val.i64), "invalid"));
+av_log(av_log_obj, AV_LOG_INFO, "%s",
get_bool_name(opt->default_val.i64));
break;
case AV_OPT_TYPE_FLAGS: {
char *def_flags = get_opt_flags_string(obj, opt->unit,
opt->default_val.i64);
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 15/38] lavu/opt: add array options
AVOption.array_max_size is added before AVOption.unit to avoid
increasing sizeof(AVOption).
---
doc/APIchanges| 3 +
libavutil/opt.c | 344 --
libavutil/opt.h | 26
libavutil/tests/opt.c | 34 +
tests/ref/fate/opt| 23 ++-
5 files changed, 385 insertions(+), 45 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index d26110b285..371fd2f465 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavu 58.xx.100 - opt.h
+ Add AV_OPT_FLAG_ARRAY and AVOption.array_max_size.
+
2024-02-21 - xx - lavc 60.40.100 - avcodec.h
Deprecate AV_INPUT_BUFFER_MIN_SIZE without replacement.
diff --git a/libavutil/opt.c b/libavutil/opt.c
index ebc8063dc6..88236660a1 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -56,6 +56,77 @@ const AVOption *av_opt_next(const void *obj, const AVOption
*last)
return NULL;
}
+static const size_t opt_elem_size[] = {
+[AV_OPT_TYPE_FLAGS] = sizeof(unsigned),
+[AV_OPT_TYPE_INT] = sizeof(int),
+[AV_OPT_TYPE_INT64] = sizeof(int64_t),
+[AV_OPT_TYPE_UINT64]= sizeof(uint64_t),
+[AV_OPT_TYPE_DOUBLE]= sizeof(double),
+[AV_OPT_TYPE_FLOAT] = sizeof(float),
+[AV_OPT_TYPE_STRING]= sizeof(char *),
+[AV_OPT_TYPE_RATIONAL] = sizeof(AVRational),
+[AV_OPT_TYPE_BINARY]= sizeof(uint8_t *),
+[AV_OPT_TYPE_DICT] = sizeof(AVDictionary *),
+[AV_OPT_TYPE_IMAGE_SIZE]= sizeof(int[2]),
+[AV_OPT_TYPE_VIDEO_RATE]= sizeof(AVRational),
+[AV_OPT_TYPE_PIXEL_FMT] = sizeof(int),
+[AV_OPT_TYPE_SAMPLE_FMT]= sizeof(int),
+[AV_OPT_TYPE_DURATION] = sizeof(int64_t),
+[AV_OPT_TYPE_COLOR] = sizeof(uint8_t[4]),
+#if FF_API_OLD_CHANNEL_LAYOUT
+[AV_OPT_TYPE_CHANNEL_LAYOUT]= sizeof(uint64_t),
+#endif
+[AV_OPT_TYPE_CHLAYOUT] = sizeof(AVChannelLayout),
+[AV_OPT_TYPE_BOOL] = sizeof(int),
+};
+
+static uint8_t opt_array_sep(const AVOption *o)
+{
+av_assert1(o->flags & AV_OPT_FLAG_ARRAY);
+return o->default_val.str ? o->default_val.str[0] : ',';
+}
+
+static void *opt_array_pelem(const AVOption *o, void *array, unsigned idx)
+{
+av_assert1(o->flags & AV_OPT_FLAG_ARRAY);
+return (uint8_t *)array + idx * opt_elem_size[o->type];
+}
+
+static unsigned *opt_array_pcount(void *parray)
+{
+return (unsigned *)((void **)parray + 1);
+}
+
+static void opt_free_elem(const AVOption *o, void *ptr)
+{
+switch (o->type) {
+case AV_OPT_TYPE_STRING:
+case AV_OPT_TYPE_BINARY:
+av_freep(ptr);
+break;
+
+case AV_OPT_TYPE_DICT:
+av_dict_free((AVDictionary **)ptr);
+break;
+
+case AV_OPT_TYPE_CHLAYOUT:
+av_channel_layout_uninit((AVChannelLayout *)ptr);
+break;
+
+default:
+break;
+}
+}
+
+static void opt_free_array(const AVOption *o, void *parray, unsigned *count)
+{
+for (unsigned i = 0; i < *count; i++)
+opt_free_elem(o, opt_array_pelem(o, *(void **)parray, i));
+
+av_freep(parray);
+*count = 0;
+}
+
static int read_number(const AVOption *o, const void *dst, double *num, int
*den, int64_t *intnum)
{
switch (o->type) {
@@ -580,6 +651,76 @@ FF_ENABLE_DEPRECATION_WARNINGS
return AVERROR(EINVAL);
}
+static int opt_set_array(void *obj, void *target_obj, const AVOption *o,
+ const char *val, void *dst)
+{
+const size_t elem_size = opt_elem_size[o->type];
+const uint8_t sep = opt_array_sep(o);
+uint8_t *str = NULL;
+
+void *elems = NULL;
+unsigned nb_elems = 0;
+int ret;
+
+if (val && *val) {
+str = av_malloc(strlen(val) + 1);
+if (!str)
+return AVERROR(ENOMEM);
+}
+
+// split and unescape the string
+while (val && *val) {
+uint8_t *p = str;
+void *tmp;
+
+if (o->array_max_size && nb_elems >= o->array_max_size) {
+av_log(obj, AV_LOG_ERROR,
+ "Cannot assign more than %u elements to array option %s\n",
+ o->array_max_size, o->name);
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+for (; *val; val++, p++) {
+if (*val == '\\' && val[1])
+val++;
+else if (*val == sep) {
+val++;
+break;
+}
+*p = *val;
+}
+*p = 0;
+
+tmp = av_realloc_array(elems, nb_elems + 1, elem_size);
+if (!tmp) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+elems = tmp;
+
+tmp = opt_array_pelem(o, elems, nb_elems);
+memset(tmp, 0, elem_size);
+
+ret = opt_set_elem(obj, target_obj, o, str, tmp);
+if (ret < 0)
+
[FFmpeg-devel] [PATCH 11/38] lavu/opt: simplify error handling in get_number()
--- libavutil/opt.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/libavutil/opt.c b/libavutil/opt.c index 54a99c689c..75a27c4d9b 100644 --- a/libavutil/opt.c +++ b/libavutil/opt.c @@ -961,16 +961,11 @@ static int get_number(void *obj, const char *name, double *num, int *den, int64_ void *dst, *target_obj; const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags, _obj); if (!o || !target_obj) -goto error; +return AVERROR_OPTION_NOT_FOUND; dst = ((uint8_t *)target_obj) + o->offset; return read_number(o, dst, num, den, intnum); - -error: -*den= -*intnum = 0; -return -1; } int av_opt_get_int(void *obj, const char *name, int search_flags, int64_t *out_val) -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 05/38] lavu/opt: cosmetics, group option setting function together
---
libavutil/opt.h | 102 +---
1 file changed, 54 insertions(+), 48 deletions(-)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index e2b6ba1f35..6ed19888a5 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -576,6 +576,11 @@ enum {
* @}
*/
+/**
+ * @defgroup opt_write Setting and modifying option values
+ * @{
+ */
+
/**
* Parse the key/value pairs list in opts. For each key/value pair
* found, stores the value in the field in ctx that is named like the
@@ -627,16 +632,6 @@ int av_opt_set_from_string(void *ctx, const char *opts,
const char *const *shorthand,
const char *key_val_sep, const char *pairs_sep);
-/**
- * Check whether a particular flag is set in a flags field.
- *
- * @param field_name the name of the flag field option
- * @param flag_name the name of the flag to check
- * @return non-zero if the flag is set, zero if the flag isn't set,
- * isn't of the right type, or the flags field doesn't exist.
- */
-int av_opt_flag_is_set(void *obj, const char *field_name, const char
*flag_name);
-
/**
* Set all the options from a given dictionary on an object.
*
@@ -672,28 +667,23 @@ int av_opt_set_dict(void *obj, struct AVDictionary
**options);
int av_opt_set_dict2(void *obj, struct AVDictionary **options, int
search_flags);
/**
- * @defgroup opt_eval_funcs Evaluating option strings
- * @{
- * This group of functions can be used to evaluate option strings
- * and get numbers out of them. They do the same thing as av_opt_set(),
- * except the result is written into the caller-supplied pointer.
+ * Copy options from src object into dest object.
*
- * @param obj a struct whose first element is a pointer to AVClass.
- * @param o an option for which the string is to be evaluated.
- * @param val string to be evaluated.
- * @param *_out value of the string will be written here.
+ * The underlying AVClass of both src and dest must coincide. The guarantee
+ * below does not apply if this is not fulfilled.
*
- * @return 0 on success, a negative number on failure.
- */
-int av_opt_eval_flags (void *obj, const AVOption *o, const char *val, int
*flags_out);
-int av_opt_eval_int (void *obj, const AVOption *o, const char *val, int
*int_out);
-int av_opt_eval_int64 (void *obj, const AVOption *o, const char *val, int64_t
*int64_out);
-int av_opt_eval_float (void *obj, const AVOption *o, const char *val, float
*float_out);
-int av_opt_eval_double(void *obj, const AVOption *o, const char *val, double
*double_out);
-int av_opt_eval_q (void *obj, const AVOption *o, const char *val,
AVRational *q_out);
-/**
- * @}
+ * Options that require memory allocation (e.g. string or binary) are
malloc'ed in dest object.
+ * Original memory allocated for such options is freed unless both src and
dest options points to the same memory.
+ *
+ * Even on error it is guaranteed that allocated options from src and dest
+ * no longer alias each other afterwards; in particular calling av_opt_free()
+ * on both src and dest is safe afterwards if dest has been memdup'ed from src.
+ *
+ * @param dest Object to copy from
+ * @param src Object to copy into
+ * @return 0 on success, negative on error
*/
+int av_opt_copy(void *dest, const void *src);
/**
* @defgroup opt_set_funcs Option setting functions
@@ -761,6 +751,7 @@ int av_opt_set_dict_val(void *obj, const char *name, const
AVDictionary *val, in
av_int_list_length(val, term) * sizeof(*(val)), flags))
/**
+ * @}
* @}
*/
@@ -805,6 +796,31 @@ int av_opt_get_dict_val(void *obj, const char *name, int
search_flags, AVDiction
/**
* @}
*/
+
+/**
+ * @defgroup opt_eval_funcs Evaluating option strings
+ * @{
+ * This group of functions can be used to evaluate option strings
+ * and get numbers out of them. They do the same thing as av_opt_set(),
+ * except the result is written into the caller-supplied pointer.
+ *
+ * @param obj a struct whose first element is a pointer to AVClass.
+ * @param o an option for which the string is to be evaluated.
+ * @param val string to be evaluated.
+ * @param *_out value of the string will be written here.
+ *
+ * @return 0 on success, a negative number on failure.
+ */
+int av_opt_eval_flags (void *obj, const AVOption *o, const char *val, int
*flags_out);
+int av_opt_eval_int (void *obj, const AVOption *o, const char *val, int
*int_out);
+int av_opt_eval_int64 (void *obj, const AVOption *o, const char *val, int64_t
*int64_out);
+int av_opt_eval_float (void *obj, const AVOption *o, const char *val, float
*float_out);
+int av_opt_eval_double(void *obj, const AVOption *o, const char *val, double
*double_out);
+int av_opt_eval_q (void *obj, const AVOption *o, const char *val,
AVRational *q_out);
+/**
+ * @}
+ */
+
/**
* Gets a pointer to the requested field in a struct.
* This function allows accessing a
[FFmpeg-devel] [PATCH 10/38] lavu/opt: drop an always-NULL argument to get_number()
---
libavutil/opt.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 0ffdfc9a1e..54a99c689c 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -955,7 +955,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
return *out_val ? 0 : AVERROR(ENOMEM);
}
-static int get_number(void *obj, const char *name, const AVOption **o_out,
double *num, int *den, int64_t *intnum,
+static int get_number(void *obj, const char *name, double *num, int *den,
int64_t *intnum,
int search_flags)
{
void *dst, *target_obj;
@@ -965,8 +965,6 @@ static int get_number(void *obj, const char *name, const
AVOption **o_out, doubl
dst = ((uint8_t *)target_obj) + o->offset;
-if (o_out) *o_out= o;
-
return read_number(o, dst, num, den, intnum);
error:
@@ -981,7 +979,7 @@ int av_opt_get_int(void *obj, const char *name, int
search_flags, int64_t *out_v
double num = 1;
int ret, den = 1;
-if ((ret = get_number(obj, name, NULL, , , , search_flags))
< 0)
+if ((ret = get_number(obj, name, , , , search_flags)) < 0)
return ret;
if (num == den)
*out_val = intnum;
@@ -996,7 +994,7 @@ int av_opt_get_double(void *obj, const char *name, int
search_flags, double *out
double num = 1;
int ret, den = 1;
-if ((ret = get_number(obj, name, NULL, , , , search_flags))
< 0)
+if ((ret = get_number(obj, name, , , , search_flags)) < 0)
return ret;
*out_val = num * intnum / den;
return 0;
@@ -1008,7 +1006,7 @@ int av_opt_get_q(void *obj, const char *name, int
search_flags, AVRational *out_
double num = 1;
int ret, den = 1;
-if ((ret = get_number(obj, name, NULL, , , , search_flags))
< 0)
+if ((ret = get_number(obj, name, , , , search_flags)) < 0)
return ret;
if (num == 1.0 && (int)intnum == intnum)
@@ -1042,7 +1040,7 @@ int av_opt_get_video_rate(void *obj, const char *name,
int search_flags, AVRatio
double num = 1;
int ret, den = 1;
-if ((ret = get_number(obj, name, NULL, , , , search_flags))
< 0)
+if ((ret = get_number(obj, name, , , , search_flags)) < 0)
return ret;
if (num == 1.0 && (int)intnum == intnum)
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 02/38] lavu/opt: cosmetics, move AV_OPT_FLAG_* out of AVOption
Also drop an obsolete FIXME.
---
libavutil/opt.h | 69 -
1 file changed, 34 insertions(+), 35 deletions(-)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 6ed3407b09..36e28249ee 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -245,40 +245,6 @@ enum AVOptionType{
AV_OPT_TYPE_CHLAYOUT,
};
-/**
- * AVOption
- */
-typedef struct AVOption {
-const char *name;
-
-/**
- * short English help text
- * @todo What about other languages?
- */
-const char *help;
-
-/**
- * The offset relative to the context structure where the option
- * value is stored. It should be 0 for named constants.
- */
-int offset;
-enum AVOptionType type;
-
-/**
- * the default value for scalar options
- */
-union {
-int64_t i64;
-double dbl;
-const char *str;
-/* TODO those are unused now */
-AVRational q;
-} default_val;
-double min; ///< minimum valid value for the option
-double max; ///< maximum valid value for the option
-
-int flags;
-
/**
* A generic parameter which can be set by the user for muxing or encoding.
*/
@@ -321,7 +287,40 @@ typedef struct AVOption {
* Set if option constants can also reside in child objects.
*/
#define AV_OPT_FLAG_CHILD_CONSTS(1 << 18)
-//FIXME think about enc-audio, ... style flags
+
+/**
+ * AVOption
+ */
+typedef struct AVOption {
+const char *name;
+
+/**
+ * short English help text
+ * @todo What about other languages?
+ */
+const char *help;
+
+/**
+ * The offset relative to the context structure where the option
+ * value is stored. It should be 0 for named constants.
+ */
+int offset;
+enum AVOptionType type;
+
+/**
+ * the default value for scalar options
+ */
+union {
+int64_t i64;
+double dbl;
+const char *str;
+/* TODO those are unused now */
+AVRational q;
+} default_val;
+double min; ///< minimum valid value for the option
+double max; ///< maximum valid value for the option
+
+int flags;
/**
* The logical unit to which the option belongs. Non-constant
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 01/38] lavu/opt: cosmetics, change option flags to (1 << N) style
It is easier to read. Also, change their doxy comments to use the same
style.
---
libavutil/opt.h | 48
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 461b5d3b6b..6ed3407b09 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -278,25 +278,49 @@ typedef struct AVOption {
double max; ///< maximum valid value for the option
int flags;
-#define AV_OPT_FLAG_ENCODING_PARAM 1 ///< a generic parameter which can be
set by the user for muxing or encoding
-#define AV_OPT_FLAG_DECODING_PARAM 2 ///< a generic parameter which can be
set by the user for demuxing or decoding
-#define AV_OPT_FLAG_AUDIO_PARAM 8
-#define AV_OPT_FLAG_VIDEO_PARAM 16
-#define AV_OPT_FLAG_SUBTITLE_PARAM 32
+
+/**
+ * A generic parameter which can be set by the user for muxing or encoding.
+ */
+#define AV_OPT_FLAG_ENCODING_PARAM (1 << 0)
+/**
+ * A generic parameter which can be set by the user for demuxing or decoding.
+ */
+#define AV_OPT_FLAG_DECODING_PARAM (1 << 1)
+#define AV_OPT_FLAG_AUDIO_PARAM (1 << 3)
+#define AV_OPT_FLAG_VIDEO_PARAM (1 << 4)
+#define AV_OPT_FLAG_SUBTITLE_PARAM (1 << 5)
/**
* The option is intended for exporting values to the caller.
*/
-#define AV_OPT_FLAG_EXPORT 64
+#define AV_OPT_FLAG_EXPORT (1 << 6)
/**
* The option may not be set through the AVOptions API, only read.
* This flag only makes sense when AV_OPT_FLAG_EXPORT is also set.
*/
-#define AV_OPT_FLAG_READONLY128
-#define AV_OPT_FLAG_BSF_PARAM (1<<8) ///< a generic parameter which can
be set by the user for bit stream filtering
-#define AV_OPT_FLAG_RUNTIME_PARAM (1<<15) ///< a generic parameter which can
be set by the user at runtime
-#define AV_OPT_FLAG_FILTERING_PARAM (1<<16) ///< a generic parameter which can
be set by the user for filtering
-#define AV_OPT_FLAG_DEPRECATED (1<<17) ///< set if option is deprecated,
users should refer to AVOption.help text for more information
-#define AV_OPT_FLAG_CHILD_CONSTS(1<<18) ///< set if option constants can
also reside in child objects
+#define AV_OPT_FLAG_READONLY(1 << 7)
+/**
+ * A generic parameter which can be set by the user for bit stream filtering.
+ */
+#define AV_OPT_FLAG_BSF_PARAM (1 << 8)
+
+/**
+ * A generic parameter which can be set by the user at runtime.
+ */
+#define AV_OPT_FLAG_RUNTIME_PARAM (1 << 15)
+/**
+ * A generic parameter which can be set by the user for filtering.
+ */
+#define AV_OPT_FLAG_FILTERING_PARAM (1 << 16)
+/**
+ * Set if option is deprecated, users should refer to AVOption.help text for
+ * more information.
+ */
+#define AV_OPT_FLAG_DEPRECATED (1 << 17)
+/**
+ * Set if option constants can also reside in child objects.
+ */
+#define AV_OPT_FLAG_CHILD_CONSTS(1 << 18)
//FIXME think about enc-audio, ... style flags
/**
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] array AVOptions and side data preference
Hi,
this patchset implements a solution to the problem of side data
precedence for lavc decoding, recently raised by Derek (#10857).
The issue was caused by the recent addition of a mechanism for providing
global side data (typically from the demuxer) to decoders, which will
then propagate it to decoded frames. The problem is that some side data
may be present both in global headers and in the coded bytestream, which
will result in output frames having both attached, with no way to tell
which is which.
The solution in this set is as follows:
* at most one side data of a given type will ever be attached to a
frame
* by default, bytestream side data is preferred
* a new decoder option is added to allow overriding this default on a
per-side-data-type basis; to implement this I am adding array-type
AVOptions, which should also be useful elsewhere
Some potential points of interest:
* I am adding AVOption.array_max_size to allow specifying a maximum
array size for array-type options. Since Andreas seemed strongly
opposed to increasing sizeof(AVOption), I am placing it in a hole
before AVOption.unit (which is the reason 15/38 needs to go in as a
part of the major bump). This means that I cannot also add a minimum
array size. We might also:
* give up on specifying minimum size
* drop array size limits entirely (array_max_size is not used as of
this set)
* make array_max_size 16-bit and add a 16-bit min as well, since I
don't expect array sizes to be very large
* I am not providing any API for accessing array-type AVOptions other
than av_opt_{get,set}() (i.e. converting to/from strings), because
it's not strictly necessary for this set and I did not want to delay
the bump because of it. But clearly some such API will be needed.
Big thanks to Niklas for helping with decoder conversion.
Cheers,
--
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] hwcontext_videotoolbox: add vt_device_derive
___ 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] clarifying the TC conflict of interest rule
On Thu, Feb 22, 2024 at 10:54:56PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-02-20 22:51:20) > > On Tue, Feb 20, 2024 at 09:12:11PM +, Cosmin Stejerean via ffmpeg-devel > > wrote: > > > > > > > > > > On Feb 20, 2024, at 12:41 PM, Michael Niedermayer > > > > wrote: > > > > > > > > On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote: > > > >> Quoting Michael Niedermayer (2024-02-20 15:01:11) > > > >>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote: > > > >>> [...] > > > their preferred wording, and then we can have the GA vote on it. > > > >>> > > > >>> Before this GA vote, we need another extra member discussion/vote. > > > >>> Because the last GA reset droped several developers from the GA > > > >> > > > >> I see neither why would we "need" such a vote, or why should it be > > > >> related to this one. > > > > > > > > Because thats what was done in the past. > > > > The extra member vote was done between a GA reset and the following > > > > votes > > > > like the CC/TC votes > > > > The exception was the STF vote because there just was not enough time > > > > > > > > We should do this consistently, and > > > > given that we reset the GA every 6 months, thats the natural rate > > > > at which to do a extra member vote (unless there is no other vote then > > > > the extra member vote can be skiped as it would make no difference) > > > > > > It's not clear from https://www.ffmpeg.org/community.html that the extra > > > members should be refreshed every time the GA is updated or that a vote > > > should get held up if that hasn't happened yet. > > > > > > > > > Additional members are added to the General Assembly through a vote > > > > after proposal by a member of the General Assembly. They are part of > > > > the GA for two years, after which they need a confirmation by the GA. > > > > > > It looks like a request to add extra members to the GA should be done > > > explicitly by someone requesting a vote on it, which can be done at any > > > time. Waiting until something else comes up for a vote seems suboptimal > > > because it then delays that first decision by at least a couple of weeks > > > (given the rules for voting). > > > > We probably dont vote every 6 month on anything > > > > If we wait for a vote, and only then do a extra member vote before, that > > would > > result in some delay but fewer votes > > > > Than > > > > if someone starts a extra member vote every 6 month because its unknown if > > maybe in the next 6 month there could be a vote > > > > so for me, it seemed natural to only do this when theres some decision > > to be made. (which yes, could add some delay) > > This is also what we did previously. we only did extra member votes when > > there > > was something to vote on like CC/TC > > No, this is not what happened. We did the extra member votes as a part > of a "grand reset" of the voting system, after it was gridlocked for > years. > > I agree with Cosmin that it does not follow that we have to vote for > extra members as a prelude to any other vote. If you want everyone to accept the vote as valid you should make sure noone is left out. > > Moreover, you seem to be arguing yet again that anyone dropped from GA > because of inactivity needs to be added back as an extra member. You've The beauty of politics, whatever one says, others will present it in a way that makes it look bad. IIRC two people where droped, carl and andriy. andriy is maintaining patchwork and also IIRC helped setup the vote docker thingy. He isnt in the GA because the GA counts people based on authored commits but none the less he had enough commits previously so he wasnt in the extra member vote. He just fell below the threshold. > raised this point before, and GA disagreed, repeatedly. First in 2020 > when it was agreed that GA is made up of *active contributors*. Then > again last October, when your proposal to never drop anyone from GA lost > by a large margin to the winning option. "your proposal"? ok :) I think the idea was to provide voters with all options that would represent everyones position fairly ane then find out what was what people as majority where happiest with. Not so much my vs your, but whatever thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
Gyan Doshi (12024-02-23): > Just to be clear, that's not my basis. > > I said, > > "As a TC member who is part of the disagreement, I believe your > participation is recused." > > based on the existing rule, > > "If the disagreement involves a member of the TC, that member should recuse > themselves from the decision" > > Disagreement implies the existence of opposing sides, so discussion members > from both sides are barred from the TC proceedings. > The wiggle room in interpretation is over whether 'involves' captures all > participants, including minor ones, or just the principal interlocutors. > Note that the rule says nothing about patch authorship or asymmetry in its > application. > > Anton's original disagreement, as I understand it, is about the propriety of > the rule i.e. he believes that pre-existing public opposition (or agreement) > on the issue should not bar a TC member. That's a disagreement with the > rule, not with its interpretation. I am not sure what you mean exactly, but I suppose that if you mentioned the rule here and not any other rule, it was because you thought it was right to apply it, that this rule applied would make the ruling more just and trustworthy. My proposal wants to make absolutely clear your concern was valid. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
Michael Niedermayer (12024-02-23): > Each option should provide a patch. Fine. But the wording can be discussed too. Regards, -- Nicolas George >From 7955ed2c1074f85f0f55a58072a8623c8ff4bf34 Mon Sep 17 00:00:00 2001 From: Nicolas George Date: Fri, 23 Feb 2024 15:12:51 +0100 Subject: [PATCH] doc/community: strengthen TC member recusal rule The role of the TC, like any body of this kind, is not only to *decide* but to *convince* the involved parties that the decision is *fair*. To achieve that goal, the rules must not only exclude real conflicts of interest but even the appearance of bias. Sitting on the TC is not a *right*, does not mean the member is *above* the other developers, but rather a *duty*. The TC has several members who take up the duty if one or more members are recused or recuse themselves. Therefore it is best for the trust in the system to exclude preventively all members of the TC who might exhibit a bias or the suspicion of a bias to let decide the members who clearly had no pre-conception on the issue, Signed-off-by: Nicolas George --- doc/community.texi | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/community.texi b/doc/community.texi index 90d2b6f366..31d3e21df6 100644 --- a/doc/community.texi +++ b/doc/community.texi @@ -82,7 +82,17 @@ The TC has 2 modes of operation: a RFC one and an internal one. If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself. -If the disagreement involves a member of the TC, that member should recuse themselves from the decision. +Any member of the TC who had a strong opinion on the question raised before it was raised should recuse themselves. + +In particular, must recuse themselves any member of the TC who: +- participated in the discussion (on the ML, on IRC or elsewhere) in a specific direction (minor comments and questions being acceptable); +- has a personal interest in the outcome; +- is, was recently or soon will be employed by an entity having a personal interest in the outcome or has any kind of hierarchical relationship with such entity. +Failure to do so would result, upon discovery, into the exclusion of all FFmpeg governance bodies, including the general assembly, for a duration of no less than five years. + +Additionally, any member of the general assembly can recuse any member of the TC without having to provide a reason. + +If the application of these rules result in all members of the TC recused or if the remaining members do not feel comfortable being too few, that means the project is in a crisis of trust that needs to be resolved by the general assembly. The decision to use a RFC process or an internal discussion is a discretionary decision of the TC. -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avutil/hwcontext_opencl: Add map from Videotoolbox to OpenCL
From: Zhao Zhili
For example:
./ffmpeg -hwaccel videotoolbox \
-hwaccel_output_format videotoolbox_vld \
-i foo.mp4 \
-vf
hwmap=derive_device=opencl,transpose_opencl=dir=clock,hwmap,format=nv12 \
-c:v hevc_videotoolbox \
-c:a copy \
-b:v 2M -tag:v hvc1 bar.mp4
---
configure| 6 +++
libavutil/hwcontext_opencl.c | 97
2 files changed, 103 insertions(+)
diff --git a/configure b/configure
index 197f762b58..efcb4c4e49 100755
--- a/configure
+++ b/configure
@@ -2460,6 +2460,7 @@ HAVE_LIST="
opencl_dxva2
opencl_vaapi_beignet
opencl_vaapi_intel_media
+opencl_videotoolbox
perl
pod2man
texi2html
@@ -7217,6 +7218,11 @@ if enabled_all opencl d3d11va ; then
enable opencl_d3d11
fi
+if enabled_all opencl videotoolbox ; then
+check_func_headers OpenCL/cl_gl_ext.h
clCreateImageFromIOSurfaceWithPropertiesAPPLE -framework VideoToolbox
-framework OpenCL &&
+enable opencl_videotoolbox
+fi
+
enabled vdpau &&
check_cpp_condition vdpau vdpau/vdpau.h "defined
VDP_DECODER_PROFILE_MPEG4_PART2_ASP"
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index de093fffb1..efd8d0e094 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -72,6 +72,11 @@
#include "hwcontext_drm.h"
#endif
+#if HAVE_OPENCL_VIDEOTOOLBOX
+#include
+#include
+#endif
+
#if HAVE_OPENCL_VAAPI_INTEL_MEDIA && CONFIG_LIBMFX
extern int ff_qsv_get_surface_base_handle(mfxFrameSurface1 *surf,
enum AVHWDeviceType base_dev_typ,
@@ -1364,6 +1369,12 @@ static int opencl_device_derive(AVHWDeviceContext *hwdev,
break;
#endif
+#if HAVE_OPENCL_VIDEOTOOLBOX
+case AV_HWDEVICE_TYPE_VIDEOTOOLBOX:
+err = opencl_device_create(hwdev, NULL, NULL, 0);
+break;
+#endif
+
default:
err = AVERROR(ENOSYS);
break;
@@ -2819,6 +2830,84 @@ fail:
#endif
+#if HAVE_OPENCL_VIDEOTOOLBOX
+
+static void opencl_unmap_from_vt(AVHWFramesContext *hwfc,
+ HWMapDescriptor *hwmap)
+{
+uint8_t *desc = hwmap->priv;
+opencl_pool_free(hwfc, desc);
+}
+
+static int opencl_map_from_vt(AVHWFramesContext *dst_fc, AVFrame *dst,
+ const AVFrame *src, int flags)
+{
+CVPixelBufferRef pixbuf = (CVPixelBufferRef) src->data[3];
+IOSurfaceRef io_surface_ref = CVPixelBufferGetIOSurface(pixbuf);
+cl_int err = 0;
+AVOpenCLFrameDescriptor *desc = NULL;
+AVOpenCLDeviceContext *dst_dev = dst_fc->device_ctx->hwctx;
+
+if (!io_surface_ref) {
+av_log(dst_fc, AV_LOG_ERROR, "Failed to get IOSurfaceRef\n");
+return AVERROR_EXTERNAL;
+}
+
+desc = av_mallocz(sizeof(*desc));
+if (!desc)
+return AVERROR(ENOMEM);
+
+for (int p = 0;; p++) {
+cl_image_format image_format;
+cl_image_desc image_desc;
+cl_iosurface_properties_APPLE props[] = {
+CL_IOSURFACE_REF_APPLE, (cl_iosurface_properties_APPLE)
io_surface_ref,
+CL_IOSURFACE_PLANE_APPLE, p,
+0
+};
+
+err = opencl_get_plane_format(dst_fc->sw_format, p,
+ src->width, src->height,
+ _format, _desc);
+if (err == AVERROR(ENOENT))
+break;
+if (err < 0)
+goto fail;
+
+desc->planes[p] =
clCreateImageFromIOSurfaceWithPropertiesAPPLE(dst_dev->context,
+
opencl_mem_flags_for_mapping(flags),
+_format, _desc,
+props, );
+if (!desc->planes[p]) {
+av_log(dst_fc, AV_LOG_ERROR, "Failed to create image from
IOSurfaceRef\n");
+err = AVERROR(EIO);
+goto fail;
+}
+desc->nb_planes++;
+}
+
+for (int i = 0; i < desc->nb_planes; i++)
+dst->data[i] = (uint8_t *) desc->planes[i];
+
+err = ff_hwframe_map_create(dst->hw_frames_ctx, dst, src,
+opencl_unmap_from_vt, desc);
+if (err < 0)
+goto fail;
+
+dst->width = src->width;
+dst->height = src->height;
+
+return 0;
+
+fail:
+for (int i = 0; i < desc->nb_planes; i++)
+clReleaseMemObject(desc->planes[i]);
+av_freep();
+return err;
+}
+
+#endif
+
static int opencl_map_from(AVHWFramesContext *hwfc, AVFrame *dst,
const AVFrame *src, int flags)
{
@@ -2864,6 +2953,10 @@ static int opencl_map_to(AVHWFramesContext *hwfc,
AVFrame *dst,
case AV_PIX_FMT_DRM_PRIME:
if (priv->drm_arm_mapping_usable)
return opencl_map_from_drm_arm(hwfc, dst, src, flags);
+#endif
+#if HAVE_OPENCL_VIDEOTOOLBOX
+case AV_PIX_FMT_VIDEOTOOLBOX:
+return
[FFmpeg-devel] [PATCH 1/2] avutil/hwcontext_opencl: Fix missing linesize when map from opencl
From: Zhao Zhili --- libavutil/hwcontext_opencl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c index c1764ed098..de093fffb1 100644 --- a/libavutil/hwcontext_opencl.c +++ b/libavutil/hwcontext_opencl.c @@ -2014,6 +2014,7 @@ static int opencl_map_frame(AVHWFramesContext *hwfc, AVFrame *dst, } dst->data[p] = map->address[p]; +dst->linesize[p] = row_pitch; av_log(hwfc, AV_LOG_DEBUG, "Map plane %d (%p -> %p).\n", p, src->data[p], dst->data[p]); -- 2.42.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 v1] lavc/vvc_ps: Correct vaule of ALF_NUM_FILTERS_CC
applied, thank you Fei
On Fri, Feb 23, 2024 at 2:27 PM wrote:
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vvc/vvc_ps.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/vvc_ps.h b/libavcodec/vvc/vvc_ps.h
> index 5adf3f3453..1164d0eab6 100644
> --- a/libavcodec/vvc/vvc_ps.h
> +++ b/libavcodec/vvc/vvc_ps.h
> @@ -152,7 +152,7 @@ typedef struct VVCPH {
>
> #define ALF_NUM_FILTERS_LUMA25
> #define ALF_NUM_FILTERS_CHROMA 8
> -#define ALF_NUM_FILTERS_CC 5
> +#define ALF_NUM_FILTERS_CC 4
>
> #define ALF_NUM_COEFF_LUMA 12
> #define ALF_NUM_COEFF_CHROMA 6
> --
> 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] [RFC] clarifying the TC conflict of interest rule
On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote: > Hi, > in the 'avcodec/s302m: enable non-PCM decoding' thread it became > apparent that there is wide disagreement about the interpretation of > this line in the TC rules: > > > If the disagreement involves a member of the TC, that member should > > recuse themselves from the decision. > > The word 'involves' in it can be intepreted a variety of very different > ways, to apply to TC members who e.g.: > 1) authored the changes that are being objected to > 2) are objecting to the changes > 3) have any opinion on the changes, either positive or negative > 4) have previously voiced an opinion that would apply to the changes > 5) authored the code that is being modified > 6) have a financial or other similar interest in a specific outcome of >the disagreement > > I believe the best way to address this is to make the rule more > explicit, so I propose that people with an opinion on the matter submit > their preferred wording, and then we can have the GA vote on it. For the actual vote about changing the rules and the discussion of it. Each option should provide a patch. Otherwise you could have a whole new discussion after the vote how to turn it into a change to the rules thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/evc: Reference to ISO_IEC_23094-1-2020 document section for EVC_MAX_APS_COUNT enum has been changed
Signed-off-by: Dawid Kozinski
---
libavcodec/evc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/evc.h b/libavcodec/evc.h
index 9711c760fe..182a01f3d2 100644
--- a/libavcodec/evc.h
+++ b/libavcodec/evc.h
@@ -106,14 +106,14 @@ enum EVCSliceType {
};
enum {
-// 7.4.3.2: aps_video_parameter_set_id is u(4).
-EVC_MAX_APS_COUNT = 32,
-
// 7.4.3.1: sps_seq_parameter_set_id is in [0, 15].
EVC_MAX_SPS_COUNT = 16,
// 7.4.3.2: pps_pic_parameter_set_id is in [0, 63].
EVC_MAX_PPS_COUNT = 64,
+
+// 7.4.3.3: adaptional_parameter_set_id is in [0, 31].
+EVC_MAX_APS_COUNT = 32,
// 7.4.5: slice header slice_pic_parameter_set_id in [0, 63]
EVC_MAX_SH_COUNT = 64,
--
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 11/11] avcodec/vvcdec: add Intra Block Copy decoder
On Thu, Feb 22, 2024 at 3:15 PM Nuo Mi wrote: > From: Wu Jianhua > > Introduction at https://ieeexplore.ieee.org/document/9408666 > > passed files: > 10b444_A_Kwai_3.bit > 10b444_B_Kwai_3.bit > CodingToolsSets_D_Tencent_2.bit > IBC_A_Tencent_2.bit > IBC_B_Tencent_2.bit > IBC_C_Tencent_2.bit > IBC_D_Tencent_2.bit > IBC_E_Tencent_1.bit > LOSSLESS_B_HHI_3.bit > Will push tomorrow if there are no 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 1/2] avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets
>De : ffmpeg-devel De la part de Michael >Niedermayer >Envoyé : mercredi 21 février 2024 05:32 >On Tue, Feb 20, 2024 at 05:33:01PM +0100, Nicolas Gaullier wrote: >> Fix fetch_timestamp when the frame start is in a previous packet. >> >> Signed-off-by: Nicolas Gaullier >> --- >> libavcodec/parser.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > >This change looses pts I missed it : some broken streams are missing the zero_byte which makes the current h264 parser code to borrow a terminating null byte in the previous frame if available. It seems there is currently no issue with that behaviour, but with my patch fixing the fetch_timestamp mechanism, it becomes one. So, what is somewhat tricky is to guess if we are facing a broken stream or a conformant stream which actually has its zero_byte in the previous frame. In my experience (including the sample from Michael and a sample of mine where there is no available null byte at the end of the frame), the "usual broken streams" are missing the zero_byte for the first NAL unit which is an AUD, but the following NAL still has this zero_byte. The following patch is a proposal to detect and overcome such a situation: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10877 At the end, this patch is required to handle broken streams and thus prepare the ground for the fetch_timestamp patch. Another option would be for example to handle the data_alignment_indicator in the mpegts demuxer to force the alignment (ex: with a parser state reset), but it seems it would involve some big unhappy changes in the code, with demux and parser tied together. Moreover, I don't think it is reliable and there might exists broken stream with unaligned packets that we would still like to support. Any inputs concerning broken streams for other codecs is welcome. For example, it may be required to handle broken hevc streams alike h264 ones: I have no opinion/ samples for that matter. Nicolas ___ 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/x86: disable hevc 12b luma deblock
On Wed, Feb 21, 2024 at 7:10 PM J. Dekker wrote:
> Over/underflow in some cases.
>
> Signed-off-by: J. Dekker
> ---
> libavcodec/x86/hevcdsp_init.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
> index 31e81eb11f..11cb1b3bfd 100644
> --- a/libavcodec/x86/hevcdsp_init.c
> +++ b/libavcodec/x86/hevcdsp_init.c
> @@ -1205,10 +1205,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const
> int bit_depth)
> if (EXTERNAL_SSE2(cpu_flags)) {
> c->hevc_v_loop_filter_chroma =
> ff_hevc_v_loop_filter_chroma_12_sse2;
> c->hevc_h_loop_filter_chroma =
> ff_hevc_h_loop_filter_chroma_12_sse2;
> -if (ARCH_X86_64) {
> -c->hevc_v_loop_filter_luma =
> ff_hevc_v_loop_filter_luma_12_sse2;
> -c->hevc_h_loop_filter_luma =
> ff_hevc_h_loop_filter_luma_12_sse2;
> -}
> +// FIXME: 12-bit luma deblock over/underflows in some cases
> +// if (ARCH_X86_64) {
> +// c->hevc_v_loop_filter_luma =
> ff_hevc_v_loop_filter_luma_12_sse2;
> +// c->hevc_h_loop_filter_luma =
> ff_hevc_h_loop_filter_luma_12_sse2;
> +// }
> SAO_BAND_INIT(12, sse2);
> SAO_EDGE_INIT(12, sse2);
>
Hi Dekker,
VVC will utilize this function as well.
Could you please share the HEVC clip or data that caused the overflow?
We'll make efforts to address it during the VVC porting
Thank you.
>
> --
> 2.43.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/h264_parser: fix start of packet for some broken streams
---
libavcodec/h264_parser.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -124,7 +124,16 @@ static int h264_find_frame_end(H264ParseContext *p, const
uint8_t *buf,
if (nalu_type == H264_NAL_SEI || nalu_type == H264_NAL_SPS ||
nalu_type == H264_NAL_PPS || nalu_type == H264_NAL_AUD) {
if (pc->frame_start_found) {
-i++;
+/* Some streams in the wild are missing the zero_byte at
the NAL_AUD:
+ * it is following just afterwards.
+ * To avoid any accidental borrowing of a byte in the
previous frame
+ * (which would return a negative index and indicate that
fetch_timestamps
+ * has to get the pts from the previous frame),
+ * better have the start of packet strictly aligned.
+ * To make it a more general rule, just test the following
three bytes are null.
+ */
+i += 1 + (!p->is_avc && state == 5 && i == 3 && nalu_type
== H264_NAL_AUD &&
+buf_size >= 9 && !AV_RB24(buf + 5));
goto found;
}
} else if (nalu_type == H264_NAL_SLICE || nalu_type ==
H264_NAL_DPA ||
--
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] [RFC] clarifying the TC conflict of interest rule
On 2024-02-23 01:26 pm, Nicolas George wrote: Anton Khirnov (12024-02-22): In my updated proposal, based on comments by Niklas and Rémi, I'm leaving it up to the TC member in question, based on the assumption that TC members are honest. A "stronger" version could conceivably leave it to CC to decide ambiguous cases. Feel free to propose such a version if you prefer it. Your version does nothing to address the issue of the current situation, where the contributor who has to raise an issue in front of the TC does not trust one member of the TC to be unbiased on this issue. Just to be clear, that's not my basis. I said, "As a TC member who is part of the disagreement, I believe your participation is recused." based on the existing rule, "If the disagreement involves a member of the TC, that member should recuse themselves from the decision" Disagreement implies the existence of opposing sides, so discussion members from both sides are barred from the TC proceedings. The wiggle room in interpretation is over whether 'involves' captures all participants, including minor ones, or just the principal interlocutors. Note that the rule says nothing about patch authorship or asymmetry in its application. Anton's original disagreement, as I understand it, is about the propriety of the rule i.e. he believes that pre-existing public opposition (or agreement) on the issue should not bar a TC member. That's a disagreement with the rule, not with its interpretation. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avfilter: add vf_overlay_videotoolbox
A ping for this.
> On Feb 21, 2024, at 09:53, gnattu wrote:
>
> Overlay filter for VideoToolbox hwframes. Unlike most hardware
> overlay filters, this filter does not require the two inputs to
> have the same pixel format; instead, it will perform format
> conversion automatically with hardware accelerated methods.
>
> Signed-off-by: Gnattu OC
> ---
> Changelog | 1 +
> configure | 1 +
> doc/filters.texi | 52 ++
> libavfilter/Makefile | 3 +
> libavfilter/allfilters.c | 1 +
> libavfilter/metal/utils.h | 1 -
> libavfilter/metal/utils.m | 7 +-
> .../metal/vf_overlay_videotoolbox.metal | 58 ++
> libavfilter/vf_overlay_videotoolbox.m | 551 ++
> 9 files changed, 672 insertions(+), 3 deletions(-)
> create mode 100644 libavfilter/metal/vf_overlay_videotoolbox.metal
> create mode 100644 libavfilter/vf_overlay_videotoolbox.m
>
> diff --git a/Changelog b/Changelog
> index 610ee61dd6..3ecfdab81b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -27,6 +27,7 @@ version :
> - a C11-compliant compiler is now required; note that this requirement
> will be bumped to C17 in the near future, so consider updating your
> build environment if it lacks C17 support
> +- VideoToolbox overlay filter
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index 23066efa32..a7c349d126 100755
> --- a/configure
> +++ b/configure
> @@ -3807,6 +3807,7 @@ overlay_qsv_filter_deps="libmfx"
> overlay_qsv_filter_select="qsvvpp"
> overlay_vaapi_filter_deps="vaapi VAProcPipelineCaps_blend_flags"
> overlay_vulkan_filter_deps="vulkan spirv_compiler"
> +overlay_videotoolbox_filter_deps="metal corevideo coreimage videotoolbox"
> owdenoise_filter_deps="gpl"
> pad_opencl_filter_deps="opencl"
> pan_filter_deps="swresample"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e0436a5755..bfb77562cb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19033,6 +19033,58 @@ See @ref{framesync}.
>
> This filter also supports the @ref{framesync} options.
>
> +@section overlay_videotoolbox
> +
> +Overlay one video on top of another.
> +
> +This is the VideoToolbox variant of the @ref{overlay} filter.
> +It takes two inputs and has one output. The first input is the "main" video
> on which the second input is overlaid.
> +It only accepts VideoToolbox frames. The underlying input pixel formats do
> not have to match.
> +Different input pixel formats and color spaces will be automatically
> converted using hardware accelerated methods.
> +The final output will have the same pixel format and color space as the
> "main" input.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +
> +@item x
> +Set the x coordinate of the overlaid video on the main video.
> +Default value is @code{0}.
> +
> +@item y
> +Set the y coordinate of the overlaid video on the main video.
> +Default value is @code{0}.
> +
> +@item eof_action
> +See @ref{framesync}.
> +
> +@item shortest
> +See @ref{framesync}.
> +
> +@item repeatlast
> +See @ref{framesync}.
> +
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Overlay an image LOGO at the top-left corner of the INPUT video.
> +The INPUT video is in nv12 format and the LOGO image is in rgba format.
> +@example
> +-hwaccel videotoolbox -i INPUT -i LOGO -codec:v:0 h264_videotoolbox
> -filter_complex "[0:v]format=nv12,hwupload[a], [1:v]format=rgba,hwupload[b],
> [a][b]overlay_videotoolbox" OUTPUT
> +@end example
> +@item
> +Overlay an SDR video OVERLAY at the top-left corner of the HDR video MAIN.
> +The INPUT video is in p010 format and the LOGO image is in nv12 format.
> +The OUTPUT video will also be an HDR video with OVERLAY mapped to HDR.
> +@example
> +-hwaccel videotoolbox -i MAIN -i OVERLAY -codec:v:0 hevc_videotoolbox -tag:v
> hvc1 -filter_complex "[0:v]format=p010,hwupload[a],
> [1:v]format=nv12,hwupload[b], [a][b]overlay_videotoolbox" OUTPUT
> +@end example
> +
> +@end itemize
> +
> @section owdenoise
>
> Apply Overcomplete Wavelet denoiser.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index f6c1d641d6..ea1389ab57 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -413,6 +413,9 @@ OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) +=
> vf_overlay_opencl.o opencl.o \
> OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o framesync.o
> OBJS-$(CONFIG_OVERLAY_VAAPI_FILTER) += vf_overlay_vaapi.o
> framesync.o vaapi_vpp.o
> OBJS-$(CONFIG_OVERLAY_VULKAN_FILTER) += vf_overlay_vulkan.o vulkan.o
> vulkan_filter.o
> +OBJS-$(CONFIG_OVERLAY_VIDEOTOOLBOX_FILTER) += vf_overlay_videotoolbox.o
> framesync.o \
> +
> metal/vf_overlay_videotoolbox.metallib.o \
> +
[FFmpeg-devel] [REFUND-REQUEST] FOSDEM 2024
Hi, I attended FOSDEM for ffmpeg and would like to request travel reimbursement. Flight | 162,46 EUR === Total | 162,46 EUR -- jd ___ 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".
