Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
On date Friday 2024-03-08 13:50:59 +, ffmpeg-devel Mailing List wrote:
> Thank you for your incredibly thorough and fast response. I've applied all
> the corrections you requested. Please let me know if there's anything else
> wrong with my patch, and thank you for your time.
>
> - asivery
[...]
> From d2163e7d943a5ba53148aa73a813a28d346124a4 Mon Sep 17 00:00:00 2001
> From: asivery
> Date: Fri, 8 Mar 2024 14:45:02 +0100
> Subject: [PATCH] avformat/aea: Add aea muxer
>
> Signed-off-by: asivery
> ---
> libavformat/Makefile| 3 +-
> libavformat/{aea.c => aeadec.c} | 0
> libavformat/aeaenc.c| 103
> libavformat/allformats.c| 1 +
Please add some information in doc/muxers.texi, even if just a short
notice about where this format is expected to be used or a quick
historical intro. Also you might mention that the title metadata is
used to fill the container title.
> 4 files changed, 106 insertions(+), 1 deletion(-)
> rename libavformat/{aea.c => aeadec.c} (100%)
> create mode 100644 libavformat/aeaenc.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 8811a0ffc9..70d56f391f 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -91,7 +91,8 @@ OBJS-$(CONFIG_ADTS_MUXER)+= adtsenc.o
> apetag.o img2.o \
> id3v2enc.o
> OBJS-$(CONFIG_ADX_DEMUXER) += adxdec.o
> OBJS-$(CONFIG_ADX_MUXER) += rawenc.o
> -OBJS-$(CONFIG_AEA_DEMUXER) += aea.o pcm.o
> +OBJS-$(CONFIG_AEA_DEMUXER) += aeadec.o pcm.o
> +OBJS-$(CONFIG_AEA_MUXER) += aeaenc.o rawenc.o
> OBJS-$(CONFIG_AFC_DEMUXER) += afc.o
> OBJS-$(CONFIG_AIFF_DEMUXER) += aiffdec.o aiff.o pcm.o \
> mov_chan.o replaygain.o
> diff --git a/libavformat/aea.c b/libavformat/aeadec.c
> similarity index 100%
> rename from libavformat/aea.c
> rename to libavformat/aeadec.c
> diff --git a/libavformat/aeaenc.c b/libavformat/aeaenc.c
> new file mode 100644
> index 00..e01fabcace
> --- /dev/null
> +++ b/libavformat/aeaenc.c
> @@ -0,0 +1,103 @@
> +/*
> + * MD STUDIO audio muxer
> + *
> + * Copyright (c) 2024 asivery
> + *
> + * 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/channel_layout.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/avstring.h"
> +#include "avformat.h"
> +#include "avio_internal.h"
> +#include "rawenc.h"
> +#include "mux.h"
> +
> +static int aea_write_header(AVFormatContext *s)
> +{
> +const AVDictionaryEntry *title_entry;
> +int title_length = 0;
> +char* title_contents;
> +AVStream *st;
> +
> +if (s->nb_streams > 1) {
> +av_log(s, AV_LOG_WARNING, "Got more than one stream to encode. This
> is not supported.\n");
ERROR
> +return AVERROR(EINVAL);
> +}
> +
> +st = s->streams[0];
do you also need to check the stream type (probably this is handled by
the librarye already)?
> +if (st->codecpar->ch_layout.nb_channels != 1 &&
> st->codecpar->ch_layout.nb_channels != 2) {
> +av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n",
> st->codecpar->ch_layout.nb_channels);
this can be made more explicit to aid users:
Only maximum 2 channels are supported in the audio stream, %d channels were
found
> +return AVERROR(EINVAL);
> +}
> +
> +if (st->codecpar->sample_rate != 44100) {
> +av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports
> 44.1kHz.\n", st->codecpar->sample_rate);
> +return AVERROR(EINVAL);
> +}
> +
> +/* Write magic */
> +avio_wl32(s->pb, 2048);
> +
> +/* Write AEA title */
> +title_entry = av_dict_get(st->metadata, "title", NULL, 0);
> +if (title_entry) {
> +title_contents = title_entry->value;
> +title_length = strlen(title_contents);
> +title_length = FFMIN(256, title_length);
> +avio_write(s->pb, title_contents, title_length);
> +}
> +
> +ffio_fill(s->pb, 0, 256 - title_length);
> +
> +/* Write number of frames (zero at header-writing time, will se
Re: [FFmpeg-devel] [PATCH 1/2 v3] fftools/ffprobe: export Tile Grid Stream Group parameters
On date Friday 2024-03-08 17:24:47 -0300, James Almer wrote: > Signed-off-by: James Almer > --- > doc/ffprobe.xsd | 50 + > fftools/ffprobe.c | 53 --- > tests/fate/mov.mak| 6 +-- > .../ref/fate/mov-heic-demux-still-image-grid | 29 ++ > .../ref/fate/mov-heic-demux-still-image-iovl | 19 +++ > .../fate/mov-heic-demux-still-image-iovl-2| 19 +++ > 6 files changed, 165 insertions(+), 11 deletions(-) You might also want to add an entry to Changelog. > > I'll factorize the tests arguments later. > > diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd > index 5010c5a45f..bd52000725 100644 > --- a/doc/ffprobe.xsd > +++ b/doc/ffprobe.xsd > @@ -15,6 +15,7 @@ > maxOccurs="1" /> > type="ffprobe:packetsAndFramesType" minOccurs="0" maxOccurs="1" /> > maxOccurs="1" /> > + minOccurs="0" maxOccurs="1" /> > maxOccurs="1" /> > maxOccurs="1" /> > maxOccurs="1" /> > @@ -229,6 +230,12 @@ > > > > + consistency: streamGroupsType > + > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > > > > @@ -325,6 +332,49 @@ > use="required"/> > > > + > + > + type="ffprobe:streamDispositionType" minOccurs="0" maxOccurs="1"/> > + minOccurs="0" maxOccurs="1"/> > + minOccurs="0" maxOccurs="1"/> > + type="ffprobe:streamGroupComponentList" minOccurs="0" maxOccurs="1"/> > + > + > + > + > + > + > + > + > + > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + type="ffprobe:streamGroupSubComponentList" minOccurs="0" maxOccurs="1"/> nit: here and below, probaly better to use Subcomponent as this is considered a single word > + type="ffprobe:streamGroupEntryType" minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + type="ffprobe:streamGroupSubComponentType" minOccurs="0" > maxOccurs="unbounded"/> > + > + > + > + > + > + type="ffprobe:streamGroupEntryType" minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + > + > + > > > maxOccurs="1"/> [...] Looks nice to me otherwise, 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 2/2 v2] fftools/ffprobe: export IAMF Stream Group parameters
On date Friday 2024-03-08 17:24:48 -0300, James Almer wrote: > Signed-off-by: James Almer > --- > doc/ffprobe.xsd | 39 ++ > fftools/ffprobe.c | 160 +++- > tests/fate/iamf.mak | 12 +- > tests/fate/mov.mak | 8 +- > tests/ref/fate/iamf-5_1_4 | 92 ++ > tests/ref/fate/iamf-7_1_4 | 92 ++ > tests/ref/fate/iamf-ambisonic_1 | 39 ++ > tests/ref/fate/iamf-stereo | 67 ++ > tests/ref/fate/mov-mp4-iamf-5_1_4 | 92 ++ > tests/ref/fate/mov-mp4-iamf-7_1_4 | 92 ++ > tests/ref/fate/mov-mp4-iamf-ambisonic_1 | 39 ++ > tests/ref/fate/mov-mp4-iamf-stereo | 67 ++ > 12 files changed, 787 insertions(+), 12 deletions(-) You might also want to add a changelog entry. > > diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd > index bd52000725..6d5d094d97 100644 > --- a/doc/ffprobe.xsd > +++ b/doc/ffprobe.xsd > @@ -366,10 +366,49 @@ > > > > + minOccurs="0" maxOccurs="1"/> > type="ffprobe:streamGroupEntryType" minOccurs="0" maxOccurs="unbounded"/> > > > > + > + > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + minOccurs="0" maxOccurs="1"/> > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + nit: I'd use Subpiece since it's considered as a single word > + > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + minOccurs="0" maxOccurs="1"/> > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > + > + > + minOccurs="0" maxOccurs="unbounded"/> > + > + > + > > > [...] No more comments from me, looks nice otherwise, 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] avfilter/fifo: Remove (a)fifo filters
On Sat, Mar 9, 2024 at 2:09 AM Muhammad Faiz wrote: > On Fri, Mar 8, 2024 at 10:30 PM Paul B Mahol wrote: > > > On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz wrote: > > > > > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > > > andreas.rheinha...@outlook.com> wrote: > > > > > > > Muhammad Faiz: > > > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > > > > > andreas.rheinha...@outlook.com> wrote: > > > > > > > > > >> Andreas Rheinhardt: > > > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > > > >>> > > > > >>> Signed-off-by: Andreas Rheinhardt < > andreas.rheinha...@outlook.com> > > > > >>> --- > > > > >>> 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 > > > > >> > > > > >> > > > > > This breaks backward compatibility. > > > > > > > > > > Please revert. > > > > > > > > > > Thank's. > > > > > > > > What breaks that can't simply be fixed by removing the (a)fifo filter > > > > from the filterchain? > > > > > > > > - Andreas > > > > > > > > > > > I use afifo to optimize memory usage. > > > > > > > That statement sync with reality is questionable, fifo filters were > mainly > > used before .activate was added, > > for cases filters used >1 inputs. Now they should be irrelevant, unless > > there are bugs in code than this filters just hide more bugs. > > > > Yes, I've used it before .activate was added, and it worked, and still > works. > Although maybe the bugs have been fixed by .activate, what's wrong if > (a)fifo still exist? > As already wrote, lets repeat it again, hiding real bugs. Hiding is not correct word, it just adds yet another layer in filtergraph to accumulate memory/frames, with extra allocations per each frame for linking between prev and next frame. Which is pointless, as libavfilter internal code already have own queue mechanism. Check for which filters used after afifo, afifo count of queued frames reach > 1 than such filters needs fixing. Personally, my mpv visualizer modified script is not using afifo filters, and it works fine. > > Thank's > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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] libavcodec: Don't include libavcodec/x86/vvc/Makefile on any architecture
Hi Martin,
On Fri, Mar 8, 2024 at 3:38 AM Martin Storsjö wrote:
>
> This currently builds files in the libavcodec/x86/{vvc,h26x}
> subdirectories, which is somewhat unexpected when building for
> another architecture than x86.
>
> The regular arch subdirectories are handled with
>
> -include $(SRC_PATH)/$(1)/$(ARCH)/Makefile
>
> in the toplevel Makefile. Switch this to a similar optional
> inclusion, using $(ARCH).
> ---
> libavcodec/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 5d99120aa9..708434ac76 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -64,7 +64,7 @@ OBJS = ac3_parser.o
> \
>
> # subsystems
> include $(SRC_PATH)/libavcodec/vvc/Makefile
> -include $(SRC_PATH)/libavcodec/x86/vvc/Makefile
> +-include $(SRC_PATH)/libavcodec/$(ARCH)/vvc/Makefile
> OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
> OBJS-$(CONFIG_AC3DSP) += ac3dsp.o ac3.o ac3tab.o
> OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o
> mpeg4audio_sample_rates.o
> --
This patch looks good to me.
Thanks,
Sean McGovern
___
ffmpeg-devel mailing list
ffmpeg-devel@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] makefile: Clean up missed object files with "make clean"
Hi, On Fri, Mar 8, 2024 at 3:38 AM Martin Storsjö wrote: > > In some builds, the following object files could be left behind > after make clean: > > ./libavfilter/metal/utils.o > ./libavfilter/metal/vf_yadif_videotoolbox.metallib.o > ./libavcodec/x86/h26x/h2656dsp.o > ./libavcodec/neon/mpegvideo.o > ./ffbuild/bin2c_host.o > --- > ffbuild/common.mak | 2 +- > libavcodec/neon/Makefile| 3 +++ > libavcodec/x86/vvc/Makefile | 2 +- > libavfilter/Makefile| 1 + > 4 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/ffbuild/common.mak b/ffbuild/common.mak > index ac54ac0681..87a3ffd2b0 100644 > --- a/ffbuild/common.mak > +++ b/ffbuild/common.mak > @@ -140,7 +140,7 @@ else > endif > > clean:: > - $(RM) $(BIN2CEXE) > + $(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%) > > %.c %.h %.pc %.ver %.version: TAG = GEN > > diff --git a/libavcodec/neon/Makefile b/libavcodec/neon/Makefile > index 607f116a77..83c2f0051c 100644 > --- a/libavcodec/neon/Makefile > +++ b/libavcodec/neon/Makefile > @@ -1 +1,4 @@ > +clean:: > + $(RM) $(CLEANSUFFIXES:%=libavcodec/neon/%) > + > OBJS-$(CONFIG_MPEGVIDEO) += neon/mpegvideo.o > diff --git a/libavcodec/x86/vvc/Makefile b/libavcodec/x86/vvc/Makefile > index 82f281d1c7..d1623bd46a 100644 > --- a/libavcodec/x86/vvc/Makefile > +++ b/libavcodec/x86/vvc/Makefile > @@ -1,5 +1,5 @@ > clean:: > - $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%) > + $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%) > $(CLEANSUFFIXES:%=libavcodec/x86/h26x/%) > > OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvcdsp_init.o \ >x86/h26x/h2656dsp.o > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index f6c1d641d6..994d9773ba 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -666,6 +666,7 @@ TOOLS-$(CONFIG_LIBZMQ) += zmqsend > > clean:: > $(RM) $(CLEANSUFFIXES:%=libavfilter/dnn/%) > $(CLEANSUFFIXES:%=libavfilter/opencl/%) \ > + $(CLEANSUFFIXES:%=libavfilter/metal/%) \ >$(CLEANSUFFIXES:%=libavfilter/vulkan/%) > > OPENCL = $(subst $(SRC_PATH)/,,$(wildcard > $(SRC_PATH)/libavfilter/opencl/*.cl)) > -- This also looks good to me, and closes Trac #10895. Thanks, Sean McGovern ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 1/2] lavc/vvcdec: Add missed chroma sampling factor for crop offset
Thank you, Fei, Do you happen to know why the following clips are still failing? CROP_A_Panasonic_4.bit CROP_B_Panasonic_4.bit https://github.com/ffvvc/tests/tree/main/conformance/failed/v1/CROP On Fri, Mar 8, 2024 at 8:54 AM wrote: > From: Fei Wang > > Signed-off-by: Fei Wang > --- > libavcodec/vvc/vvc_refs.c | 8 > libavcodec/vvc/vvcdec.c | 4 ++-- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c > index 99f2dcf3ec..afcfc09da7 100644 > --- a/libavcodec/vvc/vvc_refs.c > +++ b/libavcodec/vvc/vvc_refs.c > @@ -185,10 +185,10 @@ int ff_vvc_set_new_ref(VVCContext *s, > VVCFrameContext *fc, AVFrame **frame) > > ref->poc = poc; > ref->sequence = s->seq_decode; > -ref->frame->crop_left = fc->ps.pps->r->pps_conf_win_left_offset; > -ref->frame->crop_right = fc->ps.pps->r->pps_conf_win_right_offset; > -ref->frame->crop_top= fc->ps.pps->r->pps_conf_win_top_offset; > -ref->frame->crop_bottom = fc->ps.pps->r->pps_conf_win_bottom_offset; > +ref->frame->crop_left = fc->ps.pps->r->pps_conf_win_left_offset << > fc->ps.sps->hshift[CHROMA]; > +ref->frame->crop_right = fc->ps.pps->r->pps_conf_win_right_offset << > fc->ps.sps->hshift[CHROMA]; > +ref->frame->crop_top= fc->ps.pps->r->pps_conf_win_top_offset << > fc->ps.sps->vshift[CHROMA]; > +ref->frame->crop_bottom = fc->ps.pps->r->pps_conf_win_bottom_offset > << fc->ps.sps->vshift[CHROMA]; > > return 0; > } > diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c > index 570e2aa513..a979ebd41c 100644 > --- a/libavcodec/vvc/vvcdec.c > +++ b/libavcodec/vvc/vvcdec.c > @@ -727,8 +727,8 @@ static void export_frame_params(VVCContext *s, const > VVCFrameContext *fc) > c->pix_fmt = sps->pix_fmt; > c->coded_width = pps->width; > c->coded_height = pps->height; > -c->width= pps->width - pps->r->pps_conf_win_left_offset - > pps->r->pps_conf_win_right_offset; > -c->height = pps->height - pps->r->pps_conf_win_top_offset - > pps->r->pps_conf_win_bottom_offset; > +c->width= pps->width - ((pps->r->pps_conf_win_left_offset + > pps->r->pps_conf_win_right_offset) << sps->hshift[CHROMA]); > +c->height = pps->height - ((pps->r->pps_conf_win_top_offset + > pps->r->pps_conf_win_bottom_offset) << sps->vshift[CHROMA]); > } > > static int frame_setup(VVCFrameContext *fc, VVCContext *s) > -- > 2.25.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
Muhammad Faiz: > On Fri, Mar 8, 2024 at 10:46 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Muhammad Faiz: >>> On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < >>> andreas.rheinha...@outlook.com> wrote: >>> Muhammad Faiz: > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> 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 >> >> > This breaks backward compatibility. > > Please revert. > > Thank's. What breaks that can't simply be fixed by removing the (a)fifo filter from the filterchain? - Andreas >>> I use afifo to optimize memory usage. >>> And backward incompatible change should only be allowed with deprecation >>> periods and major version bump. >>> >> >> Deprecation periods etc. are only common for API breaks; we do not >> guarantee that any particular filter etc. stays available and therefore >> occasionally remove them without deprecation. Examples of this are the >> removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in >> 45070eec4c or the removal of the XvMC hardware acceleration in >> be95df12bb06 (the last commit was accompanied by cefa595361db9 and >> b648ece34b6f which deprecated the parts of XvMC that were part of the >> public API and therefore subject to the API stability contract). >> >> - Andreas >> >> > It seems that all of them are external dependent components. So, I think > that non external dependent components should be treated differently. > Also, what is the urgency of (a)fifo removal? > The reason for removing these features is that they have outlived their usefulness; so have the (a)fifo filters. - 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 v1 2/2] lavc/vvc_ps: Correct NoOutputBeforeRecoveryFlag of IDR
Hi Fei,
Thank you fei,
Better provide more comments
Is there any clip fail for this?
On Fri, Mar 8, 2024 at 8:55 AM wrote:
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vvc/vvc_ps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
> index e6e46d2039..7972803da6 100644
> --- a/libavcodec/vvc/vvc_ps.c
> +++ b/libavcodec/vvc/vvc_ps.c
> @@ -742,7 +742,7 @@ static int decode_frame_ps(VVCFrameParamSets *fps,
> const VVCParamSets *ps,
> static void decode_recovery_flag(VVCContext *s)
> {
> if (IS_IDR(s))
> -s->no_output_before_recovery_flag = 0;
> +s->no_output_before_recovery_flag = 1;
> else if (IS_CRA(s) || IS_GDR(s))
> s->no_output_before_recovery_flag = s->last_eos;
> }
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
asivery via ffmpeg-devel:
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/avstring.h"
These two headers seem unused.
> +#include "avformat.h"
> +#include "avio_internal.h"
> +#include "rawenc.h"
> +#include "mux.h"
> +
> +static int aea_write_header(AVFormatContext *s)
> +{
> +const AVDictionaryEntry *title_entry;
> +int title_length = 0;
> +char* title_contents;
const please. Also we put the * to the variable (because "char* foo,
bar" still only declares one pointer to char). Furthermore, the scope
for this should be the block below.
> +AVStream *st;
> +
> +if (s->nb_streams > 1) {
> +av_log(s, AV_LOG_WARNING, "Got more than one stream to encode. This
> is not supported.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +st = s->streams[0];
> +if (st->codecpar->ch_layout.nb_channels != 1 &&
> st->codecpar->ch_layout.nb_channels != 2) {
> +av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n",
> st->codecpar->ch_layout.nb_channels);
> +return AVERROR(EINVAL);
> +}
> +
> +if (st->codecpar->sample_rate != 44100) {
> +av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports
> 44.1kHz.\n", st->codecpar->sample_rate);
> +return AVERROR(EINVAL);
> +}
> +
> +/* Write magic */
> +avio_wl32(s->pb, 2048);
> +
> +/* Write AEA title */
> +title_entry = av_dict_get(st->metadata, "title", NULL, 0);
> +if (title_entry) {
> +title_contents = title_entry->value;
> +title_length = strlen(title_contents);
Possible truncation here.
> +title_length = FFMIN(256, title_length);
> +avio_write(s->pb, title_contents, title_length);
> +}
> +
> +ffio_fill(s->pb, 0, 256 - title_length);
> +
> +/* Write number of frames (zero at header-writing time, will seek
> later), number of channels */
> +avio_wl32(s->pb, 0);
> +avio_w8(s->pb, st->codecpar->ch_layout.nb_channels);
> +avio_w8(s->pb, 0);
> +
> +/* Pad the header to 2048 bytes */
> +ffio_fill(s->pb, 0, 1782);
> +
> +return 0;
> +}
> +
> +static int aea_write_trailer(struct AVFormatContext *s)
> +{
> +AVIOContext *pb = s->pb;
> +AVStream *st = s->streams[0];
> +if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> +/* Seek to rewrite the block count. */
> +avio_seek(pb, 260, SEEK_SET);
> +avio_wl32(pb, st->nb_frames * st->codecpar->ch_layout.nb_channels);
I don't see anything guaranteeing that the result fits into 32 bits.
> +} else {
> +av_log(s, AV_LOG_WARNING, "unable to rewrite AEA header.\n");
> +}
> +
> +return 0;
> +}
> +
> +const FFOutputFormat ff_aea_muxer = {
> +.p.name = "aea",
> +.p.long_name = NULL_IF_CONFIG_SMALL("MD STUDIO audio"),
> +.p.extensions = "aea",
> +.p.audio_codec= AV_CODEC_ID_ATRAC1,
> +
> +.write_header = aea_write_header,
> +.write_packet = ff_raw_write_packet,
> +.write_trailer= aea_write_trailer,
> +};
___
ffmpeg-devel mailing list
ffmpeg-devel@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] FFmpeg 7.0 blocking issues
On Fri, Mar 8, 2024 at 11:41 PM Kieran Kunhya wrote: > On Fri, 8 Mar 2024 at 15:04, Frank Plowman wrote: > > > On 08/03/2024 14:04, James Almer wrote: > > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote: > > >> On Fri, 8 Mar 2024 at 14:00, James Almer wrote: > > >> > > >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: > > > > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer > wrote: > > >> Hi all > > >> > > >> As it was a little difficult for me to not loose track of what is > > >> blocking a release. I suggest that for all release blocking issues > > >> open a ticket and set Blocking to 7.0 > > >> that way this: > > >> https://trac.ffmpeg.org/query?blocking=~7.0 > > >> > > >> or for the ones not closed: > > >> > > >>> > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0 > > >> > > >> will list all blocking issues > > >> > > >> Ive added one, for testing that, i intend to add more if i see > > >>> something > > >> > > >> What is blocking? (IMHO) > > >> * regressions (unless its non possible to fix before release) > > >> * crashes > > >> * security issues > > >> * data loss > > >> * privacy issues > > >> * anything the commuity agrees should be in the release > > > > > > We still have 3 blocking issues on trac > > > > > > do people want me to wait or ignore them and branch ? > > > > I think you can branch soon. > > However, those 3 bugs are quite important, tbh. > > >>> > > >>> The bump and the AVOption changes were already applied, so IMO we can > > >>> branch. > > >>> The two remaining issues should not be blocking as they can be > > >>> backported to 7.0 in a point release. > > >>> > > >> > > >> VVC experimental flag is blocking. > > >> > > >> Kieran > > > > > > Is there a patch for that? > > > > There is this: > > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html > > (missing from patchwork for some reason), but it looks like it causes > > FATE to fail as is. > > > > Yes it does not update FATE to account for experimental. > Hi Kieran, Could you help send a new patch to make the FATE pass thank you > > 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". > ___ ffmpeg-devel mailing list ffmpeg-devel@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] avformat: harmonise "- {decoding, encoding, demuxing, muxing}: " comments
Hi, sorry for the slow reply.
On date Thursday 2024-02-29 16:23:06 +, Andrew Sayers wrote:
> There seems to be a convention for documenting ownership:
I find "ownership" a bit confusing, probably it's better to talk about
context usage.
>
> /**
> * - encoding: (who sets this in encoding context)
> * - decoding: (who sets this in decoding context)
> */
> int foo;
>
> Ensure all such comments start with a "-" and use lower case,
> so doxygen formats them as a bulleted lists instead of one
> long paragraph.
>
> Signed-off-by: Andrew Sayers
> ---
> libavformat/avformat.h | 67 +-
> 1 file changed, 34 insertions(+), 33 deletions(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index f4506f4cf1..35b7f78ec7 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -849,8 +849,8 @@ typedef struct AVStream {
> int index;/**< stream index in AVFormatContext */
> /**
> * Format-specific stream ID.
> - * decoding: set by libavformat
> - * encoding: set by the user, replaced by libavformat if left unset
> + * - decoding: set by libavformat
> + * - encoding: set by the user, replaced by libavformat if left unset
> */
> int id;
>
> @@ -871,13 +871,13 @@ typedef struct AVStream {
> * This is the fundamental unit of time (in seconds) in terms
> * of which frame timestamps are represented.
> *
> - * decoding: set by libavformat
> - * encoding: May be set by the caller before avformat_write_header() to
> - * provide a hint to the muxer about the desired timebase. In
> - * avformat_write_header(), the muxer will overwrite this field
> - * with the timebase that will actually be used for the
> timestamps
> - * written into the file (which may or may not be related to
> the
> - * user-provided one, depending on the format).
> + * - decoding: set by libavformat
> + * - encoding: May be set by the caller before avformat_write_header() to
> + * provide a hint to the muxer about the desired timebase. In
> + * avformat_write_header(), the muxer will overwrite this
> field
> + * with the timebase that will actually be used for the
> timestamps
> + * written into the file (which may or may not be related to
> the
> + * user-provided one, depending on the format).
> */
> AVRational time_base;
>
> @@ -896,8 +896,9 @@ typedef struct AVStream {
> * If a source file does not specify a duration, but does specify
> * a bitrate, this value will be estimated from bitrate and file size.
> *
> - * Encoding: May be set by the caller before avformat_write_header() to
> - * provide a hint to the muxer about the estimated duration.
> + * - decoding: set by libavformat
> + * - encoding: may be set by the caller before avformat_write_header() to
> + * provide a hint to the muxer about the estimated duration.
> */
> int64_t duration;
>
> @@ -935,8 +936,8 @@ typedef struct AVStream {
> * For streams with AV_DISPOSITION_ATTACHED_PIC disposition, this packet
> * will contain the attached picture.
> *
> - * decoding: set by libavformat, must not be modified by the caller.
> - * encoding: unused
> + * - decoding: set by libavformat, must not be modified by the caller.
> + * - encoding: unused
> */
> AVPacket attached_pic;
>
> @@ -1203,16 +1204,16 @@ typedef struct AVStreamGroup {
> /**
> * Group type-specific group ID.
> *
> - * decoding: set by libavformat
> - * encoding: may set by the user
> + * - decoding: set by libavformat
> + * - encoding: may set by the user
> */
> int64_t id;
>
> /**
> * Group type
> *
> - * decoding: set by libavformat on group creation
> - * encoding: set by avformat_stream_group_create()
> + * - decoding: set by libavformat on group creation
> + * - encoding: set by avformat_stream_group_create()
> */
> enum AVStreamGroupParamsType type;
>
> @@ -1534,19 +1535,19 @@ typedef struct AVFormatContext {
>
> /**
> * Forced video codec_id.
> - * Demuxing: Set by user.
> + * - demuxing: Set by user.
while at it, probably we should use "decoding" in place of demuxing,
since in this file "decoding" is semantically equivalent and used most
prominently, same below
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@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] all: harmonise "{Decoding, Encoding, Audio, Video}:" comments
On date Thursday 2024-02-29 16:23:07 +, Andrew Sayers wrote:
> There seems to be a convention for documenting meanings:
>
> /**
> * Encoding: (meaning in encoding context)
> * Decoding: (meaning in decoding context)
> */
>
> At a glance, these are confusingly similar to ownership comments.
> They are also rendered by doxygen as long, hard-to-read paragraphs.
I still don't understand what you mean by "ownership" and "meaning"
and their difference.
To me they look like the same thing, i.e. they define the semantics
depending on the operation context (encoding/decoding). In addition to
this, there might be a difference releated to the media content. To
distinguish the two, I'd say "operational" and "media" context.
> Reformat these comments to be more visually distinct and readable.
> ---
> libavcodec/avcodec.h | 19 +--
> libavformat/avformat.h | 22 +++---
> 2 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 43859251cc..e2193f1d00 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -586,16 +586,23 @@ typedef struct AVCodecContext {
> /**
> * Codec delay.
> *
> - * Encoding: Number of frames delay there will be from the encoder input
> to
> - * the decoder output. (we assume the decoder matches the spec)
> - * Decoding: Number of frames delay in addition to what a standard
> decoder
> - * as specified in the spec would produce.
> + * *Encoding:*
> + *
> + * Number of frames delay there will be from the encoder input to
> + * the decoder output. (we assume the decoder matches the spec).
> + *
> + * *Decoding:*
> + *
> + * Number of frames delay in addition to what a standard decoder
> + * as specified in the spec would produce.
> + *
> + * *Video:*
> *
> - * Video:
> * Number of frames the decoded output will be delayed relative to the
> * encoded input.
> *
> - * Audio:
> + * *Audio:*
> + *
> * For encoding, this field is unused (see initial_padding).
> *
> * For decoding, this is the number of samples the decoder needs to
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 35b7f78ec7..be97947bd1 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -882,19 +882,27 @@ typedef struct AVStream {
> AVRational time_base;
>
> /**
> - * Decoding: pts of the first frame of the stream in presentation order,
> in stream time base.
> - * Only set this if you are absolutely 100% sure that the value you set
> - * it to really is the pts of the first frame.
> - * This may be undefined (AV_NOPTS_VALUE).
> + * *Decoding:*
> + *
> + * pts of the first frame of the stream in presentation order, in
> stream time base.
> + *
> + * Only set this if you are absolutely 100% sure that the value you set
> + * it to really is the pts of the first frame.
> + *
> + * This may be undefined (AV_NOPTS_VALUE).
> + *
This conventions seems at odd with the prevoius patch, where you was
preferring the - decoding/- encoding style.
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/9] avcodec/bsf/pcm_rechunk: reorder supported codec list
On date Friday 2024-03-08 01:53:25 +0100, Marton Balint wrote: > Use lexical order. > > Signed-off-by: Marton Balint > --- > libavcodec/bsf/pcm_rechunk.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) LGTM, 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 v2 2/9] avcodec/bsf/pcm_rechunk: add some more supported PCM formats
On date Friday 2024-03-08 01:53:26 +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavcodec/bsf/pcm_rechunk.c | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) LGTM (although I didn't check that the *LAW values for 0 match), 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 v2 3/9] avformat/daudenc: force 2000 sample packet size with a bsf
On date Friday 2024-03-08 01:53:27 +0100, Marton Balint wrote: > The samples I found all have 2000 sample packets, and by forcing the packet > size with a bsf we could automagically make muxing work for packets containing > more than 3640 samples. > > Signed-off-by: Marton Balint > --- > configure | 1 + > doc/muxers.texi | 16 +--- > libavformat/daudenc.c | 11 +-- > tests/ref/fate/dcinema-encode | 31 +++ > 4 files changed, 22 insertions(+), 37 deletions(-) LGTM, 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] avformat/aea: Add aea muxer
Thank you both for the suggestions. I've updated the code as requested, and I
apologize for the AV_LOG_WARNING instead of AV_LOG_ERROR - it was an oversight
on my part.
I have also added the stream codec check, and it did get triggered when I tried
to feed it audio that was not ATRAC1, so it seems it is required.
Regarding titles being truncated - that was my intention. However I've now
added a warning if it was going to happen.
As for the block count in the header - none of the modern software which uses
AEA reads that field, but for the older software, it will now be truncated to
UINT32_MAX if needed.
Is there anything else that needs changes?
- asivery
On Saturday, March 9th, 2024 at 1:06 PM, Andreas Rheinhardt
wrote:
> asivery via ffmpeg-devel:
>
> > +#include "libavutil/intreadwrite.h"
> > +#include "libavutil/avstring.h"
>
>
> These two headers seem unused.
>
> > +#include "avformat.h"
> > +#include "avio_internal.h"
> > +#include "rawenc.h"
> > +#include "mux.h"
> > +
> > +static int aea_write_header(AVFormatContext *s)
> > +{
> > + const AVDictionaryEntry title_entry;
> > + int title_length = 0;
> > + char title_contents;
>
>
> const please. Also we put the * to the variable (because "char* foo,
> bar" still only declares one pointer to char). Furthermore, the scope
> for this should be the block below.
>
> > + AVStream st;
> > +
> > + if (s->nb_streams > 1) {
> > + av_log(s, AV_LOG_WARNING, "Got more than one stream to encode. This is
> > not supported.\n");
> > + return AVERROR(EINVAL);
> > + }
> > +
> > + st = s->streams[0];
> > + if (st->codecpar->ch_layout.nb_channels != 1 &&
> > st->codecpar->ch_layout.nb_channels != 2) {
> > + av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n",
> > st->codecpar->ch_layout.nb_channels);
> > + return AVERROR(EINVAL);
> > + }
> > +
> > + if (st->codecpar->sample_rate != 44100) {
> > + av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports
> > 44.1kHz.\n", st->codecpar->sample_rate);
> > + return AVERROR(EINVAL);
> > + }
> > +
> > + / Write magic /
> > + avio_wl32(s->pb, 2048);
> > +
> > + / Write AEA title */
> > + title_entry = av_dict_get(st->metadata, "title", NULL, 0);
> > + if (title_entry) {
> > + title_contents = title_entry->value;
> > + title_length = strlen(title_contents);
>
>
> Possible truncation here.
>
> > + title_length = FFMIN(256, title_length);
> > + avio_write(s->pb, title_contents, title_length);
> > + }
> > +
> > + ffio_fill(s->pb, 0, 256 - title_length);
> > +
> > + /* Write number of frames (zero at header-writing time, will seek later),
> > number of channels /
> > + avio_wl32(s->pb, 0);
> > + avio_w8(s->pb, st->codecpar->ch_layout.nb_channels);
> > + avio_w8(s->pb, 0);
> > +
> > + / Pad the header to 2048 bytes */
> > + ffio_fill(s->pb, 0, 1782);
> > +
> > + return 0;
> > +}
> > +
> > +static int aea_write_trailer(struct AVFormatContext *s)
> > +{
> > + AVIOContext *pb = s->pb;
> > + AVStream st = s->streams[0];
> > + if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> > + / Seek to rewrite the block count. */
> > + avio_seek(pb, 260, SEEK_SET);
> > + avio_wl32(pb, st->nb_frames * st->codecpar->ch_layout.nb_channels);
>
>
> I don't see anything guaranteeing that the result fits into 32 bits.
>
> > + } else {
> > + av_log(s, AV_LOG_WARNING, "unable to rewrite AEA header.\n");
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +const FFOutputFormat ff_aea_muxer = {
> > + .p.name = "aea",
> > + .p.long_name = NULL_IF_CONFIG_SMALL("MD STUDIO audio"),
> > + .p.extensions = "aea",
> > + .p.audio_codec = AV_CODEC_ID_ATRAC1,
> > +
> > + .write_header = aea_write_header,
> > + .write_packet = ff_raw_write_packet,
> > + .write_trailer = aea_write_trailer,
> > +};
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 ee1d4c93c66e729d9d0456b2e8e789f3f98389e3 Mon Sep 17 00:00:00 2001
From: asivery
Date: Fri, 8 Mar 2024 14:45:02 +0100
Subject: [PATCH] avformat/aea: Add aea muxer
Signed-off-by: asivery
---
doc/muxers.texi | 10 +++
libavformat/Makefile| 3 +-
libavformat/{aea.c => aeadec.c} | 0
libavformat/aeaenc.c| 115
libavformat/allformats.c| 1 +
5 files changed, 128 insertions(+), 1 deletion(-)
rename libavformat/{aea.c => aeadec.c} (100%)
create mode 100644 libavformat/aeaenc.c
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..a4df8f736d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -663,6 +663,16 @@ when enabled, write a CRC checksum for each packet to the output,
default is @code{false}
@end table
+@anchor{aea}
+@section aea
+MD STUDIO audio muxer.
+
+This muxer accepts a single ATRAC1 audio stream with either one or two channels
+and a sample rate of 44100
Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
asivery via ffmpeg-devel:
> +const char *title_contents = title_entry->value;
> +title_length = strlen(title_contents);
> +if (title_length > 256) {
> +av_log(s, AV_LOG_WARNING, "Title too long, truncated to 256
> bytes.\n");
> +title_length = 256;
> +}
I actually meant that you should use size_t for title_length (so that
the output of strlen() is never truncated) instead of adding a warning
that will likely never be triggered in practice.
- 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/aea: Add aea muxer
I see, I've changed title_length to size_t, but left the warning as is to
inform the user in case truncation needs to take place.
On Saturday, March 9th, 2024 at 6:48 PM, Andreas Rheinhardt
wrote:
> asivery via ffmpeg-devel:
>
> > + const char *title_contents = title_entry->value;
> > + title_length = strlen(title_contents);
> > + if (title_length > 256) {
> > + av_log(s, AV_LOG_WARNING, "Title too long, truncated to 256 bytes.\n");
> > + title_length = 256;
> > + }
>
>
> I actually meant that you should use size_t for title_length (so that
> the output of strlen() is never truncated) instead of adding a warning
> that will likely never be triggered in practice.
>
> - 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".From 512e25ee49e30a0ac2d77cf865185cbfe92a850e Mon Sep 17 00:00:00 2001
From: asivery
Date: Fri, 8 Mar 2024 14:45:02 +0100
Subject: [PATCH] avformat/aea: Add aea muxer
Signed-off-by: asivery
---
doc/muxers.texi | 10 +++
libavformat/Makefile| 3 +-
libavformat/{aea.c => aeadec.c} | 0
libavformat/aeaenc.c| 115
libavformat/allformats.c| 1 +
5 files changed, 128 insertions(+), 1 deletion(-)
rename libavformat/{aea.c => aeadec.c} (100%)
create mode 100644 libavformat/aeaenc.c
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..a4df8f736d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -663,6 +663,16 @@ when enabled, write a CRC checksum for each packet to the output,
default is @code{false}
@end table
+@anchor{aea}
+@section aea
+MD STUDIO audio muxer.
+
+This muxer accepts a single ATRAC1 audio stream with either one or two channels
+and a sample rate of 44100Hz.
+
+As AEA supports storing the track title, this muxer will also write
+the title from stream's metadata to the container.
+
@anchor{adts}
@section adts
Audio Data Transport Stream muxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8811a0ffc9..70d56f391f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -91,7 +91,8 @@ OBJS-$(CONFIG_ADTS_MUXER)+= adtsenc.o apetag.o img2.o \
id3v2enc.o
OBJS-$(CONFIG_ADX_DEMUXER) += adxdec.o
OBJS-$(CONFIG_ADX_MUXER) += rawenc.o
-OBJS-$(CONFIG_AEA_DEMUXER) += aea.o pcm.o
+OBJS-$(CONFIG_AEA_DEMUXER) += aeadec.o pcm.o
+OBJS-$(CONFIG_AEA_MUXER) += aeaenc.o rawenc.o
OBJS-$(CONFIG_AFC_DEMUXER) += afc.o
OBJS-$(CONFIG_AIFF_DEMUXER) += aiffdec.o aiff.o pcm.o \
mov_chan.o replaygain.o
diff --git a/libavformat/aea.c b/libavformat/aeadec.c
similarity index 100%
rename from libavformat/aea.c
rename to libavformat/aeadec.c
diff --git a/libavformat/aeaenc.c b/libavformat/aeaenc.c
new file mode 100644
index 00..f7b945b382
--- /dev/null
+++ b/libavformat/aeaenc.c
@@ -0,0 +1,115 @@
+/*
+ * MD STUDIO audio muxer
+ *
+ * Copyright (c) 2024 asivery
+ *
+ * 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 "avformat.h"
+#include "avio_internal.h"
+#include "rawenc.h"
+#include "mux.h"
+
+static int aea_write_header(AVFormatContext *s)
+{
+const AVDictionaryEntry *title_entry;
+size_t title_length = 0;
+AVStream *st;
+
+if (s->nb_streams > 1) {
+av_log(s, AV_LOG_ERROR, "Got more than one stream to encode. This is not supported.\n");
+return AVERROR(EINVAL);
+}
+
+st = s->streams[0];
+if (st->codecpar->ch_layout.nb_channels != 1 && st->codecpar->ch_layout.nb_channels != 2) {
+av_log(s, AV_LOG_ERROR, "Only maximum 2 channels are supported in the audio"
+ " stream, %d channels were found.\n", st->codecpar->ch_layout.nb_channels);
+return AVERROR(EINVAL);
+}
+
+if (st->codecpar->codec_id != AV_CODEC_ID_ATRAC1) {
+av_log(s, AV_LOG_ERROR, "AEA can only store ATRAC1 streams, %s was found.\n", avcodec_get_name(st->codecpar->code
[FFmpeg-devel] [PATCH v2 0/3] avformat/dvdvideodec: various improvements
In this patchset, following improvements are prioritized and made. (1) explicitly set mono channel layout (reviewed) (2) add subtitle color support (reviewed; in response to feedback I have removed the YUV option) (3) menu support (reviewed; updated based on feedback) When all merged, I will follow up with a trivial patch to update log messages based on feedback from Stefano with respect to how options are mentioned. You may also tour the diffs on GitHub: https://github.com/Marth64x/FFmpeg/commits/20240309_dvdvideodec Thank you very much. Signed-off-by: Marth64 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] avformat/dvdvideodec: assign mono channel layout explicitly
Signed-off-by: Marth64 --- libavformat/dvdvideodec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c index b3cc32b864..ca85aa8d3d 100644 --- a/libavformat/dvdvideodec.c +++ b/libavformat/dvdvideodec.c @@ -932,7 +932,9 @@ static int dvdvideo_audio_stream_analyze(AVFormatContext *s, audio_attr_t audio_ return AVERROR_INVALIDDATA; } -if (nb_channels == 2) +if (nb_channels == 1) +ch_layout = (AVChannelLayout) AV_CHANNEL_LAYOUT_MONO; +else if (nb_channels == 2) ch_layout = (AVChannelLayout) AV_CHANNEL_LAYOUT_STEREO; else if (nb_channels == 6) ch_layout = (AVChannelLayout) AV_CHANNEL_LAYOUT_5POINT1; -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] avformat/dvdvideodec: add CLUT utilities and subtitle color support
Signed-off-by: Marth64
---
libavformat/Makefile | 2 +-
libavformat/dvdclut.c | 75 +++
libavformat/dvdclut.h | 37 +++
libavformat/dvdvideodec.c | 14
4 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644 libavformat/dvdclut.c
create mode 100644 libavformat/dvdclut.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8811a0ffc9..a3bfc209c3 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -194,7 +194,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
OBJS-$(CONFIG_DV_MUXER) += dvenc.o
OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
-OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o
+OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o dvdclut.o
OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o
OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o
OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
diff --git a/libavformat/dvdclut.c b/libavformat/dvdclut.c
new file mode 100644
index 00..cd4b103e4b
--- /dev/null
+++ b/libavformat/dvdclut.c
@@ -0,0 +1,75 @@
+/*
+ * DVD-Video subpicture CLUT (Color Lookup Table) utilities
+ *
+ * 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/bprint.h"
+#include "libavutil/colorspace.h"
+#include "libavutil/common.h"
+
+#include "dvdclut.h"
+#include "internal.h"
+
+int ff_dvdclut_palette_extradata_cat(const uint32_t *clut,
+ const size_t clut_size,
+ AVCodecParameters *par)
+{
+AVBPrint bp;
+
+if (clut_size != FF_DVDCLUT_CLUT_SIZE)
+return AVERROR(EINVAL);
+
+av_bprint_init(&bp, 0, FF_DVDCLUT_EXTRADATA_SIZE);
+
+av_bprintf(&bp, "palette: ");
+
+for (int i = 0; i < FF_DVDCLUT_CLUT_LEN; i++)
+av_bprintf(&bp, "%06"PRIx32"%s", clut[i],
+ i != (FF_DVDCLUT_CLUT_LEN - 1) ? ", " : "");
+
+av_bprintf(&bp, "\n");
+
+return ff_bprint_to_codecpar_extradata(par, &bp);
+}
+
+int ff_dvdclut_yuv_to_rgb(uint32_t *clut, const size_t clut_size)
+{
+int y, cb, cr;
+uint8_t r, g, b;
+int r_add, g_add, b_add;
+
+if (clut_size != FF_DVDCLUT_CLUT_SIZE)
+return AVERROR(EINVAL);
+
+for (int i = 0; i < FF_DVDCLUT_CLUT_LEN; i++) {
+y = (clut[i] >> 16) & 0xFF;
+cr = (clut[i] >> 8) & 0xFF;
+cb = clut[i] & 0xFF;
+
+YUV_TO_RGB1_CCIR(cb, cr);
+
+y = (y - 16) * FIX(255.0 / 219.0);
+r = av_clip_uint8((y + r_add - 1024) >> SCALEBITS);
+g = av_clip_uint8((y + g_add - 1024) >> SCALEBITS);
+b = av_clip_uint8((y + b_add - 1024) >> SCALEBITS);
+
+clut[i] = (r << 16) | (g << 8) | b;
+}
+
+return 0;
+}
diff --git a/libavformat/dvdclut.h b/libavformat/dvdclut.h
new file mode 100644
index 00..41cea7e2c9
--- /dev/null
+++ b/libavformat/dvdclut.h
@@ -0,0 +1,37 @@
+/*
+ * DVD-Video subpicture CLUT (Color Lookup Table) utilities
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFORMAT_DVDCLUT_H
+#define AVFORMAT_DVDCLUT_H
+
+#include "libavcodec/codec_par.h"
+
+/* ("palette: ") + ("rrggbb, "*15) + ("rrggbb") + \n + \0 */
+#define FF_DVDCLUT_EXTRADATA_SIZE(9 + (8 * 15) + 6 + 1 + 1)
+#define FF_DVDCLUT_CLUT_LEN 16
+#define FF_DVDCLUT_CLUT_SIZE FF_DVDCLUT_CLUT_LEN * sizeof(uint32_t)
+
+int ff_dvdclut_palette_extradata_cat(co
[FFmpeg-devel] [PATCH v2 3/3] avformat/dvdvideodec: add menu demuxing support
Signed-off-by: Marth64
---
doc/demuxers.texi | 43 +-
libavformat/dvdvideodec.c | 314 --
2 files changed, 339 insertions(+), 18 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index f4bac8f3b3..b70f3a38d7 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -289,8 +289,10 @@ This demuxer accepts the following option:
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.
+Can directly ingest DVD titles, specifically sequential PGCs, into
+a conversion pipeline. Menu assets, such as background video or audio,
+can also be demuxed given the menu's coordinates (at best effort).
+Seeking is 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.
@@ -347,37 +349,56 @@ This demuxer accepts the following options:
@item title @var{int}
The title number to play. Must be set if @option{pgc} and @option{pg} are not
set.
+Not applicable to menus.
Default is 0 (auto), which currently only selects the first available title
(title 1)
and notifies the user about the implications.
@item chapter_start @var{int}
-The chapter, or PTT (part-of-title), number to start at. Default is 1.
+The chapter, or PTT (part-of-title), number to start at. Not applicable to
menus.
+Default is 1.
@item chapter_end @var{int}
-The chapter, or PTT (part-of-title), number to end at. Default is 0,
-which is a special value to signal end at the last possible chapter.
+The chapter, or PTT (part-of-title), number to end at. Not applicable to menus.
+Default is 0, which is a special value to signal end at the last possible
chapter.
@item angle @var{int}
The video angle number, referring to what is essentially an additional
video stream that is composed from alternate frames interleaved in the VOBs.
+Not applicable to menus.
Default is 1.
@item region @var{int}
The region code to use for playback. Some discs may use this to default
playback
at a particular angle in different regions. This option will not affect the
region code
-of a real DVD drive, if used as an input. Default is 0, "world".
+of a real DVD drive, if used as an input. Not applicable to menus.
+Default is 0, "world".
+
+@item menu @var{bool}
+Demux menu assets instead of navigating a title. Requires exact coordinates
+of the menu (@option{menu_lu}, @option{menu_vts}, @option{pgc}, @option{pg}).
+Default is false.
+
+@item menu_lu @var{int}
+The menu language to demux. In DVD, menus are grouped by language.
+Default is 0, the first language unit.
+
+@item menu_vts @var{int}
+The VTS where the menu lives, or 0 if it is a VMG menu (root-level).
+Default is 0, VMG menu.
@item pgc @var{int}
The entry PGC to start playback, in conjunction with @option{pg}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
+Must be explicitly set for menus.
Default is 0, automatically resolve from value of @option{title}.
@item pg @var{int}
The entry PG to start playback, in conjunction with @option{pgc}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
-Default is 0, automatically resolve from value of @option{title}.
+Default is 0, automatically resolve from value of @option{title}, or
+start from the beginning (PG 1) of the menu.
@item preindex @var{bool}
Enable this to have accurate chapter (PTT) markers and duration measurement,
@@ -385,6 +406,7 @@ which requires a slow second pass read in order to index
the chapter marker
timestamps from NAV packets. This is non-ideal extra work for real optical
drives.
It is recommended and faster to use this option with a backup of the DVD
structure
stored on a hard drive. Not compatible with @option{pgc} and @option{pg}.
+Not applicable to menus.
Default is 0, false.
@item trim @var{bool}
@@ -392,6 +414,7 @@ Skip padding cells (i.e. cells shorter than 1 second) from
the beginning.
There exist many discs with filler segments at the beginning of the PGC,
often with junk data intended for controlling a real DVD player's
buffering speed and with no other material data value.
+Not applicable to menus.
Default is 1, true.
@end table
@@ -416,6 +439,12 @@ Open only chapter 5 from title 1 from a given DVD
structure:
@example
ffmpeg -f dvdvideo -chapter_start 5 -chapter_end 5 -title 1 -i
...
@end example
+
+@item
+Demux menu with language 1 from VTS 1, PGC 1, starting at PG 1:
+@example
+ffmpeg -f dvdvideo -menu 1 -menu_lu 1 -menu_vts 1 -pgc 1 -pg 1 -i ...
+@end example
@end itemize
@section ea
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index 6f626ce9a0..a182f95097 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -57,9 +57,11 @@
#define DVDVIDEO_B
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
It is by no means a blocker but I think it would be nice for users to be able view subtitle colors with the dvdvideo demuxer, after all it is part of the presentation. There is a patch for this that has gone through several reviews. I have (hopefully) addressed the last round of feedback, but I will stay alert and ready to address anything else that comes up. Thank you. On Sat, Mar 9, 2024 at 6:33 AM Nuo Mi wrote: > On Fri, Mar 8, 2024 at 11:41 PM Kieran Kunhya wrote: > > > On Fri, 8 Mar 2024 at 15:04, Frank Plowman > wrote: > > > > > On 08/03/2024 14:04, James Almer wrote: > > > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote: > > > >> On Fri, 8 Mar 2024 at 14:00, James Almer wrote: > > > >> > > > >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: > > > > > > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer > > wrote: > > > >> Hi all > > > >> > > > >> As it was a little difficult for me to not loose track of what > is > > > >> blocking a release. I suggest that for all release blocking > issues > > > >> open a ticket and set Blocking to 7.0 > > > >> that way this: > > > >> https://trac.ffmpeg.org/query?blocking=~7.0 > > > >> > > > >> or for the ones not closed: > > > >> > > > >>> > > > > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0 > > > >> > > > >> will list all blocking issues > > > >> > > > >> Ive added one, for testing that, i intend to add more if i see > > > >>> something > > > >> > > > >> What is blocking? (IMHO) > > > >> * regressions (unless its non possible to fix before release) > > > >> * crashes > > > >> * security issues > > > >> * data loss > > > >> * privacy issues > > > >> * anything the commuity agrees should be in the release > > > > > > > > We still have 3 blocking issues on trac > > > > > > > > do people want me to wait or ignore them and branch ? > > > > > > I think you can branch soon. > > > However, those 3 bugs are quite important, tbh. > > > >>> > > > >>> The bump and the AVOption changes were already applied, so IMO we > can > > > >>> branch. > > > >>> The two remaining issues should not be blocking as they can be > > > >>> backported to 7.0 in a point release. > > > >>> > > > >> > > > >> VVC experimental flag is blocking. > > > >> > > > >> Kieran > > > > > > > > Is there a patch for that? > > > > > > There is this: > > > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html > > > (missing from patchwork for some reason), but it looks like it causes > > > FATE to fail as is. > > > > > > > Yes it does not update FATE to account for experimental. > > > Hi Kieran, > Could you help send a new patch to make the FATE pass > thank you > > > > > > 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". > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/ccaption_dec: clarify log message when out-of-display columns are ignored
Signed-off-by: Marth64
---
libavcodec/ccaption_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 1550e4b253..d03413265a 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -358,7 +358,7 @@ static void write_char(CCaptionSubContext *ctx, struct
Screen *screen, char ch)
return;
}
else {
-av_log(ctx, AV_LOG_WARNING, "Data Ignored since exceeding screen
width\n");
+av_log(ctx, AV_LOG_WARNING, "Data ignored due to columns exceeding
screen width\n");
return;
}
}
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/ccaption_dec: use consistent naming convention of Closed Captions
Signed-off-by: Marth64
---
libavcodec/ccaption_dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index d03413265a..faf058ce97 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -948,7 +948,7 @@ static const AVOption options[] = {
};
static const AVClass ccaption_dec_class = {
-.class_name = "Closed caption Decoder",
+.class_name = "Closed Captions Decoder",
.item_name = av_default_item_name,
.option = options,
.version= LIBAVUTIL_VERSION_INT,
@@ -956,7 +956,7 @@ static const AVClass ccaption_dec_class = {
const FFCodec ff_ccaption_decoder = {
.p.name = "cc_dec",
-CODEC_LONG_NAME("Closed Caption (EIA-608 / CEA-708)"),
+CODEC_LONG_NAME("Closed Captions (EIA-608 / CEA-708)"),
.p.type = AVMEDIA_TYPE_SUBTITLE,
.p.id = AV_CODEC_ID_EIA_608,
.p.priv_class = &ccaption_dec_class,
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself as dvdvideo demuxer, rcwt muxer maintainer
I am willing to maintain these into the future as needed. Thank you. Signed-off-by: Marth64 --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cc7f564f48..dd633f37e8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -373,6 +373,7 @@ Muxers/Demuxers: dss.c Oleksij Rempel dtsdec.c foo86 dv.c Roman Shaposhnik + dvdvideodec.c Marth64 electronicarts.c Peter Ross evc* Samsung (Dawid Kozinski) ffm* Baptiste Coudurier @@ -425,6 +426,7 @@ Muxers/Demuxers: pva.c Ivo van Poorten r3d.c Baptiste Coudurier raw.c Michael Niedermayer + rcwtenc.c Marth64 rdt.c Ronald S. Bultje rl2.c Sascha Sommer rmdec.c, rmenc.c Ronald S. Bultje -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_filter: don't forward EOF in close_output()
The caller does not need or expect it, and it can lead to terminating filtering prematurely in case there is more than one output. --- fftools/ffmpeg_filter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c index 960393b943..7cd5415341 100644 --- a/fftools/ffmpeg_filter.c +++ b/fftools/ffmpeg_filter.c @@ -2199,7 +2199,8 @@ static int close_output(OutputFilterPriv *ofp, FilterGraphThread *fgt) fgt->eof_out[ofp->index] = 1; -return sch_filter_send(fgp->sch, fgp->sch_idx, ofp->index, NULL); +ret = sch_filter_send(fgp->sch, fgp->sch_idx, ofp->index, NULL); +return (ret == AVERROR_EOF) ? 0 : ret; } static int fg_output_frame(OutputFilterPriv *ofp, FilterGraphThread *fgt, -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] fftools/ffmpeg_filter: merge block with the enclosing one
It has no reason to exist.
---
fftools/ffmpeg_filter.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 7cd5415341..a87bed6ec7 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2251,19 +2251,17 @@ static int fg_output_frame(OutputFilterPriv *ofp,
FilterGraphThread *fgt,
frame_out = frame;
}
-{
-// send the frame to consumers
-ret = sch_filter_send(fgp->sch, fgp->sch_idx, ofp->index,
frame_out);
-if (ret < 0) {
-av_frame_unref(frame_out);
+// send the frame to consumers
+ret = sch_filter_send(fgp->sch, fgp->sch_idx, ofp->index, frame_out);
+if (ret < 0) {
+av_frame_unref(frame_out);
-if (!fgt->eof_out[ofp->index]) {
-fgt->eof_out[ofp->index] = 1;
-fgp->nb_outputs_done++;
-}
-
-return ret == AVERROR_EOF ? 0 : ret;
+if (!fgt->eof_out[ofp->index]) {
+fgt->eof_out[ofp->index] = 1;
+fgp->nb_outputs_done++;
}
+
+return ret == AVERROR_EOF ? 0 : ret;
}
if (type == AVMEDIA_TYPE_VIDEO) {
--
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 01/18] fftools/cmdutils: fix printing group name in split_commandline()
Will push tomorrow if nobody has further comments. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avformat/dvdvideodec: add menu demuxing support
Fixes compiler warning introduced in v2 due to incorrect printf format for
ssize_t.
Apologies for the inconvenience.
Signed-off-by: Marth64
---
doc/demuxers.texi | 43 +-
libavformat/dvdvideodec.c | 314 --
2 files changed, 339 insertions(+), 18 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index f4bac8f3b3..b70f3a38d7 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -289,8 +289,10 @@ This demuxer accepts the following option:
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.
+Can directly ingest DVD titles, specifically sequential PGCs, into
+a conversion pipeline. Menu assets, such as background video or audio,
+can also be demuxed given the menu's coordinates (at best effort).
+Seeking is 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.
@@ -347,37 +349,56 @@ This demuxer accepts the following options:
@item title @var{int}
The title number to play. Must be set if @option{pgc} and @option{pg} are not
set.
+Not applicable to menus.
Default is 0 (auto), which currently only selects the first available title
(title 1)
and notifies the user about the implications.
@item chapter_start @var{int}
-The chapter, or PTT (part-of-title), number to start at. Default is 1.
+The chapter, or PTT (part-of-title), number to start at. Not applicable to
menus.
+Default is 1.
@item chapter_end @var{int}
-The chapter, or PTT (part-of-title), number to end at. Default is 0,
-which is a special value to signal end at the last possible chapter.
+The chapter, or PTT (part-of-title), number to end at. Not applicable to menus.
+Default is 0, which is a special value to signal end at the last possible
chapter.
@item angle @var{int}
The video angle number, referring to what is essentially an additional
video stream that is composed from alternate frames interleaved in the VOBs.
+Not applicable to menus.
Default is 1.
@item region @var{int}
The region code to use for playback. Some discs may use this to default
playback
at a particular angle in different regions. This option will not affect the
region code
-of a real DVD drive, if used as an input. Default is 0, "world".
+of a real DVD drive, if used as an input. Not applicable to menus.
+Default is 0, "world".
+
+@item menu @var{bool}
+Demux menu assets instead of navigating a title. Requires exact coordinates
+of the menu (@option{menu_lu}, @option{menu_vts}, @option{pgc}, @option{pg}).
+Default is false.
+
+@item menu_lu @var{int}
+The menu language to demux. In DVD, menus are grouped by language.
+Default is 0, the first language unit.
+
+@item menu_vts @var{int}
+The VTS where the menu lives, or 0 if it is a VMG menu (root-level).
+Default is 0, VMG menu.
@item pgc @var{int}
The entry PGC to start playback, in conjunction with @option{pg}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
+Must be explicitly set for menus.
Default is 0, automatically resolve from value of @option{title}.
@item pg @var{int}
The entry PG to start playback, in conjunction with @option{pgc}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
-Default is 0, automatically resolve from value of @option{title}.
+Default is 0, automatically resolve from value of @option{title}, or
+start from the beginning (PG 1) of the menu.
@item preindex @var{bool}
Enable this to have accurate chapter (PTT) markers and duration measurement,
@@ -385,6 +406,7 @@ which requires a slow second pass read in order to index
the chapter marker
timestamps from NAV packets. This is non-ideal extra work for real optical
drives.
It is recommended and faster to use this option with a backup of the DVD
structure
stored on a hard drive. Not compatible with @option{pgc} and @option{pg}.
+Not applicable to menus.
Default is 0, false.
@item trim @var{bool}
@@ -392,6 +414,7 @@ Skip padding cells (i.e. cells shorter than 1 second) from
the beginning.
There exist many discs with filler segments at the beginning of the PGC,
often with junk data intended for controlling a real DVD player's
buffering speed and with no other material data value.
+Not applicable to menus.
Default is 1, true.
@end table
@@ -416,6 +439,12 @@ Open only chapter 5 from title 1 from a given DVD
structure:
@example
ffmpeg -f dvdvideo -chapter_start 5 -chapter_end 5 -title 1 -i
...
@end example
+
+@item
+Demux menu with language 1 from VTS 1, PGC 1, starting at PG 1:
+@example
+ffmpeg -f dvdvideo -menu 1 -menu_lu 1 -menu_vts 1 -pgc 1 -pg 1 -i ...
+@end example
@end itemize
@section ea
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index 6f626ce9a0..
Re: [FFmpeg-devel] [PATCH] avcodec/libdav1d: Stop mangling AVPacket.opaque
Andreas Rheinhardt:
> Unnecessary since 67e7f0b0537eee1357769038270fda08fe32
> as there are no longer two opaque fields.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libdav1d.c | 27 ---
> 1 file changed, 27 deletions(-)
>
> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> index 79478ae893..08fe7a841d 100644
> --- a/libavcodec/libdav1d.c
> +++ b/libavcodec/libdav1d.c
> @@ -296,10 +296,6 @@ static void libdav1d_flush(AVCodecContext *c)
> dav1d_flush(dav1d->c);
> }
>
> -typedef struct OpaqueData {
> -void*pkt_orig_opaque;
> -} OpaqueData;
> -
> static void libdav1d_data_free(const uint8_t *data, void *opaque) {
> AVBufferRef *buf = opaque;
>
> @@ -309,7 +305,6 @@ static void libdav1d_data_free(const uint8_t *data, void
> *opaque) {
> static void libdav1d_user_data_free(const uint8_t *data, void *opaque) {
> AVPacket *pkt = opaque;
> av_assert0(data == opaque);
> -av_free(pkt->opaque);
> av_packet_free(&pkt);
> }
>
> @@ -332,8 +327,6 @@ static int libdav1d_receive_frame_internal(AVCodecContext
> *c, Dav1dPicture *p)
> }
>
> if (pkt->size) {
> -OpaqueData *od = NULL;
> -
> res = dav1d_data_wrap(data, pkt->data, pkt->size,
>libdav1d_data_free, pkt->buf);
> if (res < 0) {
> @@ -343,21 +336,9 @@ static int
> libdav1d_receive_frame_internal(AVCodecContext *c, Dav1dPicture *p)
>
> pkt->buf = NULL;
>
> -if (pkt->opaque && (c->flags & AV_CODEC_FLAG_COPY_OPAQUE)) {
> -od = av_mallocz(sizeof(*od));
> -if (!od) {
> -av_packet_free(&pkt);
> -dav1d_data_unref(data);
> -return AVERROR(ENOMEM);
> -}
> -od->pkt_orig_opaque = pkt->opaque;
> -}
> -pkt->opaque = od;
> -
> res = dav1d_data_wrap_user_data(data, (const uint8_t *)pkt,
> libdav1d_user_data_free, pkt);
> if (res < 0) {
> -av_free(pkt->opaque);
> av_packet_free(&pkt);
> dav1d_data_unref(data);
> return res;
> @@ -396,7 +377,6 @@ static int libdav1d_receive_frame(AVCodecContext *c,
> AVFrame *frame)
> Libdav1dContext *dav1d = c->priv_data;
> Dav1dPicture pic = { 0 }, *p = &pic;
> AVPacket *pkt;
> -OpaqueData *od = NULL;
> #if FF_DAV1D_VERSION_AT_LEAST(5,1)
> enum Dav1dEventFlags event_flags = 0;
> #endif
> @@ -451,16 +431,9 @@ static int libdav1d_receive_frame(AVCodecContext *c,
> AVFrame *frame)
> ff_set_sar(c, frame->sample_aspect_ratio);
>
> pkt = (AVPacket *)p->m.user_data.data;
> -od = pkt->opaque;
> -
> -// restore the original user opaque value for
> -// ff_decode_frame_props_from_pkt()
> -pkt->opaque = od ? od->pkt_orig_opaque : NULL;
> -av_freep(&od);
>
> // match timestamps and packet size
> res = ff_decode_frame_props_from_pkt(c, frame, pkt);
> -pkt->opaque = NULL;
> if (res < 0)
> goto fail;
>
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] avcodec/librav1e: Don't unnecessarily create new references
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> Absolutely untested (not even compiled).
>
> libavcodec/librav1e.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
> index dbd728a408..2a6d8bfbed 100644
> --- a/libavcodec/librav1e.c
> +++ b/libavcodec/librav1e.c
> @@ -472,12 +472,8 @@ static int librav1e_receive_packet(AVCodecContext
> *avctx, AVPacket *pkt)
>
> if (avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
> fd->frame_opaque = frame->opaque;
> -ret = av_buffer_replace(&fd->frame_opaque_ref,
> frame->opaque_ref);
> -if (ret < 0) {
> -frame_data_free(fd);
> -av_frame_unref(frame);
> -return ret;
> -}
> +fd->frame_opaque_ref = frame->opaque_ref;
> +frame->opaque_ref= NULL;
> }
>
> rframe = rav1e_frame_new(ctx->ctx);
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] avcodec/xpmdec: Use LUT for hex char->number conversion
Andreas Rheinhardt:
> Speeds up decoding and also reduces binary size.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/xpmdec.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
> index 5bc02378c8..804cf8568d 100644
> --- a/libavcodec/xpmdec.c
> +++ b/libavcodec/xpmdec.c
> @@ -193,15 +193,22 @@ static const ColorEntry color_table[] = {
>
> static unsigned hex_char_to_number(uint8_t x)
> {
> -if (x >= 'a' && x <= 'f')
> -x -= 'a' - 10;
> -else if (x >= 'A' && x <= 'F')
> -x -= 'A' - 10;
> -else if (x >= '0' && x <= '9')
> -x -= '0';
> -else
> -x = 0;
> -return x;
> +#define TIMES256(idx) \
> +TIMES64(4 * (idx)) TIMES64(4 * (idx) + 1) TIMES64(4 * (idx) + 2) TIMES64(4 *
> (idx) + 3)
> +#define TIMES64(idx) \
> +TIMES16(4 * (idx)) TIMES16(4 * (idx) + 1) TIMES16(4 * (idx) + 2) TIMES16(4 *
> (idx) + 3)
> +#define TIMES16(idx) \
> +TIMES4(4 * (idx)) TIMES4(4 * (idx) + 1) TIMES4(4 * (idx) + 2) TIMES4(4 *
> (idx) + 3)
> +#define TIMES4(idx) \
> +ENTRY(4 * (idx)) ENTRY(4 * (idx) + 1) ENTRY(4 * (idx) + 2) ENTRY(4 * (idx) +
> 3)
> +#define ENTRY(x) [x] = ((x) >= 'a' && (x) <= 'f') ? (x) - ('a' - 10) : \
> + ((x) >= 'A' && (x) <= 'F') ? (x) - ('A' - 10) : \
> + ((x) >= '0' && (x) <= '9') ? (x) - '0' : 0,
> +
> +static const uint8_t lut[] = {
> +TIMES256(0)
> +};
> +return lut[x];
> }
>
> /*
Will apply.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/avstring: Use proper types
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/avstring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> index 8751ce5576..2071dd36a5 100644
> --- a/libavutil/avstring.c
> +++ b/libavutil/avstring.c
> @@ -345,7 +345,7 @@ int av_escape(char **dst, const char *src, const char
> *special_chars,
> int av_match_name(const char *name, const char *names)
> {
> const char *p;
> -int len, namelen;
> +size_t len, namelen;
>
> if (!name || !names)
> return 0;
Will apply.
- 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] avcodec/h264_ps: Fix shadowing
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/h264_ps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index dcc51b96db..3c8fc33c7f 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -522,7 +522,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb,
> AVCodecContext *avctx,
>
> sps->vui_parameters_present_flag = get_bits1(gb);
> if (sps->vui_parameters_present_flag) {
> -int ret = decode_vui_parameters(gb, avctx, sps);
> +ret = decode_vui_parameters(gb, avctx, sps);
> if (ret < 0)
> goto fail;
> }
Will apply.
- 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] avcodec/xbmdec: Use LUT for hex char->number conversion
Andreas Rheinhardt:
> Improves performance by about 30%.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> [1] is a patch that would also move the bitreverse into the LUT;
> it didn't make a difference in the benchmarks here, but if it is
> an improvement for someone else, it could still be applied.
> [1]:
> https://github.com/mkver/FFmpeg/commit/d4fdac5335d2ccf29f7b55fe3147edf388bb7efa
> libavcodec/xbmdec.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/xbmdec.c b/libavcodec/xbmdec.c
> index ecfc957a3f..2d84327e02 100644
> --- a/libavcodec/xbmdec.c
> +++ b/libavcodec/xbmdec.c
> @@ -28,17 +28,22 @@
>
> static int get_nibble(uint8_t x)
> {
> -int ret = 255;
> -
> -if (x <= '9') {
> -if (x >= '0')
> -ret = x - '0';
> -} else if (x >= 'a') {
> -if (x <= 'f')
> -ret = x - ('a' - 10);
> -} else if (x >= 'A' && x <= 'F')
> -ret = x - ('A' - 10);
> -return ret;
> +#define TIMES256(idx) \
> +TIMES64(4 * (idx)) TIMES64(4 * (idx) + 1) TIMES64(4 * (idx) + 2) TIMES64(4 *
> (idx) + 3)
> +#define TIMES64(idx) \
> +TIMES16(4 * (idx)) TIMES16(4 * (idx) + 1) TIMES16(4 * (idx) + 2) TIMES16(4 *
> (idx) + 3)
> +#define TIMES16(idx) \
> +TIMES4(4 * (idx)) TIMES4(4 * (idx) + 1) TIMES4(4 * (idx) + 2) TIMES4(4 *
> (idx) + 3)
> +#define TIMES4(idx) \
> +ENTRY(4 * (idx)) ENTRY(4 * (idx) + 1) ENTRY(4 * (idx) + 2) ENTRY(4 * (idx) +
> 3)
> +#define ENTRY(x) [x] = ((x) >= 'a' && (x) <= 'f') ? (x) - ('a' - 10) : \
> + ((x) >= 'A' && (x) <= 'F') ? (x) - ('A' - 10) : \
> + ((x) >= '0' && (x) <= '9') ? (x) - '0' : 255,
> +
> +static const uint8_t lut[] = {
> +TIMES256(0)
> +};
> +return lut[x];
> }
>
> static int parse_str_int(const uint8_t *p, const uint8_t *end, const uint8_t
> *key)
Will apply.
- 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] avcodec/xbmenc: Avoid snprintf() for data->hex conversion
Andreas Rheinhardt:
> Use a small LUT instead. Improves performance.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/xbmenc.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/xbmenc.c b/libavcodec/xbmenc.c
> index cd8b73afa3..5231d4691d 100644
> --- a/libavcodec/xbmenc.c
> +++ b/libavcodec/xbmenc.c
> @@ -20,11 +20,9 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> -#include "libavutil/reverse.h"
> #include "avcodec.h"
> #include "codec_internal.h"
> #include "encode.h"
> -#include "mathops.h"
>
> #define ANSI_MIN_READLINE 509
>
> @@ -57,14 +55,25 @@ static int xbm_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> buf += snprintf(buf, 39, "static unsigned char image_bits[] = {\n");
> for (i = 0, l = lineout; i < avctx->height; i++) {
> for (j = 0; j < linesize; j++) {
> -buf += snprintf(buf, 6, " 0x%02X", ff_reverse[*ptr++]);
> +// 0..15 bitreversed as chars
> +static const char lut[] = {
> +'0', '8', '4', 'C', '2', 'A', '6', 'E',
> +'1', '9', '5', 'D', '3', 'B', '7', 'F'
> +};
> +buf[0] = ' ';
> +buf[1] = '0';
> +buf[2] = 'x';
> +buf[3] = lut[*ptr & 0xF];
> +buf[4] = lut[*ptr >> 4];
> +buf += 5;
> +ptr++;
> if (--commas <= 0) {
> -buf += snprintf(buf, 2, "\n");
> +*buf++ = '\n';
> break;
> }
> -buf += snprintf(buf, 2, ",");
> +*buf++ = ',';
> if (--l <= 0) {
> -buf += snprintf(buf, 2, "\n");
> +*buf++ = '\n';
> l = lineout;
> }
> }
Will apply.
- 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] avformat: harmonise "- {decoding, encoding, demuxing, muxing}: " comments
Hey, no problem :)
On 09/03/2024 16:06, Stefano Sabatini wrote:
Hi, sorry for the slow reply.
On date Thursday 2024-02-29 16:23:06 +, Andrew Sayers wrote:
There seems to be a convention for documenting ownership:
I find "ownership" a bit confusing, probably it's better to talk about
context usage.
On reflection, it might be better to borrow some terms from function
documentation. So s/ownership/direction/ and s/meaning/description/
Here's a silly example of a well-documented function and equivalent
struct using the proposed layout:
/**
*
* @brief AI-aging magic (functional version)
*
* @param[in,out] age AI-generated age value
*
* - encoding: in
* - decoding: out
*
* *Video encoding*
*
* Run all faces through a filter that makes them look
* this many years old.
*
* Values outside of the range 1-100 will be ignored.
*
* *Audio decoding*
*
* Indicates the age of the primary speaker in years.
* May be less accurate for non-English speakers.
*
* Values <0 indicate the age could not be determined.
*/
void example_function( ExampleContext* ctx, int age );
/**
* @brief AI-aging magic (structural version)
*/
struct ExampleContext {
/**
*
* @brief AI-generated age value
*
* - encoding: set by user
* - decoding: set by libav
*
* *Video encoding*
*
* Run all faces through a filter that makes them look
* this many years old.
*
* Values outside of the range 1-100 will be ignored.
*
* *Audio decoding*
*
* Indicates the age of the primary speaker in years.
* May be less accurate for non-English speakers.
*
* Values <0 indicate the age could not be determined.
*/
int age;
};
As a reader, I want to know how I'm supposed to engage with a variable
(direction) before I can understand the deeper semantics (description).
Representing the former with a bulleted list makes it easier to glance
through the docs and find the variable I'm looking for, while
representing the latter with headings and paragraphs makes it easier to
focus on the bit I care about right now.
/**
* - encoding: (who sets this in encoding context)
* - decoding: (who sets this in decoding context)
*/
int foo;
Ensure all such comments start with a "-" and use lower case,
so doxygen formats them as a bulleted lists instead of one
long paragraph.
Signed-off-by: Andrew Sayers
---
libavformat/avformat.h | 67 +-
1 file changed, 34 insertions(+), 33 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f4506f4cf1..35b7f78ec7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -849,8 +849,8 @@ typedef struct AVStream {
int index;/**< stream index in AVFormatContext */
/**
* Format-specific stream ID.
- * decoding: set by libavformat
- * encoding: set by the user, replaced by libavformat if left unset
+ * - decoding: set by libavformat
+ * - encoding: set by the user, replaced by libavformat if left unset
*/
int id;
@@ -871,13 +871,13 @@ typedef struct AVStream {
* This is the fundamental unit of time (in seconds) in terms
* of which frame timestamps are represented.
*
- * decoding: set by libavformat
- * encoding: May be set by the caller before avformat_write_header() to
- * provide a hint to the muxer about the desired timebase. In
- * avformat_write_header(), the muxer will overwrite this field
- * with the timebase that will actually be used for the
timestamps
- * written into the file (which may or may not be related to the
- * user-provided one, depending on the format).
+ * - decoding: set by libavformat
+ * - encoding: May be set by the caller before avformat_write_header() to
+ * provide a hint to the muxer about the desired timebase. In
+ * avformat_write_header(), the muxer will overwrite this field
+ * with the timebase that will actually be used for the
timestamps
+ * written into the file (which may or may not be related to
the
+ * user-provided one, depending on the format).
*/
AVRational time_base;
@@ -896,8 +896,9 @@ typedef struct AVStream {
* If a source file does not specify a duration, but does specify
* a bitrate, this value will be estimated from bitrate and file size.
*
- * Encoding: May be set by the caller before avformat_write_header() to
- * provide a hint to the muxer about the estimated duration.
+ * - decoding: set by libavformat
+ * - encoding: may be set by the caller before avformat_write_header() to
+ * provide a hint to the muxer about the estimated duration.
*/
int64_t duration;
@@ -935,8 +936,8 @@ typedef struct AVStream
[FFmpeg-devel] Fixes #10509
I have attached the git patch containing the changes for your review. This patch is submitted as part of my qualification task for Google Summer of Code (GSoC) 0001-avfilter-f_select.c-add-support-for-iw-and-ih-consta.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@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] avutil/channel_layout: add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/channel_layout.c | 30 ++
libavutil/channel_layout.h | 7 +++
libavutil/version.h| 2 +-
4 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index cf58c8c5f0..a44c8e4f10 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-03-xx - xx - lavu 59.2.100 - channel_layout.h
+ Add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL.
+
2024-03-08 - xx - lavc 61.1.100 - avcodec.h
Add AVCodecContext.[nb_]side_data_prefer_packet.
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 8c1b3362f7..d3abb2dc42 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -553,6 +553,33 @@ static int ambisonic_order(const AVChannelLayout
*channel_layout)
return order;
}
+static enum AVChannelOrder canonical_order(AVChannelLayout *channel_layout)
+{
+int has_known_channel = 0;
+int order;
+
+if (channel_layout->order != AV_CHANNEL_ORDER_CUSTOM)
+return channel_layout->order;
+
+if (has_channel_names(channel_layout))
+return AV_CHANNEL_ORDER_CUSTOM;
+
+for (int i = 0; i < channel_layout->nb_channels && !has_known_channel; i++)
+if (channel_layout->u.map[i].id != AV_CHAN_UNKNOWN)
+has_known_channel = 1;
+if (!has_known_channel)
+return AV_CHANNEL_ORDER_UNSPEC;
+
+if (masked_description(channel_layout, 0) > 0)
+return AV_CHANNEL_ORDER_NATIVE;
+
+order = ambisonic_order(channel_layout);
+if (order >= 0 && masked_description(channel_layout, (order + 1) * (order
+ 1)) >= 0)
+return AV_CHANNEL_ORDER_AMBISONIC;
+
+return AV_CHANNEL_ORDER_CUSTOM;
+}
+
/**
* If the custom layout is n-th order standard-order ambisonic, with optional
* extra non-diegetic channels at the end, write its string description in bp.
@@ -892,6 +919,9 @@ int av_channel_layout_retype(AVChannelLayout
*channel_layout, enum AVChannelOrde
if (!av_channel_layout_check(channel_layout))
return AVERROR(EINVAL);
+if (flags & AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL)
+order = canonical_order(channel_layout);
+
if (channel_layout->order == order)
return 0;
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 10ffe74468..a1e9b08064 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -680,6 +680,13 @@ int av_channel_layout_compare(const AVChannelLayout *chl,
const AVChannelLayout
*/
#define AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS (1 << 0)
+/**
+ * The specified retype target order is ignored and the simplest possible
+ * (canonical) order is used for which the input layout can be losslessy
+ * represented.
+ */
+#define AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL (1 << 1)
+
/**
* Change the AVChannelOrder of a channel layout.
*
diff --git a/libavutil/version.h b/libavutil/version.h
index 09f8cdc292..57cad02ec0 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 59
-#define LIBAVUTIL_VERSION_MINOR 1
+#define LIBAVUTIL_VERSION_MINOR 2
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/7] avformat/mov_chan: simplify channel layout canonicalization
Signed-off-by: Marton Balint
---
libavformat/mov_chan.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index 3e186b0837..ead3a9b91b 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -543,10 +543,8 @@ int ff_mov_read_chan(AVFormatContext *s, AVIOContext *pb,
AVStream *st,
ch_layout->u.map[i].id = mov_get_channel_id(label);
}
-ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE,
AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS);
-if (ret == AVERROR(ENOSYS))
-ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_UNSPEC,
AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS);
-if (ret < 0 && ret != AVERROR(ENOSYS))
+ret = av_channel_layout_retype(ch_layout, 0,
AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL);
+if (ret < 0)
goto out;
} else {
uint64_t mask = mov_get_channel_layout(layout_tag, bitmap);
@@ -843,10 +841,8 @@ int ff_mov_read_chnl(AVFormatContext *s, AVIOContext *pb,
AVStream *st)
ch_layout->u.map[i].id = channel;
}
-ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE,
AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS);
-if (ret == AVERROR(ENOSYS))
-ret = av_channel_layout_retype(ch_layout,
AV_CHANNEL_ORDER_UNSPEC, AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS);
-if (ret < 0 && ret != AVERROR(ENOSYS))
+ret = av_channel_layout_retype(ch_layout, 0,
AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL);
+if (ret < 0)
return ret;
} else {
uint64_t omitted_channel_map = avio_rb64(pb);
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/7] avutil/tests/channel_layout: make printing results part of the tests
Deduplicates a lot of code.
Some minor differences (mostly white space and inconsistent use of quotes) are
expected in the fate tests, there was no point aiming for exactly the same
formatting.
Signed-off-by: Marton Balint
---
libavutil/tests/channel_layout.c | 283 +++
tests/ref/fate/channel_layout| 176 +--
2 files changed, 186 insertions(+), 273 deletions(-)
diff --git a/libavutil/tests/channel_layout.c b/libavutil/tests/channel_layout.c
index 23bb6009fb..d62b69a5db 100644
--- a/libavutil/tests/channel_layout.c
+++ b/libavutil/tests/channel_layout.c
@@ -162,39 +162,50 @@ static const char *channel_layout_retype(AVChannelLayout
*layout, AVBPrint *bp,
}
#define CHANNEL_NAME(x)\
-channel_name(&bp, (x));
+channel_name(&bp, (x));\
+printf("With %-32s %14s\n", AV_STRINGIFY(x)":", bp.str)
#define CHANNEL_DESCRIPTION(x) \
-channel_description(&bp, (x));
+channel_description(&bp, (x)); \
+printf("With %-23s %23s\n", AV_STRINGIFY(x)":", bp.str);
+
+#define CHANNEL_FROM_STRING(x) \
+printf("With %-38s %8d\n", AV_STRINGIFY(x)":", av_channel_from_string(x))
#define CHANNEL_LAYOUT_FROM_MASK(x)\
channel_layout_from_mask(&layout, &bp, (x));
#define CHANNEL_LAYOUT_FROM_STRING(x) \
-channel_layout_from_string(&layout, &bp, (x));
+channel_layout_from_string(&layout, &bp, (x)); \
+printf("With \"%s\":%*s %32s\n", x, strlen(x) > 32 ? 0 : 32 -
(int)strlen(x), "", bp.str);
-#define CHANNEL_LAYOUT_CHANNEL_FROM_INDEX(x) \
+#define CHANNEL_LAYOUT_CHANNEL_FROM_INDEX(l, x)\
ret = av_channel_layout_channel_from_index(&layout, x);\
if (ret < 0) \
-ret = -1
+ret = -1; \
+printf("On \"%s\" layout with %2d: %8d\n", l, x, ret)
-#define CHANNEL_LAYOUT_SUBSET(x) \
-mask = av_channel_layout_subset(&layout, x)
+#define CHANNEL_LAYOUT_SUBSET(l, xstr, x) \
+mask = av_channel_layout_subset(&layout, x); \
+printf("On \"%s\" layout with %-22s 0x%"PRIx64"\n", l, xstr, mask)
-#define CHANNEL_LAYOUT_INDEX_FROM_CHANNEL(x) \
+#define CHANNEL_LAYOUT_INDEX_FROM_CHANNEL(l, x)\
ret = av_channel_layout_index_from_channel(&layout, x);\
if (ret < 0) \
-ret = -1
+ret = -1; \
+printf("On \"%s\" layout with %-23s %3d\n", l, AV_STRINGIFY(x)":", ret)
-#define CHANNEL_LAYOUT_CHANNEL_FROM_STRING(x) \
+#define CHANNEL_LAYOUT_CHANNEL_FROM_STRING(l, x) \
ret = av_channel_layout_channel_from_string(&layout, x); \
if (ret < 0) \
-ret = -1
+ret = -1; \
+printf("On \"%s\" layout with %-21s %3d\n", bp.str, AV_STRINGIFY(x)":",
ret);
-#define CHANNEL_LAYOUT_INDEX_FROM_STRING(x)\
+#define CHANNEL_LAYOUT_INDEX_FROM_STRING(l, x) \
ret = av_channel_layout_index_from_string(&layout, x); \
if (ret < 0) \
-ret = -1
+ret = -1; \
+printf("On \"%s\" layout with %-20s %3d\n", l, AV_STRINGIFY(x)":", ret);
int main(void)
{
@@ -226,152 +237,94 @@ int main(void)
printf("\nTesting av_channel_name\n");
CHANNEL_NAME(AV_CHAN_FRONT_LEFT);
-printf("With AV_CHAN_FRONT_LEFT: %27s\n", bp.str);
CHANNEL_NAME(AV_CHAN_FRONT_RIGHT);
-printf("With AV_CHAN_FRONT_RIGHT: %26s\n", bp.str);
CHANNEL_NAME(63);
-printf("With 63: %43s\n", bp.str);
CHANNEL_NAME(AV_CHAN_AMBISONIC_BASE);
-printf("With AV_CHAN_AMBISONIC_BASE: %23s\n", bp.str);
CHANNEL_NAME(AV_CHAN_AMBISONIC_END);
-printf("With AV_CHAN_AMBISONIC_END: %24s\n", bp.str);
printf("Testing av_channel_description\n");
CHANNEL_DESCRIPTION(AV_CHAN_FRONT_LEFT);
-printf("With AV_CHAN_FRONT_LEFT: %27s\n", bp.str);
CHANNEL_DESCRIPTION(AV_CHAN_FRONT_RIGHT);
-printf("With AV_CHAN_FRONT_RIGHT: %26s\n", bp.str);
CHANNEL_DESCRIPTION(63);
-printf("With 63: %43s\n", bp.
[FFmpeg-devel] [PATCH 4/7] avutil/tests/channel_layout: add some av_channel_from_string and av_channel_layout_from_string tests
We lacked tests which supposed to fail, and there are some which should fail
but right now it does not. This will be fixed in a later commit.
Signed-off-by: Marton Balint
---
libavutil/tests/channel_layout.c | 26 ++
tests/ref/fate/channel_layout| 26 ++
2 files changed, 52 insertions(+)
diff --git a/libavutil/tests/channel_layout.c b/libavutil/tests/channel_layout.c
index d62b69a5db..14d36c71b5 100644
--- a/libavutil/tests/channel_layout.c
+++ b/libavutil/tests/channel_layout.c
@@ -255,6 +255,11 @@ int main(void)
CHANNEL_FROM_STRING("USR63");
CHANNEL_FROM_STRING("AMBI0");
CHANNEL_FROM_STRING("AMBI1023");
+CHANNEL_FROM_STRING("AMBI1024");
+CHANNEL_FROM_STRING("Dummy");
+CHANNEL_FROM_STRING("FL@Foo");
+CHANNEL_FROM_STRING("Foo@FL");
+CHANNEL_FROM_STRING("@FL");
printf("\n==Native layouts==\n");
@@ -301,6 +306,9 @@ int main(void)
CHANNEL_LAYOUT_CHANNEL_FROM_STRING(bp.str, "SL");
CHANNEL_LAYOUT_CHANNEL_FROM_STRING(bp.str, "SR");
CHANNEL_LAYOUT_CHANNEL_FROM_STRING(bp.str, "BC");
+CHANNEL_LAYOUT_CHANNEL_FROM_STRING(bp.str, "@");
+CHANNEL_LAYOUT_CHANNEL_FROM_STRING(bp.str, "@Foo");
+CHANNEL_LAYOUT_CHANNEL_FROM_STRING(bp.str, "FL@Foo");
printf("\nTesting av_channel_layout_index_from_string\n");
CHANNEL_LAYOUT_INDEX_FROM_STRING(bp.str, "FL");
@@ -321,9 +329,27 @@ int main(void)
printf("\nTesting av_channel_layout_from_string\n");
CHANNEL_LAYOUT_FROM_STRING("FL+FR+FC+BL+BR+LFE");
CHANNEL_LAYOUT_FROM_STRING("2 channels (FR+FL)");
+CHANNEL_LAYOUT_FROM_STRING("2 channels (AMBI1023+FL)");
+CHANNEL_LAYOUT_FROM_STRING("3 channels (FR+FL)");
+CHANNEL_LAYOUT_FROM_STRING("-3 channels (FR+FL)");
+CHANNEL_LAYOUT_FROM_STRING("0 channels ()");
+CHANNEL_LAYOUT_FROM_STRING("2 channels (FL+FR");
CHANNEL_LAYOUT_FROM_STRING("ambisonic 1+FR+FL");
CHANNEL_LAYOUT_FROM_STRING("ambisonic 2+FC@Foo");
CHANNEL_LAYOUT_FROM_STRING("FL@Foo+FR@Bar");
+CHANNEL_LAYOUT_FROM_STRING("FL+stereo");
+CHANNEL_LAYOUT_FROM_STRING("stereo+stereo");
+CHANNEL_LAYOUT_FROM_STRING("stereo@Boo");
+CHANNEL_LAYOUT_FROM_STRING("");
+CHANNEL_LAYOUT_FROM_STRING("@");
+CHANNEL_LAYOUT_FROM_STRING("@Dummy");
+CHANNEL_LAYOUT_FROM_STRING("@FL");
+CHANNEL_LAYOUT_FROM_STRING("Dummy");
+CHANNEL_LAYOUT_FROM_STRING("Dummy@FL");
+CHANNEL_LAYOUT_FROM_STRING("FR+Dummy");
+CHANNEL_LAYOUT_FROM_STRING("FR+Dummy@FL");
+CHANNEL_LAYOUT_FROM_STRING("FR+@FL");
+CHANNEL_LAYOUT_FROM_STRING("FL+@");
CHANNEL_LAYOUT_FROM_STRING("FR+FL@Foo+USR63@Foo");
ret = av_channel_layout_copy(&layout2, &layout);
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index b98ccdb0f0..ea7ec6fa3c 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -56,6 +56,11 @@ With "FR": 1
With "USR63": 63
With "AMBI0": 1024
With "AMBI1023":2047
+With "AMBI1024": -1
+With "Dummy": -1
+With "FL@Foo":-1
+With "Foo@FL":-1
+With "@FL": -1
==Native layouts==
@@ -101,6 +106,9 @@ On "5.1(side)" layout with "LFE": 3
On "5.1(side)" layout with "SL": 9
On "5.1(side)" layout with "SR": 10
On "5.1(side)" layout with "BC": -1
+On "5.1(side)" layout with "@": -1
+On "5.1(side)" layout with "@Foo":-1
+On "5.1(side)" layout with "FL@Foo": -1
Testing av_channel_layout_index_from_string
On "5.1(side)" layout with "FL": 0
@@ -121,9 +129,27 @@ On "5.1(side)" layout with AV_CH_LAYOUT_4POINT1: 0xf
Testing av_channel_layout_from_string
With "FL+FR+FC+BL+BR+LFE":6 channels (FL+FR+FC+BL+BR+LFE)
With "2 channels (FR+FL)": 2 channels (FR+FL)
+With "2 channels (AMBI1023+FL)": fail
+With "3 channels (FR+FL)": fail
+With "-3 channels (FR+FL)": fail
+With "0 channels ()":fail
+With "2 channels (FL+FR":fail
With "ambisonic 1+FR+FL": ambisonic 1+2 channels (FR+FL)
With "ambisonic 2+FC@Foo":ambisonic 2+1 channels (FC@Foo)
With "FL@Foo+FR@Bar": 2 channels (FL@Foo+FR@Bar)
+With "FL+stereo":fail
+With "stereo+stereo":fail
+With "stereo@Boo":
[FFmpeg-devel] [PATCH 6/7] avutil/channel_layout: fix some (un)initialization issues in av_channel_layout_from_string()
Also make initialization/uninitialization behaviour more explicit in the docs,
and make sure we do not leak a channel map on error.
Signed-off-by: Marton Balint
---
libavutil/channel_layout.c | 5 +
libavutil/channel_layout.h | 8 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 5db4cc9df0..9e8a1c12e6 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -302,6 +302,10 @@ int av_channel_layout_from_string(AVChannelLayout
*channel_layout,
}
}
+/* This function is a channel layout initializer, so we have to
+ * zero-initialize before we start setting fields individually. */
+memset(channel_layout, 0, sizeof(*channel_layout));
+
/* ambisonic */
if (!strncmp(str, "ambisonic ", 10)) {
const char *p = str + 10;
@@ -343,6 +347,7 @@ int av_channel_layout_from_string(AVChannelLayout
*channel_layout,
for (i = 0; i < extra.nb_channels; i++) {
enum AVChannel ch =
av_channel_layout_channel_from_index(&extra, i);
if (CHAN_IS_AMBI(ch)) {
+av_channel_layout_uninit(channel_layout);
av_channel_layout_uninit(&extra);
return AVERROR(EINVAL);
}
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index a1e9b08064..8a078d1601 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -512,10 +512,14 @@ int av_channel_layout_from_mask(AVChannelLayout
*channel_layout, uint64_t mask);
* - the number of unordered channels (eg. "4C" or "4 channels")
* - the ambisonic order followed by optional non-diegetic channels (eg.
*"ambisonic 2+stereo")
+ * On error, the channel layout will remain uninitialized, but not necessarily
+ * untouched.
*
- * @param channel_layout input channel layout
+ * @param channel_layout uninitialized channel layout for the result
* @param str string describing the channel layout
- * @return 0 channel layout was detected, AVERROR_INVALIDATATA otherwise
+ * @return 0 on success parsing the channel layout
+ * AVERROR(EINVAL) if an invalid channel layout string was provided
+ * AVERROR(ENOMEM) if there was not enough memory
*/
int av_channel_layout_from_string(AVChannelLayout *channel_layout,
const char *str);
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/7] avutil/channel_layout: add specific text versions for unknown and unused channels
Signed-off-by: Marton Balint
---
libavutil/channel_layout.c | 13 +
libavutil/tests/channel_layout.c | 2 ++
tests/ref/fate/channel_layout| 4 +++-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 9e8a1c12e6..a83618bcc7 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -86,6 +86,10 @@ void av_channel_name_bprint(AVBPrint *bp, enum AVChannel
channel_id)
av_bprintf(bp, "%s", channel_names[channel_id].name);
else if (channel_id == AV_CHAN_NONE)
av_bprintf(bp, "NONE");
+else if (channel_id == AV_CHAN_UNKNOWN)
+av_bprintf(bp, "UNK");
+else if (channel_id == AV_CHAN_UNUSED)
+av_bprintf(bp, "UNSD");
else
av_bprintf(bp, "USR%d", channel_id);
}
@@ -115,6 +119,10 @@ void av_channel_description_bprint(AVBPrint *bp, enum
AVChannel channel_id)
av_bprintf(bp, "%s", channel_names[channel_id].description);
else if (channel_id == AV_CHAN_NONE)
av_bprintf(bp, "none");
+else if (channel_id == AV_CHAN_UNKNOWN)
+av_bprintf(bp, "unknown");
+else if (channel_id == AV_CHAN_UNUSED)
+av_bprintf(bp, "unused");
else
av_bprintf(bp, "user %d", channel_id);
}
@@ -151,6 +159,11 @@ enum AVChannel av_channel_from_string(const char *str)
if (channel_names[i].name && !strcmp(str, channel_names[i].name))
return i;
}
+if (!strcmp(str, "UNK"))
+return AV_CHAN_UNKNOWN;
+if (!strcmp(str, "UNSD"))
+return AV_CHAN_UNUSED;
+
if (!strncmp(str, "USR", 3)) {
const char *p = str + 3;
id = strtol(p, &endptr, 0);
diff --git a/libavutil/tests/channel_layout.c b/libavutil/tests/channel_layout.c
index 14d36c71b5..8132b83434 100644
--- a/libavutil/tests/channel_layout.c
+++ b/libavutil/tests/channel_layout.c
@@ -348,6 +348,8 @@ int main(void)
CHANNEL_LAYOUT_FROM_STRING("Dummy@FL");
CHANNEL_LAYOUT_FROM_STRING("FR+Dummy");
CHANNEL_LAYOUT_FROM_STRING("FR+Dummy@FL");
+CHANNEL_LAYOUT_FROM_STRING("UNK+UNSD");
+CHANNEL_LAYOUT_FROM_STRING("NONE");
CHANNEL_LAYOUT_FROM_STRING("FR+@FL");
CHANNEL_LAYOUT_FROM_STRING("FL+@");
CHANNEL_LAYOUT_FROM_STRING("FR+FL@Foo+USR63@Foo");
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index 117a5fd84d..0bcfefce3b 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -148,6 +148,8 @@ With "Dummy":
fail
With "Dummy@FL": fail
With "FR+Dummy": fail
With "FR+Dummy@FL": fail
+With "UNK+UNSD":2 channels (UNK+UNSD)
+With "NONE": fail
With "FR+@FL": fail
With "FL+@": fail
With "FR+FL@Foo+USR63@Foo": 3 channels (FR+FL@Foo+USR63@Foo)
@@ -236,5 +238,5 @@ With "ambisonic 2+stereo": AMBI (ambisonic 2+stereo)
With "2C": UNSPEC (2 channels)
== UNSPEC (2 channels)
!= NATIVE
- == CUSTOM (2 channels (USR768+USR768))
+ == CUSTOM (2 channels (UNK+UNK))
!= AMBI
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/7] avutil/channel_layout: factorize parsing list of channel names
Also make use of the av_channel_from_string() function to determine the channel
id. This fixes some parse issues in av_channel_layout_from_string().
Signed-off-by: Marton Balint
---
libavutil/channel_layout.c| 172 --
tests/ref/fate/channel_layout | 8 +-
2 files changed, 62 insertions(+), 118 deletions(-)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index d3abb2dc42..5db4cc9df0 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -239,13 +239,58 @@ int av_channel_layout_from_mask(AVChannelLayout
*channel_layout,
return 0;
}
+static int parse_channel_list(AVChannelLayout *ch_layout, const char *str)
+{
+int ret;
+int nb_channels = 0;
+AVChannelCustom *map = NULL;
+AVChannelCustom custom = {0};
+
+while (*str) {
+char *channel, *chname;
+int ret = av_opt_get_key_value(&str, "@", "+",
AV_OPT_FLAG_IMPLICIT_KEY, &channel, &chname);
+if (ret < 0) {
+av_freep(&map);
+return ret;
+}
+if (*str)
+str++; // skip separator
+if (!channel) {
+channel = chname;
+chname = NULL;
+}
+av_strlcpy(custom.name, chname ? chname : "", sizeof(custom.name));
+custom.id = av_channel_from_string(channel);
+av_free(channel);
+av_free(chname);
+if (custom.id == AV_CHAN_NONE) {
+av_freep(&map);
+return AVERROR(EINVAL);
+}
+
+av_dynarray2_add((void **)&map, &nb_channels, sizeof(custom), (void
*)&custom);
+if (!map)
+return AVERROR(ENOMEM);
+}
+
+if (!nb_channels)
+return AVERROR(EINVAL);
+
+ch_layout->order = AV_CHANNEL_ORDER_CUSTOM;
+ch_layout->u.map = map;
+ch_layout->nb_channels = nb_channels;
+
+ret = av_channel_layout_retype(ch_layout, 0,
AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL);
+av_assert0(ret == 0);
+
+return 0;
+}
+
int av_channel_layout_from_string(AVChannelLayout *channel_layout,
const char *str)
{
-int i;
-int channels = 0, nb_channels = 0, native = 1;
-enum AVChannel highest_channel = AV_CHAN_NONE;
-const char *dup;
+int i, matches, ret;
+int channels = 0, nb_channels = 0;
char *chlist, *end;
uint64_t mask = 0;
@@ -321,121 +366,20 @@ int av_channel_layout_from_string(AVChannelLayout
*channel_layout,
return AVERROR(ENOMEM);
/* channel names */
-av_sscanf(str, "%d channels (%[^)]", &nb_channels, chlist);
-end = strchr(str, ')');
-
-dup = chlist;
-while (*dup) {
-char *channel, *chname;
-int ret = av_opt_get_key_value(&dup, "@", "+",
AV_OPT_FLAG_IMPLICIT_KEY, &channel, &chname);
-if (ret < 0) {
-av_free(chlist);
-return ret;
-}
-if (*dup)
-dup++; // skip separator
-if (channel && !*channel)
-av_freep(&channel);
-for (i = 0; i < FF_ARRAY_ELEMS(channel_names); i++) {
-if (channel_names[i].name && !strcmp(channel ? channel : chname,
channel_names[i].name)) {
-if (channel || i < highest_channel || mask & (1ULL << i))
-native = 0; // Not a native layout, use a custom one
-highest_channel = i;
-mask |= 1ULL << i;
-break;
-}
-}
-
-if (!channel && i >= FF_ARRAY_ELEMS(channel_names)) {
-char *endptr = chname;
-enum AVChannel id = AV_CHAN_NONE;
-
-if (!strncmp(chname, "USR", 3)) {
-const char *p = chname + 3;
-id = strtol(p, &endptr, 0);
-}
-if (id < 0 || *endptr) {
-native = 0; // Unknown channel name
-channels = 0;
-mask = 0;
-av_free(chname);
-break;
-}
-if (id > 63)
-native = 0; // Not a native layout, use a custom one
-else {
-if (id < highest_channel || mask & (1ULL << id))
-native = 0; // Not a native layout, use a custom one
-highest_channel = id;
-mask |= 1ULL << id;
-}
-}
-channels++;
-av_free(channel);
-av_free(chname);
-}
-
-if (mask && native) {
-av_free(chlist);
-if (nb_channels && ((nb_channels != channels) || (!end || *++end)))
-return AVERROR(EINVAL);
-av_channel_layout_from_mask(channel_layout, mask);
-return 0;
-}
-
-/* custom layout of channel names */
-if (channels && !native) {
-int idx = 0;
+matches = av_sscanf(str, "%d channels (%[^)]", &nb_channels, chlist);
+ret = parse_channel_list(channel_layout, chlist);
+av_freep(&chlist);
+if (ret < 0 && ret != AVERROR(EINVAL))
+return ret;
-
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
On Sat, Mar 9, 2024 at 6:59 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Muhammad Faiz: > > On Fri, Mar 8, 2024 at 10:46 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > >> Muhammad Faiz: > >>> On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > >>> andreas.rheinha...@outlook.com> wrote: > >>> > Muhammad Faiz: > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > >> 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 > >> > >> > > This breaks backward compatibility. > > > > Please revert. > > > > Thank's. > > What breaks that can't simply be fixed by removing the (a)fifo filter > from the filterchain? > > - Andreas > > > >>> I use afifo to optimize memory usage. > >>> And backward incompatible change should only be allowed with > deprecation > >>> periods and major version bump. > >>> > >> > >> Deprecation periods etc. are only common for API breaks; we do not > >> guarantee that any particular filter etc. stays available and therefore > >> occasionally remove them without deprecation. Examples of this are the > >> removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in > >> 45070eec4c or the removal of the XvMC hardware acceleration in > >> be95df12bb06 (the last commit was accompanied by cefa595361db9 and > >> b648ece34b6f which deprecated the parts of XvMC that were part of the > >> public API and therefore subject to the API stability contract). > >> > >> - Andreas > >> > >> > > It seems that all of them are external dependent components. So, I think > > that non external dependent components should be treated differently. > > Also, what is the urgency of (a)fifo removal? > > > > The reason for removing these features is that they have outlived their > usefulness; so have the (a)fifo filters. > > - Andreas > OK Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@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
On Sat, Mar 9, 2024 at 6:11 PM Paul B Mahol wrote: > On Sat, Mar 9, 2024 at 2:09 AM Muhammad Faiz wrote: > > > On Fri, Mar 8, 2024 at 10:30 PM Paul B Mahol wrote: > > > > > On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz wrote: > > > > > > > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > > > > andreas.rheinha...@outlook.com> wrote: > > > > > > > > > Muhammad Faiz: > > > > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > > > > > > andreas.rheinha...@outlook.com> wrote: > > > > > > > > > > > >> Andreas Rheinhardt: > > > > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > > > > >>> > > > > > >>> Signed-off-by: Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> > > > > > >>> --- > > > > > >>> 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 > > > > > >> > > > > > >> > > > > > > This breaks backward compatibility. > > > > > > > > > > > > Please revert. > > > > > > > > > > > > Thank's. > > > > > > > > > > What breaks that can't simply be fixed by removing the (a)fifo > filter > > > > > from the filterchain? > > > > > > > > > > - Andreas > > > > > > > > > > > > > > I use afifo to optimize memory usage. > > > > > > > > > > That statement sync with reality is questionable, fifo filters were > > mainly > > > used before .activate was added, > > > for cases filters used >1 inputs. Now they should be irrelevant, unless > > > there are bugs in code than this filters just hide more bugs. > > > > > > > Yes, I've used it before .activate was added, and it worked, and still > > works. > > Although maybe the bugs have been fixed by .activate, what's wrong if > > (a)fifo still exist? > > > > As already wrote, lets repeat it again, hiding real bugs. Hiding is not > correct word, > it just adds yet another layer in filtergraph to accumulate memory/frames, > with extra allocations per each frame for linking between prev and next > frame. > Which is pointless, as libavfilter internal code already have own queue > mechanism. > Check for which filters used after afifo, afifo count of queued frames > reach > 1 than > such filters needs fixing. Personally, my mpv visualizer modified script is > not using afifo filters, and it works fine. > > OK Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavc/thread: move generic-layer API to avcodec_internal.h
On Fri, Mar 08, 2024 at 09:27:47AM +0100, Anton Khirnov wrote: > thread.h currently contains both API for decoder use and functions > internal to lavc generic layer. Move the latter to avcodec_internal.h, > which is a more appropriate place for them. > --- > libavcodec/avcodec_internal.h | 24 > libavcodec/pthread.c | 1 + > libavcodec/thread.h | 25 + > 3 files changed, 26 insertions(+), 24 deletions(-) breaks ppc build make -j32 -k CC libavcodec/utils.o src/libavcodec/utils.c:810:5: error: no previous prototype for ‘ff_thread_init’ [-Werror=missing-prototypes] int ff_thread_init(AVCodecContext *s) ^~ cc1: some warnings being treated as errors src/ffbuild/common.mak:81: recipe for target 'libavcodec/utils.o' failed make: *** [libavcodec/utils.o] Error 1 make: Target 'all' not remade because of errors. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/ccaption_dec: honor transparency of leading non-breaking space
In Closed Captions (US), the non-breaking space (0xA0) can be used to align
text horizontally from the left by using it as a leading character.
However, CC decoder does not ignore it as a leading character like it does
an ordinary space, so a blank padding is rendered over the black CC box.
This is not the intended viewing experience.
Ignore the leading non-breaking spaces, thus creating the intended transparency
which aligns the text. Since all characters are fixed-width in CC, it
can be handled the same way as we currently treat leading ordinary spaces.
Also, as a nit, lowercase the NBSP's hex code in the entry table to match
casing of the other hex codes.
Signed-off-by: Marth64
---
libavcodec/ccaption_dec.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index faf058ce97..591013d202 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -91,7 +91,7 @@ enum cc_charset {
ENTRY(0x36, "\u00a3")\
ENTRY(0x37, "\u266a")\
ENTRY(0x38, "\u00e0")\
-ENTRY(0x39, "\u00A0")\
+ENTRY(0x39, "\u00a0")\
ENTRY(0x3a, "\u00e8")\
ENTRY(0x3b, "\u00e2")\
ENTRY(0x3c, "\u00ea")\
@@ -471,7 +471,8 @@ static int capture_screen(CCaptionSubContext *ctx)
const char *row = screen->characters[i];
const char *charset = screen->charsets[i];
j = 0;
-while (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN)
+while ((row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN) ||
+ (row[j] == 0x39 && charset[j] == CCSET_SPECIAL_AMERICAN))
j++;
if (!tab || j < tab)
tab = j;
@@ -491,7 +492,9 @@ static int capture_screen(CCaptionSubContext *ctx)
j = 0;
/* skip leading space */
-while (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN && j <
tab)
+while (j < tab &&
+ (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN) ||
+ (row[j] == 0x39 && charset[j] == CCSET_SPECIAL_AMERICAN))
j++;
x = ASS_DEFAULT_PLAYRESX * (0.1 + 0.0250 * j);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On 10 Mar 2024, at 2:25, Michael Niedermayer wrote: > Hi everyone > > Some members of the CC want to indefinitely ban Balling > from trac. And as our doc/community.texi says: > "Indefinite bans from the community must be confirmed by the General > Assembly, in a majority vote." > > Thus some CC member wishes to involve the public here > (really theres no other option, the GA cannot discuss/vote on what it doesnt > know) > > Also people have asked for more transparency and i strongly agree with > transparency. > > As reference, and to make it possible for the community to discuss > this easily without too much google searching. Ive attached the > list of all changes in trac done by Balling. > > I do not and never did support permanently banning contributors. > > In summary: since 2019 > 842 comment0' changed > 389 comment1' changed > 176 comment2' changed > 87 comment3' changed > 49 comment4' changed > 24 comment5' changed > 12 comment6' changed > 6 comment7' changed > 4 comment8' changed > 3 comment9' changed >2194 comment' changed > 10 component' changed > 12 description' changed > 29 keywords' changed > 37 owner' changed > 8 priority' changed > 7 reproduced' changed > 291 resolution' changed > 537 status' changed > 32 summary' changed > 2 type' changed > 11 version' changed > I already have an opinion about this topic due to various things I read from him on various OSS projects communication channels, but I am wondering how the attached document is helpful for the GA to get an idea of what this is about? Do you expect us to go through all of this list and visit each Trac ticket and look at what they wrote there? Maybe I am missing something here on the purpose of this document. > > On Sat, Mar 02, 2024 at 10:23:32PM +0100, Michael Niedermayer wrote: >> The CC has no authority for permanent bans >> "Indefinite bans from the community must be confirmed by the General >> Assembly, in a majority vote." >> >> I checked and it seems there are over 4800 events in trac from Balling, 3783 >> match the word "comment" >> since 2019 >> >> By what rules does the CC deal out warnings and bans ? >> >> I think this needs to be put in writing in the docs because >> currently its pretty much arbitrary. Some people get multiple >> warnings, some people get nothing, some people are suggested to be >> just banned with no prior warning > > > On Sat, Mar 09, 2024 at 11:06:39AM +0100, Jean-Baptiste Kempf wrote: >> Hello, >> >> On Sat, 9 Mar 2024, at 08:30, Anton Khirnov wrote: >>> Quoting Michael Niedermayer (2024-03-06 13:56:39) Balling does have a quite different style in his language. Not sure what is a good term, street style, ghetto style? He used the same style of language towards me 10 days ago: https://trac.ffmpeg.org/ticket/10824#comment:18 >>> >>> This is not a "style", he understands perfectly well what he is doing. >> >> Come on, the guy is a troll. >> We're not talking about a developer from FFmpeg, but an external troll, >> contributing nothing. >> Kick him out. > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > In fact, the RIAA has been known to suggest that students drop out > of college or go to community college in order to be able to afford > settlements. -- The RIAA > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/bitstream_filters: add filter_units practical examples for removing closed captions
Following up on this from December 2023. I simplified the content and hopefully addressed the feedback. Signed-off-by: Marth64 --- doc/bitstream_filters.texi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi index e06de1a73a..61539d2473 100644 --- a/doc/bitstream_filters.texi +++ b/doc/bitstream_filters.texi @@ -213,6 +213,21 @@ To remove all AUDs, SEI and filler from an H.265 stream: ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=35|38-40' OUTPUT @end example +To remove all user data from a MPEG-2 stream, including Closed Captions: +@example +ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=178' OUTPUT +@end example + +To remove all SEI from a H264 stream, including Closed Captions: +@example +ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=6' OUTPUT +@end example + +To remove all prefix and suffix SEI from a HEVC stream, including Closed Captions and dynamic HDR: +@example +ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=39|40' OUTPUT +@end example + @section hapqa_extract Extract Rgb or Alpha part of an HAPQA file, without recompression, in order to create an HAPQ or an HAPAlphaOnly file. -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Sun, Mar 10, 2024 at 02:36:48AM +0100, epira...@gmail.com wrote: > On 10 Mar 2024, at 2:25, Michael Niedermayer wrote: > > > Hi everyone > > > > Some members of the CC want to indefinitely ban Balling > > from trac. And as our doc/community.texi says: > > "Indefinite bans from the community must be confirmed by the General > > Assembly, in a majority vote." > > > > Thus some CC member wishes to involve the public here > > (really theres no other option, the GA cannot discuss/vote on what it > > doesnt know) > > > > Also people have asked for more transparency and i strongly agree with > > transparency. > > > > As reference, and to make it possible for the community to discuss > > this easily without too much google searching. Ive attached the > > list of all changes in trac done by Balling. > > > > I do not and never did support permanently banning contributors. > > > > In summary: since 2019 > > 842 comment0' changed > > 389 comment1' changed > > 176 comment2' changed > > 87 comment3' changed > > 49 comment4' changed > > 24 comment5' changed > > 12 comment6' changed > > 6 comment7' changed > > 4 comment8' changed > > 3 comment9' changed > >2194 comment' changed > > 10 component' changed > > 12 description' changed > > 29 keywords' changed > > 37 owner' changed > > 8 priority' changed > > 7 reproduced' changed > > 291 resolution' changed > > 537 status' changed > > 32 summary' changed > > 2 type' changed > > 11 version' changed > > > > I already have an opinion about this topic due to various things I read from > him on various OSS projects communication channels, but I am wondering > how the attached document is helpful for the GA to get an idea of what > this is about? > > Do you expect us to go through all of this list and visit each Trac ticket > and look at what they wrote there? > > Maybe I am missing something here on the purpose of this document. Its unbiased information, its simply the full list of changes done by the user id on trac One can read a random subset of the comments/changes or fetch the referred tickets and run some AI over all and ask for a summary If one already has formed an oppinion or does not want to vote then one can also ignore it. Or maybe the community will decide against a vote. I just tried to provide what i can so people have the information if they want it. To me, every contributor is valuable. I want people to work together as a team. But if people are asking for others to be banned thats a sign something is not right. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On 10 Mar 2024, at 4:00, Michael Niedermayer wrote: > On Sun, Mar 10, 2024 at 02:36:48AM +0100, epira...@gmail.com wrote: >> On 10 Mar 2024, at 2:25, Michael Niedermayer wrote: >> >>> Hi everyone >>> >>> Some members of the CC want to indefinitely ban Balling >>> from trac. And as our doc/community.texi says: >>> "Indefinite bans from the community must be confirmed by the General >>> Assembly, in a majority vote." >>> >>> Thus some CC member wishes to involve the public here >>> (really theres no other option, the GA cannot discuss/vote on what it >>> doesnt know) >>> >>> Also people have asked for more transparency and i strongly agree with >>> transparency. >>> >>> As reference, and to make it possible for the community to discuss >>> this easily without too much google searching. Ive attached the >>> list of all changes in trac done by Balling. >>> >>> I do not and never did support permanently banning contributors. >>> >>> In summary: since 2019 >>> 842 comment0' changed >>> 389 comment1' changed >>> 176 comment2' changed >>> 87 comment3' changed >>> 49 comment4' changed >>> 24 comment5' changed >>> 12 comment6' changed >>> 6 comment7' changed >>> 4 comment8' changed >>> 3 comment9' changed >>>2194 comment' changed >>> 10 component' changed >>> 12 description' changed >>> 29 keywords' changed >>> 37 owner' changed >>> 8 priority' changed >>> 7 reproduced' changed >>> 291 resolution' changed >>> 537 status' changed >>> 32 summary' changed >>> 2 type' changed >>> 11 version' changed >>> >> >> I already have an opinion about this topic due to various things I read from >> him on various OSS projects communication channels, but I am wondering >> how the attached document is helpful for the GA to get an idea of what >> this is about? >> >> Do you expect us to go through all of this list and visit each Trac ticket >> and look at what they wrote there? >> >> Maybe I am missing something here on the purpose of this document. > > Its unbiased information, its simply the full list of changes done by the > user id on trac > One can read a random subset of the comments/changes or fetch the referred > tickets and run some AI over all and ask for a summary > > If one already has formed an oppinion or does not want to vote then one can > also ignore it. Or maybe the community will decide against a vote. „Or maybe the community will decide against a vote.“ How would that even work? Of course you could propose a vote on having a vote but that seems like unnecessary meta-voting… > > I just tried to provide what i can so people have the information if they want > it. > > To me, every contributor is valuable. I want people to work together as a > team. But if people are asking for others to be banned thats a sign > something is not right. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Rewriting code that is poorly written but fully understood is good. > Rewriting code that one doesnt understand is a sign that one is less smart > than the original author, trying to rewrite it will not make it better. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-03-07 21:37:39) > > On Wed, Mar 06, 2024 at 12:03:03PM +0100, Anton Khirnov wrote: > > > Treat it analogously to stream parameters like format/dimensions/etc. > > > This is functionally different from previous code in 2 ways: > > > * for non-CFR video, the frame timebase (set by the decoder) is used > > > rather than the demuxer timebase > > > * for sub2video, AV_TIME_BASE_Q is used, which is hardcoded by the > > > subtitle decoding API > > > > > > These changes should avoid unnecessary and potentially lossy timestamp > > > conversions from decoder timebase into the demuxer one. > > > > > > Changes the timebases used in sub2video tests. > > > --- > > > fftools/ffmpeg_filter.c | 17 ++- > > > tests/ref/fate/sub2video_basic| 182 +- > > > tests/ref/fate/sub2video_time_limited | 8 +- > > > 3 files changed, 106 insertions(+), 101 deletions(-) > > > > breaks: > > > > ./ffmpeg -i > > \[a-s\]_full_metal_panic_fumoffu_-_01_-_the_man_from_the_south_-_a_hostage_with_no_compromises__rs2_\[1080p_bd-rip\]\[BBB48A25\].mkv > > -filter_complex '[0:s:1]scale=800:600' -t 15 -qscale 2 -y a.avi > > > > Use a constant framerate. why not automatically choose a supported timebase ? "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535" ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- 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] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Michael Niedermayer (2024-03-10 04:36:29) > On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-03-07 21:37:39) > > > On Wed, Mar 06, 2024 at 12:03:03PM +0100, Anton Khirnov wrote: > > > > Treat it analogously to stream parameters like format/dimensions/etc. > > > > This is functionally different from previous code in 2 ways: > > > > * for non-CFR video, the frame timebase (set by the decoder) is used > > > > rather than the demuxer timebase > > > > * for sub2video, AV_TIME_BASE_Q is used, which is hardcoded by the > > > > subtitle decoding API > > > > > > > > These changes should avoid unnecessary and potentially lossy timestamp > > > > conversions from decoder timebase into the demuxer one. > > > > > > > > Changes the timebases used in sub2video tests. > > > > --- > > > > fftools/ffmpeg_filter.c | 17 ++- > > > > tests/ref/fate/sub2video_basic| 182 +- > > > > tests/ref/fate/sub2video_time_limited | 8 +- > > > > 3 files changed, 106 insertions(+), 101 deletions(-) > > > > > > breaks: > > > > > > ./ffmpeg -i > > > \[a-s\]_full_metal_panic_fumoffu_-_01_-_the_man_from_the_south_-_a_hostage_with_no_compromises__rs2_\[1080p_bd-rip\]\[BBB48A25\].mkv > > > -filter_complex '[0:s:1]scale=800:600' -t 15 -qscale 2 -y a.avi > > > > > > > Use a constant framerate. > > why not automatically choose a supported timebase ? > > "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 > standard, the maximum admitted value for the timebase denominator is 65535" Because I don't want ffmpeg CLI to have codec-specific code for a codec that's been obsolete for 15+ years. One could also potentially do it inside the encoder itself, but it is nontrivial since the computations are spread across a number of places in mpeg4videoenc.c and mpegvideo_enc.c. And again, it seems like a waste of time - there is no reason to encode mpeg4 today. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
