[FFmpeg-devel] [PATCH v2 2/2] lavc/vulkan_av1: port to the new stable API
Most of this patch was written by Dave Airlie ,
with some additions by me.
v2 changes: the RefFrameSignBias field is in fact a bitmask
Patch attached.
>From d5bed9a6baa57cc4bbe591b0e09bc888a6e34009 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 19 Jan 2024 10:49:02 +1000
Subject: [PATCH v2 2/2] lavc/vulkan_av1: port to the new stable API
Most of this patch was written by Dave Airlie ,
with some additions by me.
---
libavcodec/Makefile | 3 +-
libavcodec/vulkan_av1.c | 463 ++
libavcodec/vulkan_decode.c| 24 +-
libavcodec/vulkan_decode.h| 2 +-
libavcodec/vulkan_video.c | 33 +-
libavcodec/vulkan_video.h | 3 +-
libavcodec/vulkan_video_codec_av1std.h| 403 ---
libavcodec/vulkan_video_codec_av1std_decode.h | 36 --
libavutil/hwcontext_vulkan.c | 2 +-
libavutil/vulkan_functions.h | 2 +-
libavutil/vulkan_loader.h | 2 +-
11 files changed, 304 insertions(+), 669 deletions(-)
delete mode 100644 libavcodec/vulkan_video_codec_av1std.h
delete mode 100644 libavcodec/vulkan_video_codec_av1std_decode.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 470d7cb9b1..581415f3b7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1262,7 +1262,6 @@ SKIPHEADERS+= %_tablegen.h \
aacenc_quantization.h \
aacenc_quantization_misc.h\
bitstream_template.h \
- vulkan_video_codec_av1std.h \
$(ARCH)/vpx_arith.h \
SKIPHEADERS-$(CONFIG_AMF) += amfenc.h
@@ -1285,7 +1284,7 @@ SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_decode.h vaapi_hevc.h vaapi_encode.h
SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vt_internal.h
-SKIPHEADERS-$(CONFIG_VULKAN) += vulkan.h vulkan_video.h vulkan_decode.h vulkan_video_codec_av1std_decode.h
+SKIPHEADERS-$(CONFIG_VULKAN) += vulkan.h vulkan_video.h vulkan_decode.h
SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h v4l2_context.h v4l2_m2m.h
SKIPHEADERS-$(CONFIG_ZLIB) += zlib_wrapper.h
diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c
index 9730e4b08d..538b81b648 100644
--- a/libavcodec/vulkan_av1.c
+++ b/libavcodec/vulkan_av1.c
@@ -35,18 +35,33 @@ typedef struct AV1VulkanDecodePicture {
*Can be removed once no longer needed, and threading can be enabled. */
FFVulkanDecodeContext *dec;
-StdVideoAV1MESATiletiles[MAX_TILES];
-StdVideoAV1MESATileListtile_list;
-const uint32_t*tile_offsets;
+uint32_t tile_count;
+uint32_t tile_offsets_s[MAX_TILES];
+uint32_t tile_sizes[MAX_TILES];
+const uint32_t *tile_offsets;
/* Current picture */
-VkVideoDecodeAV1DpbSlotInfoMESAvkav1_ref;
-StdVideoAV1MESAFrameHeader av1_frame_header;
-VkVideoDecodeAV1PictureInfoMESAav1_pic_info;
+StdVideoDecodeAV1ReferenceInfo std_ref;
+VkVideoDecodeAV1DpbSlotInfoKHR vkav1_ref;
+uint16_t width_in_sbs_minus1[64];
+uint16_t height_in_sbs_minus1[64];
+uint16_t mi_col_starts[64];
+uint16_t mi_row_starts[64];
+StdVideoAV1TileInfo tile_info;
+StdVideoAV1Quantization quantization;
+StdVideoAV1Segmentation segmentation;
+StdVideoAV1LoopFilter loop_filter;
+StdVideoAV1CDEF cdef;
+StdVideoAV1LoopRestoration loop_restoration;
+StdVideoAV1GlobalMotion global_motion;
+StdVideoAV1FilmGrain film_grain;
+StdVideoDecodeAV1PictureInfostd_pic_info;
+VkVideoDecodeAV1PictureInfoKHR av1_pic_info;
/* Picture refs */
const AV1Frame *ref_src [AV1_NUM_REF_FRAMES];
-VkVideoDecodeAV1DpbSlotInfoMESA vkav1_refs[AV1_NUM_REF_FRAMES];
+StdVideoDecodeAV1ReferenceInfo std_ref_info[AV1_NUM_REF_FRAMES];
+VkVideoDecodeAV1DpbSlotInfoKHR vkav1_refs[AV1_NUM_REF_FRAMES];
uint8_t frame_id_set;
uint8_t frame_id;
@@ -55,44 +70,66 @@ typedef struct AV1VulkanDecodePicture {
static int vk_av1_fill_pict(AVCodecContext *avctx, const AV1Frame **ref_src,
VkVideoReferenceSlotInfoKHR *ref_slot, /* Main structure */
VkVideoPictureResourceInfoKHR *ref, /* Goes in ^ */
-VkVideoDecodeAV1DpbSlotInfoMESA *vkav1_ref, /* Goes in ^ */
-const AV1Frame *pic, int is_current, int has_grain,
-int dpb_slot_index)
+
[FFmpeg-devel] [PATCH v2 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias
Needed for AV1.
v2 changes: moved ref_frame_sign_bias to the CodedBitstreamAV1Context structure
Patch attached.
>From d720dcbe3da223f7f228a4525e5b9fc3b114ebc6 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 2 Feb 2024 03:54:06 +0100
Subject: [PATCH v2 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias
Needed for AV1.
---
libavcodec/cbs_av1.h | 1 +
libavcodec/cbs_av1_syntax_template.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index a5402f069d..bf3047fc42 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -465,6 +465,7 @@ typedef struct CodedBitstreamAV1Context {
int tile_num;
AV1ReferenceFrameState ref[AV1_NUM_REF_FRAMES];
+uint8_t ref_frame_sign_bias[AV1_NUM_REF_FRAMES];
// AVOptions
int operating_point;
diff --git a/libavcodec/cbs_av1_syntax_template.c b/libavcodec/cbs_av1_syntax_template.c
index 3be1f2d30f..e6fd7f8a93 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1572,6 +1572,16 @@ static int FUNC(uncompressed_header)(CodedBitstreamContext *ctx, RWContext *rw,
}
if (!frame_is_intra) {
+for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
+if (seq->enable_order_hint) {
+int idx = current->ref_frame_idx[i];
+int hint = current->ref_order_hint[idx];
+priv->ref_frame_sign_bias[i] = cbs_av1_get_relative_dist(seq, hint,
+ priv->order_hint) > 0;
+} else {
+priv->ref_frame_sign_bias[i] = 0;
+}
+}
// Derive reference frame sign biases.
}
--
2.43.0.381.gb435a96ce8
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/vulkan_decode: Make Vulkan decode less spammy in verbose logs
Feb 7, 2024, 03:11 by kaspe...@gmail.com: > Drop per frame decode messages to AV_LOG_TRACE level. > > Signed-off-by: Kacper Michajłow > --- > libavcodec/vulkan_av1.c | 2 +- > libavcodec/vulkan_h264.c | 2 +- > libavcodec/vulkan_hevc.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c > index 9730e4b08d..c7d5a54012 100644 > --- a/libavcodec/vulkan_av1.c > +++ b/libavcodec/vulkan_av1.c > @@ -530,7 +530,7 @@ static int vk_av1_end_frame(AVCodecContext *avctx) > rav[i] = ap->ref_src[i]->f; > } > > -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, > %i tiles\n", > +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i > tiles\n", > vp->slices_size, ap->tile_list.nb_tiles); > > return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp); > diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c > index 39c123ddca..c918dbaa13 100644 > --- a/libavcodec/vulkan_h264.c > +++ b/libavcodec/vulkan_h264.c > @@ -529,7 +529,7 @@ static int vk_h264_end_frame(AVCodecContext *avctx) > rav[i] = hp->ref_src[i]->f; > } > > -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, > %i slices\n", > +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i > slices\n", > vp->slices_size, hp->h264_pic_info.sliceCount); > > return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp); > diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c > index 033172cbd6..0f6f2e775b 100644 > --- a/libavcodec/vulkan_hevc.c > +++ b/libavcodec/vulkan_hevc.c > @@ -903,7 +903,7 @@ static int vk_hevc_end_frame(AVCodecContext *avctx) > rvp[i] = >vp; > } > > -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, > %i slices\n", > +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i > slices\n", > vp->slices_size, hp->h265_pic_info.sliceSegmentCount); > > return ff_vk_decode_frame(avctx, pic->frame, vp, rav, rvp); > I don't agree with this, without this print, you have no idea if hardware decoding is even being used. MP4 parsing is far too noisy than a single print per frame. ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
> On Feb 6, 2024, at 10:17 AM, Michael Niedermayer > wrote: > > if "merge to git master" is a requirement then iam not participating > in this. The risk simply outweights the gain. I wont work for months to > then be at the mercy of not a single of 2000 subscribers posting some > "i object" and all 2000 know in this situation it would cause an > inconvenience to me. It doesn't have to be all or nothing. In addition to having smaller milestones so that it's not months of work that are at risk, the milestones can also split between things like initial design is ready, a functional prototype is built, the initial patchset of the final solution is ready for review, the work is merged, etc. I believe the benefit of picking experienced developers (with over 100 authored commits) is that the work is done by people that have demonstrated they know how to get their changes merged. And they should have a good intuition for what kind of work is going to be accepted and what kind of work won't. Worst case scenario they can take it up wih the TC although building consensus on the approach ahead of time rather than after months of work might be preferable. At the same time this work will be done by established developers who presumably have much more to lose from trying to game the system than they will get paid for a one-off project. If they do a good job there will likely be more work going their way in the future. If they try to cheat there probably won't be. So it should be reasonable to expect some good faith payments along the way even before everything is merged. Given all that perhaps 75% is due at the time the work is ready for review and 25% after it is merged, etc. Whatever the split I do think it's important to have a reasonable part of the payment tied to getting the work merged, while at the same time not expecting developers to work for months and have 100% of the funds tied up in contentious patch review. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@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/vulkan_decode: Make Vulkan decode less spammy in verbose logs
Drop per frame decode messages to AV_LOG_TRACE level. Signed-off-by: Kacper Michajłow --- libavcodec/vulkan_av1.c | 2 +- libavcodec/vulkan_h264.c | 2 +- libavcodec/vulkan_hevc.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c index 9730e4b08d..c7d5a54012 100644 --- a/libavcodec/vulkan_av1.c +++ b/libavcodec/vulkan_av1.c @@ -530,7 +530,7 @@ static int vk_av1_end_frame(AVCodecContext *avctx) rav[i] = ap->ref_src[i]->f; } -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i tiles\n", +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i tiles\n", vp->slices_size, ap->tile_list.nb_tiles); return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp); diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c index 39c123ddca..c918dbaa13 100644 --- a/libavcodec/vulkan_h264.c +++ b/libavcodec/vulkan_h264.c @@ -529,7 +529,7 @@ static int vk_h264_end_frame(AVCodecContext *avctx) rav[i] = hp->ref_src[i]->f; } -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i slices\n", +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i slices\n", vp->slices_size, hp->h264_pic_info.sliceCount); return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp); diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c index 033172cbd6..0f6f2e775b 100644 --- a/libavcodec/vulkan_hevc.c +++ b/libavcodec/vulkan_hevc.c @@ -903,7 +903,7 @@ static int vk_hevc_end_frame(AVCodecContext *avctx) rvp[i] = >vp; } -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i slices\n", +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i slices\n", vp->slices_size, hp->h265_pic_info.sliceSegmentCount); return ff_vk_decode_frame(avctx, pic->frame, vp, rav, rvp); -- 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 6:04 PM Michael Niedermayer wrote: > I think you should sign a SoW that has "Merged in git master" as a > Deliverable > I already did. It was fine. > PS: do you have a single person willing to sign this Deliverable you > want ? > If not, how will the STF thing work ? > You're asking for community input for your proposal, I gave comments as requested. It's OK to disagree on things, happens all the time. You can A) ignore my suggestions and submit the proposal to STF anyway, B) submit a proposal to STF as yourself rather than as FFmpeg (but for the same tasks, on FFmpeg), C) submit a proposal using another company/non-profit (e.g. fflabs), D) not submit a proposal to STF, or E) something else ??? 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 v7 1/2] libavformat/dvdvideo: add DVD-Video demuxer powered by libdvdnav and libdvdread
Thank you for your time and detailed review. I will clean all this up and
send v9
On Tue, Feb 6, 2024 at 6:53 PM Stefano Sabatini wrote:
> On date Sunday 2024-02-04 23:48:25 -0600, Marth64 wrote:
> > Sorry for the quick follow-up to v6, I wanted to get this update out now
> hopefully
> > before v6 is actually reviewed. v7 fixes a few documentation typos,
> options descriptions,
> > and log messages: nothing major. I also flattened this out to be a
> 2-patch set
> > with subtitle palette support.
> >
> > This is the result of >1yr of research and I am now very satisfied with
> it's result.
> > I will not make any more changes at this point unless it is outcome from
> a review.
> > If the community decides to merge it, I am happy to continue to improve
> it with support for
> > seeking, probing, and tests.
> >
> > Thank you so much,
> >
> >
> > Signed-off-by: Marth64
> > ---
> > Changelog |2 +
> > configure |8 +
> > doc/demuxers.texi | 129
> > libavformat/Makefile |1 +
> > libavformat/allformats.c |1 +
> > libavformat/dvdvideodec.c | 1410 +
> > 6 files changed, 1551 insertions(+)
> > create mode 100644 libavformat/dvdvideodec.c
> >
> > diff --git a/Changelog b/Changelog
> > index c5fb21d198..88653bc6d3 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -24,6 +24,8 @@ version :
> > - ffmpeg CLI options may now be used as -/opt , which is
> equivalent
> >to -opt >
> > - showinfo bitstream filter
> > +- DVD-Video demuxer, powered by libdvdnav and libdvdread
> > +
> >
> > version 6.1:
> > - libaribcaption decoder
> > diff --git a/configure b/configure
> > index 68f675a4bc..70c33ec96d 100755
> > --- a/configure
> > +++ b/configure
> > @@ -227,6 +227,8 @@ External library support:
> >--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
> >--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
> > and libraw1394 [no]
> > + --enable-libdvdnav enable libdvdnav, needed for DVD demuxing
> [no]
> > + --enable-libdvdread enable libdvdread, needed for DVD demuxing
> [no]
> >--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
> >--enable-libfliteenable flite (voice synthesis) support via
> libflite [no]
> >--enable-libfontconfig enable libfontconfig, useful for drawtext
> filter [no]
> > @@ -1806,6 +1808,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
> > frei0r
> > libcdio
> > libdavs2
> > +libdvdnav
> > +libdvdread
> > librubberband
> > libvidstab
> > libx264
> > @@ -3520,6 +3524,8 @@ dts_demuxer_select="dca_parser"
> > dtshd_demuxer_select="dca_parser"
> > dv_demuxer_select="dvprofile"
> > dv_muxer_select="dvprofile"
> > +dvdvideo_demuxer_select="mpegps_demuxer"
> > +dvdvideo_demuxer_deps="libdvdnav libdvdread"
> > dxa_demuxer_select="riffdec"
> > eac3_demuxer_select="ac3_parser"
> > evc_demuxer_select="evc_frame_merge_bsf evc_parser"
> > @@ -6761,6 +6767,8 @@ enabled libdav1d && require_pkg_config
> libdav1d "dav1d >= 0.5.0" "dav1d
> > enabled libdavs2 && require_pkg_config libdavs2 "davs2 >=
> 1.6.0" davs2.h davs2_decoder_open
> > enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
> dc1394/dc1394.h dc1394_new
> > enabled libdrm&& check_pkg_config libdrm libdrm xf86drm.h
> drmGetVersion
> > +enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >=
> 6.1.1" dvdnav/dvdnav.h dvdnav_open2
> > +enabled libdvdread&& require_pkg_config libdvdread "dvdread >=
> 6.1.2" dvdread/dvd_reader.h DVDOpen2 -ldvdread
> > enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
> "fdk-aac/aacenc_lib.h" aacEncOpen ||
> > { require libfdk_aac
> fdk-aac/aacenc_lib.h aacEncOpen -lfdk-aac &&
> > warn "using libfdk without
> pkg-config"; } }
> > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > index e4c5b560a6..ad0906f6ec 100644
> > --- a/doc/demuxers.texi
> > +++ b/doc/demuxers.texi
> > @@ -285,6 +285,135 @@ This demuxer accepts the following option:
> >
> > @end table
> >
> > +@section dvdvideo
> > +
> > +DVD-Video demuxer, powered by libdvdnav and libdvdread.
> > +
> > +Can directly ingest DVD titles, specifically sequential PGCs,
> > +into a conversion pipeline. Menus and seeking are not supported at this
> time.
> > +
> > +Block devices (DVD drives), ISO files, and directory structures are
> accepted.
> > +Activate with @code{-f dvdvideo} in front of one of these inputs.
> > +
> > +Underlying playback is fully handled by libdvdnav, and structure
> parsing by libdvdread.
>
> > +ffmpeg must be built with GPL library support available as well as the
> switches
> > +@code{--enable-libdvdnav} and @code{--enable-libdvdread}.
>
> FFmpeg must be built with GPL library support available as well as the
> configure switches
Re: [FFmpeg-devel] [PATCH v7 1/2] libavformat/dvdvideo: add DVD-Video demuxer powered by libdvdnav and libdvdread
On date Sunday 2024-02-04 23:48:25 -0600, Marth64 wrote:
> Sorry for the quick follow-up to v6, I wanted to get this update out now
> hopefully
> before v6 is actually reviewed. v7 fixes a few documentation typos, options
> descriptions,
> and log messages: nothing major. I also flattened this out to be a 2-patch set
> with subtitle palette support.
>
> This is the result of >1yr of research and I am now very satisfied with it's
> result.
> I will not make any more changes at this point unless it is outcome from a
> review.
> If the community decides to merge it, I am happy to continue to improve it
> with support for
> seeking, probing, and tests.
>
> Thank you so much,
>
>
> Signed-off-by: Marth64
> ---
> Changelog |2 +
> configure |8 +
> doc/demuxers.texi | 129
> libavformat/Makefile |1 +
> libavformat/allformats.c |1 +
> libavformat/dvdvideodec.c | 1410 +
> 6 files changed, 1551 insertions(+)
> create mode 100644 libavformat/dvdvideodec.c
>
> diff --git a/Changelog b/Changelog
> index c5fb21d198..88653bc6d3 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -24,6 +24,8 @@ version :
> - ffmpeg CLI options may now be used as -/opt , which is equivalent
>to -opt >
> - showinfo bitstream filter
> +- DVD-Video demuxer, powered by libdvdnav and libdvdread
> +
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index 68f675a4bc..70c33ec96d 100755
> --- a/configure
> +++ b/configure
> @@ -227,6 +227,8 @@ External library support:
>--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
>--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
> and libraw1394 [no]
> + --enable-libdvdnav enable libdvdnav, needed for DVD demuxing [no]
> + --enable-libdvdread enable libdvdread, needed for DVD demuxing [no]
>--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
>--enable-libfliteenable flite (voice synthesis) support via
> libflite [no]
>--enable-libfontconfig enable libfontconfig, useful for drawtext filter
> [no]
> @@ -1806,6 +1808,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
> frei0r
> libcdio
> libdavs2
> +libdvdnav
> +libdvdread
> librubberband
> libvidstab
> libx264
> @@ -3520,6 +3524,8 @@ dts_demuxer_select="dca_parser"
> dtshd_demuxer_select="dca_parser"
> dv_demuxer_select="dvprofile"
> dv_muxer_select="dvprofile"
> +dvdvideo_demuxer_select="mpegps_demuxer"
> +dvdvideo_demuxer_deps="libdvdnav libdvdread"
> dxa_demuxer_select="riffdec"
> eac3_demuxer_select="ac3_parser"
> evc_demuxer_select="evc_frame_merge_bsf evc_parser"
> @@ -6761,6 +6767,8 @@ enabled libdav1d && require_pkg_config
> libdav1d "dav1d >= 0.5.0" "dav1d
> enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.6.0"
> davs2.h davs2_decoder_open
> enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
> dc1394/dc1394.h dc1394_new
> enabled libdrm&& check_pkg_config libdrm libdrm xf86drm.h
> drmGetVersion
> +enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >= 6.1.1"
> dvdnav/dvdnav.h dvdnav_open2
> +enabled libdvdread&& require_pkg_config libdvdread "dvdread >=
> 6.1.2" dvdread/dvd_reader.h DVDOpen2 -ldvdread
> enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
> "fdk-aac/aacenc_lib.h" aacEncOpen ||
> { require libfdk_aac fdk-aac/aacenc_lib.h
> aacEncOpen -lfdk-aac &&
> warn "using libfdk without pkg-config"; } }
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index e4c5b560a6..ad0906f6ec 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -285,6 +285,135 @@ This demuxer accepts the following option:
>
> @end table
>
> +@section dvdvideo
> +
> +DVD-Video demuxer, powered by libdvdnav and libdvdread.
> +
> +Can directly ingest DVD titles, specifically sequential PGCs,
> +into a conversion pipeline. Menus and seeking are not supported at this time.
> +
> +Block devices (DVD drives), ISO files, and directory structures are accepted.
> +Activate with @code{-f dvdvideo} in front of one of these inputs.
> +
> +Underlying playback is fully handled by libdvdnav, and structure parsing by
> libdvdread.
> +ffmpeg must be built with GPL library support available as well as the
> switches
> +@code{--enable-libdvdnav} and @code{--enable-libdvdread}.
FFmpeg must be built with GPL library support available as well as the
configure switches @code{--enable-libdvdnav} and @code{--enable-libdvdread}.
> +
> +You will need to provide either the desired "title number" or exact PGC/PG
> coordinates.
> +Many open-source DVD players and tools can aid in providing this information.
unrelated, but it might be useful to have a -list-titles option to
show this information
> +If not
[FFmpeg-devel] [PATCH v1] lavc/vaapi_encode: Enable Macroblock based bitrate control
From: Fei Wang
Signed-off-by: Fei Wang
---
doc/encoders.texi | 3 +++
libavcodec/vaapi_encode.c | 11 ++-
libavcodec/vaapi_encode.h | 9 -
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c9fe6d6143..b66d5da31f 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -4080,6 +4080,9 @@ Quality-defined variable-bitrate.
Average variable bitrate.
@end table
+@item mbbrc
+Enable Macroblock based rate control. Invalid for CQP mode.
+
@end table
Each encoder also has its own specific options:
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 86f4110cd2..83eb881428 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1806,6 +1806,9 @@ static av_cold int
vaapi_encode_init_rate_control(AVCodecContext *avctx)
int i, first = 1, res;
supported_va_rc_modes = rc_attr.value;
+if (ctx->mbbrc && !(supported_va_rc_modes & VA_RC_MB))
+ctx->mbbrc = 0;
+
for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
rc_mode = _encode_rc_modes[i];
if (supported_va_rc_modes & rc_mode->va_mode) {
@@ -2017,13 +2020,18 @@ rc_mode_found:
ctx->va_bit_rate = rc_bits_per_second;
av_log(avctx, AV_LOG_VERBOSE, "RC mode: %s.\n", rc_mode->name);
+
+if (ctx->mbbrc && ctx->va_rc_mode == VA_RC_CQP)
+ctx->mbbrc = 0;
+av_log(avctx, AV_LOG_VERBOSE, "MB bitrate control: %d.\n", ctx->mbbrc);
+
if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
// This driver does not want the RC mode attribute to be set.
} else {
ctx->config_attributes[ctx->nb_config_attributes++] =
(VAConfigAttrib) {
.type = VAConfigAttribRateControl,
-.value = ctx->va_rc_mode,
+.value = ctx->mbbrc ? ctx->va_rc_mode | VA_RC_MB : ctx->va_rc_mode,
};
}
@@ -2052,6 +2060,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 1, 0)
.ICQ_quality_factor = av_clip(rc_quality, 1, 51),
.max_qp = (avctx->qmax > 0 ? avctx->qmax : 0),
+.rc_flags.bits.mb_rate_control = ctx->mbbrc ? 1 : 2,
#endif
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index d5d6d5eb1b..f2abfed459 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -216,6 +216,9 @@ typedef struct VAAPIEncodeContext {
// available modes).
int explicit_rc_mode;
+// Macroblock based rate control.
+int mbbrc;
+
// Explicitly-set QP, for use with the "qp" options.
// (Forces CQP mode when set, overriding everything else.)
int explicit_qp;
@@ -538,7 +541,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
VAAPI_ENCODE_RC_MODE(VBR, "Variable-bitrate"), \
VAAPI_ENCODE_RC_MODE(ICQ, "Intelligent constant-quality"), \
VAAPI_ENCODE_RC_MODE(QVBR, "Quality-defined variable-bitrate"), \
-VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate")
+VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate"), \
+{ "mbbrc", \
+ "Macroblock based bitrate control",\
+ OFFSET(common.mbbrc), AV_OPT_TYPE_BOOL, \
+ { .i64 = 0 }, 0, 1, FLAGS }
#endif /* AVCODEC_VAAPI_ENCODE_H */
--
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 2/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
My carelessness.. fixed it in the reply.
Rémi Denis-Courmont 于2024年2月7日周三 01:26写道：
> Hi,
>
> I'm not sure why you're mixing element sizes this way, but the code should
> not
> even compile due to mismatched extensions.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
From c7013641191a05ea67b6151ce1a91393759aed12 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:03:20 +0800
Subject: [PATCH 2/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
C908:
rv34_inv_transform_dc_c: 35.5
rv34_inv_transform_dc_rvv_i32: 27.0
---
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/rv34dsp_init.c | 39 +
libavcodec/riscv/rv34dsp_rvv.S | 38
libavcodec/rv34dsp.c| 2 ++
libavcodec/rv34dsp.h| 1 +
5 files changed, 82 insertions(+)
create mode 100644 libavcodec/riscv/rv34dsp_init.c
create mode 100644 libavcodec/riscv/rv34dsp_rvv.S
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index e15aba58f4..ffe6631cf2 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -44,6 +44,8 @@ RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
RV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvi.o
RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
+OBJS-$(CONFIG_RV34DSP) += riscv/rv34dsp_init.o
+RVV-OBJS-$(CONFIG_RV34DSP) += riscv/rv34dsp_rvv.o
OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_init.o
RVV-OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_rvv.o
OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_init.o
diff --git a/libavcodec/riscv/rv34dsp_init.c b/libavcodec/riscv/rv34dsp_init.c
new file mode 100644
index 00..852c8ad9a8
--- /dev/null
+++ b/libavcodec/riscv/rv34dsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/rv34dsp.h"
+
+void ff_rv34_inv_transform_dc_rvv(int16_t *block);
+
+av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+c->rv34_inv_transform_dc = ff_rv34_inv_transform_dc_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/rv34dsp_rvv.S b/libavcodec/riscv/rv34dsp_rvv.S
new file mode 100644
index 00..0011a17a22
--- /dev/null
+++ b/libavcodec/riscv/rv34dsp_rvv.S
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+func ff_rv34_inv_transform_dc_rvv, zve32x
+lht1, 0(a0)
+slli t2, t1, 7
+sub t2, t2, t1
+slli t2, t2, 2
+sub t2, t2, t1
+srai t2, t2, 11
+slli t2, t2, 16
+srai t2, t2, 16
+vsetivli zero, 16, e16, m2, ta, ma
+vmv.v.x v8, t2
+vsetivli zero, 8, e8, mf2, ta, ma
+vse32.v v8,
Re: [FFmpeg-devel] [PATCH 1/7] lavc/me_cmp: R-V V pix_abs
I think in most cases it is like this, but specifically for this function, using Reduction only once would be slower. The currently submitted version roughly takes: pix_abs_0_0_rvv_i32: 136.2 The version that uses Reduction only once takes: pix_abs_0_0_rvv_i32: 169.2 Here is the implementation of the version that uses it only once: func ff_pix_abs16_temp_rvv, zve32x vsetivlizero, 16, e32, m4, ta, ma vmv.v.i v24, 0 vmv.s.x v0, zero 1: vsetvli zero, zero, e8, m1, tu, ma vle8.v v4, (a1) vle8.v v12, (a2) addia4, a4, -1 vwsubu.vv v16, v4, v12 add a1, a1, a3 vwsubu.vv v20, v12, v4 vsetvli zero, zero, e16, m2, tu, ma vmax.vv v16, v16, v20 add a2, a2, a3 vwadd.wvv24, v24, v16 bneza4, 1b vsetvli zero, zero, e32, m4, ta, ma vwredsumu.vsv0, v24, v0 vmv.x.s a0, v0 ret endfunc Rémi Denis-Courmont 于2024年2月7日周三 00:58写道： > Hi, > > To sum a vector, you should only reduce once at the end of the function, > c.f. > how it's done in existing scalar products. Reduction instructions are > (intrinsically) slow. > > -- > Rémi Denis-Courmont > http://www.remlab.net/ > > > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] doc/formats: clarify meaning of igndts as per definition in avformat.h
Glad to see this one fixed. Thank you!
On Tue, Feb 6, 2024 at 5:58 PM Stefano Sabatini wrote:
> On date Monday 2024-02-05 01:27:07 +0100, Stefano Sabatini wrote:
> > On date Sunday 2024-02-04 12:41:33 -0600, Marth64 wrote:
> > > This updates the documentation to be more clear about igndts,
> > > as per feedback in December variant of this patch (thank you)
> > >
> > > Signed-off-by: Marth64
> > > ---
> > > doc/formats.texi | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/doc/formats.texi b/doc/formats.texi
> > > index 640b23b790..69fc1457a4 100644
> > > --- a/doc/formats.texi
> > > +++ b/doc/formats.texi
> > > @@ -46,7 +46,8 @@ Enable fast, but inaccurate seeks for some formats.
> > > @item genpts
> > > Generate missing PTS if DTS is present.
> > > @item igndts
> > > -Ignore DTS if PTS is set. Inert when nofillin is set.
> > > +Ignore DTS if PTS is also set. In case the PTS is set, the DTS value
> > > +is set to NOPTS. This is ignored when the @code{nofillin} flag is set.
> >
> > LGTM, I'll apply in a few days if I see no comments, thanks.
>
> Applied.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] doc/formats: clarify meaning of igndts as per definition in avformat.h
On date Monday 2024-02-05 01:27:07 +0100, Stefano Sabatini wrote:
> On date Sunday 2024-02-04 12:41:33 -0600, Marth64 wrote:
> > This updates the documentation to be more clear about igndts,
> > as per feedback in December variant of this patch (thank you)
> >
> > Signed-off-by: Marth64
> > ---
> > doc/formats.texi | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/formats.texi b/doc/formats.texi
> > index 640b23b790..69fc1457a4 100644
> > --- a/doc/formats.texi
> > +++ b/doc/formats.texi
> > @@ -46,7 +46,8 @@ Enable fast, but inaccurate seeks for some formats.
> > @item genpts
> > Generate missing PTS if DTS is present.
> > @item igndts
> > -Ignore DTS if PTS is set. Inert when nofillin is set.
> > +Ignore DTS if PTS is also set. In case the PTS is set, the DTS value
> > +is set to NOPTS. This is ignored when the @code{nofillin} flag is set.
>
> LGTM, I'll apply in a few days if I see no comments, thanks.
Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] avformat/demux: Add durationprobesize AVOption
On date Tuesday 2024-02-06 11:52:09 +0100, Nicolas Gaullier wrote:
> Yet another probesize used to get the last pts (and thus the duration)
> of mpegts/ps files. It is aimed at users interested in better durations
> probing
> for itself, or because using avformat_find_stream_info indirectly and
> requiring
> exact values: for concatdec for exemple, especially if streamcopying above it.
nit: exemple typo
> The current code does not behave well with high bitrates and high video
> buffering
> (physical gap between the last video packet and the last audio packet).
>
> Default behaviour is unchanged: 250k up to 250k << 6 (step by step)
> Setting this new option has two effects:
> - override the maximum probesize (currently 250k << 6)
> - reduce the number of steps to 1 instead of 6, this is to avoid detecting
> the audio "too early" and failing to reach a video packet. Here, even if audio
> duration is found but not the video duration, there will be a retry, so at the
> end the full user-overriden probesize will be used.
>
> Signed-off-by: Nicolas Gaullier
> ---
> libavformat/avformat.h | 8
> libavformat/demux.c | 13 -
> libavformat/options_table.h | 1 +
> 3 files changed, 17 insertions(+), 5 deletions(-)
please add missing user doc in doc/formats.texi (you might reuse the
hightlight above to explain why this is needed), also the new field
requires an entry in doc/APIChanges
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 5d0fe82250..533f5a963d 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1823,6 +1823,14 @@ typedef struct AVFormatContext {
> * Freed by libavformat in avformat_free_context().
> */
> AVStreamGroup **stream_groups;
> +
> +/**
> + * Maximum number of bytes read at the end of input in order to
> determine the
> + * stream durations. Used by avformat_find_stream_info() for MPEG-TS/PS.
let's clarify this: is there any reason why this should not be used
with other formats? If this the case, probably a private option would
be best. If not, probably we should amend the doxy as it suggests it
is only useful with MPEG TS/PS.
> + *
> + * Demuxing only, set by the caller before avformat_open_input().
> + */
> +int64_t duration_probesize;
> } AVFormatContext;
>
> /**
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index 6f640b92b1..798b44c979 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -1740,8 +1740,9 @@ static void
> estimate_timings_from_bit_rate(AVFormatContext *ic)
> "Estimating duration from bitrate, this may be inaccurate\n");
> }
>
> -#define DURATION_MAX_READ_SIZE 25LL
> -#define DURATION_MAX_RETRY 6
> +#define DURATION_MAX_READ_SIZE_DEFAULT 25LL
> +#define DURATION_MAX_RETRY_DEFAULT 6
> +#define DURATION_MAX_RETRY_USER 1
>
> /* only usable for MPEG-PS streams */
> static void estimate_timings_from_pts(AVFormatContext *ic, int64_t
> old_offset)
> @@ -1749,6 +1750,8 @@ static void estimate_timings_from_pts(AVFormatContext
> *ic, int64_t old_offset)
> FFFormatContext *const si = ffformatcontext(ic);
> AVPacket *const pkt = si->pkt;
> int num, den, read_size, ret;
> +int64_t duration_max_read_size = ic->duration_probesize ?
> ic->duration_probesize >> DURATION_MAX_RETRY_USER :
> DURATION_MAX_READ_SIZE_DEFAULT;
> +int duration_max_retry = ic->duration_probesize ?
> DURATION_MAX_RETRY_USER : DURATION_MAX_RETRY_DEFAULT;
> int found_duration = 0;
> int is_end;
> int64_t filesize, offset, duration;
> @@ -1784,7 +1787,7 @@ static void estimate_timings_from_pts(AVFormatContext
> *ic, int64_t old_offset)
> filesize = ic->pb ? avio_size(ic->pb) : 0;
> do {
> is_end = found_duration;
> -offset = filesize - (DURATION_MAX_READ_SIZE << retry);
> +offset = filesize - (duration_max_read_size << retry);
> if (offset < 0)
> offset = 0;
>
> @@ -1793,7 +1796,7 @@ static void estimate_timings_from_pts(AVFormatContext
> *ic, int64_t old_offset)
> for (;;) {
> AVStream *st;
> FFStream *sti;
> -if (read_size >= DURATION_MAX_READ_SIZE << (FFMAX(retry - 1, 0)))
> +if (read_size >= duration_max_read_size << (FFMAX(retry - 1, 0)))
> break;
>
> do {
> @@ -1847,7 +1850,7 @@ static void estimate_timings_from_pts(AVFormatContext
> *ic, int64_t old_offset)
> }
> } while (!is_end &&
> offset &&
> - ++retry <= DURATION_MAX_RETRY);
> + ++retry <= duration_max_retry);
>
> av_opt_set_int(ic, "skip_changes", 0, AV_OPT_SEARCH_CHILDREN);
>
> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
> index 91708de453..c2bdb484a7 100644
> --- a/libavformat/options_table.h
> +++ b/libavformat/options_table.h
> @@ -108,6 +108,7 @@ static const AVOption
Re: [FFmpeg-devel] [REFUND-REQUEST] FOSDEM '24 Expenses
On date Tuesday 2024-02-06 17:36:40 +, Frank Plowman wrote: > Hello, > > I am requesting reimbursement for the following expenses made attending > FOSDEM 2024, where I delivered a talk about the FFmpeg VVC decoder and > met with FFmpeg developers. > > Expense | Amount (GBP) > --+- > Return flight MAN <-> CRL |45.98 > Coach LDS -> MAN | 7.80 > Coach MAN -> LDS | 9.00 > 2 nights Airbnb | 110.07 > Train CRL -> BRU |14.90 > Coach BRU -> CRL |16.91 > Taxi LDS -> Home |10.92 > --+- > Total | 215.58 > > I took the taxi from the coach station to my house as it was in the > early hours and public transport was not running. Approved on my side, pending Michael's approval. To get the refund, follow instructions here to generate a refund request: https://www.spi-inc.org/treasurer/reimbursement-form/ Then email it to: treasu...@rt.spi-inc.org putting me and Michael in CC:, and adding the thread link from: http://ffmpeg.org/pipermail/ffmpeg-devel/ Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [REFUND-REQUEST] FOSDEM'24 Travel
On date Tuesday 2024-02-06 14:35:31 +0100, Niklas Haas wrote: > Hi, > > Due to unforeseen circumstances (DB cancelling my train), I had to take > an Uber to the train station to just barely get there in time for the > alternative connection. > > 248,40 EUR: ICE Ulm <-> Bruxelle-Midi > 18.16 EUR: Uber FOSDEM -> Bruxelle-Midi > > 266.56 EUR: total Approved on my side, pending Michael's approval. To get the refund, follow instructions here to generate a refund request: https://www.spi-inc.org/treasurer/reimbursement-form/ Then email it to: treasu...@rt.spi-inc.org putting me and Michael in CC:, and adding the thread link from: http://ffmpeg.org/pipermail/ffmpeg-devel/ Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: don't free NVDECContext->bitstream
On 07.02.2024 00:05, James Almer wrote:
On 2/6/2024 8:00 PM, Timo Rothenpieler wrote:
On 06.02.2024 23:57, James Almer wrote:
Ensure all hwaccels that allocate a buffer use
NVDECContext->bitstream_internal.
Signed-off-by: James Almer
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..d13b790632 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -259,8 +259,8 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
{
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
- av_freep(>bitstream);
av_freep(>bitstream_internal);
+ ctx->bitstream = NULL;
ctx->bitstream_len = 0;
ctx->bitstream_allocated = 0;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index f022619b64..8c72d5f4f7 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -138,11 +138,11 @@ static int
nvdec_h264_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
const H264SliceContext *sl = >slice_ctx[0];
void *tmp;
- tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+ tmp = av_fast_realloc(ctx->bitstream_internal,
>bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
- ctx->bitstream = tmp;
+ ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets,
>slice_offsets_allocated,
(ctx->nb_slices + 1) *
sizeof(*ctx->slice_offsets));
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index b83d5edcf9..25319a1328 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -274,11 +274,11 @@ static int
nvdec_hevc_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
void *tmp;
- tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+ tmp = av_fast_realloc(ctx->bitstream_internal,
>bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
- ctx->bitstream = tmp;
+ ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets,
>slice_offsets_allocated,
(ctx->nb_slices + 1) *
sizeof(*ctx->slice_offsets));
bitstream_internal was added for the av1 slice reconstructions.
Probably for the exact reason to avoid this confusion.
Looking at this some more... With this patch in place, there should
never be a situation in which we want to free/freep ctx->bitstream?
So the freep() on it should probably be removed alongside, and replace
with just setting it to NULL.
That's what i did above, in the libavcodec/nvdec.c chunk.
Ah, I somehow missed that!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: don't free NVDECContext->bitstream
On 2/6/2024 8:00 PM, Timo Rothenpieler wrote:
On 06.02.2024 23:57, James Almer wrote:
Ensure all hwaccels that allocate a buffer use
NVDECContext->bitstream_internal.
Signed-off-by: James Almer
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..d13b790632 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -259,8 +259,8 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
{
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
- av_freep(>bitstream);
av_freep(>bitstream_internal);
+ ctx->bitstream = NULL;
ctx->bitstream_len = 0;
ctx->bitstream_allocated = 0;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index f022619b64..8c72d5f4f7 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -138,11 +138,11 @@ static int
nvdec_h264_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
const H264SliceContext *sl = >slice_ctx[0];
void *tmp;
- tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+ tmp = av_fast_realloc(ctx->bitstream_internal,
>bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
- ctx->bitstream = tmp;
+ ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets,
>slice_offsets_allocated,
(ctx->nb_slices + 1) *
sizeof(*ctx->slice_offsets));
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index b83d5edcf9..25319a1328 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -274,11 +274,11 @@ static int
nvdec_hevc_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
void *tmp;
- tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+ tmp = av_fast_realloc(ctx->bitstream_internal,
>bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
- ctx->bitstream = tmp;
+ ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets,
>slice_offsets_allocated,
(ctx->nb_slices + 1) *
sizeof(*ctx->slice_offsets));
bitstream_internal was added for the av1 slice reconstructions.
Probably for the exact reason to avoid this confusion.
Looking at this some more... With this patch in place, there should
never be a situation in which we want to free/freep ctx->bitstream?
So the freep() on it should probably be removed alongside, and replace
with just setting it to NULL.
That's what i did above, in the libavcodec/nvdec.c chunk.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] STF SoWs
On Tue, Feb 06, 2024 at 04:39:51PM -0500, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 6, 2024 at 4:23 PM Michael Niedermayer > wrote: > > > What i can and did and do suggest is > > "Patches submitted for review to the FFMPEG dev mailing list. As well as > > taking care of all reasonable review comments." > > > > If "all reasonable review comments" is not enough then what are other > > review comments ? Obviously it must be UNreasonable review comments > > > > That's again a strawman. Who decides what is reasonable? Assuming this is > some community-approved process - e.g. the TC, then how is this different > from going through TC to get the patch merged? I think you should sign a SoW that has "Merged in git master" as a Deliverable for 300 commits you spend half a year of ALL your free time on This would be best. I will not sign that and it seems you are ok with it. But lets continue the argument: Let us first assume there is a blocked set of patches because otherwise obviously none of this matters. If you have a contract that says you get payed when code is merged then you cannot submit an invoice before the code is merged so its up to you to make that happen. Doing months long debates on the ML bringing things up to the TC, and there is no gurantee you will succeed or how long this process would take, it could take months or years. You might never get payed as the TC might just decide not to agree with you or might not come to a conclusion. If you have a contract that says you get payed when you took care of all reasonable comments then you can submit an invoice once you done that with documentation what and why is unreasonable. Now you need to be paid, you can just sit back and wait In the background FFmpeg and SPI might invoke the TC to verify the list claimed unreasonable. If the TC agrees you get paid, and the patches maybe would be applied If the TC disagrees there would be more work before you are paid if the TC takes months or comes up with no conclusion. You will need to be paid thx PS: do you have a single person willing to sign this Deliverable you want ? If not, how will the STF thing work ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: don't free NVDECContext->bitstream
On 07.02.2024 00:00, Timo Rothenpieler wrote:
On 06.02.2024 23:57, James Almer wrote:
Ensure all hwaccels that allocate a buffer use
NVDECContext->bitstream_internal.
Signed-off-by: James Almer
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..d13b790632 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -259,8 +259,8 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
{
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
- av_freep(>bitstream);
av_freep(>bitstream_internal);
+ ctx->bitstream = NULL;
ctx->bitstream_len = 0;
ctx->bitstream_allocated = 0;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index f022619b64..8c72d5f4f7 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -138,11 +138,11 @@ static int
nvdec_h264_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
const H264SliceContext *sl = >slice_ctx[0];
void *tmp;
- tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+ tmp = av_fast_realloc(ctx->bitstream_internal,
>bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
- ctx->bitstream = tmp;
+ ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets,
>slice_offsets_allocated,
(ctx->nb_slices + 1) *
sizeof(*ctx->slice_offsets));
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index b83d5edcf9..25319a1328 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -274,11 +274,11 @@ static int
nvdec_hevc_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
void *tmp;
- tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+ tmp = av_fast_realloc(ctx->bitstream_internal,
>bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
- ctx->bitstream = tmp;
+ ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets,
>slice_offsets_allocated,
(ctx->nb_slices + 1) *
sizeof(*ctx->slice_offsets));
bitstream_internal was added for the av1 slice reconstructions.
Probably for the exact reason to avoid this confusion.
Looking at this some more... With this patch in place, there should
never be a situation in which we want to free/freep ctx->bitstream?
So the freep() on it should probably be removed alongside, and replace
with just setting it to NULL.
Likewise, the entire need for the _simple_end_frame function is gone.
NULL'ing the bitstream can just be done in the normal one, and all
decoders can use it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: don't free NVDECContext->bitstream
On 06.02.2024 23:57, James Almer wrote:
Ensure all hwaccels that allocate a buffer use NVDECContext->bitstream_internal.
Signed-off-by: James Almer
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..d13b790632 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -259,8 +259,8 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
{
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
-av_freep(>bitstream);
av_freep(>bitstream_internal);
+ctx->bitstream = NULL;
ctx->bitstream_len = 0;
ctx->bitstream_allocated = 0;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index f022619b64..8c72d5f4f7 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -138,11 +138,11 @@ static int nvdec_h264_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
const H264SliceContext *sl = >slice_ctx[0];
void *tmp;
-tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+tmp = av_fast_realloc(ctx->bitstream_internal, >bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
-ctx->bitstream = tmp;
+ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets, >slice_offsets_allocated,
(ctx->nb_slices + 1) * sizeof(*ctx->slice_offsets));
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index b83d5edcf9..25319a1328 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -274,11 +274,11 @@ static int nvdec_hevc_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
void *tmp;
-tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+tmp = av_fast_realloc(ctx->bitstream_internal, >bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
-ctx->bitstream = tmp;
+ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets, >slice_offsets_allocated,
(ctx->nb_slices + 1) * sizeof(*ctx->slice_offsets));
bitstream_internal was added for the av1 slice reconstructions.
Probably for the exact reason to avoid this confusion.
Looking at this some more... With this patch in place, there should
never be a situation in which we want to free/freep ctx->bitstream?
So the freep() on it should probably be removed alongside, and replace
with just setting it to NULL.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: don't attempt to free NVDECContext->bitstream on simple decode_slice hwaccels
On 2/6/2024 7:14 PM, Andreas Rheinhardt wrote:
James Almer:
If FFHWAccel->end_frame() isn't called before FFHWAccel->uninit(), an attempt
to free a stale pointer could take place.
Signed-off-by: James Almer
---
libavcodec/nvdec.c| 9 +
libavcodec/nvdec.h| 1 +
libavcodec/nvdec_mjpeg.c | 2 +-
libavcodec/nvdec_mpeg12.c | 4 ++--
libavcodec/nvdec_mpeg4.c | 2 +-
libavcodec/nvdec_vc1.c| 4 ++--
libavcodec/nvdec_vp8.c| 2 +-
libavcodec/nvdec_vp9.c| 2 +-
8 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..8a7f5c0dac 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -274,6 +274,15 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
return 0;
}
+int ff_nvdec_simple_decode_uninit(AVCodecContext *avctx)
+{
+NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
+
+ctx->bitstream = NULL;
+
+return ff_nvdec_decode_uninit(avctx);
+}
+
static void nvdec_free_dummy(struct AVHWFramesContext *ctx)
{
av_buffer_pool_uninit(>pool);
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 353e95bf42..83bc1de84c 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -73,6 +73,7 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx);
int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame);
int ff_nvdec_start_frame_sep_ref(AVCodecContext *avctx, AVFrame *frame, int
has_sep_ref);
int ff_nvdec_end_frame(AVCodecContext *avctx);
+int ff_nvdec_simple_decode_uninit(AVCodecContext *avctx);
int ff_nvdec_simple_end_frame(AVCodecContext *avctx);
int ff_nvdec_simple_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
uint32_t size);
diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
index 850634bf1a..adef21b0f7 100644
--- a/libavcodec/nvdec_mjpeg.c
+++ b/libavcodec/nvdec_mjpeg.c
@@ -80,6 +80,6 @@ const FFHWAccel ff_mjpeg_nvdec_hwaccel = {
.decode_slice = nvdec_mjpeg_decode_slice,
.frame_params = nvdec_mjpeg_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index a4603c7ea7..5d100a46ba 100644
--- a/libavcodec/nvdec_mpeg12.c
+++ b/libavcodec/nvdec_mpeg12.c
@@ -110,7 +110,7 @@ const FFHWAccel ff_mpeg2_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_mpeg12_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
#endif
@@ -126,7 +126,7 @@ const FFHWAccel ff_mpeg1_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_mpeg12_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
#endif
diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
index 20a0499437..5a50f7d77f 100644
--- a/libavcodec/nvdec_mpeg4.c
+++ b/libavcodec/nvdec_mpeg4.c
@@ -120,6 +120,6 @@ const FFHWAccel ff_mpeg4_nvdec_hwaccel = {
.decode_slice = nvdec_mpeg4_decode_slice,
.frame_params = nvdec_mpeg4_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
diff --git a/libavcodec/nvdec_vc1.c b/libavcodec/nvdec_vc1.c
index 5096d784df..e9ab16c63d 100644
--- a/libavcodec/nvdec_vc1.c
+++ b/libavcodec/nvdec_vc1.c
@@ -124,7 +124,7 @@ const FFHWAccel ff_vc1_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_vc1_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
@@ -139,7 +139,7 @@ const FFHWAccel ff_wmv3_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_vc1_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
#endif
diff --git a/libavcodec/nvdec_vp8.c b/libavcodec/nvdec_vp8.c
index ff3b3f259c..bbea6f1577 100644
--- a/libavcodec/nvdec_vp8.c
+++ b/libavcodec/nvdec_vp8.c
@@ -101,6
[FFmpeg-devel] [PATCH] avcodec/nvdec: don't free NVDECContext->bitstream
Ensure all hwaccels that allocate a buffer use NVDECContext->bitstream_internal.
Signed-off-by: James Almer
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..d13b790632 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -259,8 +259,8 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
{
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
-av_freep(>bitstream);
av_freep(>bitstream_internal);
+ctx->bitstream = NULL;
ctx->bitstream_len = 0;
ctx->bitstream_allocated = 0;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index f022619b64..8c72d5f4f7 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -138,11 +138,11 @@ static int nvdec_h264_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
const H264SliceContext *sl = >slice_ctx[0];
void *tmp;
-tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+tmp = av_fast_realloc(ctx->bitstream_internal, >bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
-ctx->bitstream = tmp;
+ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets, >slice_offsets_allocated,
(ctx->nb_slices + 1) * sizeof(*ctx->slice_offsets));
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index b83d5edcf9..25319a1328 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -274,11 +274,11 @@ static int nvdec_hevc_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
void *tmp;
-tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
+tmp = av_fast_realloc(ctx->bitstream_internal, >bitstream_allocated,
ctx->bitstream_len + size + 3);
if (!tmp)
return AVERROR(ENOMEM);
-ctx->bitstream = tmp;
+ctx->bitstream = ctx->bitstream_internal = tmp;
tmp = av_fast_realloc(ctx->slice_offsets, >slice_offsets_allocated,
(ctx->nb_slices + 1) * sizeof(*ctx->slice_offsets));
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: don't attempt to free NVDECContext->bitstream on simple decode_slice hwaccels
James Almer:
> If FFHWAccel->end_frame() isn't called before FFHWAccel->uninit(), an attempt
> to free a stale pointer could take place.
>
> Signed-off-by: James Almer
> ---
> libavcodec/nvdec.c| 9 +
> libavcodec/nvdec.h| 1 +
> libavcodec/nvdec_mjpeg.c | 2 +-
> libavcodec/nvdec_mpeg12.c | 4 ++--
> libavcodec/nvdec_mpeg4.c | 2 +-
> libavcodec/nvdec_vc1.c| 4 ++--
> libavcodec/nvdec_vp8.c| 2 +-
> libavcodec/nvdec_vp9.c| 2 +-
> 8 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index 27be644356..8a7f5c0dac 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -274,6 +274,15 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
> return 0;
> }
>
> +int ff_nvdec_simple_decode_uninit(AVCodecContext *avctx)
> +{
> +NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
> +
> +ctx->bitstream = NULL;
> +
> +return ff_nvdec_decode_uninit(avctx);
> +}
> +
> static void nvdec_free_dummy(struct AVHWFramesContext *ctx)
> {
> av_buffer_pool_uninit(>pool);
> diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
> index 353e95bf42..83bc1de84c 100644
> --- a/libavcodec/nvdec.h
> +++ b/libavcodec/nvdec.h
> @@ -73,6 +73,7 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx);
> int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame);
> int ff_nvdec_start_frame_sep_ref(AVCodecContext *avctx, AVFrame *frame, int
> has_sep_ref);
> int ff_nvdec_end_frame(AVCodecContext *avctx);
> +int ff_nvdec_simple_decode_uninit(AVCodecContext *avctx);
> int ff_nvdec_simple_end_frame(AVCodecContext *avctx);
> int ff_nvdec_simple_decode_slice(AVCodecContext *avctx, const uint8_t
> *buffer,
> uint32_t size);
> diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
> index 850634bf1a..adef21b0f7 100644
> --- a/libavcodec/nvdec_mjpeg.c
> +++ b/libavcodec/nvdec_mjpeg.c
> @@ -80,6 +80,6 @@ const FFHWAccel ff_mjpeg_nvdec_hwaccel = {
> .decode_slice = nvdec_mjpeg_decode_slice,
> .frame_params = nvdec_mjpeg_frame_params,
> .init = ff_nvdec_decode_init,
> -.uninit = ff_nvdec_decode_uninit,
> +.uninit = ff_nvdec_simple_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
> diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
> index a4603c7ea7..5d100a46ba 100644
> --- a/libavcodec/nvdec_mpeg12.c
> +++ b/libavcodec/nvdec_mpeg12.c
> @@ -110,7 +110,7 @@ const FFHWAccel ff_mpeg2_nvdec_hwaccel = {
> .decode_slice = ff_nvdec_simple_decode_slice,
> .frame_params = nvdec_mpeg12_frame_params,
> .init = ff_nvdec_decode_init,
> -.uninit = ff_nvdec_decode_uninit,
> +.uninit = ff_nvdec_simple_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
> #endif
> @@ -126,7 +126,7 @@ const FFHWAccel ff_mpeg1_nvdec_hwaccel = {
> .decode_slice = ff_nvdec_simple_decode_slice,
> .frame_params = nvdec_mpeg12_frame_params,
> .init = ff_nvdec_decode_init,
> -.uninit = ff_nvdec_decode_uninit,
> +.uninit = ff_nvdec_simple_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
> #endif
> diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
> index 20a0499437..5a50f7d77f 100644
> --- a/libavcodec/nvdec_mpeg4.c
> +++ b/libavcodec/nvdec_mpeg4.c
> @@ -120,6 +120,6 @@ const FFHWAccel ff_mpeg4_nvdec_hwaccel = {
> .decode_slice = nvdec_mpeg4_decode_slice,
> .frame_params = nvdec_mpeg4_frame_params,
> .init = ff_nvdec_decode_init,
> -.uninit = ff_nvdec_decode_uninit,
> +.uninit = ff_nvdec_simple_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
> diff --git a/libavcodec/nvdec_vc1.c b/libavcodec/nvdec_vc1.c
> index 5096d784df..e9ab16c63d 100644
> --- a/libavcodec/nvdec_vc1.c
> +++ b/libavcodec/nvdec_vc1.c
> @@ -124,7 +124,7 @@ const FFHWAccel ff_vc1_nvdec_hwaccel = {
> .decode_slice = ff_nvdec_simple_decode_slice,
> .frame_params = nvdec_vc1_frame_params,
> .init = ff_nvdec_decode_init,
> -.uninit = ff_nvdec_decode_uninit,
> +.uninit = ff_nvdec_simple_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
>
> @@ -139,7 +139,7 @@ const FFHWAccel ff_wmv3_nvdec_hwaccel = {
> .decode_slice = ff_nvdec_simple_decode_slice,
> .frame_params = nvdec_vc1_frame_params,
> .init = ff_nvdec_decode_init,
> -.uninit = ff_nvdec_decode_uninit,
> +.uninit = ff_nvdec_simple_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
> #endif
> diff --git a/libavcodec/nvdec_vp8.c
Re: [FFmpeg-devel] STF SoWs
Hi, On Tue, Feb 6, 2024 at 4:23 PM Michael Niedermayer wrote: > What i can and did and do suggest is > "Patches submitted for review to the FFMPEG dev mailing list. As well as > taking care of all reasonable review comments." > > If "all reasonable review comments" is not enough then what are other > review comments ? Obviously it must be UNreasonable review comments > That's again a strawman. Who decides what is reasonable? Assuming this is some community-approved process - e.g. the TC, then how is this different from going through TC to get the patch merged? 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 0/1] avformat/mpegts: fix first NAL start code splited in two different packets
On Tue, 6 Feb 2024, Nicolas Gaullier wrote: If you think it would be better to have a related trac ticket, just tell me, I can do this of course. Nicolas I think it's ok. I wish it were less ugly but I guess it can't be. Kieran Yes, of course! I am really really sorry. Personally, I have not found a better solution as an mpegts fix, but if anyone has a better code, of course my version can be dropped. (I have not looked for a possible fix in the upper ffmpeg demux/parser layers, but it would be certainly even more ugly, if possible at all). I don't quite see why this can't be the job of the parser. After all, that is what is codec specific, and that is what usually splits unaligned packets... Could you please elaborate on that? Thanks, 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] avcodec/nvdec: don't attempt to free NVDECContext->bitstream on simple decode_slice hwaccels
If FFHWAccel->end_frame() isn't called before FFHWAccel->uninit(), an attempt
to free a stale pointer could take place.
Signed-off-by: James Almer
---
libavcodec/nvdec.c| 9 +
libavcodec/nvdec.h| 1 +
libavcodec/nvdec_mjpeg.c | 2 +-
libavcodec/nvdec_mpeg12.c | 4 ++--
libavcodec/nvdec_mpeg4.c | 2 +-
libavcodec/nvdec_vc1.c| 4 ++--
libavcodec/nvdec_vp8.c| 2 +-
libavcodec/nvdec_vp9.c| 2 +-
8 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 27be644356..8a7f5c0dac 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -274,6 +274,15 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx)
return 0;
}
+int ff_nvdec_simple_decode_uninit(AVCodecContext *avctx)
+{
+NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
+
+ctx->bitstream = NULL;
+
+return ff_nvdec_decode_uninit(avctx);
+}
+
static void nvdec_free_dummy(struct AVHWFramesContext *ctx)
{
av_buffer_pool_uninit(>pool);
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 353e95bf42..83bc1de84c 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -73,6 +73,7 @@ int ff_nvdec_decode_uninit(AVCodecContext *avctx);
int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame);
int ff_nvdec_start_frame_sep_ref(AVCodecContext *avctx, AVFrame *frame, int
has_sep_ref);
int ff_nvdec_end_frame(AVCodecContext *avctx);
+int ff_nvdec_simple_decode_uninit(AVCodecContext *avctx);
int ff_nvdec_simple_end_frame(AVCodecContext *avctx);
int ff_nvdec_simple_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
uint32_t size);
diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
index 850634bf1a..adef21b0f7 100644
--- a/libavcodec/nvdec_mjpeg.c
+++ b/libavcodec/nvdec_mjpeg.c
@@ -80,6 +80,6 @@ const FFHWAccel ff_mjpeg_nvdec_hwaccel = {
.decode_slice = nvdec_mjpeg_decode_slice,
.frame_params = nvdec_mjpeg_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index a4603c7ea7..5d100a46ba 100644
--- a/libavcodec/nvdec_mpeg12.c
+++ b/libavcodec/nvdec_mpeg12.c
@@ -110,7 +110,7 @@ const FFHWAccel ff_mpeg2_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_mpeg12_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
#endif
@@ -126,7 +126,7 @@ const FFHWAccel ff_mpeg1_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_mpeg12_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
#endif
diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
index 20a0499437..5a50f7d77f 100644
--- a/libavcodec/nvdec_mpeg4.c
+++ b/libavcodec/nvdec_mpeg4.c
@@ -120,6 +120,6 @@ const FFHWAccel ff_mpeg4_nvdec_hwaccel = {
.decode_slice = nvdec_mpeg4_decode_slice,
.frame_params = nvdec_mpeg4_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
diff --git a/libavcodec/nvdec_vc1.c b/libavcodec/nvdec_vc1.c
index 5096d784df..e9ab16c63d 100644
--- a/libavcodec/nvdec_vc1.c
+++ b/libavcodec/nvdec_vc1.c
@@ -124,7 +124,7 @@ const FFHWAccel ff_vc1_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_vc1_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
@@ -139,7 +139,7 @@ const FFHWAccel ff_wmv3_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
.frame_params = nvdec_vc1_frame_params,
.init = ff_nvdec_decode_init,
-.uninit = ff_nvdec_decode_uninit,
+.uninit = ff_nvdec_simple_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
#endif
diff --git a/libavcodec/nvdec_vp8.c b/libavcodec/nvdec_vp8.c
index ff3b3f259c..bbea6f1577 100644
--- a/libavcodec/nvdec_vp8.c
+++ b/libavcodec/nvdec_vp8.c
@@ -101,6 +101,6 @@ const FFHWAccel ff_vp8_nvdec_hwaccel = {
.decode_slice = ff_nvdec_simple_decode_slice,
Re: [FFmpeg-devel] STF SoWs
On Tue, Feb 06, 2024 at 03:53:55PM -0500, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 6, 2024 at 1:17 PM Michael Niedermayer > wrote: > > > I wont work for months to > > then be at the mercy of not a single of 2000 subscribers posting some > > "i object" and all 2000 know in this situation it would cause an > > inconvenience to me. > > > > That's a strawman version of how our review process works. I don't know why > you're bringing this up. Our review process works by any developer who wants to, review and or comment submitted patches. These are generally people who are active in FFmpeg development. But anyone of the subscribers can comment and we generally encourage others to comment if they have something to say. Its true anyone of 2000 people could block a patch. This is not neccessary for the argument at all though. Even if it is just the 30 most active developers, the problem is still there. I cannot gurantee that none of them will block a patch. A wide range of different developers have had disagreemnets over time. And disagreements have frequently blocked some patches. As a person signing a SoW i cannot gurantee that noone will block the work from being merged into git master. Thus that is something i cannot sign. What i can and did and do suggest is "Patches submitted for review to the FFMPEG dev mailing list. As well as taking care of all reasonable review comments." If "all reasonable review comments" is not enough then what are other review comments ? Obviously it must be UNreasonable review comments and no, i will not sign that. Iam not going to spend the little free time i have working on this and then have litterally "UNreasonable review comments" that iam contratually obliged to somehow handle thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 1:17 PM Michael Niedermayer wrote: > I wont work for months to > then be at the mercy of not a single of 2000 subscribers posting some > "i object" and all 2000 know in this situation it would cause an > inconvenience to me. > That's a strawman version of how our review process works. I don't know why you're bringing this up. 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 1/2] avfilter/signature_lookup: dont leave uncleared pointers in sll_free()
On Tue, Feb 06, 2024 at 11:36:13AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, Feb 05, 2024 at 12:51:57PM +0100, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
> >>> libavfilter/signature_lookup.c | 21 ++---
> >>> 1 file changed, 10 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/libavfilter/signature_lookup.c
> >>> b/libavfilter/signature_lookup.c
> >>> index 86dd0c66754..52a97e1bc7e 100644
> >>> --- a/libavfilter/signature_lookup.c
> >>> +++ b/libavfilter/signature_lookup.c
> >>> @@ -37,6 +37,15 @@
> >>> #define STATUS_END_REACHED 1
> >>> #define STATUS_BEGIN_REACHED 2
> >>>
> >>> +static void sll_free(MatchingInfo **sll)
> >>> +{
> >>> +while (*sll) {
> >>> +MatchingInfo *tmp = *sll;
> >>> +*sll = (*sll)->next;
> >>> +av_free(tmp);
> >>> +}
> >>
> >> This does not clear the pointers at all. This does (and avoids
> >> indirections).
> >>
> >> static void sll_free(MatchingInfo **sllp)
> >> {
> >> MatchingInfo *sll = *sllp;
> >>
> >> *sllp = NULL;
> >> while (sll) {
> >> MatchingInfo *tmp = sll;
> >> sll = sll->next;
> >> av_free(tmp);
> >> }
> >> }
> >
> > I tried it with code below, but your code is not different from mine in
> > behavior just more complex
> >
>
> Your code indeed resets the pointer; it overwrites the pointer once per
> loop iteration and so sets it to NULL in the last iteration. I somehow
> overlooked that.
> I actually consider your code more complex (my code resets the original
> pointer and directly traverses the list, your code does the same, but in
> between it overwrites the original pointer to store the next pointer
> instead of using a simple stack variable for this purpose).
> Apply as you wish.
ok
[...]
> sll_free_n2() is not recursive.
the function is cursed, noone can implement it without bugs
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
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 0/2] Remove SDL2 output devices
I didn't notice any problems with -f sdl2. I just tested again with Windows 11 and the latest FFmpeg build from Gyan, just 2 days old. ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 - Works without any problems. Michael ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
On Tue, Feb 6, 2024 at 7:17 PM Michael Niedermayer wrote: > Hi > > On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas wrote: > > > > > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" < > rsbul...@gmail.com> > > > wrote: > > > > Hi, > > > > > > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > > > > Hi, > > > > > > > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > > > > mich...@niedermayer.cc> > > > > > > wrote: > > > > > > > > > > > > > 2. Deliverables > > > > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > > > > > > > Yes but the individual developer cannot gurantee that. > > > > > > > > > > > > > In a bad situation, someone could send unmergeable patches and they > will > > > > satisfy the legal requirement above for being paid out. I'm > suggesting to > > > > protect the project against that situation. > > > > > > Unless I misunderstood you, what you are proposing protects the > > > Sovereign Tech Fund (aka German government), not the FFmpeg project. > > > This would only be a concern if we were funding work directly from the > > > (non-existant) FFmpeg treasury. > > > > > > > It was more about project reputation and the goals being pro-project > rather > > than pro-developer. Look at it this way: if patches get submitted but not > > merged, is FFmpeg helped? Probably not. But money was spent using > FFmpeg's > > reputation to secure the funding. Subsequent funding rounds will be more > > difficult. > > > Requiring a merge protects the project against this bad > > situation. > > "Requiring a merge" does not do that > because lets assume we have a SoW that says "merge to git master" is needed > now this merge is blocked by someone successfully > That means the SoW is not fullfilled, the developer is not payed and STF > has paid SPI. That would ruin FFmpegs reputation even more as > STF is unhappy (they paid and didnt get what was written in the SoW) > the developer was not paid, so she would definitly be unhappy > SPI as the one in the middle would also be in a very uncomfortable > position. > > So i think we should make sure the conditions in the SoW are guranteed to > be > achievable > > > > > > I understand that, hypothetically, if STF had funded SDR, this would be > > problematic, because no payment is possible for work a majority of the > > project's constituents doesn't want in. But maybe that ensures project > > funding is requested for conservative sets of tasks that everyone agrees > > are good for FFmpeg. So I don't see it as all bad. I don't think anyone > is > > realistically planning to find a GA or TC majority to block patches that > > fix problems found by a static analyzer from going in, purely because it > is > > known that work was paid for? That doesn't sound realistic to me. We've > > historically approved such patches without knowing it being declared > > whether they were paid for or not. > > We have had multiple fixes blocked from going in. > There was the "i have a file this breaks, i will not share the file" cases > There where timeout fixes blocked because someone did not like some check > There was even general argumentation about OOM/Timeout fixes to be better > not done and rather running ffmpeg in a VM (which does not solve the > problem > that the timeouts slow the fuzzer down) > Some fixes involving checking file extensions and similar also where not > popular > There was a time some people tried to block bugfixes if they printed an > error > message. (thats why now none of my fixes prints an error message unless > similar > cases do already) > I even remember that a paid bugfix in a demuxer (mov?) was rejected, the > customer > was perfectly ok with that and paid me. I think i pointed it out to him > prior like i do with everyone nowadays that merge to git master cannot be > guranteed. > This is just what i remember at the spot. > > Assuming the TC will solve it is brave because the TC is new and predates > most of the examples above. > > I disencourage people from putting "merge into git master" as a > deliverable. It can get you burned in FFmpeg. > > > > > > But look at it from a higher level: you guys are asking for review of the > > STF task proposals, and I'm trying to find problems where they exist. I > > don't think the problem I find - or solution I propose (s/submit/merge/) > - > > is crazy. I'm OK with different "fixes" for this problem I'm pointing > out. > > But saying that it's not a problem... I disagree with that. > > if "merge to git master" is a requirement then iam not participating > in this. The risk simply outweights the gain. I wont work for months to > then be at the mercy of not
Re: [FFmpeg-devel] STF SoWs
On Tue, 06 Feb 2024 12:02:51 -0500 "Ronald S. Bultje" wrote: > I understand that, hypothetically, if STF had funded SDR, this would be > problematic, because no payment is possible for work a majority of the > project's constituents doesn't want in. As far as I understood, it was proposed that the GA votes on which SoWs are sent to the STF. I don't think something as contentious as SDR would survive such a vote to begin with. ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
Hi On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas wrote: > > > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" > > wrote: > > > Hi, > > > > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > > > Hi, > > > > > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > > > mich...@niedermayer.cc> > > > > > wrote: > > > > > > > > > > > 2. Deliverables > > > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > > > > > Yes but the individual developer cannot gurantee that. > > > > > > > > > > In a bad situation, someone could send unmergeable patches and they will > > > satisfy the legal requirement above for being paid out. I'm suggesting to > > > protect the project against that situation. > > > > Unless I misunderstood you, what you are proposing protects the > > Sovereign Tech Fund (aka German government), not the FFmpeg project. > > This would only be a concern if we were funding work directly from the > > (non-existant) FFmpeg treasury. > > > > It was more about project reputation and the goals being pro-project rather > than pro-developer. Look at it this way: if patches get submitted but not > merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's > reputation to secure the funding. Subsequent funding rounds will be more > difficult. > Requiring a merge protects the project against this bad > situation. "Requiring a merge" does not do that because lets assume we have a SoW that says "merge to git master" is needed now this merge is blocked by someone successfully That means the SoW is not fullfilled, the developer is not payed and STF has paid SPI. That would ruin FFmpegs reputation even more as STF is unhappy (they paid and didnt get what was written in the SoW) the developer was not paid, so she would definitly be unhappy SPI as the one in the middle would also be in a very uncomfortable position. So i think we should make sure the conditions in the SoW are guranteed to be achievable > > I understand that, hypothetically, if STF had funded SDR, this would be > problematic, because no payment is possible for work a majority of the > project's constituents doesn't want in. But maybe that ensures project > funding is requested for conservative sets of tasks that everyone agrees > are good for FFmpeg. So I don't see it as all bad. I don't think anyone is > realistically planning to find a GA or TC majority to block patches that > fix problems found by a static analyzer from going in, purely because it is > known that work was paid for? That doesn't sound realistic to me. We've > historically approved such patches without knowing it being declared > whether they were paid for or not. We have had multiple fixes blocked from going in. There was the "i have a file this breaks, i will not share the file" cases There where timeout fixes blocked because someone did not like some check There was even general argumentation about OOM/Timeout fixes to be better not done and rather running ffmpeg in a VM (which does not solve the problem that the timeouts slow the fuzzer down) Some fixes involving checking file extensions and similar also where not popular There was a time some people tried to block bugfixes if they printed an error message. (thats why now none of my fixes prints an error message unless similar cases do already) I even remember that a paid bugfix in a demuxer (mov?) was rejected, the customer was perfectly ok with that and paid me. I think i pointed it out to him prior like i do with everyone nowadays that merge to git master cannot be guranteed. This is just what i remember at the spot. Assuming the TC will solve it is brave because the TC is new and predates most of the examples above. I disencourage people from putting "merge into git master" as a deliverable. It can get you burned in FFmpeg. > > But look at it from a higher level: you guys are asking for review of the > STF task proposals, and I'm trying to find problems where they exist. I > don't think the problem I find - or solution I propose (s/submit/merge/) - > is crazy. I'm OK with different "fixes" for this problem I'm pointing out. > But saying that it's not a problem... I disagree with that. if "merge to git master" is a requirement then iam not participating in this. The risk simply outweights the gain. I wont work for months to then be at the mercy of not a single of 2000 subscribers posting some "i object" and all 2000 know in this situation it would cause an inconvenience to me. I also recommand everyone else not to put their signature under a SoW that lists things they cannot gurantee to achieve. I have once lost a large customer from not considering
[FFmpeg-devel] [REFUND-REQUEST] FOSDEM '24 Expenses
Hello, I am requesting reimbursement for the following expenses made attending FOSDEM 2024, where I delivered a talk about the FFmpeg VVC decoder and met with FFmpeg developers. Expense | Amount (GBP) --+- Return flight MAN <-> CRL |45.98 Coach LDS -> MAN | 7.80 Coach MAN -> LDS | 9.00 2 nights Airbnb | 110.07 Train CRL -> BRU |14.90 Coach BRU -> CRL |16.91 Taxi LDS -> Home |10.92 --+- Total | 215.58 I took the taxi from the coach station to my house as it was in the early hours and public transport was not running. Thanks, Frank ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
Hi, I'm not sure why you're mixing element sizes this way, but the code should not even compile due to mismatched extensions. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF SoWs
Hi, On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas wrote: > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" > wrote: > > Hi, > > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > > Hi, > > > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > 2. Deliverables > > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > > > Yes but the individual developer cannot gurantee that. > > > > > > > In a bad situation, someone could send unmergeable patches and they will > > satisfy the legal requirement above for being paid out. I'm suggesting to > > protect the project against that situation. > > Unless I misunderstood you, what you are proposing protects the > Sovereign Tech Fund (aka German government), not the FFmpeg project. > This would only be a concern if we were funding work directly from the > (non-existant) FFmpeg treasury. > It was more about project reputation and the goals being pro-project rather than pro-developer. Look at it this way: if patches get submitted but not merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's reputation to secure the funding. Subsequent funding rounds will be more difficult. Requiring a merge protects the project against this bad situation. I understand that, hypothetically, if STF had funded SDR, this would be problematic, because no payment is possible for work a majority of the project's constituents doesn't want in. But maybe that ensures project funding is requested for conservative sets of tasks that everyone agrees are good for FFmpeg. So I don't see it as all bad. I don't think anyone is realistically planning to find a GA or TC majority to block patches that fix problems found by a static analyzer from going in, purely because it is known that work was paid for? That doesn't sound realistic to me. We've historically approved such patches without knowing it being declared whether they were paid for or not. But look at it from a higher level: you guys are asking for review of the STF task proposals, and I'm trying to find problems where they exist. I don't think the problem I find - or solution I propose (s/submit/merge/) - is crazy. I'm OK with different "fixes" for this problem I'm pointing out. But saying that it's not a problem... I disagree with that. 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 1/7] lavc/me_cmp: R-V V pix_abs
Hi, To sum a vector, you should only reduce once at the end of the function, c.f. how it's done in existing scalar products. Reduction instructions are (intrinsically) slow. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF SoWs
On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer > wrote: > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > 2. Deliverables > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > Yes but the individual developer cannot gurantee that. > > > > In a bad situation, someone could send unmergeable patches and they will > satisfy the legal requirement above for being paid out. I'm suggesting to > protect the project against that situation. Unless I misunderstood you, what you are proposing protects the Sovereign Tech Fund (aka German government), not the FFmpeg project. This would only be a concern if we were funding work directly from the (non-existant) FFmpeg treasury. (And to be frank, paying somebody to write unmergeable FFmpeg patches is probably a better use of government grant money than many of the alternatives.) ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
On Tue, 06 Feb 2024 09:18:20 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer > wrote: > > > 2. Deliverables > > Patches submitted for review to the FFMPEG dev mailing list. > > > > I think the goal is to get patches merged, not submitted. On the other hand, having payment tied to merge, rather than submission, encourages hasty merging, as well as holding hostage of patches from developers one does not like. I think that a significant contribution getting rejected late in the review process due to insurmountable design flaws is a sufficiently rare occurrence that the risk of somebody abusing this system is worth the trade-offs of less stress for all involved. ___ ffmpeg-devel mailing list ffmpeg-devel@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 7/7] lavc/me_cmp: R-V V nsse
From 31635394e89318c554a9653bd22791336309951e Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 6 Feb 2024 22:51:47 +0800
Subject: [PATCH 7/7] lavc/me_cmp: R-V V nsse
C908:
nsse_0_c: 1990.0
nsse_0_rvv_i32: 572.0
nsse_1_c: 910.0
nsse_1_rvv_i32: 456.0
---
libavcodec/riscv/me_cmp_init.c | 30 +
libavcodec/riscv/me_cmp_rvv.S | 118 +
2 files changed, 148 insertions(+)
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
index 24e78e3eeb..48c0d3d827 100644
--- a/libavcodec/riscv/me_cmp_init.c
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -55,6 +55,15 @@ int ff_vsad8_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdif
int ff_vsad_intra16_rvv(MpegEncContext *c, const uint8_t *s, const uint8_t *dummy, ptrdiff_t stride, int h);
int ff_vsad_intra8_rvv(MpegEncContext *c, const uint8_t *s, const uint8_t *dummy, ptrdiff_t stride, int h);
+int ff_nsse16_rvv(int multiplier, const uint8_t *s1, const uint8_t *s2,
+ptrdiff_t stride, int h);
+int nsse16_rvv_wrapper(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2,
+ptrdiff_t stride, int h);
+int ff_nsse8_rvv(int multiplier, const uint8_t *s1, const uint8_t *s2,
+ptrdiff_t stride, int h);
+int nsse8_rvv_wrapper(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2,
+ptrdiff_t stride, int h);
+
av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
{
#if HAVE_RVV
@@ -82,6 +91,27 @@ av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
c->vsad[1] = ff_vsad8_rvv;
c->vsad[4] = ff_vsad_intra16_rvv;
c->vsad[5] = ff_vsad_intra8_rvv;
+
+c->nsse[0] = nsse16_rvv_wrapper;
+c->nsse[1] = nsse8_rvv_wrapper;
}
#endif
}
+
+int nsse16_rvv_wrapper(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2,
+ptrdiff_t stride, int h)
+{
+if (c)
+return ff_nsse16_rvv(c->avctx->nsse_weight, s1, s2, stride, h);
+else
+return ff_nsse16_rvv(8, s1, s2, stride, h);
+}
+
+int nsse8_rvv_wrapper(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2,
+ptrdiff_t stride, int h)
+{
+if (c)
+return ff_nsse8_rvv(c->avctx->nsse_weight, s1, s2, stride, h);
+else
+return ff_nsse8_rvv(8, s1, s2, stride, h);
+}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
index f32ae6b259..c9ae5bb6fc 100644
--- a/libavcodec/riscv/me_cmp_rvv.S
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -407,3 +407,121 @@ endfunc
func ff_vsad_intra8_rvv, zve32x
vsad_vsse_intra8 abs
endfunc
+
+func ff_nsse16_rvv, zve32x
+.macro squarediff16
+vsetivlizero, 16, e8, m1, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (a2)
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, m2, tu, ma
+vwmacc.vv v24, v16, v16
+.endm
+
+.macro gradiff16 srcx srcv
+vsetivlizero, 16, e8, m1, tu, ma
+vle8.v v8, (\srcx)
+vslide1down.vx v0, \srcv, t5
+vslide1down.vx v16, v8, t5
+vwsubu.vv v20, \srcv, v0
+vwsubu.wv v0, v20, v8
+vwaddu.wv v20, v0, v16
+vsetivlizero, 15, e16, m2, tu, ma
+vneg.v v0, v20
+vmax.vv v0, v20, v0
+.endm
+
+csrwi vxrm, 0
+vsetivlit0, 16, e32, m4, ta, ma
+addia4, a4, -1
+li t5, 1
+vmv.v.x v24, zero
+vmv.v.x v28, zero
+1:
+add t1, a1, a3
+add t2, a2, a3
+addia4, a4, -1
+squarediff16
+gradiff16 t1, v4
+vwaddu.wv v28, v28, v0
+gradiff16 t2, v12
+vwsubu.wv v28, v28, v0
+add a1, a1, a3
+add a2, a2, a3
+bneza4, 1b
+
+squarediff16
+vsetivlizero, 16, e32, m4, tu, ma
+vmv.s.x v0, zero
+vmv.s.x v4, zero
+vredsum.vs v0, v24, v0
+vredsum.vs v4, v28, v4
+vmv.x.s t1, v0
+vmv.x.s t2, v4
+srait3, t2, 31
+xor t2, t3, t2
+sub t2, t2, t3
+mul t2, t2, a0
+add a0, t2, t1
+
+ret
+endfunc
+
+func ff_nsse8_rvv, zve32x
+.macro squarediff8
+vsetivlizero, 8, e8, mf2, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (a2)
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, m1, tu, ma
+vwmacc.vv v24, v16, v16
+.endm
+
+.macro gradiff8 srcx srcv
+vsetivlizero, 8, e8, mf2, tu, ma
+vle8.v v8, (\srcx)
[FFmpeg-devel] [PATCH 6/7] lavc/me_cmp: R-V V vsse vsad intra
From b4abb039f8f769104a29819a1d709f5a00bf84d5 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 6 Feb 2024 23:28:08 +0800
Subject: [PATCH 6/7] lavc/me_cmp: R-V V vsse vsad intra
C908:
vsad_4_c: 681.0
vsad_4_rvv_i32: 182.2
vsad_5_c: 278.0
vsad_5_rvv_i32: 145.2
vsse_4_c: 595.0
vsse_4_rvv_i32: 125.2
vsse_5_c: 281.0
vsse_5_rvv_i32: 101.2
---
libavcodec/riscv/me_cmp_init.c | 8
libavcodec/riscv/me_cmp_rvv.S | 78 ++
2 files changed, 86 insertions(+)
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
index a6ef5addd0..24e78e3eeb 100644
--- a/libavcodec/riscv/me_cmp_init.c
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -48,8 +48,12 @@ int ff_sse4_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
int ff_vsse16_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
int ff_vsse8_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
+int ff_vsse_intra16_rvv(MpegEncContext *c, const uint8_t *s, const uint8_t *dummy, ptrdiff_t stride, int h);
+int ff_vsse_intra8_rvv(MpegEncContext *c, const uint8_t *s, const uint8_t *dummy, ptrdiff_t stride, int h);
int ff_vsad16_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
int ff_vsad8_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
+int ff_vsad_intra16_rvv(MpegEncContext *c, const uint8_t *s, const uint8_t *dummy, ptrdiff_t stride, int h);
+int ff_vsad_intra8_rvv(MpegEncContext *c, const uint8_t *s, const uint8_t *dummy, ptrdiff_t stride, int h);
av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
{
@@ -72,8 +76,12 @@ av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
c->vsse[0] = ff_vsse16_rvv;
c->vsse[1] = ff_vsse8_rvv;
+c->vsse[4] = ff_vsse_intra16_rvv;
+c->vsse[5] = ff_vsse_intra8_rvv;
c->vsad[0] = ff_vsad16_rvv;
c->vsad[1] = ff_vsad8_rvv;
+c->vsad[4] = ff_vsad_intra16_rvv;
+c->vsad[5] = ff_vsad_intra8_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
index 25b15c74ce..f32ae6b259 100644
--- a/libavcodec/riscv/me_cmp_rvv.S
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -314,6 +314,68 @@ endfunc
ret
.endm
+.macro vsad_vsse_intra16 type
+vsetivlit0, 16, e32, m4, ta, ma
+addia4, a4, -1
+add t1, a1, a3
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, m1, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (t1)
+addia4, a4, -1
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, m2, tu, ma
+
+.ifc \type,abs
+vabsadduv24, v16, v12
+.endif
+.ifc \type,square
+vwmacc.vv v24, v16, v16
+.endif
+
+add a1, a1, a3
+add t1, t1, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m4, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+.endm
+
+.macro vsad_vsse_intra8 type
+vsetivlit0, 8, e32, m2, ta, ma
+addia4, a4, -1
+add t1, a1, a3
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, mf2, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (t1)
+addia4, a4, -1
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, m1, tu, ma
+
+.ifc \type,abs
+vabsadduv24, v16, v12
+.endif
+.ifc \type,square
+vwmacc.vv v24, v16, v16
+.endif
+
+add a1, a1, a3
+add t1, t1, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m2, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+.endm
+
func ff_vsse16_rvv, zve32x
vsad_vsse16 square
endfunc
@@ -322,6 +384,14 @@ func ff_vsse8_rvv, zve32x
vsad_vsse8 square
endfunc
+func ff_vsse_intra16_rvv, zve32x
+vsad_vsse_intra16 square
+endfunc
+
+func ff_vsse_intra8_rvv, zve32x
+vsad_vsse_intra8 square
+endfunc
+
func ff_vsad16_rvv, zve32x
vsad_vsse16 abs
endfunc
@@ -329,3 +399,11 @@ endfunc
func ff_vsad8_rvv, zve32x
vsad_vsse8 abs
endfunc
+
+func ff_vsad_intra16_rvv, zve32x
+vsad_vsse_intra16 abs
+endfunc
+
+func ff_vsad_intra8_rvv, zve32x
+vsad_vsse_intra8 abs
+endfunc
--
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 5/7] lavc/me_cmp: R-V V vsse vsad
From 67f2a662be1533e52a28971152bff670f78544fd Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 6 Feb 2024 23:18:51 +0800
Subject: [PATCH 5/7] lavc/me_cmp: R-V V vsse vsad
C908:
vsad_0_c: 936.0
vsad_0_rvv_i32: 236.2
vsad_1_c: 424.0
vsad_1_rvv_i32: 190.2
vsse_0_c: 877.0
vsse_0_rvv_i32: 204.2
vsse_1_c: 439.0
vsse_1_rvv_i32: 140.2
---
libavcodec/riscv/me_cmp_init.c | 10
libavcodec/riscv/me_cmp_rvv.S | 98 ++
2 files changed, 108 insertions(+)
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
index 85ecc22cbc..a6ef5addd0 100644
--- a/libavcodec/riscv/me_cmp_init.c
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -46,6 +46,11 @@ int ff_sse8_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
int ff_sse4_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
ptrdiff_t stride, int h);
+int ff_vsse16_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
+int ff_vsse8_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
+int ff_vsad16_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
+int ff_vsad8_rvv(MpegEncContext *c, const uint8_t *s1, const uint8_t *s2, ptrdiff_t stride, int h);
+
av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
{
#if HAVE_RVV
@@ -64,6 +69,11 @@ av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
c->sse[0] = ff_sse16_rvv;
c->sse[1] = ff_sse8_rvv;
c->sse[2] = ff_sse4_rvv;
+
+c->vsse[0] = ff_vsse16_rvv;
+c->vsse[1] = ff_vsse8_rvv;
+c->vsad[0] = ff_vsad16_rvv;
+c->vsad[1] = ff_vsad8_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
index 11848f3f21..25b15c74ce 100644
--- a/libavcodec/riscv/me_cmp_rvv.S
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -231,3 +231,101 @@ func ff_sse4_rvv, zve32x
vmv.x.s a0, v0
ret
endfunc
+
+.macro vabsaddu dst src tmp
+vneg.v \tmp, \src
+vmax.vv \tmp, \src, \tmp
+vwaddu.wv \dst, \dst, \tmp
+.endm
+
+.macro vsad_vsse16 type
+vsetivlit0, 16, e32, m4, ta, ma
+addia4, a4, -1
+add t1, a1, a3
+add t2, a2, a3
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, m1, tu, ma
+vle8.v v4, (a1)
+vle8.v v8, (t1)
+vle8.v v12, (a2)
+vle8.v v16, (t2)
+addia4, a4, -1
+vwsubu.vv v28, v4, v12
+vwsubu.wv v12, v28, v8
+vwaddu.wv v28, v12, v16
+vsetvli zero, zero, e16, m2, tu, ma
+
+.ifc \type,abs
+vabsadduv24, v28, v12
+.endif
+.ifc \type,square
+vwmacc.vv v24, v28, v28
+.endif
+
+add a1, a1, a3
+add a2, a2, a3
+add t1, t1, a3
+add t2, t2, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m4, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+.endm
+
+.macro vsad_vsse8 type
+vsetivlit0, 8, e32, m2, ta, ma
+addia4, a4, -1
+add t1, a1, a3
+add t2, a2, a3
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, mf2, tu, ma
+vle8.v v4, (a1)
+vle8.v v8, (t1)
+vle8.v v12, (a2)
+vle8.v v16, (t2)
+addia4, a4, -1
+vwsubu.vv v28, v4, v12
+vwsubu.wv v12, v28, v8
+vwaddu.wv v28, v12, v16
+vsetvli zero, zero, e16, m1, tu, ma
+
+.ifc \type,abs
+vabsadduv24, v28, v12
+.endif
+.ifc \type,square
+vwmacc.vv v24, v28, v28
+.endif
+
+add a1, a1, a3
+add a2, a2, a3
+add t1, t1, a3
+add t2, t2, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m2, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+.endm
+
+func ff_vsse16_rvv, zve32x
+vsad_vsse16 square
+endfunc
+
+func ff_vsse8_rvv, zve32x
+vsad_vsse8 square
+endfunc
+
+func ff_vsad16_rvv, zve32x
+vsad_vsse16 abs
+endfunc
+
+func ff_vsad8_rvv, zve32x
+vsad_vsse8 abs
+endfunc
--
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 4/7] lavc/me_cmp: R-V V sse
From 7d153e6b166d53c94db57be4f024986d38290042 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 6 Feb 2024 21:55:07 +0800
Subject: [PATCH 4/7] lavc/me_cmp: R-V V sse
C908:
sse_0_c: 614.7
sse_0_rvv_i32: 138.2
sse_1_c: 302.7
sse_1_rvv_i32: 107.2
sse_2_c: 175.7
sse_2_rvv_i32: 104.2
---
libavcodec/riscv/me_cmp_init.c | 11 ++
libavcodec/riscv/me_cmp_rvv.S | 66 ++
2 files changed, 77 insertions(+)
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
index 72c3248b01..85ecc22cbc 100644
--- a/libavcodec/riscv/me_cmp_init.c
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -39,6 +39,13 @@ int ff_pix_abs16_y2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *p
int ff_pix_abs8_y2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
ptrdiff_t stride, int h);
+int ff_sse16_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+int ff_sse8_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+int ff_sse4_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+
av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
{
#if HAVE_RVV
@@ -53,6 +60,10 @@ av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
c->pix_abs[1][1] = ff_pix_abs8_x2_rvv;
c->pix_abs[0][2] = ff_pix_abs16_y2_rvv;
c->pix_abs[1][2] = ff_pix_abs8_y2_rvv;
+
+c->sse[0] = ff_sse16_rvv;
+c->sse[1] = ff_sse8_rvv;
+c->sse[2] = ff_sse4_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
index 308d707136..11848f3f21 100644
--- a/libavcodec/riscv/me_cmp_rvv.S
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -165,3 +165,69 @@ func ff_pix_abs8_y2_rvv, zve32x
pix_abs_ret
endfunc
+
+func ff_sse16_rvv, zve32x
+vsetivlit0, 16, e32, m4, ta, ma
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, m1, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (a2)
+addia4, a4, -1
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, m2, tu, ma
+vwmacc.vv v24, v16, v16
+add a1, a1, a3
+add a2, a2, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m4, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+endfunc
+
+func ff_sse8_rvv, zve32x
+vsetivlit0, 8, e32, m2, ta, ma
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, mf2, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (a2)
+addia4, a4, -1
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, m1, tu, ma
+vwmacc.vv v24, v16, v16
+add a1, a1, a3
+add a2, a2, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m2, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+endfunc
+
+func ff_sse4_rvv, zve32x
+vsetivlit0, 4, e32, m1, ta, ma
+vmv.v.x v24, zero
+vmv.s.x v0, zero
+1:
+vsetvli zero, zero, e8, mf4, tu, ma
+vle8.v v4, (a1)
+vle8.v v12, (a2)
+addia4, a4, -1
+vwsubu.vv v16, v4, v12
+vsetvli zero, zero, e16, mf2, tu, ma
+vwmacc.vv v24, v16, v16
+add a1, a1, a3
+add a2, a2, a3
+bneza4, 1b
+
+vsetvli zero, zero, e32, m1, tu, ma
+vredsum.vs v0, v24, v0
+vmv.x.s a0, v0
+ret
+endfunc
--
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 3/7] lavc/me_cmp: R-V V pix_abs_y2
From 01cdfde56c4a88022f0ed8c12a2442e6bebb6a60 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 6 Feb 2024 21:46:07 +0800
Subject: [PATCH 3/7] lavc/me_cmp: R-V V pix_abs_y2
C908:
pix_abs_0_2_c: 904.0
pix_abs_0_2_rvv_i32: 172.2
pix_abs_1_2_c: 460.0
pix_abs_1_2_rvv_i32: 168.2
---
libavcodec/riscv/me_cmp_init.c | 6
libavcodec/riscv/me_cmp_rvv.S | 50 ++
2 files changed, 56 insertions(+)
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
index e46fb09c11..72c3248b01 100644
--- a/libavcodec/riscv/me_cmp_init.c
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -34,6 +34,10 @@ int ff_pix_abs16_x2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *p
ptrdiff_t stride, int h);
int ff_pix_abs8_x2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
ptrdiff_t stride, int h);
+int ff_pix_abs16_y2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+int ff_pix_abs8_y2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
{
@@ -47,6 +51,8 @@ av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
c->sad[1] = ff_pix_abs8_rvv;
c->pix_abs[0][1] = ff_pix_abs16_x2_rvv;
c->pix_abs[1][1] = ff_pix_abs8_x2_rvv;
+c->pix_abs[0][2] = ff_pix_abs16_y2_rvv;
+c->pix_abs[1][2] = ff_pix_abs8_y2_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
index cc60219466..308d707136 100644
--- a/libavcodec/riscv/me_cmp_rvv.S
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -115,3 +115,53 @@ func ff_pix_abs8_x2_rvv, zve32x
pix_abs_ret
endfunc
+
+func ff_pix_abs16_y2_rvv, zve32x
+csrwi vxrm, 0
+vsetivlizero, 1, e32, m1, ta, ma
+add t1, a2, a3
+vmv.s.x v0, zero
+1:
+vsetivlizero, 16, e8, m1, tu, ma
+vle8.v v12, (a2)
+vle8.v v24, (t1)
+addia4, a4, -1
+vle8.v v4, (a1)
+vaaddu.vv v12, v12, v24
+vwsubu.vv v16, v4, v12
+vwsubu.vv v20, v12, v4
+add a1, a1, a3
+vsetvli zero, zero, e16, m2, tu, ma
+add a2, a2, a3
+vmax.vv v16, v16, v20
+add t1, t1, a3
+vwredsum.vs v0, v16, v0
+bneza4, 1b
+
+pix_abs_ret
+endfunc
+
+func ff_pix_abs8_y2_rvv, zve32x
+csrwi vxrm, 0
+vsetivlizero, 1, e32, m1, ta, ma
+add t1, a2, a3
+vmv.s.x v0, zero
+1:
+vsetivlizero, 8, e8, mf2, tu, ma
+vle8.v v12, (a2)
+vle8.v v24, (t1)
+addia4, a4, -1
+vle8.v v4, (a1)
+vaaddu.vv v12, v12, v24
+vwsubu.vv v16, v4, v12
+vwsubu.vv v20, v12, v4
+add a1, a1, a3
+vsetvli zero, zero, e16, m1, tu, ma
+add a2, a2, a3
+vmax.vv v16, v16, v20
+add t1, t1, a3
+vwredsum.vs v0, v16, v0
+bneza4, 1b
+
+pix_abs_ret
+endfunc
--
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/7] lavc/me_cmp: R-V V pix_abs_x2
From ea0cf15e43c9a3e1b56c1a43d50f0701d42c7e9f Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 6 Feb 2024 21:41:35 +0800
Subject: [PATCH 2/7] lavc/me_cmp: R-V V pix_abs_x2
C908:
pix_abs_0_1_c: 767.0
pix_abs_0_1_rvv_i32: 196.2
pix_abs_1_1_c: 388.0
pix_abs_1_1_rvv_i32: 185.2
---
libavcodec/riscv/me_cmp_init.c | 6
libavcodec/riscv/me_cmp_rvv.S | 50 ++
2 files changed, 56 insertions(+)
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
index 9228f74cfd..e46fb09c11 100644
--- a/libavcodec/riscv/me_cmp_init.c
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -30,6 +30,10 @@ int ff_pix_abs16_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2
ptrdiff_t stride, int h);
int ff_pix_abs8_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
ptrdiff_t stride, int h);
+int ff_pix_abs16_x2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+int ff_pix_abs8_x2_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
{
@@ -41,6 +45,8 @@ av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
c->sad[0] = ff_pix_abs16_rvv;
c->pix_abs[1][0] = ff_pix_abs8_rvv;
c->sad[1] = ff_pix_abs8_rvv;
+c->pix_abs[0][1] = ff_pix_abs16_x2_rvv;
+c->pix_abs[1][1] = ff_pix_abs8_x2_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
index 8dadf39bc7..cc60219466 100644
--- a/libavcodec/riscv/me_cmp_rvv.S
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -65,3 +65,53 @@ func ff_pix_abs8_rvv, zve32x
pix_abs_ret
endfunc
+
+func ff_pix_abs16_x2_rvv, zve32x
+csrwi vxrm, 0
+vsetivlizero, 1, e32, m1, ta, ma
+li t5, 1
+vmv.s.x v0, zero
+1:
+vsetivlizero, 17, e8, m2, tu, ma
+vle8.v v12, (a2)
+addia4, a4, -1
+vslide1down.vx v24, v12, t5
+vsetivlizero, 16, e8, m1, tu, ma
+vle8.v v4, (a1)
+vaaddu.vv v12, v12, v24
+vwsubu.vv v16, v4, v12
+add a1, a1, a3
+vwsubu.vv v20, v12, v4
+vsetvli zero, zero, e16, m2, tu, ma
+vmax.vv v16, v16, v20
+add a2, a2, a3
+vwredsum.vs v0, v16, v0
+bneza4, 1b
+
+pix_abs_ret
+endfunc
+
+func ff_pix_abs8_x2_rvv, zve32x
+csrwi vxrm, 0
+vsetivlizero, 1, e32, m1, ta, ma
+li t5, 1
+vmv.s.x v0, zero
+1:
+vsetivlizero, 9, e8, m1, tu, ma
+vle8.v v12, (a2)
+addia4, a4, -1
+vslide1down.vx v24, v12, t5
+vsetivlizero, 8, e8, mf2, tu, ma
+vle8.v v4, (a1)
+vaaddu.vv v12, v12, v24
+vwsubu.vv v16, v4, v12
+add a1, a1, a3
+vwsubu.vv v20, v12, v4
+vsetvli zero, zero, e16, m1, tu, ma
+vmax.vv v16, v16, v20
+add a2, a2, a3
+vwredsum.vs v0, v16, v0
+bneza4, 1b
+
+pix_abs_ret
+endfunc
--
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 1/7] lavc/me_cmp: R-V V pix_abs
From d4d6b3ea040f3f7997463b4452813bc75d1c9f9d Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Sat, 3 Feb 2024 10:58:13 +0800
Subject: [PATCH 1/7] lavc/me_cmp: R-V V pix_abs
C908:
pix_abs_0_0_c: 534.0
pix_abs_0_0_rvv_i32: 136.2
pix_abs_1_0_c: 287.7
pix_abs_1_0_rvv_i32: 125.2
sad_0_c: 534.0
sad_0_rvv_i32: 136.2
sad_1_c: 287.7
sad_1_rvv_i32: 125.2
---
libavcodec/me_cmp.c| 2 +
libavcodec/me_cmp.h| 1 +
libavcodec/riscv/Makefile | 2 +
libavcodec/riscv/me_cmp_init.c | 46 +++
libavcodec/riscv/me_cmp_rvv.S | 67 ++
5 files changed, 118 insertions(+)
create mode 100644 libavcodec/riscv/me_cmp_init.c
create mode 100644 libavcodec/riscv/me_cmp_rvv.S
diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
index fecd70d723..8f4b3d0ad5 100644
--- a/libavcodec/me_cmp.c
+++ b/libavcodec/me_cmp.c
@@ -1136,6 +1136,8 @@ av_cold void ff_me_cmp_init(MECmpContext *c, AVCodecContext *avctx)
ff_me_cmp_init_arm(c, avctx);
#elif ARCH_PPC
ff_me_cmp_init_ppc(c, avctx);
+#elif ARCH_RISCV
+ff_me_cmp_init_riscv(c, avctx);
#elif ARCH_X86
ff_me_cmp_init_x86(c, avctx);
#elif ARCH_MIPS
diff --git a/libavcodec/me_cmp.h b/libavcodec/me_cmp.h
index aefd32a7dc..fee0ecb28e 100644
--- a/libavcodec/me_cmp.h
+++ b/libavcodec/me_cmp.h
@@ -86,6 +86,7 @@ void ff_me_cmp_init_aarch64(MECmpContext *c, AVCodecContext *avctx);
void ff_me_cmp_init_alpha(MECmpContext *c, AVCodecContext *avctx);
void ff_me_cmp_init_arm(MECmpContext *c, AVCodecContext *avctx);
void ff_me_cmp_init_ppc(MECmpContext *c, AVCodecContext *avctx);
+void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx);
void ff_me_cmp_init_x86(MECmpContext *c, AVCodecContext *avctx);
void ff_me_cmp_init_mips(MECmpContext *c, AVCodecContext *avctx);
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 97067558d8..dff8784102 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -41,6 +41,8 @@ OBJS-$(CONFIG_LLVIDENCDSP) += riscv/llvidencdsp_init.o
RVV-OBJS-$(CONFIG_LLVIDENCDSP) += riscv/llvidencdsp_rvv.o
OBJS-$(CONFIG_LPC) += riscv/lpc_init.o
RVV-OBJS-$(CONFIG_LPC) += riscv/lpc_rvv.o
+OBJS-$(CONFIG_ME_CMP) += riscv/me_cmp_init.o
+RVV-OBJS-$(CONFIG_ME_CMP) += riscv/me_cmp_rvv.o
OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_init.o
RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
diff --git a/libavcodec/riscv/me_cmp_init.c b/libavcodec/riscv/me_cmp_init.c
new file mode 100644
index 00..9228f74cfd
--- /dev/null
+++ b/libavcodec/riscv/me_cmp_init.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/me_cmp.h"
+#include "libavcodec/mpegvideo.h"
+
+int ff_pix_abs16_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+int ff_pix_abs8_rvv(MpegEncContext *v, const uint8_t *pix1, const uint8_t *pix2,
+ ptrdiff_t stride, int h);
+
+av_cold void ff_me_cmp_init_riscv(MECmpContext *c, AVCodecContext *avctx)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+c->pix_abs[0][0] = ff_pix_abs16_rvv;
+c->sad[0] = ff_pix_abs16_rvv;
+c->pix_abs[1][0] = ff_pix_abs8_rvv;
+c->sad[1] = ff_pix_abs8_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/me_cmp_rvv.S b/libavcodec/riscv/me_cmp_rvv.S
new file mode 100644
index 00..8dadf39bc7
--- /dev/null
+++ b/libavcodec/riscv/me_cmp_rvv.S
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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
Re: [FFmpeg-devel] STF SoWs
On Tue, Feb 06, 2024 at 04:26:41PM +0100, Michael Niedermayer wrote: > On Tue, Feb 06, 2024 at 10:21:21AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer > > wrote: > > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > > Hi, > > > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > 2. Deliverables > > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > > > Yes but the individual developer cannot gurantee that. > > > > > > > In a bad situation, someone could send unmergeable patches and they will > > satisfy the legal requirement above for being paid out. I'm suggesting to > > protect the project against that situation. > > yes > how foolproof do we want that wording to be ? Random try: 1. Description Fix 50% of the outstanding real issues It is explicitly declared here, that if any issues require rewrites or redesigns of modules, these are outside the scope of this SoW. 2. Deliverables Patches submitted for review to the FFMPEG dev mailing list. As well as taking care of all reasonable review comments. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin 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] STF SoWs
On Tue, Feb 06, 2024 at 10:21:21AM -0500, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer > wrote: > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > 2. Deliverables > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > Yes but the individual developer cannot gurantee that. > > > > In a bad situation, someone could send unmergeable patches and they will > satisfy the legal requirement above for being paid out. I'm suggesting to > protect the project against that situation. yes how foolproof do we want that wording to be ? 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] STF SoWs
On Tue, Feb 06, 2024 at 03:57:39PM +0100, Vittorio Giovara wrote: > On Tue, Feb 6, 2024 at 3:06 AM Michael Niedermayer > wrote: > > > Hi all > > > > As Jonatan reminded the ML we need to provide SoWs if we want to > > participate in STF-SPI > > > > We need one for each project (they do not need to list a person ATM) > > but obviously we do need someone who will do the work > > > > I do belive they do need to list the money amount. > > Thanks go to Pierre for helping me write template/example. > > (converted from google docs and with some last minute edits) > > > > @Jonatan, is this below what SPI needs for each project ? > > > > Correct me if I'm wrong but we still need the answer on "merge forks". > Which ones, where, and why -- ie what if the community doesn't want or need > any particular one? I had no intend to do the "merge forks" task but give me a moment, ill try to fill out the missing details thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer wrote: > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > 2. Deliverables > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > I think the goal is to get patches merged, not submitted. > > Yes but the individual developer cannot gurantee that. > In a bad situation, someone could send unmergeable patches and they will satisfy the legal requirement above for being paid out. I'm suggesting to protect the project against that situation. It's the difference between a goal of "a developer getting paid for work done" or "ffmpeg maintenance being paid for". They are very closely related but have slightly different finishes. 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] STF SoWs
On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > Hi, > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer > wrote: > > > 2. Deliverables > > Patches submitted for review to the FFMPEG dev mailing list. > > > > I think the goal is to get patches merged, not submitted. Yes but the individual developer cannot gurantee that. Nor can we accept a patch before we see it What the individual developer can gurantee is to provide a correct patch fixing the problem. This is similar to GSoC, the student has to finish the work that was agreed. And pass teh mentors review. If the open source project decides not to merge it thats not affecting the student. I would never sign a contract that requires me to merge code into git master and i would also not recommand anyone else to sign such contract. That said i never had a customer had a problem with that. I do try to get code through review its just that in rare cases someone fundamentally disagrees and a change cannot be put in git master. Its a recipe for conflict between teh community and whoever signed such contract. Also here we have STF which pays for maintaince, not for individual bug fixes in master. So making an exception makes even less sense here thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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] Vote STF/SPI 2024-02
On Thu, Feb 1, 2024 at 9:11 PM Rémi Denis-Courmont wrote: > Le torstaina 1. helmikuuta 2024, 19.45.52 EET Vittorio Giovara a écrit : > > The same of course should apply to any other future funding, it must be > > either the community (via GA) or a third party setting up the > sponsorship. > > Neither the community or the GA can forbid people from seeking funding for > themselves. I suppose that, in theory, developers could be required to > sign an > agreement to that effect before they are allowed to submit code for > inclusion, > but that seems neither practical, nor desirable to me. > > That is probably not what you meant, but that is what this reads like. > Yeah that's not what I meant, sorry for the confusion: what I meant was whoever secures the funding, then cannot be directly funded for any of the projects attributed in the current funding. This might be counterintuitive and possibly controversial, but the goal here is to distinguish benefiting the community and benefiting oneself as well as avoid losing a possible funding: I would really like to avoid that we miss out on funding out of fear that whoever found the funding will strongarm the community into accepting something that the community may reject. In other words, this is both protection for the community and for whoever finds the funding. I don't know how enforce-able it is, or if it is something that can actually facilitate accepting future funding for the community, but since we're in a time crunch and we're voting with unanswered open questions, it is something we should at least consider. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
On Tue, Feb 6, 2024 at 3:18 PM Ronald S. Bultje wrote: > Hi, > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer > > wrote: > > > 2. Deliverables > > Patches submitted for review to the FFMPEG dev mailing list. > > > > I think the goal is to get patches merged, not submitted. > ┓┏┓┏┓┃ ┛┗┛┗┛┃＼○／ ┓┏┓┏┓┃ / NOBODY ┛┗┛┗┛┃ノ) ┓┏┓┏┓┃ KNOWS ┛┗┛┗┛┃ ┓┏┓┏┓┃ ┛┗┛┗┛┃ ┓┏┓┏┓┃ ┃┃ ┻┻ -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@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] Remove SDL2 output devices
On Tue, Feb 6, 2024 at 9:08 AM Michael Koch wrote: > Removing SDL2 sounds like a very bad idea. There are many examples which > are using these output devices, and all these examples would be broken. > A quick search in my book > http://www.astro-electronic.de/FFmpeg_Book.pdf > finds about 40 occurences for "-f sdl" or "-f sdl2". > would it be easier/possible to fix SDL to work on any thread, instead of keeping this odd architecture in the codebase? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
On Tue, Feb 6, 2024 at 3:06 AM Michael Niedermayer wrote: > Hi all > > As Jonatan reminded the ML we need to provide SoWs if we want to > participate in STF-SPI > > We need one for each project (they do not need to list a person ATM) > but obviously we do need someone who will do the work > > I do belive they do need to list the money amount. > Thanks go to Pierre for helping me write template/example. > (converted from google docs and with some last minute edits) > > @Jonatan, is this below what SPI needs for each project ? > Correct me if I'm wrong but we still need the answer on "merge forks". Which ones, where, and why -- ie what if the community doesn't want or need any particular one? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@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] STF SoWs
Hi, On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer wrote: > 2. Deliverables > Patches submitted for review to the FFMPEG dev mailing list. > I think the goal is to get patches merged, not submitted. 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 v2] lavc/vvc: Validate alf_list indexes
Applied.
Thank you
On Mon, Feb 5, 2024 at 11:18 PM wrote:
> From: Frank Plowman
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/vvc_ps.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
> index 4ef8f9f9b9..9c4a74fc9c 100644
> --- a/libavcodec/vvc/vvc_ps.c
> +++ b/libavcodec/vvc/vvc_ps.c
> @@ -1005,6 +1005,39 @@ int ff_vvc_decode_aps(VVCParamSets *ps, const
> CodedBitstreamUnit *unit)
> return ret;
> }
>
> +static int sh_alf_aps(VVCSH *sh, const VVCFrameParamSets *fps)
> +{
> +if (!sh->r->sh_alf_enabled_flag)
> +return 0;
> +
> +for (int i = 0; i < sh->r->sh_num_alf_aps_ids_luma; i++) {
> +const VVCALF * alf_aps_luma =
> fps->alf_list[sh->r->sh_alf_aps_id_luma[i]];
> +if (!alf_aps_luma)
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (sh->r->sh_alf_cb_enabled_flag || sh->r->sh_alf_cr_enabled_flag) {
> +const VVCALF* alf_aps_chroma =
> fps->alf_list[sh->r->sh_alf_aps_id_chroma];
> +if (!alf_aps_chroma)
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (fps->sps->r->sps_ccalf_enabled_flag) {
> +if (sh->r->sh_alf_cc_cb_enabled_flag) {
> +const VVCALF *alf_aps_cc_cr =
> fps->alf_list[sh->r->sh_alf_cc_cb_aps_id];
> +if (!alf_aps_cc_cr)
> +return AVERROR_INVALIDDATA;
> +}
> +if (sh->r->sh_alf_cc_cr_enabled_flag) {
> +const VVCALF *alf_aps_cc_cr =
> fps->alf_list[sh->r->sh_alf_cc_cr_aps_id];
> +if (!alf_aps_cc_cr)
> +return AVERROR_INVALIDDATA;
> +}
> +}
> +
> +return 0;
> +}
> +
> static void sh_slice_address(VVCSH *sh, const H266RawSPS *sps, const
> VVCPPS *pps)
> {
> const int slice_address = sh->r->sh_slice_address;
> @@ -1123,8 +1156,12 @@ static int sh_derive(VVCSH *sh, const
> VVCFrameParamSets *fps)
> const H266RawSPS *sps = fps->sps->r;
> const H266RawPPS *pps = fps->pps->r;
> const H266RawPictureHeader *ph = fps->ph.r;
> +int ret;
>
> sh_slice_address(sh, sps, fps->pps);
> +ret = sh_alf_aps(sh, fps);
> +if (ret < 0)
> +return ret;
> sh_inter(sh, sps, pps);
> sh_qp_y(sh, pps, ph);
> sh_deblock_offsets(sh);
> --
> 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 mailing list
ffmpeg-devel@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] [REFUND-REQUEST] FOSDEM'24 Travel
Hi, Due to unforeseen circumstances (DB cancelling my train), I had to take an Uber to the train station to just barely get there in time for the alternative connection. 248,40 EUR: ICE Ulm <-> Bruxelle-Midi 18.16 EUR: Uber FOSDEM -> Bruxelle-Midi 266.56 EUR: total Thanks, Niklas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate: add IAMF in mp4 tests
Signed-off-by: James Almer --- tests/fate/mov.mak | 35 tests/ref/fate/mov-mp4-iamf-5_1_4 | 98 tests/ref/fate/mov-mp4-iamf-7_1_4 | 114 tests/ref/fate/mov-mp4-iamf-ambisonic_1 | 66 ++ tests/ref/fate/mov-mp4-iamf-stereo | 18 5 files changed, 331 insertions(+) create mode 100644 tests/ref/fate/mov-mp4-iamf-5_1_4 create mode 100644 tests/ref/fate/mov-mp4-iamf-7_1_4 create mode 100644 tests/ref/fate/mov-mp4-iamf-ambisonic_1 create mode 100644 tests/ref/fate/mov-mp4-iamf-stereo diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index 4850c8aa94..17fd99d8d2 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -194,6 +194,41 @@ fate-mov-pcm-remux: CMD = md5 -i $(TARGET_PATH)/tests/data/asynth-44100-1.wav -m fate-mov-pcm-remux: CMP = oneline fate-mov-pcm-remux: REF = e76115bc392d702da38f523216bba165 +FATE_MOV_FFMPEG-$(call TRANSCODE, FLAC, MOV, WAV_DEMUXER PCM_S16LE_DECODER) += fate-mov-mp4-iamf-stereo +fate-mov-mp4-iamf-stereo: tests/data/asynth-44100-2.wav tests/data/streamgroups/audio_element-stereo tests/data/streamgroups/mix_presentation-stereo +fate-mov-mp4-iamf-stereo: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav +fate-mov-mp4-iamf-stereo: CMD = transcode wav $(SRC) mp4 " \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/audio_element-stereo \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-stereo \ + -streamid 0:0 -c:a flac -t 1" "-c:a copy -map 0" + +FATE_MOV_FFMPEG-$(call TRANSCODE, FLAC, MOV, WAV_DEMUXER PCM_S16LE_DECODER) += fate-mov-mp4-iamf-5_1_4 +fate-mov-mp4-iamf-5_1_4: tests/data/asynth-44100-10.wav tests/data/filtergraphs/iamf_5_1_4 tests/data/streamgroups/audio_element-5_1_4 tests/data/streamgroups/mix_presentation-5_1_4 +fate-mov-mp4-iamf-5_1_4: SRC = $(TARGET_PATH)/tests/data/asynth-44100-10.wav +fate-mov-mp4-iamf-5_1_4: CMD = transcode wav $(SRC) mp4 "-auto_conversion_filters \ + -/filter_complex $(TARGET_PATH)/tests/data/filtergraphs/iamf_5_1_4 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/audio_element-5_1_4 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-5_1_4 \ + -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -streamid 4:4 -streamid 5:5 -map [FRONT] -map [BACK] -map [CENTER] -map [LFE] -map [TOP_FRONT] -map [TOP_BACK] -c:a flac -t 1" "-c:a copy -map 0" + +FATE_MOV_FFMPEG-$(call TRANSCODE, FLAC, MOV, WAV_DEMUXER PCM_S16LE_DECODER) += fate-mov-mp4-iamf-7_1_4 +fate-mov-mp4-iamf-7_1_4: tests/data/asynth-44100-12.wav tests/data/filtergraphs/iamf_7_1_4 tests/data/streamgroups/audio_element-7_1_4 tests/data/streamgroups/mix_presentation-7_1_4 +fate-mov-mp4-iamf-7_1_4: SRC = $(TARGET_PATH)/tests/data/asynth-44100-12.wav +fate-mov-mp4-iamf-7_1_4: CMD = transcode wav $(SRC) mp4 "-auto_conversion_filters \ + -/filter_complex $(TARGET_PATH)/tests/data/filtergraphs/iamf_7_1_4 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/audio_element-7_1_4 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-7_1_4 \ + -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -streamid 4:4 -streamid 5:5 -streamid 6:6 -map [FRONT] -map [BACK] -map [CENTER] -map [LFE] -map [SIDE] -map [TOP_FRONT] -map [TOP_BACK] -c:a flac -t 1" "-c:a copy -map 0" + +FATE_MOV_FFMPEG-$(call TRANSCODE, FLAC, MOV, WAV_DEMUXER PCM_S16LE_DECODER) += fate-mov-mp4-iamf-ambisonic_1 +fate-mov-mp4-iamf-ambisonic_1: tests/data/asynth-44100-4.wav tests/data/filtergraphs/iamf_ambisonic_1 tests/data/streamgroups/audio_element-ambisonic_1 tests/data/streamgroups/mix_presentation-ambisonic_1 +fate-mov-mp4-iamf-ambisonic_1: SRC = $(TARGET_PATH)/tests/data/asynth-44100-4.wav +fate-mov-mp4-iamf-ambisonic_1: CMD = transcode wav $(SRC) mp4 "-auto_conversion_filters \ + -/filter_complex $(TARGET_PATH)/tests/data/filtergraphs/iamf_ambisonic_1 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/audio_element-ambisonic_1 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-ambisonic_1 \ + -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -map [MONO0] -map [MONO1] -map [MONO2] -map [MONO3] -c:a flac -t 1" "-c:a copy -map 0" + FATE_FFMPEG += $(FATE_MOV_FFMPEG-yes) fate-mov: $(FATE_MOV) $(FATE_MOV_FFMPEG-yes) $(FATE_MOV_FFPROBE) $(FATE_MOV_FASTSTART) $(FATE_MOV_FFMPEG_FFPROBE-yes) diff --git a/tests/ref/fate/mov-mp4-iamf-5_1_4 b/tests/ref/fate/mov-mp4-iamf-5_1_4 new file mode 100644 index 00..804ab2ccc8 --- /dev/null +++ b/tests/ref/fate/mov-mp4-iamf-5_1_4 @@ -0,0 +1,98 @@ +d2d30f38521a49d054a6dbb47135b4e3 *tests/data/fate/mov-mp4-iamf-5_1_4.mp4 +86364 tests/data/fate/mov-mp4-iamf-5_1_4.mp4 +#extradata 0: 34, 0x40a802c6 +#extradata 1: 34, 0x40a802c6 +#extradata 2: 34, 0x407c02c4 +#extradata 3: 34, 0x407c02c4 +#extradata 4: 34, 0x40a802c6 +#extradata 5: 34, 0x40a802c6 +#tb 0: 1/44100
[FFmpeg-devel] [PATCH 6/7 v3] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
Signed-off-by: James Almer
---
No changes since last version
configure| 2 +-
libavformat/Makefile | 2 +-
libavformat/movenc.c | 336 +++
libavformat/movenc.h | 5 +
4 files changed, 281 insertions(+), 64 deletions(-)
diff --git a/configure b/configure
index 567a39b242..552e74acf8 100755
--- a/configure
+++ b/configure
@@ -3550,7 +3550,7 @@ mlp_demuxer_select="mlp_parser"
mmf_muxer_select="riffenc"
mov_demuxer_select="iso_media riffdec iamf_frame_split_bsf"
mov_demuxer_suggest="zlib"
-mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf
aac_adtstoasc_bsf ac3_parser"
+mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf
aac_adtstoasc_bsf iamf_frame_merge_bsf ac3_parser"
mp3_demuxer_select="mpegaudio_parser"
mp3_muxer_select="mpegaudioheader"
mp4_muxer_select="mov_muxer"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index ab264644c6..b5996b08ce 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -369,7 +369,7 @@ OBJS-$(CONFIG_MOV_DEMUXER) += mov.o
mov_chan.o mov_esds.o \
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vvc.o
vpcc.o \
movenchint.o mov_chan.o rtp.o \
movenccenc.o movenc_ttml.o
rawutils.o \
-dovi_isom.o evc.o
+dovi_isom.o evc.o iamf_writer.o
OBJS-$(CONFIG_MP2_MUXER) += rawenc.o
OBJS-$(CONFIG_MP3_DEMUXER) += mp3dec.o replaygain.o
OBJS-$(CONFIG_MP3_MUXER) += mp3enc.o rawenc.o id3v2enc.o
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 40473fdf56..676fba11ee 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -32,6 +32,7 @@
#include "dovi_isom.h"
#include "riff.h"
#include "avio.h"
+#include "iamf_writer.h"
#include "isom.h"
#include "av1.h"
#include "avc.h"
@@ -41,12 +42,14 @@
#include "libavcodec/flac.h"
#include "libavcodec/get_bits.h"
+#include "libavcodec/bsf.h"
#include "libavcodec/internal.h"
#include "libavcodec/put_bits.h"
#include "libavcodec/vc1_common.h"
#include "libavcodec/raw.h"
#include "internal.h"
#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
#include "libavutil/channel_layout.h"
#include "libavutil/csp.h"
#include "libavutil/intfloat.h"
@@ -316,6 +319,32 @@ static int mov_write_sdtp_tag(AVIOContext *pb, MOVTrack
*track)
return update_size(pb, pos);
}
+static int mov_write_iacb_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack
*track)
+{
+AVIOContext *dyn_bc;
+int64_t pos = avio_tell(pb);
+uint8_t *dyn_buf = NULL;
+int dyn_size;
+int ret = avio_open_dyn_buf(_bc);
+if (ret < 0)
+return ret;
+
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "iacb");
+avio_w8(pb, 1); // configurationVersion
+
+ret = ff_iamf_write_descriptors(track->iamf, dyn_bc, s);
+if (ret < 0)
+return ret;
+
+dyn_size = avio_close_dyn_buf(dyn_bc, _buf);
+ffio_write_leb(pb, dyn_size);
+avio_write(pb, dyn_buf, dyn_size);
+av_free(dyn_buf);
+
+return update_size(pb, pos);
+}
+
static int mov_write_amr_tag(AVIOContext *pb, MOVTrack *track)
{
avio_wb32(pb, 0x11); /* size */
@@ -1358,6 +1387,8 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
ret = mov_write_wave_tag(s, pb, track);
else if (track->tag == MKTAG('m','p','4','a'))
ret = mov_write_esds_tag(pb, track);
+else if (track->tag == MKTAG('i','a','m','f'))
+ret = mov_write_iacb_tag(mov->fc, pb, track);
else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)
ret = mov_write_amr_tag(pb, track);
else if (track->par->codec_id == AV_CODEC_ID_AC3)
@@ -2529,7 +2560,7 @@ static int mov_write_video_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
if (track->mode == MODE_AVIF) {
mov_write_ccst_tag(pb);
-if (s->nb_streams > 0 && track == >tracks[1])
+if (mov->nb_streams > 0 && track == >tracks[1])
mov_write_aux_tag(pb, "auxi");
}
@@ -3124,9 +3155,9 @@ static int mov_write_iloc_tag(AVIOContext *pb,
MOVMuxContext *mov, AVFormatConte
avio_wb32(pb, 0); /* Version & flags */
avio_w8(pb, (4 << 4) + 4); /* offset_size(4) and length_size(4) */
avio_w8(pb, 0); /* base_offset_size(4) and reserved(4) */
-avio_wb16(pb, s->nb_streams); /* item_count */
+avio_wb16(pb, mov->nb_streams); /* item_count */
-for (int i = 0; i < s->nb_streams; i++) {
+for (int i = 0; i < mov->nb_streams; i++) {
avio_wb16(pb, i + 1); /* item_id */
avio_wb16(pb, 0); /* data_reference_index */
avio_wb16(pb, 1); /* extent_count */
@@ -3145,9 +3176,9 @@ static int mov_write_iinf_tag(AVIOContext *pb,
MOVMuxContext *mov, AVFormatConte
avio_wb32(pb, 0); /* size */
[FFmpeg-devel] [PATCH 5/7 v3] avcodec: add an Immersive Audio Model and Formats frame merge bsf
Signed-off-by: James Almer
---
No changes since last version
doc/bitstream_filters.texi| 14 ++
libavcodec/bitstream_filters.c| 1 +
libavcodec/bsf/Makefile | 1 +
libavcodec/bsf/iamf_frame_merge_bsf.c | 228 ++
libavcodec/leb.h | 22 +++
5 files changed, 266 insertions(+)
create mode 100644 libavcodec/bsf/iamf_frame_merge_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 3d1a5e7a24..2f3077d02c 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -481,6 +481,20 @@ Lowest stream index value to set in output packets
Enable parsing in-band descriptor OBUs
@end table
+@section iamf_frame_merge
+
+Encapsulate audio data packets from different streams and merge them
+into a single packet containing all Audio Frame OBUs.
+
+@table @option
+@item index_mapping
+A :-separated list of stream_index=audio_substream_id entries to set
+stream id in output Audio Frame OBUs
+
+@item out_index
+Stream index to in output packets
+@end table
+
@section imxdump
Modifies the bitstream to fit in MOV and to be usable by the Final Cut
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 633187bc6e..a50488ad92 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -42,6 +42,7 @@ extern const FFBitStreamFilter ff_h264_redundant_pps_bsf;
extern const FFBitStreamFilter ff_hapqa_extract_bsf;
extern const FFBitStreamFilter ff_hevc_metadata_bsf;
extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
+extern const FFBitStreamFilter ff_iamf_frame_merge_bsf;
extern const FFBitStreamFilter ff_iamf_frame_split_bsf;
extern const FFBitStreamFilter ff_imx_dump_header_bsf;
extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index 738b97bdd1..662c5139bc 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -20,6 +20,7 @@ OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) +=
bsf/h264_redundant_pps.o
OBJS-$(CONFIG_HAPQA_EXTRACT_BSF) += bsf/hapqa_extract.o
OBJS-$(CONFIG_HEVC_METADATA_BSF) += bsf/h265_metadata.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += bsf/hevc_mp4toannexb.o
+OBJS-$(CONFIG_IAMF_FRAME_MERGE_BSF) += bsf/iamf_frame_merge_bsf.o
OBJS-$(CONFIG_IAMF_FRAME_SPLIT_BSF) += bsf/iamf_frame_split_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= bsf/imx_dump_header.o
OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += bsf/media100_to_mjpegb.o
diff --git a/libavcodec/bsf/iamf_frame_merge_bsf.c
b/libavcodec/bsf/iamf_frame_merge_bsf.c
new file mode 100644
index 00..98f37be653
--- /dev/null
+++ b/libavcodec/bsf/iamf_frame_merge_bsf.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright (c) 2024 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "libavutil/dict.h"
+#include "libavutil/fifo.h"
+#include "libavutil/opt.h"
+#include "libavformat/iamf.h"
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "bytestream.h"
+#include "get_bits.h"
+#include "leb.h"
+#include "put_bits.h"
+
+typedef struct IAMFMergeContext {
+AVClass *class;
+
+AVFifo *fifo;
+
+// AVOptions
+AVDictionary *index_mapping;
+int stream_count;
+int out_index;
+} IAMFMergeContext;
+
+static int find_id_from_idx(AVBSFContext *ctx, int idx)
+{
+IAMFMergeContext *const c = ctx->priv_data;
+const AVDictionaryEntry *e = NULL;
+
+while (e = av_dict_iterate(c->index_mapping, e)) {
+char *endptr = NULL;
+int id, map_idx = strtol(e->key, , 0);
+if (!endptr || *endptr)
+return AVERROR_INVALIDDATA;
+endptr = NULL;
+id = strtol(e->value, , 0);
+if (!endptr || *endptr)
+return AVERROR_INVALIDDATA;
+if (map_idx == idx)
+return id;
+}
+
+av_log(ctx, AV_LOG_ERROR, "Invalid stream idx %d\n", idx);
+return AVERROR_INVALIDDATA;
+}
+
+static int iamf_frame_merge_filter(AVBSFContext *ctx, AVPacket *out)
+{
+IAMFMergeContext *const c = ctx->priv_data;
+AVPacket *pkt;
+int ret;
+
+while (av_fifo_can_write(c->fifo)) {
+ret = ff_bsf_get_packet(ctx, );
+if
[FFmpeg-devel] [PATCH 4/7 v4] avformat/mov: add support for Immersive Audio Model and Formats in ISOBMFF
Signed-off-by: James Almer
---
Now passing descriptors to iamf_frame_split as extradata.
configure| 2 +-
libavformat/Makefile | 3 +-
libavformat/isom.h | 3 +
libavformat/mov.c| 274 ---
4 files changed, 265 insertions(+), 17 deletions(-)
diff --git a/configure b/configure
index f72533b7d2..567a39b242 100755
--- a/configure
+++ b/configure
@@ -3548,7 +3548,7 @@ matroska_demuxer_suggest="bzlib zlib"
matroska_muxer_select="mpeg4audio riffenc aac_adtstoasc_bsf
pgs_frame_merge_bsf vp9_superframe_bsf"
mlp_demuxer_select="mlp_parser"
mmf_muxer_select="riffenc"
-mov_demuxer_select="iso_media riffdec"
+mov_demuxer_select="iso_media riffdec iamf_frame_split_bsf"
mov_demuxer_suggest="zlib"
mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf
aac_adtstoasc_bsf ac3_parser"
mp3_demuxer_select="mpegaudio_parser"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 05b9b8a115..ab264644c6 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -364,7 +364,8 @@ OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
OBJS-$(CONFIG_MODS_DEMUXER) += mods.o
OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
OBJS-$(CONFIG_MOV_DEMUXER) += mov.o mov_chan.o mov_esds.o \
-qtpalette.o replaygain.o
dovi_isom.o
+qtpalette.o replaygain.o
dovi_isom.o \
+iamf.o iamf_parse.o
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vvc.o
vpcc.o \
movenchint.o mov_chan.o rtp.o \
movenccenc.o movenc_ttml.o
rawutils.o \
diff --git a/libavformat/isom.h b/libavformat/isom.h
index eee94d0449..5d74edce77 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -168,6 +168,7 @@ typedef struct MOVStreamContext {
AVIOContext *pb;
int refcount;
int pb_is_copied;
+int id; ///< AVStream id
int ffindex; ///< AVStream index
int next_chunk;
unsigned int chunk_count;
@@ -264,6 +265,8 @@ typedef struct MOVStreamContext {
AVEncryptionInfo *default_encrypted_sample;
MOVEncryptionIndex *encryption_index;
} cenc;
+
+struct IAMFContext *iamf;
} MOVStreamContext;
typedef struct HEIFItem {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 8ecc4869bb..ad316e49c7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -58,6 +58,7 @@
#include "internal.h"
#include "avio_internal.h"
#include "demux.h"
+#include "iamf_parse.h"
#include "dovi_isom.h"
#include "riff.h"
#include "isom.h"
@@ -212,6 +213,7 @@ static int mov_read_covr(MOVContext *c, AVIOContext *pb,
int type, int len)
}
st = c->fc->streams[c->fc->nb_streams - 1];
st->priv_data = sc;
+sc->id = st->id;
sc->refcount = 1;
if (st->attached_pic.size >= 8 && id != AV_CODEC_ID_BMP) {
@@ -836,6 +838,181 @@ static int mov_read_dac3(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
+static int mov_read_iacb(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+FFIOContext b;
+AVIOContext *descriptor_pb;
+AVDictionary *metadata;
+IAMFContext *iamf;
+char args[128];
+int64_t start_time, duration;
+unsigned descriptors_size;
+int nb_frames, disposition;
+int version, ret;
+
+if (atom.size < 5)
+return AVERROR_INVALIDDATA;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+version = avio_r8(pb);
+if (version != 1) {
+av_log(c->fc, AV_LOG_ERROR, "%s configurationVersion %d",
+ version < 1 ? "invalid" : "unsupported", version);
+return AVERROR_INVALIDDATA;
+}
+
+descriptors_size = ffio_read_leb(pb);
+if (!descriptors_size || descriptors_size > INT_MAX)
+return AVERROR_INVALIDDATA;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+iamf = sc->iamf = av_mallocz(sizeof(*iamf));
+if (!iamf)
+return AVERROR(ENOMEM);
+
+st->codecpar->extradata = av_malloc(descriptors_size);
+if (!st->codecpar->extradata)
+return AVERROR(ENOMEM);
+st->codecpar->extradata_size = descriptors_size;
+
+ret = avio_read(pb, st->codecpar->extradata, descriptors_size);
+if (ret != descriptors_size)
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
+
+snprintf(args, sizeof(args), "first_index=%d:inband_descriptors=false",
st->index);
+
+ret = ff_stream_add_bitstream_filter(st, "iamf_frame_split", args);
+if (ret == AVERROR_BSF_NOT_FOUND) {
+av_log(c->fc, AV_LOG_ERROR, "iamf_frame_split bitstream filter "
+ "not found. This is a bug, please report it.\n");
+ret = AVERROR_BUG;
+goto fail;
+}
+
+ffio_init_read_context(, st->codecpar->extradata,
[FFmpeg-devel] [PATCH 3/7 v4] avformat/mov: make MOVStreamContext refcounted
This will be useful in the next commit.
Signed-off-by: James Almer
---
No changes since last version
libavformat/isom.h | 1 +
libavformat/mov.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index a4cca4c798..eee94d0449 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -166,6 +166,7 @@ typedef struct MOVIndexRange {
typedef struct MOVStreamContext {
AVIOContext *pb;
+int refcount;
int pb_is_copied;
int ffindex; ///< AVStream index
int next_chunk;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 42b0135987..8ecc4869bb 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -212,6 +212,7 @@ static int mov_read_covr(MOVContext *c, AVIOContext *pb,
int type, int len)
}
st = c->fc->streams[c->fc->nb_streams - 1];
st->priv_data = sc;
+sc->refcount = 1;
if (st->attached_pic.size >= 8 && id != AV_CODEC_ID_BMP) {
if (AV_RB64(st->attached_pic.data) == 0x89504e470d0a1a0a) {
@@ -4672,6 +4673,7 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
sc->ffindex = st->index;
c->trak_index = st->index;
+sc->refcount = 1;
if ((ret = mov_read_default(c, pb, atom)) < 0)
return ret;
@@ -4959,6 +4961,7 @@ static int heif_add_stream(MOVContext *c, HEIFItem *item)
sc = st->priv_data;
sc->pb = c->fc->pb;
sc->pb_is_copied = 1;
+sc->refcount = 1;
// Populate the necessary fields used by mov_build_index.
sc->stsc_count = 1;
@@ -8660,8 +8663,10 @@ static void mov_free_stream_context(AVFormatContext *s,
AVStream *st)
{
MOVStreamContext *sc = st->priv_data;
-if (!sc)
+if (!sc || --sc->refcount) {
+st->priv_data = NULL;
return;
+}
av_freep(>ctts_data);
for (int i = 0; i < sc->drefs_count; i++) {
--
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/7 v4] avformat/demux: support inserting bitstream filters in demuxing scenarios
Packets will be passed to the bsf immediately after being generated by a
demuxer, and no further data will be read from the input until all packets
have been returned by the bsf.
Signed-off-by: James Almer
---
No changes since last version
libavformat/avformat.c | 47
libavformat/demux.c| 162 ++---
libavformat/internal.h | 13 +++-
libavformat/mux.c | 43 ---
libavformat/mux.h | 11 ---
libavformat/rawenc.c | 1 +
6 files changed, 181 insertions(+), 96 deletions(-)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..0e22d47c8b 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -931,3 +931,50 @@ FF_ENABLE_DEPRECATION_WARNINGS
*pb = NULL;
return ret;
}
+
+int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char
*args)
+{
+int ret;
+const AVBitStreamFilter *bsf;
+FFStream *const sti = ffstream(st);
+AVBSFContext *bsfc;
+
+av_assert0(!sti->bsfc);
+
+if (name) {
+bsf = av_bsf_get_by_name(name);
+if (!bsf) {
+av_log(NULL, AV_LOG_ERROR, "Unknown bitstream filter '%s'\n",
name);
+return AVERROR_BSF_NOT_FOUND;
+}
+ret = av_bsf_alloc(bsf, );
+} else
+ret = av_bsf_get_null_filter();
+if (ret < 0)
+return ret;
+
+bsfc->time_base_in = st->time_base;
+if ((ret = avcodec_parameters_copy(bsfc->par_in, st->codecpar)) < 0) {
+av_bsf_free();
+return ret;
+}
+
+if (args && bsfc->filter->priv_class) {
+if ((ret = av_set_options_string(bsfc->priv_data, args, "=", ":")) <
0) {
+av_bsf_free();
+return ret;
+}
+}
+
+if ((ret = av_bsf_init(bsfc)) < 0) {
+av_bsf_free();
+return ret;
+}
+
+sti->bsfc = bsfc;
+
+av_log(NULL, AV_LOG_VERBOSE,
+ "Automatically inserted bitstream filter '%s'; args='%s'\n",
+ name, args ? args : "");
+return 1;
+}
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..fb9bf9e4ac 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -540,6 +540,109 @@ static int update_wrap_reference(AVFormatContext *s,
AVStream *st, int stream_in
return 1;
}
+static void update_timestamps(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFStream *const sti = ffstream(st);
+
+if (update_wrap_reference(s, st, pkt->stream_index, pkt) &&
sti->pts_wrap_behavior == AV_PTS_WRAP_SUB_OFFSET) {
+// correct first time stamps to negative values
+if (!is_relative(sti->first_dts))
+sti->first_dts = wrap_timestamp(st, sti->first_dts);
+if (!is_relative(st->start_time))
+st->start_time = wrap_timestamp(st, st->start_time);
+if (!is_relative(sti->cur_dts))
+sti->cur_dts = wrap_timestamp(st, sti->cur_dts);
+}
+
+pkt->dts = wrap_timestamp(st, pkt->dts);
+pkt->pts = wrap_timestamp(st, pkt->pts);
+
+force_codec_ids(s, st);
+
+/* TODO: audio: time filter; video: frame reordering (pts != dts) */
+if (s->use_wallclock_as_timestamps)
+pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
st->time_base);
+}
+
+static int filter_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFFormatContext *const si = ffformatcontext(s);
+FFStream *const sti = ffstream(st);
+const AVPacket *pkt1;
+int err;
+
+if (!sti->bsfc) {
+const PacketListEntry *pktl = si->raw_packet_buffer.head;
+if (AVPACKET_IS_EMPTY(pkt))
+return 0;
+
+update_timestamps(s, st, pkt);
+
+if (!pktl && sti->request_probe <= 0)
+return 0;
+
+err = avpriv_packet_list_put(>raw_packet_buffer, pkt, NULL, 0);
+if (err < 0) {
+av_packet_unref(pkt);
+return err;
+}
+
+pkt1 = >raw_packet_buffer.tail->pkt;
+si->raw_packet_buffer_size += pkt1->size;
+
+if (sti->request_probe <= 0)
+return 0;
+
+return probe_codec(s, s->streams[pkt1->stream_index], pkt1);
+}
+
+err = av_bsf_send_packet(sti->bsfc, pkt);
+if (err < 0) {
+av_log(s, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d\n",
+sti->bsfc->filter->name, st->index);
+return err;
+}
+
+do {
+AVStream *out_st;
+FFStream *out_sti;
+
+err = av_bsf_receive_packet(sti->bsfc, pkt);
+if (err < 0) {
+if (err == AVERROR(EAGAIN) || err == AVERROR_EOF)
+return 0;
+av_log(s, AV_LOG_ERROR, "Error applying bitstream filters to an
output "
+ "packet for stream #%d: %s\n", st->index, av_err2str(err));
+if (!(s->error_recognition & AV_EF_EXPLODE) && err !=
AVERROR(ENOMEM))
+continue;
+return err;
+}
+out_st =
[FFmpeg-devel] [PATCH 1/7 v4] avcodec: add an Immersive Audio Model and Formats frame split bsf
Signed-off-by: James Almer
---
Now reading decriptors from extradata, plus a setting to ensure any descriptors
present inband are omitted has been added.
doc/bitstream_filters.texi| 16 +
libavcodec/bitstream_filters.c| 1 +
libavcodec/bsf/Makefile | 1 +
libavcodec/bsf/iamf_frame_split_bsf.c | 887 ++
4 files changed, 905 insertions(+)
create mode 100644 libavcodec/bsf/iamf_frame_split_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index d5bac105ff..3d1a5e7a24 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -465,6 +465,22 @@ Please note that this filter is auto-inserted for MPEG-TS
(muxer
@code{mpegts}) and raw HEVC/H.265 (muxer @code{h265} or
@code{hevc}) output formats.
+@section iamf_frame_split
+
+Split a packet containing one or more Audio Frame OBUs into several
+packets each containing the respective extracted audio data without the
+Audio Frame OBU encapsulation.
+Stream index in output packets will be set based on the order the OBUs
+are coded.
+
+@table @option
+@item first_index
+Lowest stream index value to set in output packets
+
+@item inband_descriptors
+Enable parsing in-band descriptor OBUs
+@end table
+
@section imxdump
Modifies the bitstream to fit in MOV and to be usable by the Final Cut
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1bae113d92..633187bc6e 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -42,6 +42,7 @@ extern const FFBitStreamFilter ff_h264_redundant_pps_bsf;
extern const FFBitStreamFilter ff_hapqa_extract_bsf;
extern const FFBitStreamFilter ff_hevc_metadata_bsf;
extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
+extern const FFBitStreamFilter ff_iamf_frame_split_bsf;
extern const FFBitStreamFilter ff_imx_dump_header_bsf;
extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index 62609eb24e..738b97bdd1 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -20,6 +20,7 @@ OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) +=
bsf/h264_redundant_pps.o
OBJS-$(CONFIG_HAPQA_EXTRACT_BSF) += bsf/hapqa_extract.o
OBJS-$(CONFIG_HEVC_METADATA_BSF) += bsf/h265_metadata.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += bsf/hevc_mp4toannexb.o
+OBJS-$(CONFIG_IAMF_FRAME_SPLIT_BSF) += bsf/iamf_frame_split_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= bsf/imx_dump_header.o
OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += bsf/media100_to_mjpegb.o
OBJS-$(CONFIG_MJPEG2JPEG_BSF) += bsf/mjpeg2jpeg.o
diff --git a/libavcodec/bsf/iamf_frame_split_bsf.c
b/libavcodec/bsf/iamf_frame_split_bsf.c
new file mode 100644
index 00..dc8ad6730a
--- /dev/null
+++ b/libavcodec/bsf/iamf_frame_split_bsf.c
@@ -0,0 +1,887 @@
+/*
+ * Copyright (c) 2023 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "libavutil/dict.h"
+#include "libavutil/opt.h"
+#include "libavformat/iamf.h"
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "get_bits.h"
+#include "leb.h"
+
+typedef struct ParamDefinition {
+AVIAMFParamDefinition *param;
+size_t param_size;
+int mode;
+int recon_gain_present_bitmask;
+} ParamDefinition;
+
+typedef struct IAMFSplitContext {
+AVClass *class;
+AVPacket *buffer_pkt;
+
+ParamDefinition *param_definitions;
+unsigned int nb_param_definitions;
+
+unsigned int *ids;
+int nb_ids;
+
+// AVOptions
+int first_index;
+int inband_descriptors;
+
+// Packet side data
+AVIAMFParamDefinition *mix;
+size_t mix_size;
+AVIAMFParamDefinition *demix;
+size_t demix_size;
+AVIAMFParamDefinition *recon;
+size_t recon_size;
+} IAMFSplitContext;
+
+static int param_parse(AVBSFContext *ctx, GetBitContext *gb,
+ unsigned int type,
+ ParamDefinition **out)
+{
+IAMFSplitContext *const c = ctx->priv_data;
+ParamDefinition *param_definition = NULL;
+AVIAMFParamDefinition *param;
+unsigned int parameter_id, parameter_rate, mode;
+
Re: [FFmpeg-devel] [PATCH 0/2] Remove SDL2 output devices
Zhao Zhili (12024-02-06): > Those examples are broken already before the patch. Funny that the people who actually use the feature had not noticed. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/1] avformat/mpegts: fix first NAL start code splited in two different packets
On Tue, 6 Feb 2024 at 11:39, Nicolas Gaullier wrote: > >> If you think it would be better to have a related trac ticket, just > >> tell me, I can do this of course. > >> Nicolas > >> > > > >I think it's ok. I wish it were less ugly but I guess it can't be. > > > >Kieran > > Yes, of course! I am really really sorry. > Personally, I have not found a better solution as an mpegts fix, but if > anyone has a better code, of course my version can be dropped. > (I have not looked for a possible fix in the upper ffmpeg demux/parser > layers, but it would be certainly even more ugly, if possible at all). > > Again, sorry. There are some implementers who take the standards very > crude to "optimize" for every little byte unreasonably. > Fact is, here, the standard should not have allowed this! > Nicolas > Yes, I know exactly who is creating these files. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vvc: Fix slice_idx out-of-bounds memset
On Tue, Feb 6, 2024 at 2:00 AM wrote:
> From: Frank Plowman
>
> If the number of CTUs reduces between one picture and the next, the
> slice_idx table is reduced in size in the frame_context_for_each_tl call
> on vvcdec.c:321. When initialising the slice_idx table on vvcdec.c:325,
> the old code uses fc->tab.sz.ctu_count when calculating the table size.
> fc->tab.sz.ctu_count holds the old ctu count at this point however, not
> being updated to hold the new ctu count until vvcdec.c:342. This causes
> an out-of-bounds write.
>
> Patch fixes the problem by using pps->ctb_count, which was just used
> when allocating the table, in place of fc->tab.sz.ctu_count when
> initialising the table.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/vvcdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
> index 1a050600eb..8163b5ecb6 100644
> --- a/libavcodec/vvc/vvcdec.c
> +++ b/libavcodec/vvc/vvcdec.c
> @@ -322,7 +322,7 @@ static int pic_arrays_init(VVCContext *s,
> VVCFrameContext *fc)
> if (ret < 0)
> return ret;
>
> -memset(fc->tab.slice_idx, -1, sizeof(*fc->tab.slice_idx) *
> fc->tab.sz.ctu_count);
> +memset(fc->tab.slice_idx, -1, sizeof(*fc->tab.slice_idx) * ctu_count);
>
applied,
thank you frank
>
> if (fc->tab.sz.ctu_count != ctu_count) {
> ff_refstruct_pool_uninit(>rpl_tab_pool);
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Feb 6, 2024, 07:51 by dcni...@gmail.com: > On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov wrote: > >> diff --git a/configure b/configure >> index f72533b7d2..1bb9e23f19 100755 >> --- a/configure >> +++ b/configure >> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then >> die "C compiler test failed." >> fi >> >> -add_cppflags -D_ISOC99_SOURCE >> +add_cppflags -D_ISOC11_SOURCE >> > > Not an expert, should this be D_ISOC17_SOURCE? A google shows this > doesn't exist, so i guess i'm wrong. Some comment may be helpful here > C17 added no new functions that users have to opt-in to, so there isn't a D_ISOC17_SOURCE define. Opting into C11 is all that's needed. ___ ffmpeg-devel mailing list ffmpeg-devel@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] Remove SDL2 output devices
> On Feb 6, 2024, at 16:08, Michael Koch wrote: > > Removing SDL2 sounds like a very bad idea. There are many examples which are > using these output devices, and all these examples would be broken. A quick > search in my book > http://www.astro-electronic.de/FFmpeg_Book.pdf > finds about 40 occurences for "-f sdl" or "-f sdl2". Those examples are broken already before the patch. We are not talking about that in this thread. Please reference https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg155921.html > > Michael > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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 0/1] avformat/mpegts: fix first NAL start code splited in two different packets
>> If you think it would be better to have a related trac ticket, just >> tell me, I can do this of course. >> Nicolas >> > >I think it's ok. I wish it were less ugly but I guess it can't be. > >Kieran Yes, of course! I am really really sorry. Personally, I have not found a better solution as an mpegts fix, but if anyone has a better code, of course my version can be dropped. (I have not looked for a possible fix in the upper ffmpeg demux/parser layers, but it would be certainly even more ugly, if possible at all). Again, sorry. There are some implementers who take the standards very crude to "optimize" for every little byte unreasonably. Fact is, here, the standard should not have allowed this! 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 0/1] avformat/mpegts: fix first NAL start code splited in two different packets
On Tue, 6 Feb 2024 at 10:58, Nicolas Gaullier wrote: > >Envoyé : vendredi 2 février 2024 16:24 > >À : ffmpeg-devel@ffmpeg.org > >Objet : [PATCH 0/1] avformat/mpegts: fix first NAL start code splited in > two different packets > > > >This issue happens in the following case: > >- unaligned PES and NAL encoding > >- the first NAL of the access unit begins at the very end of a ts packet, > sometimes only the 0x00 of the trailing byte (unfortunately, this is still > conformant to the standards!) > >- the video frame is so small (ex: typically still picture) it fits in a > ts packet and a new PES is immediately started > > > >Two sample files can be found here: > >a) https://0x0.st/HDwD.ts > >b) https://0x0.st/HDwd.ts > > > >For sample a, the first NAL (AUD) is splited this way: > >0x00 / 0x00 0x00 0x01 0x09 > >And for sample b: > >0x00 0x00 0x00 / 0x01 0x09 > > > >ffmpeg -i input.ts -f null /dev/null > >=> Application provided invalid, non monotonically increasing dts... > > > > > >Nicolas Gaullier (1): > > avformat/mpegts: fix first NAL start code splited in two different > >packets > > > > libavformat/mpegts.c | 41 +++-- > > 1 file changed, 39 insertions(+), 2 deletions(-) > > Ping ? > If you think it would be better to have a related trac ticket, just tell > me, I can do this of course. > Nicolas > I think it's ok. I wish it were less ugly but I guess it can't be. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@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] x86/tx_float: enable SIMD for sizes over 131072
Please push this ASAP, my all private projects depends on it. ___ ffmpeg-devel mailing list ffmpeg-devel@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/1] avformat/mpegts: fix first NAL start code splited in two different packets
>Envoyé : vendredi 2 février 2024 16:24 >À : ffmpeg-devel@ffmpeg.org >Objet : [PATCH 0/1] avformat/mpegts: fix first NAL start code splited in two >different packets > >This issue happens in the following case: >- unaligned PES and NAL encoding >- the first NAL of the access unit begins at the very end of a ts packet, >sometimes only the 0x00 of the trailing byte (unfortunately, this is still >conformant to the standards!) >- the video frame is so small (ex: typically still picture) it fits in a ts >packet and a new PES is immediately started > >Two sample files can be found here: >a) https://0x0.st/HDwD.ts >b) https://0x0.st/HDwd.ts > >For sample a, the first NAL (AUD) is splited this way: >0x00 / 0x00 0x00 0x01 0x09 >And for sample b: >0x00 0x00 0x00 / 0x01 0x09 > >ffmpeg -i input.ts -f null /dev/null >=> Application provided invalid, non monotonically increasing dts... > > >Nicolas Gaullier (1): > avformat/mpegts: fix first NAL start code splited in two different >packets > > libavformat/mpegts.c | 41 +++-- > 1 file changed, 39 insertions(+), 2 deletions(-) Ping ? If you think it would be better to have a related trac ticket, just tell me, I can do this of course. 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".
[FFmpeg-devel] [PATCH v2 2/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable
Offers a modest performance gain due to the switch from naive linear
probling to robin hood.
Signed-off-by: Connor Worley
---
libavcodec/dxvenc.c | 121
1 file changed, 33 insertions(+), 88 deletions(-)
diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
index b274175689..ebc48aace3 100644
--- a/libavcodec/dxvenc.c
+++ b/libavcodec/dxvenc.c
@@ -21,7 +21,7 @@
#include
-#include "libavutil/crc.h"
+#include "libavutil/hashtable.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
@@ -37,76 +37,13 @@
* appeared in the decompressed stream. Using a simple hash table (HT)
* significantly speeds up the lookback process while encoding.
*/
-#define LOOKBACK_HT_ELEMS 0x4
+#define LOOKBACK_HT_ELEMS 0x20202
#define LOOKBACK_WORDS0x20202
enum DXVTextureFormat {
DXV_FMT_DXT1 = MKBETAG('D', 'X', 'T', '1'),
};
-typedef struct HTEntry {
-uint32_t key;
-uint32_t pos;
-} HTEntry;
-
-static void ht_init(HTEntry *ht)
-{
-for (size_t i = 0; i < LOOKBACK_HT_ELEMS; i++) {
-ht[i].pos = -1;
-}
-}
-
-static uint32_t ht_lookup_and_upsert(HTEntry *ht, const AVCRC *hash_ctx,
-uint32_t key, uint32_t pos)
-{
-uint32_t ret = -1;
-size_t hash = av_crc(hash_ctx, 0, (uint8_t*), 4) % LOOKBACK_HT_ELEMS;
-for (size_t i = hash; i < hash + LOOKBACK_HT_ELEMS; i++) {
-size_t wrapped_index = i % LOOKBACK_HT_ELEMS;
-HTEntry *entry = [wrapped_index];
-if (entry->key == key || entry->pos == -1) {
-ret = entry->pos;
-entry->key = key;
-entry->pos = pos;
-break;
-}
-}
-return ret;
-}
-
-static void ht_delete(HTEntry *ht, const AVCRC *hash_ctx,
- uint32_t key, uint32_t pos)
-{
-HTEntry *removed_entry = NULL;
-size_t removed_hash;
-size_t hash = av_crc(hash_ctx, 0, (uint8_t*), 4) % LOOKBACK_HT_ELEMS;
-
-for (size_t i = hash; i < hash + LOOKBACK_HT_ELEMS; i++) {
-size_t wrapped_index = i % LOOKBACK_HT_ELEMS;
-HTEntry *entry = [wrapped_index];
-if (entry->pos == -1)
-return;
-if (removed_entry) {
-size_t candidate_hash = av_crc(hash_ctx, 0, (uint8_t*)>key,
4) % LOOKBACK_HT_ELEMS;
-if ((wrapped_index > removed_hash && (candidate_hash <=
removed_hash || candidate_hash > wrapped_index)) ||
-(wrapped_index < removed_hash && (candidate_hash <=
removed_hash && candidate_hash > wrapped_index))) {
-*removed_entry = *entry;
-entry->pos = -1;
-removed_entry = entry;
-removed_hash = wrapped_index;
-}
-} else if (entry->key == key) {
-if (entry->pos <= pos) {
-entry->pos = -1;
-removed_entry = entry;
-removed_hash = wrapped_index;
-} else {
-return;
-}
-}
-}
-}
-
typedef struct DXVEncContext {
AVClass *class;
@@ -123,10 +60,8 @@ typedef struct DXVEncContext {
enum DXVTextureFormat tex_fmt;
int (*compress_tex)(AVCodecContext *avctx);
-const AVCRC *crc_ctx;
-
-HTEntry color_lookback_ht[LOOKBACK_HT_ELEMS];
-HTEntry lut_lookback_ht[LOOKBACK_HT_ELEMS];
+struct AVHashtableContext *color_ht;
+struct AVHashtableContext *lut_ht;
} DXVEncContext;
/* Converts an index offset value to a 2-bit opcode and pushes it to a stream.
@@ -161,27 +96,32 @@ static int dxv_compress_dxt1(AVCodecContext *avctx)
DXVEncContext *ctx = avctx->priv_data;
PutByteContext *pbc = >pbc;
uint32_t *value;
-uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos =
2, op = 0;
+uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos =
0, op = 0;
-ht_init(ctx->color_lookback_ht);
-ht_init(ctx->lut_lookback_ht);
+av_hashtable_clear(ctx->color_ht);
+av_hashtable_clear(ctx->lut_ht);
bytestream2_put_le32(pbc, AV_RL32(ctx->tex_data));
+av_hashtable_set(ctx->color_ht, ctx->tex_data, );
+pos++;
bytestream2_put_le32(pbc, AV_RL32(ctx->tex_data + 4));
-
-ht_lookup_and_upsert(ctx->color_lookback_ht, ctx->crc_ctx,
AV_RL32(ctx->tex_data), 0);
-ht_lookup_and_upsert(ctx->lut_lookback_ht, ctx->crc_ctx,
AV_RL32(ctx->tex_data + 4), 1);
+av_hashtable_set(ctx->lut_ht, ctx->tex_data + 4, );
+pos++;
while (pos + 2 <= ctx->tex_size / 4) {
idx = 0;
+color_idx = 0;
+lut_idx = 0;
color = AV_RL32(ctx->tex_data + pos * 4);
-prev_pos = ht_lookup_and_upsert(ctx->color_lookback_ht, ctx->crc_ctx,
color, pos);
-color_idx = prev_pos != -1 ? pos - prev_pos : 0;
+if (av_hashtable_get(ctx->color_ht, , _pos))
+color_idx = pos - prev_pos;
+av_hashtable_set(ctx->color_ht, , );
+
if (pos >= LOOKBACK_WORDS) {
uint32_t
[FFmpeg-devel] [PATCH v2 1/2] lavu/hashtable: create generic robin hood hash table
Signed-off-by: Connor Worley
---
libavutil/Makefile | 2 +
libavutil/hashtable.c | 183
libavutil/hashtable.h | 47 +
libavutil/tests/hashtable.c | 108 +
4 files changed, 340 insertions(+)
create mode 100644 libavutil/hashtable.c
create mode 100644 libavutil/hashtable.h
create mode 100644 libavutil/tests/hashtable.c
diff --git a/libavutil/Makefile b/libavutil/Makefile
index e7709b97d0..be75d464fc 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -138,6 +138,7 @@ OBJS = adler32.o
\
fixed_dsp.o \
frame.o \
hash.o \
+ hashtable.o \
hdr_dynamic_metadata.o \
hdr_dynamic_vivid_metadata.o \
hmac.o \
@@ -251,6 +252,7 @@ TESTPROGS = adler32
\
file\
fifo\
hash\
+hashtable \
hmac\
hwdevice\
integer \
diff --git a/libavutil/hashtable.c b/libavutil/hashtable.c
new file mode 100644
index 00..6fa2af8af3
--- /dev/null
+++ b/libavutil/hashtable.c
@@ -0,0 +1,183 @@
+/*
+ * Generic hashtable
+ * Copyright (C) 2024 Connor Worley
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "crc.h"
+#include "error.h"
+#include "mem.h"
+#include "hashtable.h"
+
+struct AVHashtableContext {
+size_t key_size;
+size_t val_size;
+size_t entry_size;
+size_t max_entries;
+size_t utilization;
+const AVCRC *crc;
+uint8_t *table;
+uint8_t *swapbuf;
+};
+
+#define ENTRY_PSL(entry) (entry)
+#define ENTRY_OCC(entry) (ENTRY_PSL(entry) + sizeof(size_t))
+#define ENTRY_KEY(entry) (ENTRY_OCC(entry) + 4)
+#define ENTRY_VAL(entry) (ENTRY_KEY(entry) + FFALIGN(ctx->key_size, 4))
+
+#define KEYS_EQUAL(k1, k2) !memcmp(k1, k2, ctx->key_size)
+
+int av_hashtable_alloc(struct AVHashtableContext** ctx, size_t key_size,
size_t val_size, size_t max_entries)
+{
+struct AVHashtableContext *res = av_malloc(sizeof(struct
AVHashtableContext));
+if (!res)
+return AVERROR(ENOMEM);
+res->key_size = key_size;
+res->val_size = val_size;
+res->entry_size = sizeof(size_t) + 4 + FFALIGN(key_size, 4) +
FFALIGN(val_size, 4);
+res->max_entries = max_entries;
+res->utilization = 0;
+res->crc = av_crc_get_table(AV_CRC_32_IEEE);
+if (!res->crc) {
+av_hashtable_freep();
+return AVERROR_BUG;
+}
+res->table = av_calloc(res->max_entries, res->entry_size);
+if (!res->table) {
+av_hashtable_freep();
+return AVERROR(ENOMEM);
+}
+res->swapbuf = av_calloc(2, FFALIGN(key_size, 4) + FFALIGN(val_size, 4));
+if (!res->swapbuf) {
+av_hashtable_freep();
+return AVERROR(ENOMEM);
+}
+*ctx = res;
+return 0;
+}
+
+static size_t hash_key(const struct AVHashtableContext* ctx, const void* key)
+{
+return av_crc(ctx->crc, 0, key, ctx->key_size) % ctx->max_entries;
+}
+
+int av_hashtable_get(const struct AVHashtableContext* ctx, const void* key,
void* val)
+{
+size_t hash = hash_key(ctx, key);
+
+if (!ctx->utilization)
+return 0;
+
+for (size_t psl = 0; psl < ctx->max_entries; psl++) {
+size_t wrapped_index = (hash + psl) % ctx->max_entries;
+uint8_t *entry = ctx->table + wrapped_index * ctx->entry_size;
+if (!*ENTRY_OCC(entry) || *(size_t*)ENTRY_PSL(entry) < psl)
+
[FFmpeg-devel] [PATCH 0/1] avformat/demux: Add durationprobesize AVOption
I posted "avformat/demux: Add more retries to get more stream durations" last friday and it is a complementary patch. https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10654 Note that, if this "Add more retries" patch is accepted, I would update this patch to set DURATION_MAX_RETRY_USER to the value of MORE_DURATIONS_MAX_RETRY (3), which means that if the user ask for 8M, the first step will be to try 1M, then 2M, then up to 8M until all A/V durations are found. Currently, since there is only one extra retry to get all durations, if the user ask for 8M, the first step is to try with 4M. The default behaviour remains unchanged as exact stream durations is only required for somes use cases and/or some specific files. Here is a sample file (mpegts @15Mb/s, with A/V pts cleanly cut at the end): https://0x0.st/HkxN.ts If it can help, I can add a trac issue or build a patchset with the two patches. Nicolas Gaullier (1): avformat/demux: Add durationprobesize AVOption libavformat/avformat.h | 8 libavformat/demux.c | 13 - libavformat/options_table.h | 1 + 3 files changed, 17 insertions(+), 5 deletions(-) -- 2.30.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/1] avformat/demux: Add durationprobesize AVOption
Yet another probesize used to get the last pts (and thus the duration)
of mpegts/ps files. It is aimed at users interested in better durations probing
for itself, or because using avformat_find_stream_info indirectly and requiring
exact values: for concatdec for exemple, especially if streamcopying above it.
The current code does not behave well with high bitrates and high video
buffering
(physical gap between the last video packet and the last audio packet).
Default behaviour is unchanged: 250k up to 250k << 6 (step by step)
Setting this new option has two effects:
- override the maximum probesize (currently 250k << 6)
- reduce the number of steps to 1 instead of 6, this is to avoid detecting
the audio "too early" and failing to reach a video packet. Here, even if audio
duration is found but not the video duration, there will be a retry, so at the
end the full user-overriden probesize will be used.
Signed-off-by: Nicolas Gaullier
---
libavformat/avformat.h | 8
libavformat/demux.c | 13 -
libavformat/options_table.h | 1 +
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..533f5a963d 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1823,6 +1823,14 @@ typedef struct AVFormatContext {
* Freed by libavformat in avformat_free_context().
*/
AVStreamGroup **stream_groups;
+
+/**
+ * Maximum number of bytes read at the end of input in order to determine
the
+ * stream durations. Used by avformat_find_stream_info() for MPEG-TS/PS.
+ *
+ * Demuxing only, set by the caller before avformat_open_input().
+ */
+int64_t duration_probesize;
} AVFormatContext;
/**
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..798b44c979 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1740,8 +1740,9 @@ static void
estimate_timings_from_bit_rate(AVFormatContext *ic)
"Estimating duration from bitrate, this may be inaccurate\n");
}
-#define DURATION_MAX_READ_SIZE 25LL
-#define DURATION_MAX_RETRY 6
+#define DURATION_MAX_READ_SIZE_DEFAULT 25LL
+#define DURATION_MAX_RETRY_DEFAULT 6
+#define DURATION_MAX_RETRY_USER 1
/* only usable for MPEG-PS streams */
static void estimate_timings_from_pts(AVFormatContext *ic, int64_t old_offset)
@@ -1749,6 +1750,8 @@ static void estimate_timings_from_pts(AVFormatContext
*ic, int64_t old_offset)
FFFormatContext *const si = ffformatcontext(ic);
AVPacket *const pkt = si->pkt;
int num, den, read_size, ret;
+int64_t duration_max_read_size = ic->duration_probesize ?
ic->duration_probesize >> DURATION_MAX_RETRY_USER :
DURATION_MAX_READ_SIZE_DEFAULT;
+int duration_max_retry = ic->duration_probesize ? DURATION_MAX_RETRY_USER
: DURATION_MAX_RETRY_DEFAULT;
int found_duration = 0;
int is_end;
int64_t filesize, offset, duration;
@@ -1784,7 +1787,7 @@ static void estimate_timings_from_pts(AVFormatContext
*ic, int64_t old_offset)
filesize = ic->pb ? avio_size(ic->pb) : 0;
do {
is_end = found_duration;
-offset = filesize - (DURATION_MAX_READ_SIZE << retry);
+offset = filesize - (duration_max_read_size << retry);
if (offset < 0)
offset = 0;
@@ -1793,7 +1796,7 @@ static void estimate_timings_from_pts(AVFormatContext
*ic, int64_t old_offset)
for (;;) {
AVStream *st;
FFStream *sti;
-if (read_size >= DURATION_MAX_READ_SIZE << (FFMAX(retry - 1, 0)))
+if (read_size >= duration_max_read_size << (FFMAX(retry - 1, 0)))
break;
do {
@@ -1847,7 +1850,7 @@ static void estimate_timings_from_pts(AVFormatContext
*ic, int64_t old_offset)
}
} while (!is_end &&
offset &&
- ++retry <= DURATION_MAX_RETRY);
+ ++retry <= duration_max_retry);
av_opt_set_int(ic, "skip_changes", 0, AV_OPT_SEARCH_CHILDREN);
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 91708de453..c2bdb484a7 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -108,6 +108,7 @@ static const AVOption avformat_options[] = {
{"max_streams", "maximum number of streams", OFFSET(max_streams),
AV_OPT_TYPE_INT, { .i64 = 1000 }, 0, INT_MAX, D },
{"skip_estimate_duration_from_pts", "skip duration calculation in
estimate_timings_from_pts", OFFSET(skip_estimate_duration_from_pts),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, D},
{"max_probe_packets", "Maximum number of packets to probe a codec",
OFFSET(max_probe_packets), AV_OPT_TYPE_INT, { .i64 = 2500 }, 0, INT_MAX, D },
+{"durationprobesize", "maximum number of bytes to probe the stream durations",
OFFSET(duration_probesize), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0, INT64_MAX, D},
{NULL},
};
--
2.30.2
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/signature_lookup: dont leave uncleared pointers in sll_free()
Michael Niedermayer:
> On Mon, Feb 05, 2024 at 12:51:57PM +0100, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavfilter/signature_lookup.c | 21 ++---
>>> 1 file changed, 10 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
>>> index 86dd0c66754..52a97e1bc7e 100644
>>> --- a/libavfilter/signature_lookup.c
>>> +++ b/libavfilter/signature_lookup.c
>>> @@ -37,6 +37,15 @@
>>> #define STATUS_END_REACHED 1
>>> #define STATUS_BEGIN_REACHED 2
>>>
>>> +static void sll_free(MatchingInfo **sll)
>>> +{
>>> +while (*sll) {
>>> +MatchingInfo *tmp = *sll;
>>> +*sll = (*sll)->next;
>>> +av_free(tmp);
>>> +}
>>
>> This does not clear the pointers at all. This does (and avoids
>> indirections).
>>
>> static void sll_free(MatchingInfo **sllp)
>> {
>> MatchingInfo *sll = *sllp;
>>
>> *sllp = NULL;
>> while (sll) {
>> MatchingInfo *tmp = sll;
>> sll = sll->next;
>> av_free(tmp);
>> }
>> }
>
> I tried it with code below, but your code is not different from mine in
> behavior just more complex
>
Your code indeed resets the pointer; it overwrites the pointer once per
loop iteration and so sets it to NULL in the last iteration. I somehow
overlooked that.
I actually consider your code more complex (my code resets the original
pointer and directly traverses the list, your code does the same, but in
between it overwrites the original pointer to store the next pointer
instead of using a simple stack variable for this purpose).
Apply as you wish.
> output:
> (nil) 0x560e8daad2c0 (nil)
> vs.
> (nil) 0x557ae6e472c0 (nil)
>
> sll_free_n2() is simpler and will clear all, the reason i did not
> propose it, is its recursive and can hit stack space limits in principle
> sll_free_n3() and sll_free_n4() are other options that will clear all
> but maybe every choice contains bugs, i didnt really test them with more than
> one testcase
sll_free_n2() is not recursive.
>
> ---
>
> #include
> #include
> #include
>
> #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
>
> static void av_free(void *ptr)
> {
> free(ptr);
> }
>
> static void av_freep(void *arg)
> {
> void *val;
>
> memcpy(, arg, sizeof(val));
> memcpy(arg, &(void *){ NULL }, sizeof(val));
> av_free(val);
> }
>
>
> typedef struct MatchingInfo {
> struct MatchingInfo *next;
> } MatchingInfo;
>
>
> static void sll_free_n(MatchingInfo **sll)
> {
> while (*sll) {
> MatchingInfo *tmp = *sll;
> *sll = (*sll)->next;
> av_free(tmp);
> }
> }
>
> static void sll_free_n2(MatchingInfo **sll)
> {
> if (*sll)
> sll_free_n(&(*sll)->next);
> av_freep(sll);
> }
>
> static void sll_free_n3(MatchingInfo **sll)
> {
> while (*sll) {
> MatchingInfo *tmp = *sll;
> *sll = tmp->next;
> tmp->next = NULL;
> av_free(tmp);
> }
> }
>
> static void sll_free_n4(MatchingInfo **sll)
> {
> MatchingInfo *tmp = NULL;
> while (*sll) {
> FFSWAP(MatchingInfo *, tmp, (*sll)->next);
> av_freep(sll);
> FFSWAP(MatchingInfo *, tmp, *sll);
> }
> }
>
> static void sll_free_r(MatchingInfo **sllp)
> {
> MatchingInfo *sll = *sllp;
>
> *sllp = NULL;
> while (sll) {
> MatchingInfo *tmp = sll;
> sll = sll->next;
> av_free(tmp);
> }
> }
>
> main() {
> MatchingInfo *mi, *m1, *m2;
>
> m1 = mi = malloc(sizeof(MatchingInfo));
> m2 = mi->next = malloc(sizeof(MatchingInfo));
> m2->next= NULL;
>
> sll_free_r();
>
> printf("%p %p %p\n", mi, m1->next, m2->next);
>
> }
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavu/thread: Check HAVE_PTHREAD_SET_?NAME_NP is defined
On 06/02/2024 11:23, Andreas Rheinhardt wrote: > p...@frankplowman.com: >> From: Frank Plowman >> >> Check HAVE_PTHREAD_SETNAME_NP and HAVE_PTHREAD_SET_NAME_NP are defined >> before using them in macro conditions. Gets rid of lots of -Wundef >> warnings present when building on MacOS since >> fd16d8c68cd7b820eda76c407b0645b7cf470efd. >> >> Signed-off-by: Frank Plowman >> --- >> libavutil/thread.h | 8 +--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/libavutil/thread.h b/libavutil/thread.h >> index 2c00c7cc35..0200b7b511 100644 >> --- a/libavutil/thread.h >> +++ b/libavutil/thread.h >> @@ -26,7 +26,9 @@ >> >> #if HAVE_PRCTL >> #include >> -#elif (HAVE_PTHREAD_SETNAME_NP || HAVE_PTHREAD_SET_NAME_NP) && >> HAVE_PTHREAD_NP_H >> +#elif ((defined(HAVE_PTHREAD_SETNAME_NP) && HAVE_PTHREAD_SETNAME_NP) \ >> +|| (defined(HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_SET_NAME_NP)) \ >> +&& HAVE_PTHREAD_NP_H >> #include >> #endif >> >> @@ -219,7 +221,7 @@ static inline int ff_thread_setname(const char *name) >> >> #if HAVE_PRCTL >> ret = AVERROR(prctl(PR_SET_NAME, name)); >> -#elif HAVE_PTHREAD_SETNAME_NP >> +#elif defined(HAVE_PTHREAD_SETNAME_NP) && HAVE_PTHREAD_SETNAME_NP >> #if defined(__APPLE__) >> ret = AVERROR(pthread_setname_np(name)); >> #elif defined(__NetBSD__) >> @@ -227,7 +229,7 @@ static inline int ff_thread_setname(const char *name) >> #else >> ret = AVERROR(pthread_setname_np(pthread_self(), name)); >> #endif >> -#elif HAVE_PTHREAD_SET_NAME_NP >> +#elif defined(HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_SET_NAME_NP >> pthread_set_name_np(pthread_self(), name); >> #else >> ret = AVERROR(ENOSYS); > > You need to rerun configure. Since > fd16d8c68cd7b820eda76c407b0645b7cf470efd running configure will add > HAVE_PTHREAD_SET_NAME_NP and HAVE_PTHREAD_SETNAME_NP to your config.h file. Ah, I see thanks. Sorry for the noise! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavu/thread: Check HAVE_PTHREAD_SET_?NAME_NP is defined
p...@frankplowman.com: > From: Frank Plowman > > Check HAVE_PTHREAD_SETNAME_NP and HAVE_PTHREAD_SET_NAME_NP are defined > before using them in macro conditions. Gets rid of lots of -Wundef > warnings present when building on MacOS since > fd16d8c68cd7b820eda76c407b0645b7cf470efd. > > Signed-off-by: Frank Plowman > --- > libavutil/thread.h | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/libavutil/thread.h b/libavutil/thread.h > index 2c00c7cc35..0200b7b511 100644 > --- a/libavutil/thread.h > +++ b/libavutil/thread.h > @@ -26,7 +26,9 @@ > > #if HAVE_PRCTL > #include > -#elif (HAVE_PTHREAD_SETNAME_NP || HAVE_PTHREAD_SET_NAME_NP) && > HAVE_PTHREAD_NP_H > +#elif ((defined(HAVE_PTHREAD_SETNAME_NP) && HAVE_PTHREAD_SETNAME_NP) \ > +|| (defined(HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_SET_NAME_NP)) \ > +&& HAVE_PTHREAD_NP_H > #include > #endif > > @@ -219,7 +221,7 @@ static inline int ff_thread_setname(const char *name) > > #if HAVE_PRCTL > ret = AVERROR(prctl(PR_SET_NAME, name)); > -#elif HAVE_PTHREAD_SETNAME_NP > +#elif defined(HAVE_PTHREAD_SETNAME_NP) && HAVE_PTHREAD_SETNAME_NP > #if defined(__APPLE__) > ret = AVERROR(pthread_setname_np(name)); > #elif defined(__NetBSD__) > @@ -227,7 +229,7 @@ static inline int ff_thread_setname(const char *name) > #else > ret = AVERROR(pthread_setname_np(pthread_self(), name)); > #endif > -#elif HAVE_PTHREAD_SET_NAME_NP > +#elif defined(HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_SET_NAME_NP > pthread_set_name_np(pthread_self(), name); > #else > ret = AVERROR(ENOSYS); You need to rerun configure. Since fd16d8c68cd7b820eda76c407b0645b7cf470efd running configure will add HAVE_PTHREAD_SET_NAME_NP and HAVE_PTHREAD_SETNAME_NP to your config.h file. - Andreas PS: There is actually a different problem with this: In file included from ./libavutil/common.h:88, from ./libavutil/avutil.h:301, from ./libavutil/opt.h:31, from libavdevice/sdl2.c:31: ./config.h:340: warning: "HAVE_PTHREAD_SETNAME_NP" redefined 340 | #define HAVE_PTHREAD_SETNAME_NP 0 | In file included from /usr/include/SDL2/SDL_config.h:4, from /usr/include/SDL2/SDL_stdinc.h:31, from /usr/include/SDL2/SDL_main.h:25, from /usr/include/SDL2/SDL.h:32, from libavdevice/sdl2.c:26: /usr/include/x86_64-linux-gnu/SDL2/_real_SDL_config.h:205: note: this is the location of the previous definition 205 | #define HAVE_PTHREAD_SETNAME_NP 1 | ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavu/thread: Check HAVE_PTHREAD_SET_?NAME_NP is defined
From: Frank Plowman Check HAVE_PTHREAD_SETNAME_NP and HAVE_PTHREAD_SET_NAME_NP are defined before using them in macro conditions. Gets rid of lots of -Wundef warnings present when building on MacOS since fd16d8c68cd7b820eda76c407b0645b7cf470efd. Signed-off-by: Frank Plowman --- libavutil/thread.h | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/libavutil/thread.h b/libavutil/thread.h index 2c00c7cc35..0200b7b511 100644 --- a/libavutil/thread.h +++ b/libavutil/thread.h @@ -26,7 +26,9 @@ #if HAVE_PRCTL #include -#elif (HAVE_PTHREAD_SETNAME_NP || HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_NP_H +#elif ((defined(HAVE_PTHREAD_SETNAME_NP) && HAVE_PTHREAD_SETNAME_NP) \ +|| (defined(HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_SET_NAME_NP)) \ +&& HAVE_PTHREAD_NP_H #include #endif @@ -219,7 +221,7 @@ static inline int ff_thread_setname(const char *name) #if HAVE_PRCTL ret = AVERROR(prctl(PR_SET_NAME, name)); -#elif HAVE_PTHREAD_SETNAME_NP +#elif defined(HAVE_PTHREAD_SETNAME_NP) && HAVE_PTHREAD_SETNAME_NP #if defined(__APPLE__) ret = AVERROR(pthread_setname_np(name)); #elif defined(__NetBSD__) @@ -227,7 +229,7 @@ static inline int ff_thread_setname(const char *name) #else ret = AVERROR(pthread_setname_np(pthread_self(), name)); #endif -#elif HAVE_PTHREAD_SET_NAME_NP +#elif defined(HAVE_PTHREAD_SET_NAME_NP) && HAVE_PTHREAD_SET_NAME_NP pthread_set_name_np(pthread_self(), name); #else ret = AVERROR(ENOSYS); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavu/hashtable: create generic robin hood hash table
NVM, I see what you mean by pointerswaps. On Mon, Feb 5, 2024 at 9:00 PM Connor Worley wrote: > On Mon, Feb 5, 2024 at 3:58 AM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Connor Worley: >> > +memcpy(ctx->tmp_key, ctx->set_key, ctx->key_size); >> > +memcpy(ctx->tmp_val, ctx->set_val, ctx->val_size); >> >> Given that set_key/val are overwritten below, these two can be done via >> pointerswaps. > > > I don't quite follow, can you elaborate on this part? > -- > Connor Worley > -- Connor Worley ___ ffmpeg-devel mailing list ffmpeg-devel@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] .mailmap: update my mailmap entry
Am 05.02.24 um 21:02 schrieb Cosmin Stejerean via ffmpeg-devel: From: Cosmin Stejerean --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 7546cf0caf..cbe6b3ff99 100644 --- a/.mailmap +++ b/.mailmap @@ -22,3 +22,4 @@ rcombs +Cosmin Stejerean Cosmin Stejerean via ffmpeg-devel Tested & pushed. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Fix AV_OPT_TYPE_CONST default value
Andreas Rheinhardt:
> It uses the int64_t instead of the double member.
>
> (This code can currently not be reached: av_opt_get() calls
> av_opt_find2() with NULL as unit in which case AV_OPT_TYPE_CONST
> options are never returned, leading av_opt_get() to always
> return AVERROR_OPTION_NOT_FOUND when searching for AV_OPT_TYPE_CONST*.
> For the same reason the code read_number() will never be called
> from get_number() when searching for an option of type
> AV_OPT_TYPE_CONST. The other callers of read_number() also only
> call it with types other than AV_OPT_TYPE_CONST.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/opt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index 0908751752..d13b1ab504 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -93,7 +93,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> *den= ((AVRational *)dst)->den;
> return 0;
> case AV_OPT_TYPE_CONST:
> -*num = o->default_val.dbl;
> +*intnum = o->default_val.i64;
> return 0;
> }
> return AVERROR(EINVAL);
> @@ -878,7 +878,7 @@ int av_opt_get(void *obj, const char *name, int
> search_flags, uint8_t **out_val)
> ret = snprintf(buf, sizeof(buf), "%d/%d", ((AVRational *)dst)->num,
> ((AVRational *)dst)->den);
> break;
> case AV_OPT_TYPE_CONST:
> -ret = snprintf(buf, sizeof(buf), "%f", o->default_val.dbl);
> +ret = snprintf(buf, sizeof(buf), "%"PRId64, o->default_val.i64);
> break;
> case AV_OPT_TYPE_STRING:
> if (*(uint8_t **)dst) {
Will apply 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] avformat/nutenc: Fix indentation
Andreas Rheinhardt:
> Forgotten after 82beb46e65e5f820b187355bf757725c22a59c45.
> Also use loop-scope for iterators while at it.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/nutenc.c | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index a5198c7ca9..5e0e36babe 100644
> --- a/libavformat/nutenc.c
> +++ b/libavformat/nutenc.c
> @@ -1063,21 +1063,21 @@ static int nut_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> ffio_free_dyn_buf(_bc);
>
> if (nut->write_index) {
> -if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/,
> pkt->dts)) < 0)
> -goto fail;
> -
> -if ((1ll<<60) % nut->sp_count == 0)
> -for (i=0; inb_streams; i++) {
> -int j;
> -StreamContext *nus = >stream[i];
> -av_reallocp_array(>keyframe_pts, 2*nut->sp_count,
> sizeof(*nus->keyframe_pts));
> -if (!nus->keyframe_pts) {
> -ret = AVERROR(ENOMEM);
> -goto fail;
> -}
> -for (j=nut->sp_count == 1 ? 0 : nut->sp_count;
> j<2*nut->sp_count; j++)
> -nus->keyframe_pts[j] = AV_NOPTS_VALUE;
> -}
> +if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0
> /*unused*/, pkt->dts)) < 0)
> +goto fail;
> +
> +if ((1ll<<60) % nut->sp_count == 0)
> +for (unsigned i = 0; i < s->nb_streams; i++) {
> +StreamContext *nus = >stream[i];
> +av_reallocp_array(>keyframe_pts, 2*nut->sp_count,
> sizeof(*nus->keyframe_pts));
> +if (!nus->keyframe_pts) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +for (int j = nut->sp_count == 1 ? 0 : nut->sp_count;
> + j < 2 * nut->sp_count; j++)
> +nus->keyframe_pts[j] = AV_NOPTS_VALUE;
> +}
> }
> }
> av_assert0(nus->last_pts != AV_NOPTS_VALUE);
Will apply tonight 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] avfilter/fifo: Remove (a)fifo filters
Andreas Rheinhardt: > Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > Signed-off-by: Andreas Rheinhardt > --- > doc/filters.texi | 9 --- > libavfilter/Makefile | 1 - > libavfilter/allfilters.c | 2 - > libavfilter/fifo.c | 165 --- > 4 files changed, 177 deletions(-) > delete mode 100644 libavfilter/fifo.c > Will apply in a few days 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] avfilter/ccfifo: Inline trivial functions
Andreas Rheinhardt:
> Besides being extremly simple this also avoids including
> ff_ccfifo_ccdetected() unnecessarily (it is only used by decklink).
> This is possible because this is not avpriv, but duplicated into
> lavd if necessary.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/ccfifo.c | 11 ---
> libavfilter/ccfifo.h | 13 +++--
> 2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
> index 6ae61a4b15..29108822be 100644
> --- a/libavfilter/ccfifo.c
> +++ b/libavfilter/ccfifo.c
> @@ -24,7 +24,6 @@
> #include "ccfifo.h"
>
> #define MAX_CC_ELEMENTS 128
> -#define CC_BYTES_PER_ENTRY 3
>
> struct cc_lookup {
> int num;
> @@ -89,16 +88,6 @@ error:
> return AVERROR(ENOMEM);
> }
>
> -int ff_ccfifo_getoutputsize(const CCFifo *ccf)
> -{
> -return ccf->expected_cc_count * CC_BYTES_PER_ENTRY;
> -}
> -
> -int ff_ccfifo_ccdetected(const CCFifo *ccf)
> -{
> -return ccf->cc_detected;
> -}
> -
> int ff_ccfifo_injectbytes(CCFifo *ccf, uint8_t *cc_data, size_t len)
> {
> int cc_608_tuples = 0;
> diff --git a/libavfilter/ccfifo.h b/libavfilter/ccfifo.h
> index a3c302b6b2..565a837a00 100644
> --- a/libavfilter/ccfifo.h
> +++ b/libavfilter/ccfifo.h
> @@ -33,6 +33,8 @@
> #include "libavutil/frame.h"
> #include "libavutil/fifo.h"
>
> +#define CC_BYTES_PER_ENTRY 3
> +
> typedef struct CCFifo {
> AVFifo *cc_608_fifo;
> AVFifo *cc_708_fifo;
> @@ -88,7 +90,11 @@ int ff_ccfifo_extractbytes(CCFifo *ccf, uint8_t *data,
> size_t len);
> * an appropriately sized buffer and pass it to ff_ccfifo_injectbytes()
> *
> */
> -int ff_ccfifo_getoutputsize(const CCFifo *ccf);
> +static inline int ff_ccfifo_getoutputsize(const CCFifo *ccf)
> +{
> +return ccf->expected_cc_count * CC_BYTES_PER_ENTRY;
> +}
> +
>
> /**
> * Insert CC data from the FIFO into an AVFrame (as side data)
> @@ -113,6 +119,9 @@ int ff_ccfifo_injectbytes(CCFifo *ccf, uint8_t *data,
> size_t len);
> * Returns 1 if captions have been found as a prior call
> * to ff_ccfifo_extract() or ff_ccfifo_extractbytes()
> */
> -int ff_ccfifo_ccdetected(const CCFifo *ccf);
> +static inline int ff_ccfifo_ccdetected(const CCFifo *ccf)
> +{
> +return ccf->cc_detected;
> +}
>
> #endif /* AVFILTER_CCFIFO_H */
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] avformat/avformat: Remove dead check, write-only assignment
Andreas Rheinhardt:
> For muxers, the internal AVCodecContext is basically unused
> except in avformat_transfer_internal_stream_timing_info()
> (which sets time_base and ticks_per_frame) and
> av_stream_get_codec_timebase() (a getter for time_base).
> This makes ticks_per_frame write-only, so don't set it.
>
> Also remove an always-false check for the AVCodecContext's
> codec_tag.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avformat.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> index 8e8c6fbe55..1a99598d6f 100644
> --- a/libavformat/avformat.c
> +++ b/libavformat/avformat.c
> @@ -775,11 +775,6 @@ int avformat_transfer_internal_stream_timing_info(const
> AVOutputFormat *ofmt,
> || copy_tb == AVFMT_TBCF_R_FRAMERATE) {
> enc_ctx->time_base.num = ist->r_frame_rate.den;
> enc_ctx->time_base.den = 2*ist->r_frame_rate.num;
> -#if FF_API_TICKS_PER_FRAME
> -FF_DISABLE_DEPRECATION_WARNINGS
> -enc_ctx->ticks_per_frame = 2;
> -FF_ENABLE_DEPRECATION_WARNINGS
> -#endif
> } else
> #endif
> if (copy_tb == AVFMT_TBCF_AUTO && dec_ctx->framerate.num &&
> @@ -792,7 +787,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
> #if FF_API_TICKS_PER_FRAME
> FF_DISABLE_DEPRECATION_WARNINGS
> enc_ctx->time_base.num *= dec_ctx->ticks_per_frame;
> -enc_ctx->ticks_per_frame = 2;
> FF_ENABLE_DEPRECATION_WARNINGS
> #endif
> }
> @@ -812,7 +806,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> }
>
> -if ((enc_ctx->codec_tag == AV_RL32("tmcd") || ost->codecpar->codec_tag
> == AV_RL32("tmcd"))
> +if (ost->codecpar->codec_tag == AV_RL32("tmcd")
> && dec_ctx_tb.num < dec_ctx_tb.den
> && dec_ctx_tb.num > 0
> && 121LL*dec_ctx_tb.num > dec_ctx_tb.den) {
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 0/2] Remove SDL2 output devices
Removing SDL2 sounds like a very bad idea. There are many examples which are using these output devices, and all these examples would be broken. A quick search in my book http://www.astro-electronic.de/FFmpeg_Book.pdf finds about 40 occurences for "-f sdl" or "-f sdl2". Michael ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
