Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing
On 2022-05-12 09:53 pm, Vignesh Venkatasubramanian wrote:
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
Bumped lavf minor and pushed set as ab05e9a7f2...84241e63cf
Regards,
Gyan
AVIF Specification: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -still-picture 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verified to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian
---
configure| 1 +
libavformat/allformats.c | 1 +
libavformat/movenc.c | 341 ---
libavformat/movenc.h | 5 +
4 files changed, 323 insertions(+), 25 deletions(-)
diff --git a/configure b/configure
index 196873c4aa..2992f9760e 100755
--- a/configure
+++ b/configure
@@ -3404,6 +3404,7 @@ asf_stream_muxer_select="asf_muxer"
av1_demuxer_select="av1_frame_merge_bsf av1_parser"
avi_demuxer_select="riffdec exif"
avi_muxer_select="riffenc"
+avif_muxer_select="mov_muxer"
caf_demuxer_select="iso_media"
caf_muxer_select="iso_media"
dash_muxer_select="mp4_muxer"
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 63876c468f..1802536633 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -81,6 +81,7 @@ extern const AVOutputFormat ff_au_muxer;
extern const AVInputFormat ff_av1_demuxer;
extern const AVInputFormat ff_avi_demuxer;
extern const AVOutputFormat ff_avi_muxer;
+extern const AVOutputFormat ff_avif_muxer;
extern const AVInputFormat ff_avisynth_demuxer;
extern const AVOutputFormat ff_avm2_muxer;
extern const AVInputFormat ff_avr_demuxer;
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 271db99b46..a07c0ae2b4 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1335,7 +1335,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, MOVTrack
*track)
avio_wb32(pb, 0);
ffio_wfourcc(pb, "av1C");
-ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
+ff_isom_write_av1c(pb, track->vos_data, track->vos_len, track->mode !=
MODE_AVIF);
return update_size(pb, pos);
}
@@ -2037,12 +2037,13 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack *track, int prefer_icc)
}
}
-/* We should only ever be called by MOV or MP4. */
-av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4);
+/* We should only ever be called for MOV, MP4 and AVIF. */
+av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4 ||
+ track->mode == MODE_AVIF);
avio_wb32(pb, 0); /* size */
ffio_wfourcc(pb, "colr");
-if (track->mode == MODE_MP4)
+if (track->mode == MODE_MP4 || track->mode == MODE_AVIF)
ffio_wfourcc(pb, "nclx");
else
ffio_wfourcc(pb, "nclc");
@@ -2052,7 +2053,7 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack
*track, int prefer_icc)
avio_wb16(pb, track->par->color_primaries);
avio_wb16(pb, track->par->color_trc);
avio_wb16(pb, track->par->color_space);
-if (track->mode == MODE_MP4) {
+if (track->mode == MODE_MP4 || track->mode == MODE_AVIF) {
int full_range = track->par->color_range == AVCOL_RANGE_JPEG;
avio_w8(pb, full_range << 7);
}
@@ -2118,7 +2119,7 @@ static void find_compressor(char * compressor_name, int
len, MOVTrack *track)
|| (track->par->width == 1440 && track->par->height == 1080)
|| (track->par->width == 1920 && track->par->height ==
1080);
-if (track->mode == MODE_MOV &&
+if ((track->mode == MODE_AVIF || track->mode == MODE_MOV) &&
(encoder = av_dict_get(track->st->metadata, "encoder", NULL, 0))) {
av_strlcpy(compressor_name, encoder->value, 32);
} else if (track->par->codec_id == AV_CODEC_ID_MPEG2VIDEO && xdcam_res) {
@@ -2139,6 +2140,25 @@ static void find_compressor(char * compressor_name, int
len, MOVTrack *track)
}
}
+static int mov_write_ccst_tag(AVIOContext *pb)
+{
+int64_t pos = avio_tell(pb);
+// Write sane defaults:
+// all_ref_pics_intra = 0 : all samples can use any type of reference.
+// intra_pred_used = 1 : intra prediction may or may not be used.
+// max_ref_per_pic = 15 : reserved value to indicate that any number of
+//reference images can be used.
+uint8_t ccstValue = (0 << 7) | /* all_ref_pics_intra */
+
Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
Soft Works:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: Tuesday, May 3, 2022 8:38 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Andreas Rheinhardt
>> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
>> ff_nlmeans_init into a header
>>
>> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
>> and also allows to inline ff_nlmeans_init() irrespectively of
>> interposing.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>
> [..]
>
>> +
>> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
>> +{
>> +dsp->compute_safe_ssd_integral_image =
>> compute_safe_ssd_integral_image_c;
>> +dsp->compute_weights_line = compute_weights_line_c;
>> +
>> +if (ARCH_AARCH64)
>> +ff_nlmeans_init_aarch64(dsp);
>
> Hi Andreas,
>
> the above breaks compilation for me:
>
> 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019: unresolved
> external symbol ff_nlmeans_init_aarch64 referenced in function ff_nlmeans_init
>
> The reason is that I'm (obviously) not compiling stuff from the
> libavfilter\aarch64 subfolder.
>
> It might need an #ifdef ?
>
> I haven't taken a deeper look at it, though.
>
> Thanks,
> softworkz
>
>
That surprises me: The earlier code did exactly the same; in fact, using
if (ARCH_*) is our typical check for arches in dsp-init code.
Is this the only place where this happens?
#ifdef is certainly wrong: All ARCH_* are always defined; they are just
0 or 1.
Anyway, will send a patch with #if.
- 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 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
On Fri, May 13, 2022 at 10:27 AM Andreas Rheinhardt
wrote:
>
> Soft Works:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Tuesday, May 3, 2022 8:38 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Andreas Rheinhardt
> >> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> >> ff_nlmeans_init into a header
> >>
> >> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> >> and also allows to inline ff_nlmeans_init() irrespectively of
> >> interposing.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >
> > [..]
> >
> >> +
> >> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> >> +{
> >> +dsp->compute_safe_ssd_integral_image =
> >> compute_safe_ssd_integral_image_c;
> >> +dsp->compute_weights_line = compute_weights_line_c;
> >> +
> >> +if (ARCH_AARCH64)
> >> +ff_nlmeans_init_aarch64(dsp);
> >
> > Hi Andreas,
> >
> > the above breaks compilation for me:
> >
> > 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019: unresolved
> > external symbol ff_nlmeans_init_aarch64 referenced in function
> > ff_nlmeans_init
> >
> > The reason is that I'm (obviously) not compiling stuff from the
> > libavfilter\aarch64 subfolder.
> >
> > It might need an #ifdef ?
> >
> > I haven't taken a deeper look at it, though.
> >
> > Thanks,
> > softworkz
> >
> >
>
> That surprises me: The earlier code did exactly the same; in fact, using
> if (ARCH_*) is our typical check for arches in dsp-init code.
> Is this the only place where this happens?
> #ifdef is certainly wrong: All ARCH_* are always defined; they are just
> 0 or 1.
> Anyway, will send a patch with #if.
>
The inlining due to the code coming from a header probably breaks
dead-code-elimination in some compilers.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
> -Original Message-
> From: Andreas Rheinhardt
> Sent: Friday, May 13, 2022 10:27 AM
> To: Soft Works ; FFmpeg development discussions
> and patches
> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> ff_nlmeans_init into a header
>
> Soft Works:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Tuesday, May 3, 2022 8:38 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Andreas Rheinhardt
> >> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> >> ff_nlmeans_init into a header
> >>
> >> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> >> and also allows to inline ff_nlmeans_init() irrespectively of
> >> interposing.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >
> > [..]
> >
> >> +
> >> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> >> +{
> >> +dsp->compute_safe_ssd_integral_image =
> >> compute_safe_ssd_integral_image_c;
> >> +dsp->compute_weights_line = compute_weights_line_c;
> >> +
> >> +if (ARCH_AARCH64)
> >> +ff_nlmeans_init_aarch64(dsp);
> >
> > Hi Andreas,
> >
> > the above breaks compilation for me:
> >
> > 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
> unresolved external symbol ff_nlmeans_init_aarch64 referenced in
> function ff_nlmeans_init
> >
> > The reason is that I'm (obviously) not compiling stuff from the
> > libavfilter\aarch64 subfolder.
> >
> > It might need an #ifdef ?
> >
> > I haven't taken a deeper look at it, though.
> >
> > Thanks,
> > softworkz
> >
> >
>
> That surprises me: The earlier code did exactly the same; in fact,
> using
> if (ARCH_*) is our typical check for arches in dsp-init code.
I looked at this a bit further. It seems that the VS project
generation tool that I'm using is creating dummy definitions
for such cases. In the previous workspace it had generated
void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp) {return;}
in a separate code file for being able to work with the ffmpeg
code in VS without modifying any of the code.
Now that you have moved that code to a header file, this logic
doesn't work anymore.
> Is this the only place where this happens?
Yes.
> Anyway, will send a patch with #if.
Great, thanks!
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Friday, May 13, 2022 11:00 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> ff_nlmeans_init into a header
>
> On Fri, May 13, 2022 at 10:27 AM Andreas Rheinhardt
> wrote:
> >
> > Soft Works:
> > >
> > >
> > >> -Original Message-
> > >> From: ffmpeg-devel On Behalf Of
> > >> Andreas Rheinhardt
> > >> Sent: Tuesday, May 3, 2022 8:38 AM
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Cc: Andreas Rheinhardt
> > >> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> > >> ff_nlmeans_init into a header
> > >>
> > >> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> > >> and also allows to inline ff_nlmeans_init() irrespectively of
> > >> interposing.
> > >>
> > >> Signed-off-by: Andreas Rheinhardt
>
> > >> ---
> > >
> > > [..]
> > >
> > >> +
> > >> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> > >> +{
> > >> +dsp->compute_safe_ssd_integral_image =
> > >> compute_safe_ssd_integral_image_c;
> > >> +dsp->compute_weights_line = compute_weights_line_c;
> > >> +
> > >> +if (ARCH_AARCH64)
> > >> +ff_nlmeans_init_aarch64(dsp);
> > >
> > > Hi Andreas,
> > >
> > > the above breaks compilation for me:
> > >
> > > 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
> unresolved external symbol ff_nlmeans_init_aarch64 referenced in
> function ff_nlmeans_init
> > >
> > > The reason is that I'm (obviously) not compiling stuff from the
> > > libavfilter\aarch64 subfolder.
> > >
> > > It might need an #ifdef ?
> > >
> > > I haven't taken a deeper look at it, though.
> > >
> > > Thanks,
> > > softworkz
> > >
> > >
> >
> > That surprises me: The earlier code did exactly the same; in fact,
> using
> > if (ARCH_*) is our typical check for arches in dsp-init code.
> > Is this the only place where this happens?
> > #ifdef is certainly wrong: All ARCH_* are always defined; they are
> just
> > 0 or 1.
> > Anyway, will send a patch with #if.
> >
>
> The inlining due to the code coming from a header probably breaks
> dead-code-elimination in some compilers.
Ah, that explains why that file with the empty stubs is named
dce_defs.c :-)
Thanks,
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
On Fri, May 13, 2022 at 11:01 AM Soft Works wrote:
>
>
>
> > -Original Message-
> > From: Andreas Rheinhardt
> > Sent: Friday, May 13, 2022 10:27 AM
> > To: Soft Works ; FFmpeg development discussions
> > and patches
> > Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> > ff_nlmeans_init into a header
> >
> > Soft Works:
> > >
> > >
> > >> -Original Message-
> > >> From: ffmpeg-devel On Behalf Of
> > >> Andreas Rheinhardt
> > >> Sent: Tuesday, May 3, 2022 8:38 AM
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Cc: Andreas Rheinhardt
> > >> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> > >> ff_nlmeans_init into a header
> > >>
> > >> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> > >> and also allows to inline ff_nlmeans_init() irrespectively of
> > >> interposing.
> > >>
> > >> Signed-off-by: Andreas Rheinhardt
> > >> ---
> > >
> > > [..]
> > >
> > >> +
> > >> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> > >> +{
> > >> +dsp->compute_safe_ssd_integral_image =
> > >> compute_safe_ssd_integral_image_c;
> > >> +dsp->compute_weights_line = compute_weights_line_c;
> > >> +
> > >> +if (ARCH_AARCH64)
> > >> +ff_nlmeans_init_aarch64(dsp);
> > >
> > > Hi Andreas,
> > >
> > > the above breaks compilation for me:
> > >
> > > 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
> > unresolved external symbol ff_nlmeans_init_aarch64 referenced in
> > function ff_nlmeans_init
> > >
> > > The reason is that I'm (obviously) not compiling stuff from the
> > > libavfilter\aarch64 subfolder.
> > >
> > > It might need an #ifdef ?
> > >
> > > I haven't taken a deeper look at it, though.
> > >
> > > Thanks,
> > > softworkz
> > >
> > >
> >
> > That surprises me: The earlier code did exactly the same; in fact,
> > using
> > if (ARCH_*) is our typical check for arches in dsp-init code.
>
> I looked at this a bit further. It seems that the VS project
> generation tool that I'm using is creating dummy definitions
> for such cases. In the previous workspace it had generated
>
> void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp) {return;}
>
> in a separate code file for being able to work with the ffmpeg
> code in VS without modifying any of the code.
>
> Now that you have moved that code to a header file, this logic
> doesn't work anymore.
>
Nevermind my previous comment then, perhaps external tools should be
updated if they somehow work around our need for DCE (which is well
documented).
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter, avcodec/*_init.h: Use #if to disable code
Should fix the compilation issue reported in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
and should also prevent such issues on arches other than X86.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/v210dec_init.h | 3 ++-
libavcodec/v210enc_init.h | 3 ++-
libavfilter/af_afirdsp.h| 3 ++-
libavfilter/vf_blend_init.h | 3 ++-
libavfilter/vf_eq.h | 3 ++-
libavfilter/vf_gblur_init.h | 3 ++-
libavfilter/vf_hflip_init.h | 3 ++-
libavfilter/vf_nlmeans_init.h | 6 +++---
libavfilter/vf_threshold_init.h | 3 ++-
9 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavcodec/v210dec_init.h b/libavcodec/v210dec_init.h
index 305ab3911e..707c101ab0 100644
--- a/libavcodec/v210dec_init.h
+++ b/libavcodec/v210dec_init.h
@@ -54,8 +54,9 @@ static void v210_planar_unpack_c(const uint32_t *src,
uint16_t *y, uint16_t *u,
static av_unused av_cold void ff_v210dec_init(V210DecContext *s)
{
s->unpack_frame = v210_planar_unpack_c;
-if (ARCH_X86)
+#if ARCH_X86
ff_v210_x86_init(s);
+#endif
}
#endif /* AVCODEC_V210DEC_INIT_H */
diff --git a/libavcodec/v210enc_init.h b/libavcodec/v210enc_init.h
index 6d81cac319..09828d4a14 100644
--- a/libavcodec/v210enc_init.h
+++ b/libavcodec/v210enc_init.h
@@ -83,8 +83,9 @@ static av_cold av_unused void ff_v210enc_init(V210EncContext
*s)
s->sample_factor_8 = 2;
s->sample_factor_10 = 1;
-if (ARCH_X86)
+#if ARCH_X86
ff_v210enc_init_x86(s);
+#endif
}
#endif /* AVCODEC_V210ENC_INIT_H */
diff --git a/libavfilter/af_afirdsp.h b/libavfilter/af_afirdsp.h
index 05182bebb4..8127194836 100644
--- a/libavfilter/af_afirdsp.h
+++ b/libavfilter/af_afirdsp.h
@@ -54,8 +54,9 @@ static av_unused void ff_afir_init(AudioFIRDSPContext *dsp)
{
dsp->fcmul_add = fcmul_add_c;
-if (ARCH_X86)
+#if ARCH_X86
ff_afir_init_x86(dsp);
+#endif
}
#endif /* AVFILTER_AFIRDSP_H */
diff --git a/libavfilter/vf_blend_init.h b/libavfilter/vf_blend_init.h
index 5fb2599490..b377219806 100644
--- a/libavfilter/vf_blend_init.h
+++ b/libavfilter/vf_blend_init.h
@@ -194,8 +194,9 @@ static av_unused void ff_blend_init(FilterParams *param,
int depth)
param->blend = depth > 8 ? depth > 16 ? blend_copybottom_32 :
blend_copybottom_16 : blend_copybottom_8;
}
-if (ARCH_X86)
+#if ARCH_X86
ff_blend_init_x86(param, depth);
+#endif
}
#endif /* AVFILTER_BLEND_INIT_H */
diff --git a/libavfilter/vf_eq.h b/libavfilter/vf_eq.h
index a5756977d2..d68fb7295e 100644
--- a/libavfilter/vf_eq.h
+++ b/libavfilter/vf_eq.h
@@ -123,8 +123,9 @@ void ff_eq_init_x86(EQContext *eq);
static av_unused void ff_eq_init(EQContext *eq)
{
eq->process = process_c;
-if (ARCH_X86)
+#if ARCH_X86
ff_eq_init_x86(eq);
+#endif
}
#endif /* AVFILTER_EQ_H */
diff --git a/libavfilter/vf_gblur_init.h b/libavfilter/vf_gblur_init.h
index 0fee64bc98..9ff28c6f59 100644
--- a/libavfilter/vf_gblur_init.h
+++ b/libavfilter/vf_gblur_init.h
@@ -115,8 +115,9 @@ static av_unused void ff_gblur_init(GBlurContext *s)
s->horiz_slice = horiz_slice_c;
s->verti_slice = verti_slice_c;
s->postscale_slice = postscale_c;
-if (ARCH_X86)
+#if ARCH_X86
ff_gblur_init_x86(s);
+#endif
}
#endif /* AVFILTER_GBLUR_INIT_H */
diff --git a/libavfilter/vf_hflip_init.h b/libavfilter/vf_hflip_init.h
index b58cfec901..63f9e3b92a 100644
--- a/libavfilter/vf_hflip_init.h
+++ b/libavfilter/vf_hflip_init.h
@@ -101,8 +101,9 @@ static av_unused int ff_hflip_init(FlipContext *s, int
step[4], int nb_planes)
return AVERROR_BUG;
}
}
-if (ARCH_X86)
+#if ARCH_X86
ff_hflip_init_x86(s, step, nb_planes);
+#endif
return 0;
}
diff --git a/libavfilter/vf_nlmeans_init.h b/libavfilter/vf_nlmeans_init.h
index 04ad8801b6..87fca13b2e 100644
--- a/libavfilter/vf_nlmeans_init.h
+++ b/libavfilter/vf_nlmeans_init.h
@@ -129,11 +129,11 @@ static av_unused void ff_nlmeans_init(NLMeansDSPContext
*dsp)
dsp->compute_safe_ssd_integral_image = compute_safe_ssd_integral_image_c;
dsp->compute_weights_line = compute_weights_line_c;
-if (ARCH_AARCH64)
+#if ARCH_AARCH64
ff_nlmeans_init_aarch64(dsp);
-
-if (ARCH_X86)
+#elif ARCH_X86
ff_nlmeans_init_x86(dsp);
+#endif
}
#endif /* AVFILTER_NLMEANS_INIT_H */
diff --git a/libavfilter/vf_threshold_init.h b/libavfilter/vf_threshold_init.h
index e79d2bb63d..c86e9da7f2 100644
--- a/libavfilter/vf_threshold_init.h
+++ b/libavfilter/vf_threshold_init.h
@@ -84,8 +84,9 @@ static av_unused void ff_threshold_init(ThresholdContext *s)
s->bpc = 2;
}
-if (ARCH_X86)
+#if ARCH_X86
ff_threshold_init_x86(s);
+#endif
}
#endif /* AVFILTER_THRESHOLD_INIT_H */
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
Soft Works:
>
>
>> -Original Message-
>> From: Andreas Rheinhardt
>> Sent: Friday, May 13, 2022 10:27 AM
>> To: Soft Works ; FFmpeg development discussions
>> and patches
>> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
>> ff_nlmeans_init into a header
>>
>> Soft Works:
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: Tuesday, May 3, 2022 8:38 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Andreas Rheinhardt
Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
ff_nlmeans_init into a header
This removes a dependency of checkasm on lavfi/vf_nlmeans.o
and also allows to inline ff_nlmeans_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt
---
>>>
>>> [..]
>>>
+
+static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
+{
+dsp->compute_safe_ssd_integral_image =
compute_safe_ssd_integral_image_c;
+dsp->compute_weights_line = compute_weights_line_c;
+
+if (ARCH_AARCH64)
+ff_nlmeans_init_aarch64(dsp);
>>>
>>> Hi Andreas,
>>>
>>> the above breaks compilation for me:
>>>
>>> 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
>> unresolved external symbol ff_nlmeans_init_aarch64 referenced in
>> function ff_nlmeans_init
>>>
>>> The reason is that I'm (obviously) not compiling stuff from the
>>> libavfilter\aarch64 subfolder.
>>>
>>> It might need an #ifdef ?
>>>
>>> I haven't taken a deeper look at it, though.
>>>
>>> Thanks,
>>> softworkz
>>>
>>>
>>
>> That surprises me: The earlier code did exactly the same; in fact,
>> using
>> if (ARCH_*) is our typical check for arches in dsp-init code.
>
> I looked at this a bit further. It seems that the VS project
> generation tool that I'm using is creating dummy definitions
> for such cases. In the previous workspace it had generated
>
> void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp) {return;}
>
> in a separate code file for being able to work with the ffmpeg
> code in VS without modifying any of the code.
>
> Now that you have moved that code to a header file, this logic
> doesn't work anymore.
>
Why does your compiler not just eliminate dead code like all the others?
Is this MSVC -O0 behaviour?
I just sent the patch
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296380.html, but now
that I read this I have to agree with Hendrik: Why not update your tool
instead?
- 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] avfilter, avcodec/*_init.h: Use #if to disable code
On Fri, May 13, 2022 at 11:19 AM Andreas Rheinhardt wrote: > > Should fix the compilation issue reported in > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html > and should also prevent such issues on arches other than X86. > Since this doesn't actually affect actual compilers, but custom scripts that generate project files, maybe those should just be updated to process header files? These issues are likely to come back, as this is a rather standard pattern for all our code, so this is just a bandaid. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
On Fri, May 13, 2022 at 11:26 AM Andreas Rheinhardt
wrote:
>
> Soft Works:
> >
> >
> >> -Original Message-
> >> From: Andreas Rheinhardt
> >> Sent: Friday, May 13, 2022 10:27 AM
> >> To: Soft Works ; FFmpeg development discussions
> >> and patches
> >> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> >> ff_nlmeans_init into a header
> >>
> >> Soft Works:
> >>>
> >>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Tuesday, May 3, 2022 8:38 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> ff_nlmeans_init into a header
>
> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> and also allows to inline ff_nlmeans_init() irrespectively of
> interposing.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> >>>
> >>> [..]
> >>>
> +
> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> +{
> +dsp->compute_safe_ssd_integral_image =
> compute_safe_ssd_integral_image_c;
> +dsp->compute_weights_line = compute_weights_line_c;
> +
> +if (ARCH_AARCH64)
> +ff_nlmeans_init_aarch64(dsp);
> >>>
> >>> Hi Andreas,
> >>>
> >>> the above breaks compilation for me:
> >>>
> >>> 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
> >> unresolved external symbol ff_nlmeans_init_aarch64 referenced in
> >> function ff_nlmeans_init
> >>>
> >>> The reason is that I'm (obviously) not compiling stuff from the
> >>> libavfilter\aarch64 subfolder.
> >>>
> >>> It might need an #ifdef ?
> >>>
> >>> I haven't taken a deeper look at it, though.
> >>>
> >>> Thanks,
> >>> softworkz
> >>>
> >>>
> >>
> >> That surprises me: The earlier code did exactly the same; in fact,
> >> using
> >> if (ARCH_*) is our typical check for arches in dsp-init code.
> >
> > I looked at this a bit further. It seems that the VS project
> > generation tool that I'm using is creating dummy definitions
> > for such cases. In the previous workspace it had generated
> >
> > void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp) {return;}
> >
> > in a separate code file for being able to work with the ffmpeg
> > code in VS without modifying any of the code.
> >
> > Now that you have moved that code to a header file, this logic
> > doesn't work anymore.
> >
>
> Why does your compiler not just eliminate dead code like all the others?
> Is this MSVC -O0 behaviour?
MSVC does not do DCE when optimizations are disabled, yes. So this is
where this is coming from.
> I just sent the patch
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296380.html, but now
> that I read this I have to agree with Hendrik: Why not update your tool
> instead?
>
Actually looking at the tool, it seems like it handles header files.
Did you actually re-run the generation tool after applying this patch?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
> -Original Message-
> From: Andreas Rheinhardt
> Sent: Friday, May 13, 2022 11:26 AM
> To: Soft Works ; FFmpeg development discussions
> and patches
> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> ff_nlmeans_init into a header
>
> Soft Works:
> >
> >
> >> -Original Message-
> >> From: Andreas Rheinhardt
> >> Sent: Friday, May 13, 2022 10:27 AM
> >> To: Soft Works ; FFmpeg development
> discussions
> >> and patches
> >> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> >> ff_nlmeans_init into a header
> >>
> >> Soft Works:
> >>>
> >>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Tuesday, May 3, 2022 8:38 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> ff_nlmeans_init into a header
>
> This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> and also allows to inline ff_nlmeans_init() irrespectively of
> interposing.
>
> Signed-off-by: Andreas Rheinhardt
>
> ---
> >>>
> >>> [..]
> >>>
> +
> +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> +{
> +dsp->compute_safe_ssd_integral_image =
> compute_safe_ssd_integral_image_c;
> +dsp->compute_weights_line = compute_weights_line_c;
> +
> +if (ARCH_AARCH64)
> +ff_nlmeans_init_aarch64(dsp);
> >>>
> >>> Hi Andreas,
> >>>
> >>> the above breaks compilation for me:
> >>>
> >>> 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
> >> unresolved external symbol ff_nlmeans_init_aarch64 referenced in
> >> function ff_nlmeans_init
> >>>
> >>> The reason is that I'm (obviously) not compiling stuff from the
> >>> libavfilter\aarch64 subfolder.
> >>>
> >>> It might need an #ifdef ?
> >>>
> >>> I haven't taken a deeper look at it, though.
> >>>
> >>> Thanks,
> >>> softworkz
> >>>
> >>>
> >>
> >> That surprises me: The earlier code did exactly the same; in fact,
> >> using
> >> if (ARCH_*) is our typical check for arches in dsp-init code.
> >
> > I looked at this a bit further. It seems that the VS project
> > generation tool that I'm using is creating dummy definitions
> > for such cases. In the previous workspace it had generated
> >
> > void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp) {return;}
> >
> > in a separate code file for being able to work with the ffmpeg
> > code in VS without modifying any of the code.
> >
> > Now that you have moved that code to a header file, this logic
> > doesn't work anymore.
> >
>
> Why does your compiler not just eliminate dead code like all the
> others?
> Is this MSVC -O0 behaviour?
> I just sent the patch
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296380.html, but
> now
> that I read this I have to agree with Hendrik: Why not update your
> tool
> instead?
I'm using https://github.com/ShiftMediaProject/FFVS-Project-Generator
for years and I'm sure he will adapt.
When I had posted, the whole situation wasn't clear to me.
Thanks a lot for the patch!
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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 07/10] avfilter/vf_nlmeans: Move ff_nlmeans_init into a header
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Friday, May 13, 2022 11:27 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> ff_nlmeans_init into a header
>
> On Fri, May 13, 2022 at 11:26 AM Andreas Rheinhardt
> wrote:
> >
> > Soft Works:
> > >
> > >
> > >> -Original Message-
> > >> From: Andreas Rheinhardt
> > >> Sent: Friday, May 13, 2022 10:27 AM
> > >> To: Soft Works ; FFmpeg development
> discussions
> > >> and patches
> > >> Subject: Re: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans:
> Move
> > >> ff_nlmeans_init into a header
> > >>
> > >> Soft Works:
> > >>>
> > >>>
> > -Original Message-
> > From: ffmpeg-devel On Behalf
> Of
> > Andreas Rheinhardt
> > Sent: Tuesday, May 3, 2022 8:38 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Andreas Rheinhardt
> > Subject: [FFmpeg-devel] [PATCH 07/10] avfilter/vf_nlmeans: Move
> > ff_nlmeans_init into a header
> >
> > This removes a dependency of checkasm on lavfi/vf_nlmeans.o
> > and also allows to inline ff_nlmeans_init() irrespectively of
> > interposing.
> >
> > Signed-off-by: Andreas Rheinhardt
>
> > ---
> > >>>
> > >>> [..]
> > >>>
> > +
> > +static av_unused void ff_nlmeans_init(NLMeansDSPContext *dsp)
> > +{
> > +dsp->compute_safe_ssd_integral_image =
> > compute_safe_ssd_integral_image_c;
> > +dsp->compute_weights_line = compute_weights_line_c;
> > +
> > +if (ARCH_AARCH64)
> > +ff_nlmeans_init_aarch64(dsp);
> > >>>
> > >>> Hi Andreas,
> > >>>
> > >>> the above breaks compilation for me:
> > >>>
> > >>> 1>libavfilterd.lib(libavfilter_vf_nlmeans.obj) : error LNK2019:
> > >> unresolved external symbol ff_nlmeans_init_aarch64 referenced in
> > >> function ff_nlmeans_init
> > >>>
> > >>> The reason is that I'm (obviously) not compiling stuff from the
> > >>> libavfilter\aarch64 subfolder.
> > >>>
> > >>> It might need an #ifdef ?
> > >>>
> > >>> I haven't taken a deeper look at it, though.
> > >>>
> > >>> Thanks,
> > >>> softworkz
> > >>>
> > >>>
> > >>
> > >> That surprises me: The earlier code did exactly the same; in
> fact,
> > >> using
> > >> if (ARCH_*) is our typical check for arches in dsp-init code.
> > >
> > > I looked at this a bit further. It seems that the VS project
> > > generation tool that I'm using is creating dummy definitions
> > > for such cases. In the previous workspace it had generated
> > >
> > > void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp) {return;}
> > >
> > > in a separate code file for being able to work with the ffmpeg
> > > code in VS without modifying any of the code.
> > >
> > > Now that you have moved that code to a header file, this logic
> > > doesn't work anymore.
> > >
> >
> > Why does your compiler not just eliminate dead code like all the
> others?
> > Is this MSVC -O0 behaviour?
>
>
> MSVC does not do DCE when optimizations are disabled, yes. So this is
> where this is coming from.
>
> > I just sent the patch
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296380.html, but
> now
> > that I read this I have to agree with Hendrik: Why not update your
> tool
> > instead?
> >
>
> Actually looking at the tool, it seems like it handles header files.
> Did you actually re-run the generation tool after applying this patch?
Today I pulled HEAD and ran the tool (after I had pulled the latest
version of the tool and compiled it). It didn't detect the header
definition. That's why I wrote to Andreas.
Thanks a lot for your help!
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/libuavs3d: use output_reorder_delay as has_b_frames
has_b_frames is more than a bool, it's the size of the frame reordering buffer in the decoder. --- libavcodec/libuavs3d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c index 23de4c8cd5..e911963a41 100644 --- a/libavcodec/libuavs3d.c +++ b/libavcodec/libuavs3d.c @@ -206,7 +206,7 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx, AVFrame *frm, avctx->framerate.num = ff_avs3_frame_rate_tab[seqh->frame_rate_code].num; avctx->framerate.den = ff_avs3_frame_rate_tab[seqh->frame_rate_code].den; } -avctx->has_b_frames = !seqh->low_delay; +avctx->has_b_frames = seqh->output_reorder_delay; avctx->pix_fmt = seqh->bit_depth_internal == 8 ? AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV420P10LE; ret = ff_set_dimensions(avctx, seqh->horizontal_size, seqh->vertical_size); if (ret < 0) -- 2.35.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/avs3_parser: set has_b_frames properly
has_b_frames should be output_reorder_delay field in AVS3 sequence header and larger than 1. The parser implementation doesn't parse that field. Decoder can set has_b_frames properly, so use FFMAX here to avoid resetting has_b_frames from output_reorder_delay to 1. --- libavcodec/avs3_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/avs3_parser.c b/libavcodec/avs3_parser.c index d04d96a03a..0d2e940d1e 100644 --- a/libavcodec/avs3_parser.c +++ b/libavcodec/avs3_parser.c @@ -114,7 +114,7 @@ static void parse_avs3_nal_units(AVCodecParserContext *s, const uint8_t *buf, //bitrate_high(12) skip_bits(&gb, 32); -avctx->has_b_frames = !get_bits(&gb, 1); +avctx->has_b_frames = FFMAX(avctx->has_b_frames, !get_bits(&gb, 1)); avctx->framerate.num = avctx->time_base.den = ff_avs3_frame_rate_tab[ratecode].num; avctx->framerate.den = avctx->time_base.num = ff_avs3_frame_rate_tab[ratecode].den; -- 2.35.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avcodec/libdavs2: export has_b_frames info
More precisely, we should use picture_reorder_delay, but it's unavailable yet. --- libavcodec/libdavs2.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c index a47027d300..bc31745a4f 100644 --- a/libavcodec/libdavs2.c +++ b/libavcodec/libdavs2.c @@ -78,6 +78,12 @@ static int davs2_dump_frames(AVCodecContext *avctx, davs2_picture_t *pic, int *g avctx->height= headerset->height; avctx->pix_fmt = headerset->output_bit_depth == 10 ? AV_PIX_FMT_YUV420P10 : AV_PIX_FMT_YUV420P; +/* It should be picture_reorder_delay, but libdavs2 doesn't export that + * info. + * Use FFMAX since has_b_frames could be set by AVS2 parser in theory, + * which doesn't do it yet. + */ +avctx->has_b_frames = FFMAX(avctx->has_b_frames, !headerset->low_delay); avctx->framerate = av_d2q(headerset->frame_rate,4096); *got_frame = 0; -- 2.35.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/avs3_parser: set has_b_frames properly
Zhao Zhili: > has_b_frames should be output_reorder_delay field in AVS3 sequence > header and larger than 1. The parser implementation doesn't parse > that field. Decoder can set has_b_frames properly, so use FFMAX > here to avoid resetting has_b_frames from output_reorder_delay to 1. > --- > libavcodec/avs3_parser.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/avs3_parser.c b/libavcodec/avs3_parser.c > index d04d96a03a..0d2e940d1e 100644 > --- a/libavcodec/avs3_parser.c > +++ b/libavcodec/avs3_parser.c > @@ -114,7 +114,7 @@ static void parse_avs3_nal_units(AVCodecParserContext *s, > const uint8_t *buf, > //bitrate_high(12) > skip_bits(&gb, 32); > > -avctx->has_b_frames = !get_bits(&gb, 1); > +avctx->has_b_frames = FFMAX(avctx->has_b_frames, !get_bits(&gb, > 1)); > > avctx->framerate.num = avctx->time_base.den = > ff_avs3_frame_rate_tab[ratecode].num; > avctx->framerate.den = avctx->time_base.num = > ff_avs3_frame_rate_tab[ratecode].den; FFMAX can evaluate its arguments more than once which is not intended here. - 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] avfilter, avcodec/*_init.h: Use #if to disable code
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Friday, May 13, 2022 11:19 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH] avfilter, avcodec/*_init.h: Use #if to
> disable code
>
> Should fix the compilation issue reported in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
> and should also prevent such issues on arches other than X86.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/v210dec_init.h | 3 ++-
> libavcodec/v210enc_init.h | 3 ++-
> libavfilter/af_afirdsp.h| 3 ++-
> libavfilter/vf_blend_init.h | 3 ++-
> libavfilter/vf_eq.h | 3 ++-
> libavfilter/vf_gblur_init.h | 3 ++-
> libavfilter/vf_hflip_init.h | 3 ++-
> libavfilter/vf_nlmeans_init.h | 6 +++---
> libavfilter/vf_threshold_init.h | 3 ++-
> 9 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/v210dec_init.h b/libavcodec/v210dec_init.h
> index 305ab3911e..707c101ab0 100644
> --- a/libavcodec/v210dec_init.h
> +++ b/libavcodec/v210dec_init.h
> @@ -54,8 +54,9 @@ static void v210_planar_unpack_c(const uint32_t
> *src, uint16_t *y, uint16_t *u,
> static av_unused av_cold void ff_v210dec_init(V210DecContext *s)
> {
> s->unpack_frame = v210_planar_unpack_c;
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_v210_x86_init(s);
> +#endif
> }
>
> #endif /* AVCODEC_V210DEC_INIT_H */
> diff --git a/libavcodec/v210enc_init.h b/libavcodec/v210enc_init.h
> index 6d81cac319..09828d4a14 100644
> --- a/libavcodec/v210enc_init.h
> +++ b/libavcodec/v210enc_init.h
> @@ -83,8 +83,9 @@ static av_cold av_unused void
> ff_v210enc_init(V210EncContext *s)
> s->sample_factor_8 = 2;
> s->sample_factor_10 = 1;
>
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_v210enc_init_x86(s);
> +#endif
> }
>
> #endif /* AVCODEC_V210ENC_INIT_H */
> diff --git a/libavfilter/af_afirdsp.h b/libavfilter/af_afirdsp.h
> index 05182bebb4..8127194836 100644
> --- a/libavfilter/af_afirdsp.h
> +++ b/libavfilter/af_afirdsp.h
> @@ -54,8 +54,9 @@ static av_unused void
> ff_afir_init(AudioFIRDSPContext *dsp)
> {
> dsp->fcmul_add = fcmul_add_c;
>
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_afir_init_x86(dsp);
> +#endif
> }
>
> #endif /* AVFILTER_AFIRDSP_H */
> diff --git a/libavfilter/vf_blend_init.h b/libavfilter/vf_blend_init.h
> index 5fb2599490..b377219806 100644
> --- a/libavfilter/vf_blend_init.h
> +++ b/libavfilter/vf_blend_init.h
> @@ -194,8 +194,9 @@ static av_unused void ff_blend_init(FilterParams
> *param, int depth)
> param->blend = depth > 8 ? depth > 16 ?
> blend_copybottom_32 : blend_copybottom_16 : blend_copybottom_8;
> }
>
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_blend_init_x86(param, depth);
> +#endif
> }
>
> #endif /* AVFILTER_BLEND_INIT_H */
> diff --git a/libavfilter/vf_eq.h b/libavfilter/vf_eq.h
> index a5756977d2..d68fb7295e 100644
> --- a/libavfilter/vf_eq.h
> +++ b/libavfilter/vf_eq.h
> @@ -123,8 +123,9 @@ void ff_eq_init_x86(EQContext *eq);
> static av_unused void ff_eq_init(EQContext *eq)
> {
> eq->process = process_c;
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_eq_init_x86(eq);
> +#endif
> }
>
> #endif /* AVFILTER_EQ_H */
> diff --git a/libavfilter/vf_gblur_init.h b/libavfilter/vf_gblur_init.h
> index 0fee64bc98..9ff28c6f59 100644
> --- a/libavfilter/vf_gblur_init.h
> +++ b/libavfilter/vf_gblur_init.h
> @@ -115,8 +115,9 @@ static av_unused void ff_gblur_init(GBlurContext
> *s)
> s->horiz_slice = horiz_slice_c;
> s->verti_slice = verti_slice_c;
> s->postscale_slice = postscale_c;
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_gblur_init_x86(s);
> +#endif
> }
>
> #endif /* AVFILTER_GBLUR_INIT_H */
> diff --git a/libavfilter/vf_hflip_init.h b/libavfilter/vf_hflip_init.h
> index b58cfec901..63f9e3b92a 100644
> --- a/libavfilter/vf_hflip_init.h
> +++ b/libavfilter/vf_hflip_init.h
> @@ -101,8 +101,9 @@ static av_unused int ff_hflip_init(FlipContext *s,
> int step[4], int nb_planes)
> return AVERROR_BUG;
> }
> }
> -if (ARCH_X86)
> +#if ARCH_X86
> ff_hflip_init_x86(s, step, nb_planes);
> +#endif
>
> return 0;
> }
> diff --git a/libavfilter/vf_nlmeans_init.h
> b/libavfilter/vf_nlmeans_init.h
> index 04ad8801b6..87fca13b2e 100644
> --- a/libavfilter/vf_nlmeans_init.h
> +++ b/libavfilter/vf_nlmeans_init.h
> @@ -129,11 +129,11 @@ static av_unused void
> ff_nlmeans_init(NLMeansDSPContext *dsp)
> dsp->compute_safe_ssd_integral_image =
> compute_safe_ssd_integral_image_c;
> dsp->compute_weights_line = compute_weights_line_c;
>
> -if (ARCH_AARCH64)
> +#if ARCH_AARCH64
> ff_nlmeans_init_aarch64(dsp);
> -
> -if (ARCH_X86)
> +#elif ARCH_X86
> ff_nlmeans_init_x86(dsp);
> +#endif
> }
>
> #endif /* AVFILTER_NLMEANS_INIT_H */
> diff -
[FFmpeg-devel] [PATCH] fftools/opt_common: add missing include of avf/version.h
From: softworkz required for PRINT_LIB_INFO(avfilter... Signed-off-by: softworkz --- fftools/opt_common: add missing include of avf/version.h MSVC compiler complains without this include Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-27%2Fsoftworkz%2Fsubmit_version_include-v1 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-27/softworkz/submit_version_include-v1 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/27 fftools/opt_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fftools/opt_common.c b/fftools/opt_common.c index c303db4d09..5a5e35bd7f 100644 --- a/fftools/opt_common.c +++ b/fftools/opt_common.c @@ -51,6 +51,8 @@ #include "libavdevice/avdevice.h" #include "libavdevice/version.h" +#include "libavfilter/version.h" + #include "libswscale/swscale.h" #include "libswscale/version.h" base-commit: d2d8b9b972ba2df6b2a2ebe29f5307cbb7a69c33 -- ffmpeg-codebot ___ ffmpeg-devel mailing list ffmpeg-devel@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 0/2] Support long file names on Windows
This patchset adds support for long file and directory paths on Windows. The implementation follows the same logic that .NET is using internally, with the only exception that it doesn't expand short path components in 8.3 format. .NET does this as the same function is also used for other purposes, but in our case, that's not required. Short (8.3) paths are working as well with the extended path prefix, even when longer than 260. Successfully tested: * Regular paths wth drive letter * Regular UNC paths * Long paths wth drive letter * Long paths wth drive letter and forward slashes * Long UNC paths * Prefixed paths wth drive letter * Prefixed UNC paths I have kept the individual functions separate on purpose, to make it easy to compare with the .NET impl. (compilers should inlinie those anyway) softworkz (2): avutil/wchar_filename,file_open: Support long file names on Windows avformat/os_support: Support long file names on Windows libavformat/os_support.h | 8 +-- libavutil/file_open.c | 2 +- libavutil/wchar_filename.h | 123 + 3 files changed, 128 insertions(+), 5 deletions(-) base-commit: d2d8b9b972ba2df6b2a2ebe29f5307cbb7a69c33 Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-28%2Fsoftworkz%2Fsubmit_long_filenames-v1 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-28/softworkz/submit_long_filenames-v1 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/28 -- ffmpeg-codebot ___ ffmpeg-devel mailing list ffmpeg-devel@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/2] avutil/wchar_filename, file_open: Support long file names on Windows
From: softworkz
Signed-off-by: softworkz
---
libavutil/file_open.c | 2 +-
libavutil/wchar_filename.h | 123 +
2 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/libavutil/file_open.c b/libavutil/file_open.c
index cc302f2f76..57c5e78d51 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -45,7 +45,7 @@ static int win32_open(const char *filename_utf8, int oflag,
int pmode)
wchar_t *filename_w;
/* convert UTF-8 to wide chars */
-if (utf8towchar(filename_utf8, &filename_w))
+if (get_extended_win32_path(filename_utf8, &filename_w))
return -1;
if (!filename_w)
goto fallback;
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f082452c..94b4087de0 100644
--- a/libavutil/wchar_filename.h
+++ b/libavutil/wchar_filename.h
@@ -40,6 +40,129 @@ static inline int utf8towchar(const char *filename_utf8,
wchar_t **filename_w)
MultiByteToWideChar(CP_UTF8, 0, filename_utf8, -1, *filename_w, num_chars);
return 0;
}
+
+static inline int path_is_extended(const wchar_t *path)
+{
+// see .NET6: PathInternal.IsExtended()
+size_t len = wcslen(path);
+if (len >= 4 && path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?')
&& path[2] == L'?' && path[3] == L'\\')
+return 1;
+
+return 0;
+}
+
+static inline int get_full_path_name(wchar_t **ppath_w)
+{
+int num_chars;
+wchar_t *temp_w;
+
+// see .NET6: PathHelper.GetFullPathName()
+num_chars = GetFullPathNameW(*ppath_w, 0, NULL, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+temp_w = (wchar_t *)av_calloc(num_chars, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+
+num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+static inline int path_normalize(wchar_t **ppath_w)
+{
+int ret;
+
+// see .NET6: PathHelper.Normalize()
+if ((ret = get_full_path_name(ppath_w)) < 0)
+return ret;
+
+/* What .NET does at this point is to call
PathHelper.TryExpandShortFileName()
+ in case the path contains a '~' character.
+ We don't need to do this as we don't need to normalize the file name
+ for presentation, and the extended path prefix works with 8.3 path
+ components as well */
+return 0;
+}
+
+static inline int add_extended_prefix(wchar_t **ppath_w)
+{
+const wchar_t *unc_prefix = L"?\\UNC\\";
+const wchar_t *extended_path_prefix = L"?\\";
+const wchar_t *path_w = *ppath_w;
+const size_t len= wcslen(path_w);
+wchar_t *temp_w;
+
+if (len < 2)
+return 0;
+
+// see .NET6: PathInternal.EnsureExtendedPrefix()
+if (path_w[0] == L'\\' && path_w[1] == L'\\') {
+temp_w = (wchar_t *)av_calloc(len + 6 + 1, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+wcscpy(temp_w, unc_prefix);
+wcscat(temp_w, path_w + 2);
+} else {
+temp_w = (wchar_t *)av_calloc(len + 4 + 1, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+wcscpy(temp_w, extended_path_prefix);
+wcscat(temp_w, path_w);
+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+static inline int get_extended_win32_path(const char *path, wchar_t **ppath_w)
+{
+int ret;
+size_t len;
+
+// see .NET6: Path.GetFullPath() and Path.GetFullPathInternal()
+if ((ret = utf8towchar(path, ppath_w)) < 0)
+return ret;
+
+if (path_is_extended(*ppath_w)) {
+/* \\?\ paths are considered normalized by definition. Windows doesn't
normalize \\?\
+ paths and neither should we. Even if we wanted to, GetFullPathName
does not work
+ properly with device paths. If one wants to pass a \\?\ path
through normalization
+ one can chop off the prefix, pass it to GetFullPath and add it
again. */
+return 0;
+}
+
+if ((ret = path_normalize(ppath_w)) < 0)
+return ret;
+
+// see .NET6: PathInternal.EnsureExtendedPrefixIfNeeded()
+len = wcslen(*ppath_w);
+if (len >= 260 || (*ppath_w)[len - 1] == L' ' || (*ppath_w)[len - 1] ==
L'.') {
+if ((ret = add_extended_prefix(ppath_w)) < 0)
+return ret;
+}
+
+return 0;
+}
+
#endif
#endif /* AVUTIL_WCHAR_FILENAME_H */
--
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat/os_support: Support long file names on Windows
From: softworkz
Signed-off-by: softworkz
---
libavformat/os_support.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 5e6b32d2dc..6c1e6c3851 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -153,7 +153,7 @@ static inline int win32_##name(const char *filename_utf8) \
wchar_t *filename_w; \
int ret; \
\
-if (utf8towchar(filename_utf8, &filename_w)) \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
return -1;\
if (!filename_w) \
goto fallback;\
@@ -177,7 +177,7 @@ static inline int win32_##name(const char *filename_utf8,
partype par) \
wchar_t *filename_w; \
int ret; \
\
-if (utf8towchar(filename_utf8, &filename_w)) \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
return -1;\
if (!filename_w) \
goto fallback;\
@@ -199,9 +199,9 @@ static inline int win32_rename(const char *src_utf8, const
char *dest_utf8)
wchar_t *src_w, *dest_w;
int ret;
-if (utf8towchar(src_utf8, &src_w))
+if (get_extended_win32_path(src_utf8, &src_w))
return -1;
-if (utf8towchar(dest_utf8, &dest_w)) {
+if (get_extended_win32_path(dest_utf8, &dest_w)) {
av_free(src_w);
return -1;
}
--
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@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 0/2] Support long file names on Windows
> -Original Message- > From: ffmpegagent > Sent: Friday, May 13, 2022 11:53 AM > To: ffmpeg-devel@ffmpeg.org > Cc: softworkz > Subject: [PATCH 0/2] Support long file names on Windows > > This patchset adds support for long file and directory paths on > Windows. The > implementation follows the same logic that .NET is using internally, > with > the only exception that it doesn't expand short path components in 8.3 > format. .NET does this as the same function is also used for other > purposes, > but in our case, that's not required. Short (8.3) paths are working as > well > with the extended path prefix, even when longer than 260. > > Successfully tested: > > * Regular paths wth drive letter > * Regular UNC paths > * Long paths wth drive letter > * Long paths wth drive letter and forward slashes > * Long UNC paths > * Prefixed paths wth drive letter > * Prefixed UNC paths > > I have kept the individual functions separate on purpose, to make it > easy to > compare with the .NET impl. (compilers should inlinie those anyway) Forgot to mention that I tested this with builds from both, MSVC and MinGW/MSYS2 (gcc 10.3). sw ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] avcodec/avs3_parser: set has_b_frames properly
has_b_frames should be output_reorder_delay field in AVS3 sequence
header and larger than 1. The parser implementation doesn't parse
that field. Decoder can set has_b_frames properly, so use FFMAX
here to avoid resetting has_b_frames from output_reorder_delay to 1.
---
libavcodec/avs3_parser.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avs3_parser.c b/libavcodec/avs3_parser.c
index d04d96a03a..a9fd879e9d 100644
--- a/libavcodec/avs3_parser.c
+++ b/libavcodec/avs3_parser.c
@@ -71,7 +71,7 @@ static void parse_avs3_nal_units(AVCodecParserContext *s,
const uint8_t *buf,
if (buf[0] == 0x0 && buf[1] == 0x0 && buf[2] == 0x1) {
if (buf[3] == AVS3_SEQ_START_CODE) {
GetBitContext gb;
-int profile, ratecode;
+int profile, ratecode, low_delay;
init_get_bits8(&gb, buf + 4, buf_size - 4);
@@ -114,7 +114,8 @@ static void parse_avs3_nal_units(AVCodecParserContext *s,
const uint8_t *buf,
//bitrate_high(12)
skip_bits(&gb, 32);
-avctx->has_b_frames = !get_bits(&gb, 1);
+low_delay = get_bits(&gb, 1);
+avctx->has_b_frames = FFMAX(avctx->has_b_frames, !low_delay);
avctx->framerate.num = avctx->time_base.den =
ff_avs3_frame_rate_tab[ratecode].num;
avctx->framerate.den = avctx->time_base.num =
ff_avs3_frame_rate_tab[ratecode].den;
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] Add Mono/2D option to stereo3d filter
Is there anything that needs to be done on this to get it accepted and
merged?
On Mon, May 9, 2022 at 3:23 PM James Lancaster
wrote:
> The following patch adds the option for mono input to the stereo3d filter,
> allowing a 2D video source to be duplicated to any of the output formats.
>
> This enables a few things which I find very useful:
>
> 1. Playing regular videos on VR headsets.
> Using this to simply use the VR headset as a HMD without affecting
> anything else.
>
> Example usage: ffplay -vf stereo3d=mono:sbsl 2dvideofile.avi
>
> Will simply modify it to display everywhere.
>
> 2. Screen capture and display on VR headsets as a 2D video.
>
> This is something which for me works FAR better than any of the VR
> 'desktop' software which enables you to use your desktop in a VR space
> (which always gives me a headache). In fact even watching videos of it
> gives me a headache. Whereas I spent about 5 hours using my system this way
> yesterday with no headache or problems aside from that (well and the whole
> not being able to see things)
>
> Note for anyone using this: I do recommend only going lower to the same
> resolution or higher resolution, if possible.
>
> Examples: (Main monitor set at 1280x1024 and off, and the VR headset)
>
> Basic capture:
> ffplay -vf stereo3d=mono:sbsl -video_size 1280x1024 -f x11grab :0.0+0,0
>
> Also to pad it out, so you can see all of it. (Most Desktops aren't quite
> setup for circular view.) This adds a 300 px border around the left/right
> (and by default top bottom) which means that everything is in view in my
> headset.
>
> ffplay -vf pad=1580:1080:150:0,stereo3d=mono:sbsl -video_size 1280x1024
> -f x11grab :0.0+0,0
>
> The default is pretty much exactly what is needed (frame copied to both
> right and left output) this patch is pretty trivial, and I've used it on
> multiple versions, but forgot to submit the patch for it in the past.
>
> Since I don't see anything in particular about it, just to cover bases
> (And if there's anything I did wrong, let me know so I can fix it in future
> submissions):
> Permission to apply and redistribute under the GNU GPL v2 or later
> versions granted (As is the case for the file)
> 2022 James Lancaster
>
> ---
> libavfilter/vf_stereo3d.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
> index 0ba18861af..09397af14a 100644
> --- a/libavfilter/vf_stereo3d.c
> +++ b/libavfilter/vf_stereo3d.c
> @@ -66,6 +66,7 @@ enum StereoCode {
> INTERLEAVE_COLS_LR, // column-interleave (left eye first, right eye
> second)
> INTERLEAVE_COLS_RL, // column-interleave (right eye first, left eye
> second)
> HDMI, // HDMI frame pack (left eye first, right eye
> second)
> +MONO,// Mono input for 2d to 3d
> STEREO_CODE_COUNT // TODO: needs autodetection
> };
>
> @@ -177,6 +178,7 @@ static const AVOption stereo3d_options[] = {
> { "irr", "interleave rows right first", 0,
> AV_OPT_TYPE_CONST, {.i64=INTERLEAVE_ROWS_RL}, 0, 0, FLAGS, "in" },
> { "icl", "interleave columns left first", 0,
> AV_OPT_TYPE_CONST, {.i64=INTERLEAVE_COLS_LR}, 0, 0, FLAGS, "in" },
> { "icr", "interleave columns right first", 0,
> AV_OPT_TYPE_CONST, {.i64=INTERLEAVE_COLS_RL}, 0, 0, FLAGS, "in" },
> +{ "mono", "2D video",0,
> AV_OPT_TYPE_CONST, {.i64=MONO}, 0, 0, FLAGS, "in" },
> { "out", "set output format", OFFSET(out.format), AV_OPT_TYPE_INT,
> {.i64=ANAGLYPH_RC_DUBOIS}, 0, STEREO_CODE_COUNT-1, FLAGS, "out"},
> { "ab2l", "above below half height left first", 0,
> AV_OPT_TYPE_CONST, {.i64=ABOVE_BELOW_2_LR}, 0, 0, FLAGS, "out" },
> { "tb2l", "above below half height left first", 0,
> AV_OPT_TYPE_CONST, {.i64=ABOVE_BELOW_2_LR}, 0, 0, FLAGS, "out" },
> @@ -452,6 +454,8 @@ static int config_output(AVFilterLink *outlink)
> s->out.format != CHECKERBOARD_RL)
> s->height = inlink->h / 2;
> break;
> +case MONO:
> + break;
> default:
> av_log(ctx, AV_LOG_ERROR, "input format %d is not supported\n",
> s->in.format);
> return AVERROR(EINVAL);
> --
> 2.32.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 1/3] avcodec/avs3_parser: set has_b_frames properly
> On May 13, 2022, at 5:43 PM, Andreas Rheinhardt > wrote: > > Zhao Zhili: >> has_b_frames should be output_reorder_delay field in AVS3 sequence >> header and larger than 1. The parser implementation doesn't parse >> that field. Decoder can set has_b_frames properly, so use FFMAX >> here to avoid resetting has_b_frames from output_reorder_delay to 1. >> --- >> libavcodec/avs3_parser.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/avs3_parser.c b/libavcodec/avs3_parser.c >> index d04d96a03a..0d2e940d1e 100644 >> --- a/libavcodec/avs3_parser.c >> +++ b/libavcodec/avs3_parser.c >> @@ -114,7 +114,7 @@ static void parse_avs3_nal_units(AVCodecParserContext >> *s, const uint8_t *buf, >> //bitrate_high(12) >> skip_bits(&gb, 32); >> >> -avctx->has_b_frames = !get_bits(&gb, 1); >> +avctx->has_b_frames = FFMAX(avctx->has_b_frames, !get_bits(&gb, >> 1)); >> >> avctx->framerate.num = avctx->time_base.den = >> ff_avs3_frame_rate_tab[ratecode].num; >> avctx->framerate.den = avctx->time_base.num = >> ff_avs3_frame_rate_tab[ratecode].den; > > FFMAX can evaluate its arguments more than once which is not intended here. Good catch, thanks! Here is v2: http://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296396.html Use a variable low_delay to fix the FFMAX issue and serve as document. > > - Andreas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] Add Mono/2D option to stereo3d filter
fix commit log to be consistent with other commits already in repo. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/opt_common: add missing include of avf/version.h
softworkz: > From: softworkz > > required for PRINT_LIB_INFO(avfilter... > > Signed-off-by: softworkz > --- > fftools/opt_common: add missing include of avf/version.h > > MSVC compiler complains without this include > > Published-As: > https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-27%2Fsoftworkz%2Fsubmit_version_include-v1 > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg > pr-ffstaging-27/softworkz/submit_version_include-v1 > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/27 > > fftools/opt_common.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fftools/opt_common.c b/fftools/opt_common.c > index c303db4d09..5a5e35bd7f 100644 > --- a/fftools/opt_common.c > +++ b/fftools/opt_common.c > @@ -51,6 +51,8 @@ > #include "libavdevice/avdevice.h" > #include "libavdevice/version.h" > > +#include "libavfilter/version.h" > + > #include "libswscale/swscale.h" > #include "libswscale/version.h" > > > base-commit: d2d8b9b972ba2df6b2a2ebe29f5307cbb7a69c33 What does "complain" here mean? Compilation failure? It should already be included via opt_common.h->cmdutils.h->avfilter.h->lavfi/version.h. The latter inclusion relies on HAVE_AV_CONFIG_H to not be defined. It should only be defined for the libraries, not fftools, so if it is defined for you for this file your setup is wrong. That being said it is nevertheless good to include this and avfilter.h directly. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/csp: create public API for colorspace structs
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat.
---
libavfilter/colorspace.c| 88
libavfilter/colorspace.h| 25 +---
libavfilter/fflcms2.c | 3 +-
libavfilter/fflcms2.h | 2 +-
libavfilter/vf_colorspace.c | 9 +--
libavfilter/vf_iccdetect.c | 3 +-
libavutil/Makefile | 2 +
libavutil/csp.c | 111
libavutil/csp.h | 49
9 files changed, 173 insertions(+), 119 deletions(-)
create mode 100644 libavutil/csp.c
create mode 100644 libavutil/csp.h
diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
index 8d7b882375..f22e7002e1 100644
--- a/libavfilter/colorspace.c
+++ b/libavfilter/colorspace.c
@@ -107,94 +107,6 @@ static const double gbr_matrix[3][3] =
{ 0.5, -0.5, 0 },
};
-/*
- * All constants explained in e.g.
https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
- * The older ones (bt470bg/m) are also explained in their respective ITU docs
- * (e.g.
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-S!!PDF-E.pdf)
- * whereas the newer ones can typically be copied directly from wikipedia :)
- */
-static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
-[AVCOL_SPC_FCC]= { 0.30, 0.59, 0.11 },
-[AVCOL_SPC_BT470BG]= { 0.299, 0.587, 0.114 },
-[AVCOL_SPC_SMPTE170M] = { 0.299, 0.587, 0.114 },
-[AVCOL_SPC_BT709] = { 0.2126, 0.7152, 0.0722 },
-[AVCOL_SPC_SMPTE240M] = { 0.212, 0.701, 0.087 },
-[AVCOL_SPC_YCOCG] = { 0.25, 0.5,0.25 },
-[AVCOL_SPC_RGB]= { 1, 1, 1 },
-[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
-[AVCOL_SPC_BT2020_CL] = { 0.2627, 0.6780, 0.0593 },
-};
-
-const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace csp)
-{
-const struct LumaCoefficients *coeffs;
-
-if (csp >= AVCOL_SPC_NB)
-return NULL;
-coeffs = &luma_coefficients[csp];
-if (!coeffs->cr)
-return NULL;
-
-return coeffs;
-}
-
-#define WP_D65 { 0.3127, 0.3290 }
-#define WP_C { 0.3100, 0.3160 }
-#define WP_DCI { 0.3140, 0.3510 }
-#define WP_E { 1/3.0f, 1/3.0f }
-
-static const struct ColorPrimaries color_primaries[AVCOL_PRI_NB] = {
-[AVCOL_PRI_BT709] = { WP_D65, { 0.640, 0.330, 0.300, 0.600, 0.150,
0.060 } },
-[AVCOL_PRI_BT470M]= { WP_C, { 0.670, 0.330, 0.210, 0.710, 0.140,
0.080 } },
-[AVCOL_PRI_BT470BG] = { WP_D65, { 0.640, 0.330, 0.290, 0.600, 0.150,
0.060 } },
-[AVCOL_PRI_SMPTE170M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155,
0.070 } },
-[AVCOL_PRI_SMPTE240M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155,
0.070 } },
-[AVCOL_PRI_SMPTE428] = { WP_E, { 0.735, 0.265, 0.274, 0.718, 0.167,
0.009 } },
-[AVCOL_PRI_SMPTE431] = { WP_DCI, { 0.680, 0.320, 0.265, 0.690, 0.150,
0.060 } },
-[AVCOL_PRI_SMPTE432] = { WP_D65, { 0.680, 0.320, 0.265, 0.690, 0.150,
0.060 } },
-[AVCOL_PRI_FILM] = { WP_C, { 0.681, 0.319, 0.243, 0.692, 0.145,
0.049 } },
-[AVCOL_PRI_BT2020]= { WP_D65, { 0.708, 0.292, 0.170, 0.797, 0.131,
0.046 } },
-[AVCOL_PRI_JEDEC_P22] = { WP_D65, { 0.630, 0.340, 0.295, 0.605, 0.155,
0.077 } },
-};
-
-const struct ColorPrimaries *ff_get_color_primaries(enum AVColorPrimaries prm)
-{
-const struct ColorPrimaries *p;
-
-if (prm >= AVCOL_PRI_NB)
-return NULL;
-p = &color_primaries[prm];
-if (!p->prim.xr)
-return NULL;
-
-return p;
-}
-
-enum AVColorPrimaries ff_detect_color_primaries(const struct ColorPrimaries
*prm)
-{
-double delta;
-
-for (enum AVColorPrimaries p = 0; p < AVCOL_PRI_NB; p++) {
-const struct ColorPrimaries *ref = &color_primaries[p];
-if (!ref->prim.xr)
-continue;
-
-delta = fabs(prm->prim.xr - ref->prim.xr) +
-fabs(prm->prim.yr - ref->prim.yr) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->wp.xw - ref->wp.xw) +
-fabs(prm->wp.yw - ref->wp.yw);
-
-if (delta < 0.001)
-return p;
-}
-
-return AVCOL_PRI_UNSPECIFIED;
-}
-
void ff_fill_rgb2yuv_table(const struct LumaCoefficients *coeffs,
double rgb2yuv[3][3])
{
diff --git a/libavfilter/colorspace.h b/libavfilter/colorspace.h
index 6959133a49..c5f39baca8 100644
--- a/libavfilter/colorspace.h
+++ b/libavfilter/colorspace.h
@@ -20,43 +20,20 @@
#ifndef AVFILTER_COLORSPACE_H
#define AVFILTER_COLORSPACE_H
+#include "libavutil/csp.h"
#include "libavutil/frame.h"
#include "libavutil/pixfmt.h"
#define REFERENCE_WHITE 100.0f
-struct LumaCoefficients
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/ac3: Remove declaration of inexistent function
Andreas Rheinhardt:
> Removed in 7b11eead1b4e08728561595e6b610cf8fe2b7122.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ac3.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavcodec/ac3.h b/libavcodec/ac3.h
> index dabd49f4cc..8e66d47629 100644
> --- a/libavcodec/ac3.h
> +++ b/libavcodec/ac3.h
> @@ -214,8 +214,6 @@ typedef enum {
> EAC3_FRAME_TYPE_RESERVED
> } EAC3FrameType;
>
> -void ff_ac3_common_init(void);
> -
> /**
> * Calculate the log power-spectral density of the input signal.
> * This gives a rough estimate of signal power in the frequency domain by
> using
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/2] avcodec/wrapped_avframe: Don't attach FrameDecodeData unnecessarily
Andreas Rheinhardt:
> It is unneeded, as this decoder does not call ff_get_buffer().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/wrapped_avframe.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
> index 3af007d478..06c274eed0 100644
> --- a/libavcodec/wrapped_avframe.c
> +++ b/libavcodec/wrapped_avframe.c
> @@ -98,12 +98,6 @@ static int wrapped_avframe_decode(AVCodecContext *avctx,
> AVFrame *out,
>
> av_frame_move_ref(out, in);
>
> -err = ff_attach_decode_data(out);
> -if (err < 0) {
> -av_frame_unref(out);
> -return err;
> -}
> -
> *got_frame = 1;
> return 0;
> }
Will apply this patch tomorrow.
And I'd really hope that someone can review and/or test patch 2/2.
- 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] avutil/csp: create public API for colorspace structs
Hi, On Fri, May 13, 2022 at 11:42 AM Leo Izen wrote: > This commit moves some of the functionality from avfilter/colorspace > into avutil/csp and exposes it as a public API so it can be used by > libavcodec and/or libavformat. > --- > libavfilter/colorspace.c| 88 > libavfilter/colorspace.h| 25 +--- > libavfilter/fflcms2.c | 3 +- > libavfilter/fflcms2.h | 2 +- > libavfilter/vf_colorspace.c | 9 +-- > libavfilter/vf_iccdetect.c | 3 +- > libavutil/Makefile | 2 + > libavutil/csp.c | 111 > libavutil/csp.h | 49 > 9 files changed, 173 insertions(+), 119 deletions(-) > create mode 100644 libavutil/csp.c > create mode 100644 libavutil/csp.h > I don't have objections. 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".
Re: [FFmpeg-devel] [PATCH] avutil/csp: create public API for colorspace structs
On 5/13/2022 12:42 PM, Leo Izen wrote:
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat.
If it's of no use for library users, then make them avpriv_ and not
installed.
---
libavfilter/colorspace.c| 88
libavfilter/colorspace.h| 25 +---
libavfilter/fflcms2.c | 3 +-
libavfilter/fflcms2.h | 2 +-
libavfilter/vf_colorspace.c | 9 +--
libavfilter/vf_iccdetect.c | 3 +-
libavutil/Makefile | 2 +
libavutil/csp.c | 111
libavutil/csp.h | 49
9 files changed, 173 insertions(+), 119 deletions(-)
create mode 100644 libavutil/csp.c
create mode 100644 libavutil/csp.h
diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
index 8d7b882375..f22e7002e1 100644
--- a/libavfilter/colorspace.c
+++ b/libavfilter/colorspace.c
@@ -107,94 +107,6 @@ static const double gbr_matrix[3][3] =
{ 0.5, -0.5, 0 },
};
-/*
- * All constants explained in e.g.
https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
- * The older ones (bt470bg/m) are also explained in their respective ITU docs
- * (e.g.
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-S!!PDF-E.pdf)
- * whereas the newer ones can typically be copied directly from wikipedia :)
- */
-static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
-[AVCOL_SPC_FCC]= { 0.30, 0.59, 0.11 },
-[AVCOL_SPC_BT470BG]= { 0.299, 0.587, 0.114 },
-[AVCOL_SPC_SMPTE170M] = { 0.299, 0.587, 0.114 },
-[AVCOL_SPC_BT709] = { 0.2126, 0.7152, 0.0722 },
-[AVCOL_SPC_SMPTE240M] = { 0.212, 0.701, 0.087 },
-[AVCOL_SPC_YCOCG] = { 0.25, 0.5,0.25 },
-[AVCOL_SPC_RGB]= { 1, 1, 1 },
-[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
-[AVCOL_SPC_BT2020_CL] = { 0.2627, 0.6780, 0.0593 },
-};
-
-const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace csp)
-{
-const struct LumaCoefficients *coeffs;
-
-if (csp >= AVCOL_SPC_NB)
-return NULL;
-coeffs = &luma_coefficients[csp];
-if (!coeffs->cr)
-return NULL;
-
-return coeffs;
-}
-
-#define WP_D65 { 0.3127, 0.3290 }
-#define WP_C { 0.3100, 0.3160 }
-#define WP_DCI { 0.3140, 0.3510 }
-#define WP_E { 1/3.0f, 1/3.0f }
-
-static const struct ColorPrimaries color_primaries[AVCOL_PRI_NB] = {
-[AVCOL_PRI_BT709] = { WP_D65, { 0.640, 0.330, 0.300, 0.600, 0.150,
0.060 } },
-[AVCOL_PRI_BT470M]= { WP_C, { 0.670, 0.330, 0.210, 0.710, 0.140,
0.080 } },
-[AVCOL_PRI_BT470BG] = { WP_D65, { 0.640, 0.330, 0.290, 0.600, 0.150,
0.060 } },
-[AVCOL_PRI_SMPTE170M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155,
0.070 } },
-[AVCOL_PRI_SMPTE240M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155,
0.070 } },
-[AVCOL_PRI_SMPTE428] = { WP_E, { 0.735, 0.265, 0.274, 0.718, 0.167,
0.009 } },
-[AVCOL_PRI_SMPTE431] = { WP_DCI, { 0.680, 0.320, 0.265, 0.690, 0.150,
0.060 } },
-[AVCOL_PRI_SMPTE432] = { WP_D65, { 0.680, 0.320, 0.265, 0.690, 0.150,
0.060 } },
-[AVCOL_PRI_FILM] = { WP_C, { 0.681, 0.319, 0.243, 0.692, 0.145,
0.049 } },
-[AVCOL_PRI_BT2020]= { WP_D65, { 0.708, 0.292, 0.170, 0.797, 0.131,
0.046 } },
-[AVCOL_PRI_JEDEC_P22] = { WP_D65, { 0.630, 0.340, 0.295, 0.605, 0.155,
0.077 } },
-};
-
-const struct ColorPrimaries *ff_get_color_primaries(enum AVColorPrimaries prm)
-{
-const struct ColorPrimaries *p;
-
-if (prm >= AVCOL_PRI_NB)
-return NULL;
-p = &color_primaries[prm];
-if (!p->prim.xr)
-return NULL;
-
-return p;
-}
-
-enum AVColorPrimaries ff_detect_color_primaries(const struct ColorPrimaries
*prm)
-{
-double delta;
-
-for (enum AVColorPrimaries p = 0; p < AVCOL_PRI_NB; p++) {
-const struct ColorPrimaries *ref = &color_primaries[p];
-if (!ref->prim.xr)
-continue;
-
-delta = fabs(prm->prim.xr - ref->prim.xr) +
-fabs(prm->prim.yr - ref->prim.yr) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->wp.xw - ref->wp.xw) +
-fabs(prm->wp.yw - ref->wp.yw);
-
-if (delta < 0.001)
-return p;
-}
-
-return AVCOL_PRI_UNSPECIFIED;
-}
-
void ff_fill_rgb2yuv_table(const struct LumaCoefficients *coeffs,
double rgb2yuv[3][3])
{
diff --git a/libavfilter/colorspace.h b/libavfilter/colorspace.h
index 6959133a49..c5f39baca8 100644
--- a/libavfilter/colorspace.h
+++ b/libavfilter/colorspace.h
@@ -20,43 +20,20 @@
#ifndef AVFILTER_COLORSPACE_H
#define AVFILTER_COLORSPACE_H
+
[FFmpeg-devel] [PATCH] Add FourCC codes for Hap R and Hap HDR
Signed-off-by: Malcolm Bechard
---
libavformat/isom_tags.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index 62e60470a8..24953b9821 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -237,6 +237,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
{ AV_CODEC_ID_HAP, MKTAG('H', 'a', 'p', 'Y') },
{ AV_CODEC_ID_HAP, MKTAG('H', 'a', 'p', 'A') },
{ AV_CODEC_ID_HAP, MKTAG('H', 'a', 'p', 'M') },
+{ AV_CODEC_ID_HAP, MKTAG('H', 'a', 'p', '7') },
+{ AV_CODEC_ID_HAP, MKTAG('H', 'a', 'p', 'H') },
{ AV_CODEC_ID_DXV, MKTAG('D', 'X', 'D', '3') },
{ AV_CODEC_ID_DXV, MKTAG('D', 'X', 'D', 'I') },
--
2.29.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] avutil/csp: create public API for colorspace structs
On Fri, May 13, 2022 at 11:42:08AM -0400, Leo Izen wrote:
> This commit moves some of the functionality from avfilter/colorspace
> into avutil/csp and exposes it as a public API so it can be used by
> libavcodec and/or libavformat.
[...]
> diff --git a/libavutil/csp.h b/libavutil/csp.h
> new file mode 100644
> index 00..1bcde7ddd3
> --- /dev/null
> +++ b/libavutil/csp.h
> @@ -0,0 +1,49 @@
> +/*
> + * Copyright (c) 2016 Ronald S. Bultje
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#ifndef AVUTIL_CSP_H
> +#define AVUTIL_CSP_H
> +
> +#include "libavutil/frame.h"
> +#include "libavutil/pixfmt.h"
> +
> +struct LumaCoefficients {
> +double cr, cg, cb;
> +};
> +
> +struct PrimaryCoefficients {
> +double xr, yr, xg, yg, xb, yb;
> +};
> +
> +struct WhitepointCoefficients {
> +double xw, yw;
> +};
I think we should avoid floating point so as to ensure reproduceable
results and simplify regerssion testing
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued
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] fftools/opt_common: add missing include of avf/version.h
> -Original Message- > From: ffmpeg-devel On Behalf Of > Andreas Rheinhardt > Sent: Friday, May 13, 2022 3:33 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] fftools/opt_common: add missing > include of avf/version.h > > softworkz: > > From: softworkz > > > > required for PRINT_LIB_INFO(avfilter... > > > > Signed-off-by: softworkz > > --- > > fftools/opt_common: add missing include of avf/version.h > > > > MSVC compiler complains without this include > > > > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr- > ffstaging-27%2Fsoftworkz%2Fsubmit_version_include-v1 > > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr- > ffstaging-27/softworkz/submit_version_include-v1 > > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/27 > > > > fftools/opt_common.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/fftools/opt_common.c b/fftools/opt_common.c > > index c303db4d09..5a5e35bd7f 100644 > > --- a/fftools/opt_common.c > > +++ b/fftools/opt_common.c > > @@ -51,6 +51,8 @@ > > #include "libavdevice/avdevice.h" > > #include "libavdevice/version.h" > > > > +#include "libavfilter/version.h" > > + > > #include "libswscale/swscale.h" > > #include "libswscale/version.h" > > > > > > base-commit: d2d8b9b972ba2df6b2a2ebe29f5307cbb7a69c33 > > What does "complain" here mean? Compilation failure? > It should already be included via > opt_common.h->cmdutils.h->avfilter.h->lavfi/version.h. The latter > inclusion relies on HAVE_AV_CONFIG_H to not be defined. It should only > be defined for the libraries, not fftools, so if it is defined for you > for this file your setup is wrong. You are right. HAVE_AV_CONFIG_H is defined also for the tools binaries. But this seems to be the only case where it causes an issue. > That being said it is nevertheless good to include this and avfilter.h > directly. Looking at the generation tool, it seems to be quite a complex task to shape things in a way that it can be compiled with VS... I can't speak for the author of the tool, but I think when at least some cases that can easily be avoided (to require workarounds) at the ffmpeg side, then it would be a good thing. In that specific case, the version.h files from ALL libs are included just not from avfilter, so I think it would also add to clarity to include it directly. Similar goes for the DCE issue. For me there's just more clarity when those bits are guarded by #if blocks, but I don't want to open a discussion about that. Just thank you for the quick patch to resolve it! Kind regards, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message-
> From: ffmpeg-devel On Behalf Of nil-
> admir...@mailo.com
> Sent: Wednesday, May 11, 2022 10:57 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
>
> > I think that can be changed easily.
>
> How about writing the necessary patches yourself?
I did and submitted today.
> > The prefixing can be implemented as a function and then be used
> > in file_open.c.
> > Other file system related functions like mkdir, rename, rmdir, etc.
> > are already intercepted in os_support.h, and the prefixing can be
> > applied there.
>
> I haven't found path concat in these headers. What I did find,
> however,
> is the use of snprintf with forward slash separators right inside the
> #ifdef _WIN32:
>
> #if defined(_WIN32) || defined (__ANDROID__) || defined(__DJGPP__)
> if (fd < 0) {
> snprintf(*filename, len, "./%sXX", prefix);
> fd = mkstemp(*filename);
> }
> #endif
All these paths end up either in win32_open (in file_open.c) or in
one of the functions mapped inside os_support.h where they are now
(with my submitted patchset) handled by the get_extended_win32_path()
function, which handles all cases (e.g. forward slashes, relative paths,
prefixed, non-prefixed, UNC, drive letters, long, short, etc.) in
the same way as .NET does.
> > I have not fully analyzed the situation,
> > but surely there are just a small number of places that need to
> > be changed and not 587.
>
> 587 was obtained with fgrep snprintf **/*.c | wc -l (became 588 after
> a recent pull).
> At least two of these uses of snprintf correspond to path
> concatenation,
> and have been already presented here. Not all of them do, but I have
> no interest
> in examining the other 586 cases. But if you think that it's easy,
> well go ahead.
I did that now, and you can see that it's as easy as I said.
IMO, submitting "competing" patches is not a nice behavior in general,
I only did that because you asked me to.
Hence, I didn't include replacements for those of your commits that I
think are still valid; they should be merged as well, even though
they are just covering niche cases and are not that much relevant
to "long path support" in general, which is from my understanding
primarily about being able to access input and output files on long
paths rather than running ffmpeg.exe (et al.) residing at a long
path location.
Kind regards,
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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/libuavs3d: use output_reorder_delay as has_b_frames
On Fri, May 13, 2022 at 5:41 PM Zhao Zhili wrote: > > has_b_frames is more than a bool, it's the size of the frame > reordering buffer in the decoder. > --- > libavcodec/libuavs3d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c > index 23de4c8cd5..e911963a41 100644 > --- a/libavcodec/libuavs3d.c > +++ b/libavcodec/libuavs3d.c > @@ -206,7 +206,7 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx, > AVFrame *frm, > avctx->framerate.num = > ff_avs3_frame_rate_tab[seqh->frame_rate_code].num; > avctx->framerate.den = > ff_avs3_frame_rate_tab[seqh->frame_rate_code].den; > } > -avctx->has_b_frames = !seqh->low_delay; > +avctx->has_b_frames = seqh->output_reorder_delay; The same case, AVS3 uses output_reorder_delay but AVS2 uses low_delay, which is a bit strange > avctx->pix_fmt = seqh->bit_depth_internal == 8 ? > AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV420P10LE; > ret = ff_set_dimensions(avctx, seqh->horizontal_size, > seqh->vertical_size); > if (ret < 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] avutil/csp: create public API for colorspace structs
On 5/13/22 17:22, Michael Niedermayer wrote:
On Fri, May 13, 2022 at 11:42:08AM -0400, Leo Izen wrote:
+
+struct WhitepointCoefficients {
+double xw, yw;
+};
I think we should avoid floating point so as to ensure reproduceable
results and simplify regerssion testing
thx
This code already exists in master right now in libavfilter/colorspace,
so changing these from floats to AVRational would require a bit more
work than just a movement.
- Leo Izen (thebombzen)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/csp: create public API for colorspace structs
On 5/13/22 15:18, James Almer wrote: On 5/13/2022 12:42 PM, Leo Izen wrote: This commit moves some of the functionality from avfilter/colorspace into avutil/csp and exposes it as a public API so it can be used by libavcodec and/or libavformat. If it's of no use for library users, then make them avpriv_ and not installed. I was told a public API would be useful for this. I recall haasn and Lynne voicing support on IRC, but maybe I misinterpreted what they meant. - Leo Izen (thebombzen) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/libuavs3d: use output_reorder_delay as has_b_frames
> On May 14, 2022, at 9:04 AM, myp...@gmail.com wrote: > > On Fri, May 13, 2022 at 5:41 PM Zhao Zhili wrote: >> >> has_b_frames is more than a bool, it's the size of the frame >> reordering buffer in the decoder. >> --- >> libavcodec/libuavs3d.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c >> index 23de4c8cd5..e911963a41 100644 >> --- a/libavcodec/libuavs3d.c >> +++ b/libavcodec/libuavs3d.c >> @@ -206,7 +206,7 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx, >> AVFrame *frm, >> avctx->framerate.num = >> ff_avs3_frame_rate_tab[seqh->frame_rate_code].num; >> avctx->framerate.den = >> ff_avs3_frame_rate_tab[seqh->frame_rate_code].den; >> } >> -avctx->has_b_frames = !seqh->low_delay; >> +avctx->has_b_frames = seqh->output_reorder_delay; > The same case, AVS3 uses output_reorder_delay but AVS2 uses low_delay, > which is a bit strange Patch 3/3 explains why: it should be picture_reorder_delay, but it’s not available in libdavs2’s public API. >> avctx->pix_fmt = seqh->bit_depth_internal == 8 ? >> AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV420P10LE; >> ret = ff_set_dimensions(avctx, seqh->horizontal_size, >> seqh->vertical_size); >> if (ret < 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".
