Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Sun, 10 Mar 2024, 01: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 > > > 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. > Do you have permission to post private CC discussion on the ML? Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Sun, Mar 10, 2024 at 10:24 AM Kieran Kunhya wrote: > On Sun, 10 Mar 2024, 01: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 > > > > > > 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. > > > > Do you have permission to post private CC discussion on the ML? > Yes, As approved by new supreme leader Anton. > > 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 2/2] avcodec: remove sonic lossy/lossless audio
On 2024-02-28 19:36 +0100, Jean-Baptiste Kempf wrote: > > On Wed, 28 Feb 2024, at 18:55, James Almer wrote: > > On 2/28/2024 10:31 AM, J. Dekker wrote: > >> > >> Michael Niedermayer writes: > >> > >>> [[PGP Signed Part:Undecided]] > >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > This was an experimental/research codec of which ffmpeg is the only > encoder and decoder, > >>> > >>> > development has stalled > >>> > >>> Thats not true, there was private dicussion making sonic the most > >>> advanced audio codec in FFmpeg a few months ago. > >>> Iam not saying that will happen, i am just saying there was a > >>> discussion about it. And that iam in principle interrested in > >>> working on this. Its possible i will not have enough time ... > >>> > >> > >> The last commit which actually changed the codec was > >> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > >> years ago. For an experimental codec I think it's pretty safe to say > >> that development has stalled. > >> > >> Keeping the codec around based on 'what if?'s doesn't seem > >> reasonable. Besides, if you do make sonic the most advanced audio codec > >> in FFmpeg there's nothing which says you couldn't re-add it at a later > >> date when it's being actively developed again. > > > > Does it hurt keeping it around? If it can at some point be developed > > again, then removing the codec id to re-add it later will be a bit dirty. > > > > IMO, just disable both modules by default during configure, or tag the > > encoder as experimental to prevent new streams to be created unless > > explicitly requested knowing that it's an unfinished format. > > +1 +1 But if it stays it should be regularly compiled (at least on a fate client). Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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
Hi Mark, Do you think the broken vaapi dec-filter-encode (and other hw acceleration method using fixed-size pool) is a blocking issue ? See more info below: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231220071050.3175819-11-haihao.xi...@intel.com/ https://patchwork.ffmpeg.org/project/ffmpeg/patch/817dc1ea-495e-4c7f-8615-264e755ff...@jkqxz.net/ Thanks Haihao > 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 mailing list ffmpeg-devel@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] doc/examples/qsv_decode.c: remove unused config.h header file
On date Saturday 2024-03-09 02:17:19 +, hung kuishing wrote: > > Signed-off-by: clarkh > mailto:hungkuish...@outlook.com>> > --- > doc/examples/qsv_decode.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/doc/examples/qsv_decode.c b/doc/examples/qsv_decode.c > index cc2662d5bd..901eac3b27 100644 > --- a/doc/examples/qsv_decode.c > +++ b/doc/examples/qsv_decode.c > @@ -28,8 +28,6 @@ > * GPU video surfaces, write the decoded frames to an output file. > */ > > -#include "config.h" > - > #include > > #include "libavformat/avformat.h" > -- > 2.34.1 Looks good but it fails with: git am --abort; git am patches/fix-doc-qsvdec.patch Applying: doc/examples/qsv_decode.c: remove unused config.h header file error: corrupt patch at line 15 Can you try to generate the patch (git format-patch) and attach it to the thread? Or I'll just apply the diff manually. ___ ffmpeg-devel mailing list ffmpeg-devel@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
On date Saturday 2024-03-09 17:20:49 +, ffmpeg-devel Mailing List wrote:
> 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?
>
> 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
nit: sort order (should go after adts)
> +MD STUDIO audio muxer.
out of my own curiosity, what is MD STUDIO?
[...]
You might also add an entry to the Changelog.
Looks good 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 v2 1/3] avformat/dvdvideodec: assign mono channel layout explicitly
On date Saturday 2024-03-09 12:27:50 -0600, Marth64 wrote: > 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 LGTM, will apply. ___ ffmpeg-devel mailing list ffmpeg-devel@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] avcodec/libdav1d: parse DV profile 10 T.35 OBU
From: Niklas Haas
This is thankfully passed through verbatim by libdav1d, so we can parse
it in our own code.
In theory, taking the DV profile from the packet-level configuration
struct is redundant since there is currently only one possible DV level
for AV1 (and all others would fail parsing), but this marginally
future-proofs it against possible new AV1-specific profiles being added
in the future.
---
libavcodec/libdav1d.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 5c4c643696f..1aa2d1f3436 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -35,6 +35,7 @@
#include "bytestream.h"
#include "codec_internal.h"
#include "decode.h"
+#include "dovi_rpu.h"
#include "internal.h"
#define FF_DAV1D_VERSION_AT_LEAST(x,y) \
@@ -44,6 +45,7 @@ typedef struct Libdav1dContext {
AVClass *class;
Dav1dContext *c;
AVBufferPool *pool;
+DOVIContext dovi;
int pool_size;
Dav1dData data;
@@ -213,6 +215,7 @@ static av_cold int libdav1d_init(AVCodecContext *c)
#else
int threads = (c->thread_count ? c->thread_count : av_cpu_count()) * 3 / 2;
#endif
+const AVPacketSideData *sd;
int res;
av_log(c, AV_LOG_VERBOSE, "libdav1d %s\n", dav1d_version());
@@ -285,6 +288,11 @@ static av_cold int libdav1d_init(AVCodecContext *c)
c->delay = res > 1 ? res : 0;
#endif
+dav1d->dovi.logctx = c;
+dav1d->dovi.dv_profile = 10; // default for AV1
+sd = ff_get_coded_side_data(c, AV_PKT_DATA_DOVI_CONF);
+if (sd && sd->size > 0)
+ff_dovi_update_cfg(&dav1d->dovi, (AVDOVIDecoderConfigurationRecord *)
sd->data);
return 0;
}
@@ -579,6 +587,22 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
goto fail;
break;
}
+case 0x3B: { // dolby_provider_code
+int provider_oriented_code = bytestream2_get_be32(&gb);
+if (itut_t35->country_code != 0xB5 || provider_oriented_code !=
0x800)
+break;
+
+res = ff_dovi_rpu_parse(&dav1d->dovi, gb.buffer, gb.buffer_end -
gb.buffer);
+if (res < 0) {
+av_log(c, AV_LOG_WARNING, "Error parsing DOVI OBU.\n");
+break; // ignore
+}
+
+res = ff_dovi_attach_side_data(&dav1d->dovi, frame);
+if (res < 0)
+goto fail;
+break;
+}
default: // ignore unsupported provider codes
break;
}
@@ -638,6 +662,7 @@ static av_cold int libdav1d_close(AVCodecContext *c)
Libdav1dContext *dav1d = c->priv_data;
av_buffer_pool_uninit(&dav1d->pool);
+ff_dovi_ctx_unref(&dav1d->dovi);
dav1d_data_unref(&dav1d->data);
dav1d_close(&dav1d->c);
--
2.44.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 v2 3/3] avcodec/av1dec: parse DV profile 10 T.35 OBU
From: Niklas Haas
See previous commit.
---
libavcodec/av1dec.c | 25 +
libavcodec/av1dec.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index bbb5634773f..e6346b51dbe 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -734,6 +734,7 @@ static av_cold int av1_decode_free(AVCodecContext *avctx)
ff_cbs_fragment_free(&s->current_obu);
ff_cbs_close(&s->cbc);
+ff_dovi_ctx_unref(&s->dovi);
return 0;
}
@@ -828,6 +829,7 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
{
AV1DecContext *s = avctx->priv_data;
AV1RawSequenceHeader *seq;
+const AVPacketSideData *sd;
int ret;
s->avctx = avctx;
@@ -883,6 +885,12 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
ff_cbs_fragment_reset(&s->current_obu);
}
+s->dovi.logctx = avctx;
+s->dovi.dv_profile = 10; // default for AV1
+sd = ff_get_coded_side_data(avctx, AV_PKT_DATA_DOVI_CONF);
+if (sd && sd->size > 0)
+ff_dovi_update_cfg(&s->dovi, (AVDOVIDecoderConfigurationRecord *)
sd->data);
+
return ret;
}
@@ -936,6 +944,7 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame
*frame,
const AV1RawMetadataITUTT35 *itut_t35)
{
GetByteContext gb;
+AV1DecContext *s = avctx->priv_data;
int ret, provider_code;
bytestream2_init(&gb, itut_t35->payload, itut_t35->payload_size);
@@ -985,6 +994,22 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame
*frame,
return ret;
break;
}
+case 0x3B: { // dolby_provider_code
+int provider_oriented_code = bytestream2_get_be32(&gb);
+if (itut_t35->itu_t_t35_country_code != 0xB5 || provider_oriented_code
!= 0x800)
+break;
+
+ret = ff_dovi_rpu_parse(&s->dovi, gb.buffer, gb.buffer_end -
gb.buffer);
+if (ret < 0) {
+av_log(avctx, AV_LOG_WARNING, "Error parsing DOVI OBU.\n");
+break; // ignore
+}
+
+ret = ff_dovi_attach_side_data(&s->dovi, frame);
+if (ret < 0)
+return ret;
+break;
+}
default: // ignore unsupported provider codes
break;
}
diff --git a/libavcodec/av1dec.h b/libavcodec/av1dec.h
index a6ad80c12ab..336eb613597 100644
--- a/libavcodec/av1dec.h
+++ b/libavcodec/av1dec.h
@@ -31,6 +31,7 @@
#include "packet.h"
#include "cbs.h"
#include "cbs_av1.h"
+#include "dovi_rpu.h"
typedef struct AV1Frame {
AVFrame *f;
@@ -81,6 +82,7 @@ typedef struct AV1DecContext {
AV1RawMetadataHDRCLL *cll;
AV1RawOBU *mdcv_ref; ///< RefStruct reference backing mdcv
AV1RawMetadataHDRMDCV *mdcv;
+DOVIContext dovi;
AVFifo *itut_t35_fifo;
uint16_t tile_num;
--
2.44.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 v2 1/3] avcodec/dovi_rpu: implement support for profile 10
From: Niklas Haas
Changes since v1:
- Greatly simplified EMDF implementation, after gaining insight to the
specification (which states that the emdf header must used certain
hard-coded values)
- Tested and validated on official samples
---
Instead of the nal_prefix, this profile inside wraps the RPU inside an
EMDF container, as specified in ETSI TS 102 366. However, this
DV-specific EMDF container is restricted (by the specification) to
a fixed set of hard-coded parameters, which we can effecitvely treat as
a magic byte sequence.
Validated and tested using official Dolby sample files, which
I unfortunately cannot share. However, there are public sample files
available at the merge request link below.
Relevant links:
-
https://www.etsi.org/deliver/etsi_ts/102300_102399/102366/01.04.01_60/ts_102366v010401p.pdf
-
https://patentimages.storage.googleapis.com/8a/0b/da/28294acaed2182/EP3588964A1.pdf
-
https://www.etsi.org/deliver/etsi_ts/103500_103599/103572/01.03.01_60/ts_103572v010301p.pdf
- https://gitlab.com/mbunkus/mkvtoolnix/-/merge_requests/2254
---
libavcodec/dovi_rpu.c | 45 ---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index a6b23f4dd11..529062be30a 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -174,6 +174,18 @@ static inline int64_t get_se_coef(GetBitContext *gb, const
AVDOVIRpuDataHeader *
return 0; /* unreachable */
}
+static inline unsigned get_variable_bits(GetBitContext *gb, int n)
+{
+unsigned int value = get_bits(gb, n);
+int read_more = get_bits1(gb);
+while (read_more) {
+value = (value + 1) << n;
+value |= get_bits(gb, n);
+read_more = get_bits1(gb);
+}
+return value;
+}
+
#define VALIDATE(VAR, MIN, MAX)
\
do {
\
if (VAR < MIN || VAR > MAX) {
\
@@ -200,9 +212,36 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu,
size_t rpu_size)
if ((ret = init_get_bits8(gb, rpu, rpu_size)) < 0)
return ret;
-/* RPU header, common values */
-nal_prefix = get_bits(gb, 8);
-VALIDATE(nal_prefix, 25, 25);
+/* Container header */
+if (s->dv_profile == 10 /* dav1.10 */) {
+/* DV inside AV1 re-uses an EMDF container skeleton, but with fixed
+ * values - so we can effectively treat this as a magic byte sequence.
+ *
+ * The exact fields are, as follows:
+ * emdf_version: f(2) = 0
+ * key_id : f(3) = 6
+ * emdf_payload_id : f(5) = 31
+ * emdf_payload_id_ext : var(5) = 225
+ * smploffste : f(1) = 0
+ * duratione : f(1) = 0
+ * groupide: f(1) = 0
+ * codecdatae : f(1) = 0
+ * discard_unknown_payload : f(1) = 1
+ */
+const unsigned header_magic = 0x01be6841u;
+unsigned header, emdf_payload_size;
+header = get_bits_long(gb, 27);
+VALIDATE(header, header_magic, header_magic);
+emdf_payload_size = get_variable_bits(gb, 8);
+VALIDATE(emdf_payload_size, 6, 512);
+if (emdf_payload_size * 8 > get_bits_left(gb))
+return AVERROR_INVALIDDATA;
+} else {
+nal_prefix = get_bits(gb, 8);
+VALIDATE(nal_prefix, 25, 25);
+}
+
+/* RPU header */
rpu_type = get_bits(gb, 6);
if (rpu_type != 2) {
av_log(s->logctx, AV_LOG_WARNING, "Unrecognized RPU type "
--
2.44.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/dvdvideodec: add CLUT utilities and subtitle color support
On date Saturday 2024-03-09 12:27:51 -0600, Marth64 wrote: > 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 LGTM, but will wait a few days to apply in case there are other comments (or feel free to apply in my stead). 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 1/2] avcodec/ccaption_dec: clarify log message when out-of-display columns are ignored
On date Saturday 2024-03-09 12:39:55 -0600, Marth64 wrote:
> 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;
> }
will apply, 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] avcodec/ccaption_dec: use consistent naming convention of Closed Captions
On date Saturday 2024-03-09 12:39:56 -0600, Marth64 wrote:
> 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
Will apply, 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".
[FFmpeg-devel] [PATCH 1/6] avcodec/tiff: Fix handling of av_strdup() failures
For unknown geokey values, get_geokey_val() returns
"Unknown-%d" with val being used for %d. This string
is allocated and therefore all the known geokey values
(static strings) are strdup'ed. In case this fails
it is either ignored or treated as "Unknown-%d".
(Furthermore it is possible to call av_strdup(NULL),
although this is not documented to be legal.)
This commit changes this by only returning the static strings
in get_geokey_val(); the unknown handling and strdup'ing
is moved out of it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index cb4d378753..4c7460cf41 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -36,6 +36,7 @@
#include
#include "libavutil/attributes.h"
+#include "libavutil/avstring.h"
#include "libavutil/error.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
@@ -179,19 +180,17 @@ static const char *search_keyval(const TiffGeoTagKeyName
*keys, int n, int id)
return NULL;
}
-static char *get_geokey_val(int key, int val)
+static const char *get_geokey_val(int key, uint16_t val)
{
-char *ap;
-
if (val == TIFF_GEO_KEY_UNDEFINED)
-return av_strdup("undefined");
+return "undefined";
if (val == TIFF_GEO_KEY_USER_DEFINED)
-return av_strdup("User-Defined");
+return "User-Defined";
#define RET_GEOKEY_VAL(TYPE, array)\
if (val >= TIFF_##TYPE##_OFFSET &&\
val - TIFF_##TYPE##_OFFSET < FF_ARRAY_ELEMS(tiff_##array##_codes))\
-return av_strdup(tiff_##array##_codes[val - TIFF_##TYPE##_OFFSET]);
+return tiff_##array##_codes[val - TIFF_##TYPE##_OFFSET];
switch (key) {
case TIFF_GT_MODEL_TYPE_GEOKEY:
@@ -224,13 +223,9 @@ static char *get_geokey_val(int key, int val)
RET_GEOKEY_VAL(PRIME_MERIDIAN, prime_meridian);
break;
case TIFF_PROJECTED_CS_TYPE_GEOKEY:
-ap = av_strdup(search_keyval(tiff_proj_cs_type_codes,
FF_ARRAY_ELEMS(tiff_proj_cs_type_codes), val));
-if(ap) return ap;
-break;
+return search_keyval(tiff_proj_cs_type_codes,
FF_ARRAY_ELEMS(tiff_proj_cs_type_codes), val);
case TIFF_PROJECTION_GEOKEY:
-ap = av_strdup(search_keyval(tiff_projection_codes,
FF_ARRAY_ELEMS(tiff_projection_codes), val));
-if(ap) return ap;
-break;
+return search_keyval(tiff_projection_codes,
FF_ARRAY_ELEMS(tiff_projection_codes), val);
case TIFF_PROJ_COORD_TRANS_GEOKEY:
RET_GEOKEY_VAL(COORD_TRANS, coord_trans);
break;
@@ -241,10 +236,7 @@ static char *get_geokey_val(int key, int val)
}
-ap = av_malloc(14);
-if (ap)
-snprintf(ap, 14, "Unknown-%d", val);
-return ap;
+return NULL;
}
static char *doubles2str(double *dp, int count, const char *sep)
@@ -1634,9 +1626,14 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
*frame)
s->geotags[i].type = ff_tget_short(&s->gb, s->le);
s->geotags[i].count = ff_tget_short(&s->gb, s->le);
-if (!s->geotags[i].type)
-s->geotags[i].val = get_geokey_val(s->geotags[i].key,
ff_tget_short(&s->gb, s->le));
-else
+if (!s->geotags[i].type) {
+uint16_t val= ff_tget_short(&s->gb, s->le);
+const char *str = get_geokey_val(s->geotags[i].key, val);
+
+s->geotags[i].val = str ? av_strdup(str) :
av_asprintf("Unknown-%u", val);
+if (!s->geotags[i].val)
+return AVERROR(ENOMEM);
+} else
s->geotags[i].offset = ff_tget_short(&s->gb, s->le);
}
break;
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] avcodec/tiff: Avoid duplicating strings
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 4c7460cf41..afa1289e27 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -2028,7 +2028,8 @@ again:
av_log(avctx, AV_LOG_WARNING, "Type of GeoTIFF key %d is wrong\n",
s->geotags[i].key);
continue;
}
-ret = av_dict_set(&p->metadata, keyname, s->geotags[i].val, 0);
+ret = av_dict_set(&p->metadata, keyname, s->geotags[i].val,
AV_DICT_DONT_STRDUP_VAL);
+s->geotags[i].val = NULL;
if (ret<0) {
av_log(avctx, AV_LOG_ERROR, "Writing metadata with key '%s'
failed\n", keyname);
return ret;
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] avcodec/tiff: Don't check before av_freep()
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index afa1289e27..5d350f4e7e 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -132,11 +132,8 @@ static void tiff_set_type(TiffContext *s, enum TiffType
tiff_type) {
static void free_geotags(TiffContext *const s)
{
-int i;
-for (i = 0; i < s->geotag_count; i++) {
-if (s->geotags[i].val)
-av_freep(&s->geotags[i].val);
-}
+for (int i = 0; i < s->geotag_count; i++)
+av_freep(&s->geotags[i].val);
av_freep(&s->geotags);
s->geotag_count = 0;
}
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] avcodec/tiff: Improve inclusions
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 1 -
libavcodec/tiff.c | 1 +
libavcodec/tiff.h | 3 ---
libavcodec/tiffenc.c | 3 +--
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 43b36d0a8f..c9409eac6c 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -52,7 +52,6 @@
#include "jpeglsdec.h"
#include "profiles.h"
#include "put_bits.h"
-#include "tiff.h"
#include "exif.h"
#include "bytestream.h"
#include "tiff_common.h"
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 5d350f4e7e..15e5edd93b 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -48,6 +48,7 @@
#include "faxcompr.h"
#include "lzw.h"
#include "tiff.h"
+#include "tiff_common.h"
#include "tiff_data.h"
#include "mjpegdec.h"
#include "thread.h"
diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h
index e67c59abad..2dd21dea52 100644
--- a/libavcodec/tiff.h
+++ b/libavcodec/tiff.h
@@ -30,9 +30,6 @@
#ifndef AVCODEC_TIFF_H
#define AVCODEC_TIFF_H
-#include
-#include "tiff_common.h"
-
/** TIFF types in ascenting priority (last in the list is highest) */
enum TiffType {
/** TIFF image based on the TIFF 6.0 or TIFF/EP (ISO 12234-2)
specifications */
diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
index dfe308ee17..7c3c03f1f3 100644
--- a/libavcodec/tiffenc.c
+++ b/libavcodec/tiffenc.c
@@ -30,7 +30,6 @@
#include
#endif
-#include "libavutil/imgutils.h"
#include "libavutil/log.h"
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
@@ -39,9 +38,9 @@
#include "codec_internal.h"
#include "encode.h"
#include "lzw.h"
-#include "put_bits.h"
#include "rle.h"
#include "tiff.h"
+#include "tiff_common.h"
#include "version.h"
#define TIFF_MAX_ENTRY 32
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] avcodec/tiff_data: Avoid relocations for TiffGeoTagNameType
Instead store all the strings in one continugous string
(with internal \0) and use offsets to access the actual
substrings. This replaces the pointers to the strings
and therefore avoids relocations (and on x64, it actually
shrinks TiffGeoTagNameType by reusing padding to store
the offset field).
This saves 720B of .data.rel.ro and 1080B of .rela.dyn
(containing the relocation records) here while increasing
.rodata by 384B.
Signed-off-by: Andreas Rheinhardt
---
I also have patches for the remaining tables, but am not
satisfied with them yet.
libavcodec/tiff.c | 28 +
libavcodec/tiff.h | 5 --
libavcodec/tiff_data.h | 129 -
3 files changed, 92 insertions(+), 70 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 15e5edd93b..004db89c6b 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -139,27 +139,31 @@ static void free_geotags(TiffContext *const s)
s->geotag_count = 0;
}
-#define RET_GEOKEY(TYPE, array, element)\
+static const char *get_geokey_name(int key)
+{
+#define RET_GEOKEY_STR(TYPE, array)\
if (key >= TIFF_##TYPE##_KEY_ID_OFFSET &&\
key - TIFF_##TYPE##_KEY_ID_OFFSET <
FF_ARRAY_ELEMS(tiff_##array##_name_type_map))\
-return tiff_##array##_name_type_map[key -
TIFF_##TYPE##_KEY_ID_OFFSET].element;
+return tiff_##array##_name_type_string +
tiff_##array##_name_type_map[key - TIFF_##TYPE##_KEY_ID_OFFSET].offset;
-static const char *get_geokey_name(int key)
-{
-RET_GEOKEY(VERT, vert, name);
-RET_GEOKEY(PROJ, proj, name);
-RET_GEOKEY(GEOG, geog, name);
-RET_GEOKEY(CONF, conf, name);
+RET_GEOKEY_STR(VERT, vert);
+RET_GEOKEY_STR(PROJ, proj);
+RET_GEOKEY_STR(GEOG, geog);
+RET_GEOKEY_STR(CONF, conf);
return NULL;
}
static int get_geokey_type(int key)
{
-RET_GEOKEY(VERT, vert, type);
-RET_GEOKEY(PROJ, proj, type);
-RET_GEOKEY(GEOG, geog, type);
-RET_GEOKEY(CONF, conf, type);
+#define RET_GEOKEY_TYPE(TYPE, array)\
+if (key >= TIFF_##TYPE##_KEY_ID_OFFSET &&\
+key - TIFF_##TYPE##_KEY_ID_OFFSET <
FF_ARRAY_ELEMS(tiff_##array##_name_type_map))\
+return tiff_##array##_name_type_map[key -
TIFF_##TYPE##_KEY_ID_OFFSET].type;
+RET_GEOKEY_TYPE(VERT, vert);
+RET_GEOKEY_TYPE(PROJ, proj);
+RET_GEOKEY_TYPE(GEOG, geog);
+RET_GEOKEY_TYPE(CONF, conf);
return AVERROR_INVALIDDATA;
}
diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h
index 2dd21dea52..12afcfa6e5 100644
--- a/libavcodec/tiff.h
+++ b/libavcodec/tiff.h
@@ -222,9 +222,4 @@ typedef struct TiffGeoTagKeyName {
const char *const name;
} TiffGeoTagKeyName;
-typedef struct TiffGeoTagNameType {
-const char *const name;
-const enum TiffGeoTagType type;
-} TiffGeoTagNameType;
-
#endif /* AVCODEC_TIFF_H */
diff --git a/libavcodec/tiff_data.h b/libavcodec/tiff_data.h
index 9b123ca8df..9ed46d31af 100644
--- a/libavcodec/tiff_data.h
+++ b/libavcodec/tiff_data.h
@@ -32,66 +32,89 @@
#include "tiff.h"
+typedef struct TiffGeoTagNameType {
+enum TiffGeoTagType type;
+unsigned offset;
+} TiffGeoTagNameType;
+
#define TIFF_CONF_KEY_ID_OFFSET 1024
-static const TiffGeoTagNameType tiff_conf_name_type_map[] = {
-{"GTModelTypeGeoKey", GEOTIFF_SHORT },
-{"GTRasterTypeGeoKey", GEOTIFF_SHORT },
-{"GTCitationGeoKey", GEOTIFF_STRING}
-};
+#define CONF_NAME_TYPE_MAP(KEY) \
+KEY(GTModelTypeGeoKey, SHORT ) \
+KEY(GTRasterTypeGeoKey, SHORT ) \
+KEY(GTCitationGeoKey, STRING) \
#define TIFF_GEOG_KEY_ID_OFFSET 2048
-static const TiffGeoTagNameType tiff_geog_name_type_map[] = {
-{"GeographicTypeGeoKey", GEOTIFF_SHORT },
-{"GeogCitationGeoKey", GEOTIFF_STRING},
-{"GeogGeodeticDatumGeoKey",GEOTIFF_SHORT },
-{"GeogPrimeMeridianGeoKey",GEOTIFF_SHORT },
-{"GeogLinearUnitsGeoKey", GEOTIFF_SHORT },
-{"GeogLinearUnitSizeGeoKey", GEOTIFF_DOUBLE},
-{"GeogAngularUnitsGeoKey", GEOTIFF_SHORT },
-{"GeogAngularUnitSizeGeoKey", GEOTIFF_DOUBLE},
-{"GeogEllipsoidGeoKey",GEOTIFF_SHORT },
-{"GeogSemiMajorAxisGeoKey",GEOTIFF_DOUBLE},
-{"GeogSemiMinorAxisGeoKey",GEOTIFF_DOUBLE},
-{"GeogInvFlatteningGeoKey",GEOTIFF_DOUBLE},
-{"GeogAzimuthUnitsGeoKey", GEOTIFF_SHORT },
-{"GeogPrimeMeridianLongGeoKey",GEOTIFF_DOUBLE}
-};
+#define GEOG_NAME_TYPE_MAP(KEY) \
+KEY(GeographicTypeGeoKey, SHORT ) \
+KEY(GeogCitationGeoKey, STRING) \
+KEY(GeogGeodeticDatumGeoKey,SHORT ) \
+KEY(GeogPrimeMeridianGeoKey,SHORT ) \
+KEY(GeogLinearUnitsGeoKey, SHORT ) \
+KEY(GeogLinearUnitSizeGeoKey, DOUBLE) \
+KEY(GeogAngularUnitsGeoKey, SHORT ) \
+KEY(GeogAngularUnitSizeGeoKey, DOUBLE) \
+KEY
[FFmpeg-devel] [PATCH 6/6] avcodec/tiff_data: Remove incorrect GeoTIFF entries
They are incorrect according to [1]. They also share keys with valid
entries, so that it is unspecified which entry bsearch returns
in this case. Fix this by removing the incorrect values.
[1]: https://www.earthdata.nasa.gov/s3fs-public/imported/19-008r4.pdf
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff_data.h | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/tiff_data.h b/libavcodec/tiff_data.h
index 9ed46d31af..1742ccf60f 100644
--- a/libavcodec/tiff_data.h
+++ b/libavcodec/tiff_data.h
@@ -804,13 +804,9 @@ static const TiffGeoTagKeyName tiff_proj_cs_type_codes[] =
{
{26771, "PCS_NAD27_Illinois_East"},
{26772, "PCS_NAD27_Illinois_West"},
{26773, "PCS_NAD27_Indiana_East"},
-{26774, "PCS_NAD27_BLM_14N_feet"},
{26774, "PCS_NAD27_Indiana_West"},
-{26775, "PCS_NAD27_BLM_15N_feet"},
{26775, "PCS_NAD27_Iowa_North"},
-{26776, "PCS_NAD27_BLM_16N_feet"},
{26776, "PCS_NAD27_Iowa_South"},
-{26777, "PCS_NAD27_BLM_17N_feet"},
{26777, "PCS_NAD27_Kansas_North"},
{26778, "PCS_NAD27_Kansas_South"},
{26779, "PCS_NAD27_Kentucky_North"},
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself as dvdvideo demuxer, rcwt muxer maintainer
On date Saturday 2024-03-09 12:48:22 -0600, Marth64 wrote: > I am willing to maintain these into the future as needed. Thank you. > > Signed-off-by: Marth64 > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) Will apply (not sure if there is a more formal process to add a maintainer, but given that you contributed all the code this seems totally non-controversial). 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
Great, thank you very much!
I'm attaching the (hopefully) final version of the patch.
MD studio was a piece of software created by a company called "EDL", which in
combination with alternative firmware for the Sony MDH-10 MiniDisc recorder
(https://www.minidisc.wiki/equipment/sony/misc/mdh-10) let people download raw
ATRAC1 audio from their MiniDiscs onto computers, and (probably) put this audio
back on their discs later.
Nowadays it's used by software like Web Minidisc Pro (which I maintain) to
store ATRAC1 audio, as it (until recently) was the only way to store ATRAC1 so
that it would be picked up by VLC. Now we have matroska support for ATRAC1, but
I wanted to write a muxer for AEA before I phase it out from new pieces of
software, so that the people who would like to use AEA instead of matroska have
a way to go back to it.
> On date Saturday 2024-03-09 17:20:49 +, ffmpeg-devel Mailing List wrote:
>
> > 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?
>
> > From ee1d4c93c66e729d9d0456b2e8e789f3f98389e3 Mon Sep 17 00:00:00 2001
> > From: asivery asiv...@protonmail.com
> > Date: Fri, 8 Mar 2024 14:45:02 +0100
> > Subject: [PATCH] avformat/aea: Add aea muxer
> >
> > Signed-off-by: asivery asiv...@protonmail.com
> > ---
> > 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
>
>
> nit: sort order (should go after adts)
>
> > +MD STUDIO audio muxer.
>
>
> out of my own curiosity, what is MD STUDIO?
>
> [...]
>
> You might also add an entry to the Changelog.
> Looks good to me otherwise, thanks.From e67d2df52c65528fbbfe8d5268661c88a7ad225e 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
---
Changelog | 1 +
doc/muxers.texi | 10 +++
libavformat/Makefile| 3 +-
libavformat/{aea.c => aeadec.c} | 0
libavformat/aeaenc.c| 115
libavformat/allformats.c| 1 +
6 files changed, 129 insertions(+), 1 deletion(-)
rename libavformat/{aea.c => aeadec.c} (100%)
create mode 100644 libavformat/aeaenc.c
diff --git a/Changelog b/Changelog
index 069b827448..641c6b7cc5 100644
--- a/Changelog
+++ b/Changelog
@@ -32,6 +32,7 @@ version :
- DVD-Video demuxer, powered by libdvdnav and libdvdread
- ffprobe -show_stream_groups option
- ffprobe (with -export_side_data film_grain) now prints film grain metadata
+- AEA muxer
version 6.1:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..6446d868ed 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -684,6 +684,16 @@ Enable to set MPEG version bit in the ADTS frame header to 1 which
indicates MPEG-2. Default is 0, which indicates MPEG-4.
@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{aiff}
@section aiff
Audio Interchange File Format 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-$(CON
Re: [FFmpeg-devel] [PATCH v3] avformat/dvdvideodec: add menu demuxing support
On date Saturday 2024-03-09 13:17:23 -0600, Marth64 wrote: > 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(-) Still, looks good to me, I'll wait a few days to see if there are more comments before pushing (please someone do in my stead if I'll be missing). 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] doc/bitstream_filters: add filter_units practical examples for removing closed captions
On date Saturday 2024-03-09 19:56:49 -0600, Marth64 wrote: > 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 > + Not against, but I'm not super convinced this is super useful as it does not really explain what these values come from. Probably it would be more useful a table, or even better make the parser somehow expose the supported types with the meaning (this would enable having e.g. a symbolic type "cc" abstracting the containter format). OTOH I agree thius would provide some practical examples, therefore I'll apply while we have no smarter way to expose the logic in a more effective way. 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
On date Sunday 2024-03-10 14:20:12 +, ffmpeg-devel Mailing List wrote:
> Great, thank you very much!
> I'm attaching the (hopefully) final version of the patch.
>
> MD studio was a piece of software created by a company called "EDL",
> which in combination with alternative firmware for the Sony MDH-10
> MiniDisc recorder
> (https://www.minidisc.wiki/equipment/sony/misc/mdh-10) let people
> download raw ATRAC1 audio from their MiniDiscs onto computers, and
> (probably) put this audio back on their discs later. Nowadays it's
> used by software like Web Minidisc Pro (which I maintain) to store
> ATRAC1 audio, as it (until recently) was the only way to store
> ATRAC1 so that it would be picked up by VLC. Now we have matroska
> support for ATRAC1, but I wanted to write a muxer for AEA before I
> phase it out from new pieces of software, so that the people who
> would like to use AEA instead of matroska have a way to go back to
> it.
Thanks, probably part of this information could go to the doc to
provide some context (can be done as a separate patch), as this kind
of info is very difficult to retrieve otherwise (and one of the goals
of FFmpeg is digital preservation).
> From e67d2df52c65528fbbfe8d5268661c88a7ad225e 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
> ---
> Changelog | 1 +
> doc/muxers.texi | 10 +++
> libavformat/Makefile| 3 +-
> libavformat/{aea.c => aeadec.c} | 0
> libavformat/aeaenc.c| 115
> libavformat/allformats.c| 1 +
> 6 files changed, 129 insertions(+), 1 deletion(-)
> rename libavformat/{aea.c => aeadec.c} (100%)
> create mode 100644 libavformat/aeaenc.c
Patch looks good to me, waiting for more feedback by Andreas.
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 1/6] avcodec/tiff: Fix handling of av_strdup() failures
On date Sunday 2024-03-10 15:12:16 +0100, Andreas Rheinhardt wrote:
> For unknown geokey values, get_geokey_val() returns
> "Unknown-%d" with val being used for %d. This string
> is allocated and therefore all the known geokey values
> (static strings) are strdup'ed. In case this fails
> it is either ignored or treated as "Unknown-%d".
> (Furthermore it is possible to call av_strdup(NULL),
> although this is not documented to be legal.)
>
> This commit changes this by only returning the static strings
> in get_geokey_val(); the unknown handling and strdup'ing
> is moved out of it.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tiff.c | 35 ---
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index cb4d378753..4c7460cf41 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -36,6 +36,7 @@
> #include
>
> #include "libavutil/attributes.h"
> +#include "libavutil/avstring.h"
> #include "libavutil/error.h"
> #include "libavutil/intreadwrite.h"
> #include "libavutil/opt.h"
> @@ -179,19 +180,17 @@ static const char *search_keyval(const
> TiffGeoTagKeyName *keys, int n, int id)
> return NULL;
> }
>
> -static char *get_geokey_val(int key, int val)
> +static const char *get_geokey_val(int key, uint16_t val)
> {
> -char *ap;
> -
> if (val == TIFF_GEO_KEY_UNDEFINED)
> -return av_strdup("undefined");
> +return "undefined";
> if (val == TIFF_GEO_KEY_USER_DEFINED)
> -return av_strdup("User-Defined");
> +return "User-Defined";
>
> #define RET_GEOKEY_VAL(TYPE, array)\
> if (val >= TIFF_##TYPE##_OFFSET &&\
> val - TIFF_##TYPE##_OFFSET < FF_ARRAY_ELEMS(tiff_##array##_codes))\
> -return av_strdup(tiff_##array##_codes[val - TIFF_##TYPE##_OFFSET]);
> +return tiff_##array##_codes[val - TIFF_##TYPE##_OFFSET];
>
> switch (key) {
> case TIFF_GT_MODEL_TYPE_GEOKEY:
> @@ -224,13 +223,9 @@ static char *get_geokey_val(int key, int val)
> RET_GEOKEY_VAL(PRIME_MERIDIAN, prime_meridian);
> break;
> case TIFF_PROJECTED_CS_TYPE_GEOKEY:
> -ap = av_strdup(search_keyval(tiff_proj_cs_type_codes,
> FF_ARRAY_ELEMS(tiff_proj_cs_type_codes), val));
> -if(ap) return ap;
> -break;
> +return search_keyval(tiff_proj_cs_type_codes,
> FF_ARRAY_ELEMS(tiff_proj_cs_type_codes), val);
> case TIFF_PROJECTION_GEOKEY:
> -ap = av_strdup(search_keyval(tiff_projection_codes,
> FF_ARRAY_ELEMS(tiff_projection_codes), val));
> -if(ap) return ap;
> -break;
> +return search_keyval(tiff_projection_codes,
> FF_ARRAY_ELEMS(tiff_projection_codes), val);
> case TIFF_PROJ_COORD_TRANS_GEOKEY:
> RET_GEOKEY_VAL(COORD_TRANS, coord_trans);
> break;
> @@ -241,10 +236,7 @@ static char *get_geokey_val(int key, int val)
>
> }
>
> -ap = av_malloc(14);
> -if (ap)
> -snprintf(ap, 14, "Unknown-%d", val);
> -return ap;
> +return NULL;
> }
>
> static char *doubles2str(double *dp, int count, const char *sep)
> @@ -1634,9 +1626,14 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> *frame)
> s->geotags[i].type = ff_tget_short(&s->gb, s->le);
> s->geotags[i].count = ff_tget_short(&s->gb, s->le);
>
> -if (!s->geotags[i].type)
> -s->geotags[i].val = get_geokey_val(s->geotags[i].key,
> ff_tget_short(&s->gb, s->le));
> -else
> +if (!s->geotags[i].type) {
> +uint16_t val= ff_tget_short(&s->gb, s->le);
> +const char *str = get_geokey_val(s->geotags[i].key, val);
> +
> +s->geotags[i].val = str ? av_strdup(str) :
> av_asprintf("Unknown-%u", val);
> +if (!s->geotags[i].val)
> +return AVERROR(ENOMEM);
> +} else
> s->geotags[i].offset = ff_tget_short(&s->gb, s->le);
nit++: you migth factorize the ff_tget_short call
> }
> break;
LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] doc/bitstream_filters: add filter_units practical examples for removing closed captions
Thanks, Stefano, I agree it’s not ideal with just having magic numbers. If I think of a creative solution I'll let you know. Appreciate your time, On Sun, Mar 10, 2024 at 09:56 Stefano Sabatini wrote: > On date Saturday 2024-03-09 19:56:49 -0600, Marth64 wrote: > > 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 > > + > > Not against, but I'm not super convinced this is super useful as it > does not really explain what these values come from. Probably it > would be more useful a table, or even better make the parser somehow > expose the supported types with the meaning (this would enable having > e.g. a symbolic type "cc" abstracting the containter format). > > OTOH I agree thius would provide some practical examples, therefore > I'll apply while we have no smarter way to expose the logic in a more > effective way. > > 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/6] avcodec/tiff: Avoid duplicating strings
On date Sunday 2024-03-10 15:15:00 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tiff.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index 4c7460cf41..afa1289e27 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -2028,7 +2028,8 @@ again:
> av_log(avctx, AV_LOG_WARNING, "Type of GeoTIFF key %d is
> wrong\n", s->geotags[i].key);
> continue;
> }
> -ret = av_dict_set(&p->metadata, keyname, s->geotags[i].val, 0);
> +ret = av_dict_set(&p->metadata, keyname, s->geotags[i].val,
> AV_DICT_DONT_STRDUP_VAL);
> +s->geotags[i].val = NULL;
> if (ret<0) {
> av_log(avctx, AV_LOG_ERROR, "Writing metadata with key '%s'
> failed\n", keyname);
> return ret;
Should be OK, 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".
[FFmpeg-devel] [PATCH] doc/bitstream_filters.texi: Document types used by filter_units
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 61539d2473..3351625225 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -199,6 +199,13 @@ Identical to @option{pass_types}, except the units in the
given set
removed and all others passed through.
@end table
+The types used by pass_types and remove_types correspond to NAL unit types
+(nal_unit_type) in H.264, HEVC and H.266 (see Table 7-1 in the H.264
+specification and HEVC specifications or Table 5 for H.266), to
+marker values for JPEG (without 0xFF prefix), to start codes without
+start code prefix (i.e. the byte following the 0x01) for MPEG-2.
+For VP8 and VP9, every unit has type zero.
+
Extradata is unchanged by this transformation, but note that if the stream
contains inline parameter sets then the output may be unusable if they are
removed.
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/6] avcodec/tiff: Don't check before av_freep()
On date Sunday 2024-03-10 15:15:01 +0100, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/tiff.c | 7 ++- > 1 file changed, 2 insertions(+), 5 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 4/6] avcodec/tiff: Improve inclusions
On date Sunday 2024-03-10 15:15:02 +0100, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/mjpegdec.c | 1 - > libavcodec/tiff.c | 1 + > libavcodec/tiff.h | 3 --- > libavcodec/tiffenc.c | 3 +-- > 4 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c > index 43b36d0a8f..c9409eac6c 100644 > --- a/libavcodec/mjpegdec.c > +++ b/libavcodec/mjpegdec.c > @@ -52,7 +52,6 @@ > #include "jpeglsdec.h" > #include "profiles.h" > #include "put_bits.h" > -#include "tiff.h" > #include "exif.h" > #include "bytestream.h" > #include "tiff_common.h" > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c > index 5d350f4e7e..15e5edd93b 100644 > --- a/libavcodec/tiff.c > +++ b/libavcodec/tiff.c > @@ -48,6 +48,7 @@ > #include "faxcompr.h" > #include "lzw.h" > #include "tiff.h" > +#include "tiff_common.h" > #include "tiff_data.h" > #include "mjpegdec.h" > #include "thread.h" > diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h > index e67c59abad..2dd21dea52 100644 > --- a/libavcodec/tiff.h > +++ b/libavcodec/tiff.h > @@ -30,9 +30,6 @@ > #ifndef AVCODEC_TIFF_H > #define AVCODEC_TIFF_H > > -#include > -#include "tiff_common.h" why? there are cases where only tiff.h must be used? [...] ___ ffmpeg-devel mailing list ffmpeg-devel@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] doc/bitstream_filters.texi: Document types used by filter_units
On date Sunday 2024-03-10 16:34:23 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> doc/bitstream_filters.texi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 61539d2473..3351625225 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -199,6 +199,13 @@ Identical to @option{pass_types}, except the units in
> the given set
> removed and all others passed through.
> @end table
>
> +The types used by pass_types and remove_types correspond to NAL unit types
> +(nal_unit_type) in H.264, HEVC and H.266 (see Table 7-1 in the H.264
> +specification and HEVC specifications or Table 5 for H.266), to
> +marker values for JPEG (without 0xFF prefix), to start codes without
> +start code prefix (i.e. the byte following the 0x01) for MPEG-2.
> +For VP8 and VP9, every unit has type zero.
> +
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 4/6] avcodec/tiff: Improve inclusions
Stefano Sabatini: > On date Sunday 2024-03-10 15:15:02 +0100, Andreas Rheinhardt wrote: >> Signed-off-by: Andreas Rheinhardt >> --- >> libavcodec/mjpegdec.c | 1 - >> libavcodec/tiff.c | 1 + >> libavcodec/tiff.h | 3 --- >> libavcodec/tiffenc.c | 3 +-- >> 4 files changed, 2 insertions(+), 6 deletions(-) >> >> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c >> index 43b36d0a8f..c9409eac6c 100644 >> --- a/libavcodec/mjpegdec.c >> +++ b/libavcodec/mjpegdec.c >> @@ -52,7 +52,6 @@ >> #include "jpeglsdec.h" >> #include "profiles.h" >> #include "put_bits.h" >> -#include "tiff.h" >> #include "exif.h" >> #include "bytestream.h" >> #include "tiff_common.h" >> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c >> index 5d350f4e7e..15e5edd93b 100644 >> --- a/libavcodec/tiff.c >> +++ b/libavcodec/tiff.c >> @@ -48,6 +48,7 @@ >> #include "faxcompr.h" >> #include "lzw.h" >> #include "tiff.h" >> +#include "tiff_common.h" >> #include "tiff_data.h" >> #include "mjpegdec.h" >> #include "thread.h" >> diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h >> index e67c59abad..2dd21dea52 100644 >> --- a/libavcodec/tiff.h >> +++ b/libavcodec/tiff.h >> @@ -30,9 +30,6 @@ >> #ifndef AVCODEC_TIFF_H >> #define AVCODEC_TIFF_H >> >> -#include > >> -#include "tiff_common.h" > > why? there are cases where only tiff.h must be used? > Must? Like in most header matters, this is not a question of "must". tiff.h provides (mostly) TIFF related defines that are independent of any particular implementation, whereas tiff_common.h mostly provides auxiliary functions for decoder/parser (the encoder only uses type_sizes*). And not even all of these need it: faxcompr only needs tiff.h, not tiff_common.h and mjpegdec.c needs only tiff_common.h. - Andreas *: This array uses a weird value for strings; the encoder has a size table of its own with a different value at this position and uses type_sizes at only one place. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/bitstream_filters.texi: Document types used by filter_units
LGTM from a helpfulness standpoint. (Only chiming in as I just touched the
same area in a different thread).
Cheers,
On Sun, Mar 10, 2024 at 10:52 Stefano Sabatini wrote:
> On date Sunday 2024-03-10 16:34:23 +0100, Andreas Rheinhardt wrote:
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > doc/bitstream_filters.texi | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> > index 61539d2473..3351625225 100644
> > --- a/doc/bitstream_filters.texi
> > +++ b/doc/bitstream_filters.texi
> > @@ -199,6 +199,13 @@ Identical to @option{pass_types}, except the units
> in the given set
> > removed and all others passed through.
> > @end table
> >
> > +The types used by pass_types and remove_types correspond to NAL unit
> types
> > +(nal_unit_type) in H.264, HEVC and H.266 (see Table 7-1 in the H.264
> > +specification and HEVC specifications or Table 5 for H.266), to
> > +marker values for JPEG (without 0xFF prefix), to start codes without
> > +start code prefix (i.e. the byte following the 0x01) for MPEG-2.
> > +For VP8 and VP9, every unit has type zero.
> > +
>
> 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".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] configure: Remove av_restrict
All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1db3e0f0a3b7061be6be28d00c675a0.
Signed-off-by: Andreas Rheinhardt
---
Untested except via godbolt.
MSVC actually uses it for optimizations: https://godbolt.org/z/3EzPnff9T
Btw: The block about __declspec(restrict) was always unneeded
for FFmpeg due to 17fad33f81c7e9787fcdc17934fc1eee6c6aa4bf.
It came from Libav commit 17fad33f81c7e9787fcdc17934fc1eee6c6aa4bf.
configure| 16 -
libavcodec/aacpsdsp_template.c | 10 +--
libavcodec/binkdsp.c | 2 +-
libavcodec/binkdsp.h | 4 +-
libavcodec/dnxhdenc.c| 4 +-
libavcodec/dnxhdenc.h| 4 +-
libavcodec/dvdec.c | 2 +-
libavcodec/elbg.c| 6 +-
libavcodec/h264qpel_template.c | 82
libavcodec/idctdsp.c | 14 ++--
libavcodec/idctdsp.h | 12 ++--
libavcodec/loongarch/idctdsp_lasx.c | 6 +-
libavcodec/loongarch/idctdsp_loongarch.h | 6 +-
libavcodec/mips/idctdsp_mips.h | 12 ++--
libavcodec/mips/idctdsp_mmi.c| 6 +-
libavcodec/mips/idctdsp_msa.c| 6 +-
libavcodec/mips/me_cmp_mips.h| 2 +-
libavcodec/mips/pixblockdsp_mips.h | 6 +-
libavcodec/mips/pixblockdsp_mmi.c| 4 +-
libavcodec/mips/pixblockdsp_msa.c| 6 +-
libavcodec/mpegaudiodec_template.c | 2 +-
libavcodec/opus_pvq.c| 2 +-
libavcodec/pixblockdsp.c | 6 +-
libavcodec/pixblockdsp.h | 10 ++-
libavcodec/utils.c | 4 +-
libavfilter/af_firequalizer.c| 14 ++--
libavformat/rtpenc.h | 4 +-
libavformat/rtpenc_h261.c| 4 +-
libavformat/rtpenc_h263.c| 4 +-
libavutil/arm/float_dsp_init_vfp.c | 2 +-
libavutil/fixed_dsp.c| 2 +-
libavutil/fixed_dsp.h| 3 +-
libavutil/float_dsp.c| 2 +-
libavutil/float_dsp.h| 4 +-
libavutil/mips/float_dsp_mips.c | 2 +-
libavutil/x86/fixed_dsp_init.c | 2 +-
libavutil/x86/float_dsp_init.c | 2 +-
tests/checkasm/fixed_dsp.c | 2 +-
tests/checkasm/float_dsp.c | 2 +-
tests/checkasm/pixblockdsp.c | 2 +-
tests/checkasm/vorbisdsp.c | 2 +-
41 files changed, 130 insertions(+), 157 deletions(-)
diff --git a/configure b/configure
index 05f8283af9..660b8f57a6 100755
--- a/configure
+++ b/configure
@@ -6031,10 +6031,6 @@ extern_prefix=${sym%%ff_extern*}
! disabled inline_asm && check_inline_asm inline_asm '"" ::'
-for restrict_keyword in restrict __restrict__ __restrict ""; do
-test_code cc "" "char * $restrict_keyword p" && break
-done
-
check_cc pragma_deprecated "" '_Pragma("GCC diagnostic push") _Pragma("GCC
diagnostic ignored \"-Wdeprecated-declarations\"")'
# The global variable ensures the bits appear unchanged in the object file.
@@ -7541,17 +7537,6 @@ elif enabled_any msvc icl; then
fi
# msvcrt10 x64 incorrectly enables log2, only msvcrt12 (MSVC 2013) onwards
actually has log2.
check_cpp_condition log2 crtversion.h "_VC_CRT_MAJOR_VERSION >= 12"
-# The CRT headers contain __declspec(restrict) in a few places, but if
redefining
-# restrict, this might break. MSVC 2010 and 2012 fail with
__declspec(__restrict)
-# (as it ends up if the restrict redefine is done before including
stdlib.h), while
-# MSVC 2013 and newer can handle it fine.
-# If this declspec fails, force including stdlib.h before the restrict
redefinition
-# happens in config.h.
-if [ $restrict_keyword != restrict ]; then
-test_cc <= 190024218" ||
@@ -8089,7 +8074,6 @@ cat > $TMPH <
-#include "config.h"
-
typedef struct BinkDSPContext {
void (*idct_put)(uint8_t *dest/*align 8*/, int line_size, int32_t
*block/*align 16*/);
void (*idct_add)(uint8_t *dest/*align 8*/, int line_size, int32_t
*block/*align 16*/);
void (*scale_block)(const uint8_t src[64]/*align 8*/, uint8_t *dst/*align
8*/, int linesize);
-void (*add_pixels8)(uint8_t *av_restrict pixels, int16_t *block, int
line_size);
+void (*add_pixels8)(uint8_t *restrict pixels, int16_t *block, int
line_size);
} BinkDSPContext;
void ff_binkdsp_init(BinkDSPContext *c);
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index feb7a76636..2316083b54 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -78,7 +78,7 @@ static const AVClass dnxhd_class = {
.version= LIBAVUTIL_VERSION_INT,
};
-static void dnxhd_8bit_get_pixels_8x4_sym(int16_t *av_restrict block,
+static void dnxhd_8bit_get_pixels_8x4_sym(int16_t *restrict block,
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/8bps: Consider width in the minimal size check
On Mon, Feb 26, 2024 at 12:23:52AM +0100, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 64479/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EIGHTBPS_fuzzer-5434435386081280 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/8bps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. 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 2/2] avcodec/vorbisdec: Check remaining data in vorbis_residue_decode_internal()
On Tue, Feb 27, 2024 at 11:47:08PM +0100, Michael Niedermayer wrote: > Fixes: timeout > Fixes: > 66326/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VORBIS_fuzzer-629529186304 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/vorbisdec.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- 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] avcodec/proresenc_kostya: Remove bug similarity text
On Wed, Feb 28, 2024 at 09:08:34PM +0100, Michael Niedermayer wrote: > According to kostya, it is not based on Wassermans encoder > > CC: Kostya Shishkov > CC: Anatoliy Wasserman > > Signed-off-by: Michael Niedermayer > --- > libavcodec/proresenc_kostya.c | 3 --- > 1 file changed, 3 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mpegts: Reset local nb_prg on add_program() failure
add_program() will deallocate the whole array on failure so we must clear nb_prgs Fixes: null pointer dereference Fixes: crash-35a3b39ddcc5babeeb005b7399a3a1217c8781bc Found-by: Catena cyber Signed-off-by: Michael Niedermayer --- libavformat/mpegts.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index de7a3c8b45..320926248b 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -2605,7 +2605,8 @@ static void pat_cb(MpegTSFilter *filter, const uint8_t *section, int section_len FFSWAP(struct Program, ts->prg[nb_prg], ts->prg[prg_idx]); if (prg_idx >= nb_prg) nb_prg++; -} +} else +nb_prg = 0; } } ts->nb_prg = nb_prg; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: > 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. This is not mpeg4 specific, its just a new additional case that fails ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: IMHO ffmpeg should be able to select supported parameters if the user indicated thats what he wants We also do this with pixel formats and not fail and require the user to manually specify it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- 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] Fixes #10509
On 3/9/24 15:49, Poorva wrote: 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) Your editor appears to have stripped the newline at the end of the file. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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 2/2] avcodec: remove sonic lossy/lossless audio
On 2/29/24 20:13, Michael Niedermayer wrote: Every codec we develop is experimental and used by nobody then by nobody outside ffmpeg and if we dont allow this then we can never create a new codec. FFv1 would not exist if we could not have added it at ta time noone used it. FFv1 would not have become widely used if it was in someones personal repository and main FFmpeg did not support it thx This is true, but also the code hasn't been touched in more than ten years, which makes it a bit different than, say, ffv1 which was actively developed for a while and still is. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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 v2 3/3] avformat/dvdvideodec: add menu demuxing support
On 3/9/24 13:27, Marth64 wrote:
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 100
Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dvdvideodec: add menu demuxing support
Hi,
> Is 99 an actual limit here of DVDs or is it something you picked? You
> can always use INT_MAX if this is the latter case.
It is the actual limit (as are all of them to the best of my studying.)
> Is there any risk this will be called twice? If so, we should zero out
> state->vob_file after calling DVDCloseFile.
No risk AFAIK, unless for some reason callers close the overall format ctx
twice.
(Please let me know if you see one).
On Sun, Mar 10, 2024 at 2:53 PM Leo Izen wrote:
> On 3/9/24 13:27, Marth64 wrote:
> > 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}
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Michael Niedermayer (2024-03-10 20:21:47) > On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: > > 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. > > This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. > ./ffmpeg -i mm-small.mpg test.dv > [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid > DV profiles are: There is no mechanism for an encoder to export supported time bases. > IMHO ffmpeg should be able to select supported parameters if the user > indicated thats what he wants > > We also do this with pixel formats and not fail and require the user to > manually > specify it AFAIK only a tiny number of obsolete encoders place restrictions on the timebase, so I see little point in spending effort on making them work automagically. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On 3/10/2024 7:24 PM, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 20:21:47) On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: 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. This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: There is no mechanism for an encoder to export supported time bases. Could it be added as an extension to AVProfile, or AVCodec? IMHO ffmpeg should be able to select supported parameters if the user indicated thats what he wants We also do this with pixel formats and not fail and require the user to manually specify it AFAIK only a tiny number of obsolete encoders place restrictions on the timebase, so I see little point in spending effort on making them work automagically. ___ ffmpeg-devel mailing list ffmpeg-devel@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 James Almer (2024-03-10 23:29:27) > On 3/10/2024 7:24 PM, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-03-10 20:21:47) > >> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: > >>> 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. > >> > >> This is not mpeg4 specific, its just a new additional case that fails > > > > The case you reported is mpeg4 specific. > > > >> ./ffmpeg -i mm-small.mpg test.dv > >> [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. > >> Valid DV profiles are: > > > > There is no mechanism for an encoder to export supported time bases. > > Could it be added as an extension to AVProfile, or AVCodec? The two cases are actually pretty different: * mpeg4 has a constraint on the range of timebases, and actually does some perverted computations with the timestamps * DV just needs your video to be CFR, with a list of supported framerates; dvenc should probably read AVCodecContext.framerate instead of time_base But most importantly, is there an actual current use case for either of those encoders? They have both been obsolete for close to two decades. It seems silly to add new API that won't actually be useful to anyone. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On Fri, Mar 08, 2024 at 11:00:50AM -0300, 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. If issues are not blocking, then please remove the blokcing thing on trac or update it to a higher version thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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
On Sun, Mar 10, 2024 at 11:49:12PM +0100, Anton Khirnov wrote: > Quoting James Almer (2024-03-10 23:29:27) > > On 3/10/2024 7:24 PM, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-03-10 20:21:47) > > >> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: > > >>> 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. > > >> > > >> This is not mpeg4 specific, its just a new additional case that fails > > > > > > The case you reported is mpeg4 specific. > > > > > >> ./ffmpeg -i mm-small.mpg test.dv > > >> [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. > > >> Valid DV profiles are: > > > > > > There is no mechanism for an encoder to export supported time bases. > > > > Could it be added as an extension to AVProfile, or AVCodec? > > The two cases are actually pretty different: > * mpeg4 has a constraint on the range of timebases, and actually does > some perverted computations with the timestamps > * DV just needs your video to be CFR, with a list of supported > framerates; dvenc should probably read AVCodecContext.framerate > instead of time_base > > But most importantly, is there an actual current use case for either of > those encoders? They have both been obsolete for close to two decades. > It seems silly to add new API that won't actually be useful to anyone. iam not sugesting to add API specific to mpeg4, rather that maybe it can be done as part of some more generic solution 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".
[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: extract only one type of CC substream
In MPEG-2 user data, there can be different types of Closed Captions
formats embedded (A53, SCTE-20, or DVD). The current behavior of the
CC extraction code in the MPEG-2 decoder is to not be aware of
multiple formats if multiple exist, therefore allowing one format
to overwrite the other during the extraction process since the CC
extraction shares one output buffer for the normalized bytes.
This causes sources that have two CC formats to produce flawed output.
There exist real-world samples which contain both A53 and SCTE-20 captions
in the same MPEG-2 stream, and that manifest this problem. Example of symptom:
THANK YOU (expected) --> THTHANANK K YOYOUU (actual)
The solution is to pick only the first CC substream observed with valid bytes,
and ignore the other types. Additionally, provide an option for users
to manually "force" a type in the event that this matters for a particular
source.
In tandem, I am working on an improvement to src_movie to allow passing decoder
options (as src_movie via lavfi is the "de facto" way to extract CCs right now).
This way, users can realize the newly added option.
Signed-off-by: Marth64
---
libavcodec/mpeg12dec.c | 49 +++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 3a2f17e508..a42e1c661f 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -62,6 +62,13 @@
#define A53_MAX_CC_COUNT 2000
+enum Mpeg2ClosedCaptionsFormat {
+CC_FORMAT_AUTO,
+CC_FORMAT_A53_PART4,
+CC_FORMAT_SCTE20,
+CC_FORMAT_DVD
+};
+
typedef struct Mpeg1Context {
MpegEncContext mpeg_enc_ctx;
int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
@@ -70,6 +77,7 @@ typedef struct Mpeg1Context {
AVStereo3D stereo3d;
int has_stereo3d;
AVBufferRef *a53_buf_ref;
+enum Mpeg2ClosedCaptionsFormat cc_format;
uint8_t afd;
int has_afd;
int slice_count;
@@ -1908,7 +1916,8 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
{
Mpeg1Context *s1 = avctx->priv_data;
-if (buf_size >= 6 &&
+if ((!s1->cc_format || s1->cc_format == CC_FORMAT_A53_PART4) &&
+buf_size >= 6 &&
p[0] == 'G' && p[1] == 'A' && p[2] == '9' && p[3] == '4' &&
p[4] == 3 && (p[5] & 0x40)) {
/* extract A53 Part 4 CC data */
@@ -1927,9 +1936,15 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
memcpy(s1->a53_buf_ref->data + old_size, p + 7, cc_count *
UINT64_C(3));
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+
+if (!s1->cc_format) {
+s1->cc_format = CC_FORMAT_A53_PART4;
+av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is A53
format\n");
+}
}
return 1;
-} else if (buf_size >= 2 &&
+} else if ((!s1->cc_format || s1->cc_format == CC_FORMAT_SCTE20) &&
+ buf_size >= 2 &&
p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
/* extract SCTE-20 CC data */
GetBitContext gb;
@@ -1974,9 +1989,15 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
}
}
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+
+if (!s1->cc_format) {
+s1->cc_format = CC_FORMAT_SCTE20;
+av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is
SCTE-20 format\n");
+}
}
return 1;
-} else if (buf_size >= 11 &&
+} else if ((!s1->cc_format || s1->cc_format == CC_FORMAT_DVD) &&
+ buf_size >= 11 &&
p[0] == 'C' && p[1] == 'C' && p[2] == 0x01 && p[3] == 0xf8) {
/* extract DVD CC data
*
@@ -2034,6 +2055,11 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
}
}
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+
+if (!s1->cc_format) {
+s1->cc_format = CC_FORMAT_DVD;
+av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is DVD
format\n");
+}
}
return 1;
}
@@ -2598,11 +2624,28 @@ const FFCodec ff_mpeg1video_decoder = {
},
};
+#define M2V_OFFSET(x) offsetof(Mpeg1Context, x)
+#define M2V_PARAM AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+
+static const AVOption mpeg2video_options[] = {
+{ "cc_format", "extract a specific Closed Captions format (0=auto)",
M2V_OFFSET(cc_format), AV_OPT_TYPE_INT, { .i64 = 0 }, CC_FORMAT_AUTO,
CC_FORMAT_DVD, M2V_PARAM },
+{ NULL }
+};
+
+static const AVClass mpeg2video_class = {
+.class_name = "MPEG-2 video",
+.item_name = av_default_item_name,
+.option = mpeg2video_options,
+.version= LIBAVUTIL_VERSION_INT,
+.category = AV_CLASS_CATEGORY_DECODER,
+};
+
const FFCodec ff_mpeg2video_decoder = {
.p.name = "mpeg2video",
CODEC_LONG_NAME("M
[FFmpeg-devel] [PATCH] avcodec/ccaption_dec: don't print multiple \pos tags per cue
Currently, Closed Captions decoder prints multiple \pos ASS tags per line,
per cue. This is invalid behavior, because only the first \pos tag in a cue
is honored by ASS anyway. Don't write multiple \pos tags.
Signed-off-by: Marth64
---
libavcodec/ccaption_dec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index faf058ce97..9d4a93647c 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -456,7 +456,7 @@ static void roll_up(CCaptionSubContext *ctx)
static int capture_screen(CCaptionSubContext *ctx)
{
-int i, j, tab = 0;
+int i, j, tab = 0, seen_row = 0;
struct Screen *screen = ctx->screen + ctx->active_screen;
enum cc_font prev_font = CCFONT_REGULAR;
enum cc_color_code prev_color = CCCOL_WHITE;
@@ -496,7 +496,11 @@ static int capture_screen(CCaptionSubContext *ctx)
x = ASS_DEFAULT_PLAYRESX * (0.1 + 0.0250 * j);
y = ASS_DEFAULT_PLAYRESY * (0.1 + 0.0533 * i);
-av_bprintf(&ctx->buffer[bidx], "{\\an7}{\\pos(%d,%d)}", x, y);
+
+if (!seen_row) {
+av_bprintf(&ctx->buffer[bidx], "{\\an7}{\\pos(%d,%d)}", x, y);
+seen_row = 1;
+}
for (; j < SCREEN_COLUMNS; j++) {
const char *e_tag = "", *s_tag = "", *c_tag = "", *b_tag = "";
--
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] avcodec/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.
v2 only updates the commit message which mistakenly referenced avformat.
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] [PATCH v1 1/2] lavc/vvcdec: Add missed chroma sampling factor for crop offset
On Sat, 2024-03-09 at 19:57 +0800, Nuo Mi wrote: Thank you, Fei, Do you happen to know why the following clips are still failing? CROP_A_Panasonic_4.bit Ffmepg decode doesn't apply crop strictly. It will adjust crop for alignment, see av_frame_apply_cropping(). Thanks Fei 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 mailto:fei.w.wang-at-intel@ffmpeg.org>> wrote: From: Fei Wang mailto:fei.w.w...@intel.com>> Signed-off-by: Fei Wang mailto:fei.w.w...@intel.com>> --- 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) ___ ffmpeg-devel mailing list ffmpeg-devel@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/2] lavc/vvcdec: Add missed chroma sampling factor for crop offset
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] [PATCH v2 2/2] lavc/vvc_ps: Correct NoOutputBeforeRecoveryFlag of IDR
From: Fei Wang
The NoOutputBeforeRecoveryFlag of an IDR frame should be set to 1 as
spec says in 8.1.1.
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".
Re: [FFmpeg-devel] [PATCH v1 2/2] lavc/vvc_ps: Correct NoOutputBeforeRecoveryFlag of IDR
On Sat, 2024-03-09 at 19:59 +0800, Nuo Mi wrote:
Hi Fei,
Thank you fei,
Better provide more comments
Added in V2.
Is there any clip fail for this?
No, just notice the defect when I check why recovering frames been outputted in
GDR_D_ERICSSON_1.bit.
Thanks
Fei
On Fri, Mar 8, 2024 at 8:55 AM
mailto:fei.w.wang-at-intel@ffmpeg.org>>
wrote:
From: Fei Wang mailto:fei.w.w...@intel.com>>
Signed-off-by: Fei Wang mailto:fei.w.w...@intel.com>>
---
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;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@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] When the silencedetect filter is run against long files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the output is
From: "Allan Cady"
I propose changing the format to "%.6f", which will
give microsecond precision for all timestamps, regardless of
offset. Trailing zeros can be trimmed from the fraction, without
losing precision. If the length of the fixed-precision formatted
timestamp exceeds the length of the allocated buffer
(AV_TS_MAX_STRING_SIZE, currently 32, less one for the
terminating null), then we can fall back to scientific notation, though
this seems almost certain to never occur, because 32 characters would
allow a maximum timestamp value of (32 - 1 - 6 - 1) = 24 characters.
By my calculation, 10^24 seconds is about six orders of magnitude
greater than the age of the universe.
The fix proposed here follows the following logic:
1) Try formatting the number of seconds using "%.6f". This will
always result in a string with six decimal digits in the fraction,
possibly including trailing zeros. (e.g. "897234.73200").
2) Check if that string would overflow the buffer. If it would, then
format it using scientific notation ("%.8g").
3) If the original fixed-point format fits, then trim any trailing
zeros and decimal point, and return that result.
Making this change broke two fate tests, filter-metadata-scdet,
and filter-metadata-silencedetect. To correct this, I've modified
tests/ref/fate/filter-metadata-scdet and
tests/ref/fate/filter-metadata-silencedetect to match the
new output.
Signed-off-by: Allan Cady
---
libavutil/timestamp.h| 53 +++-
tests/ref/fate/filter-metadata-scdet | 12 ++---
tests/ref/fate/filter-metadata-silencedetect | 2 +-
3 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index 2b37781eba..2f04f9bb2b 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -25,6 +25,7 @@
#define AVUTIL_TIMESTAMP_H
#include "avutil.h"
+#include
#if defined(__cplusplus) && !defined(__STDC_FORMAT_MACROS) && !defined(PRId64)
#error missing -D__STDC_FORMAT_MACROS / #define __STDC_FORMAT_MACROS
@@ -53,6 +54,32 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
*/
#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts)
+/**
+ * Strip trailing zeros and decimal point from a string. Performed
+ * in-place on input buffer. For local use only by av_ts_make_time_string.
+ *
+ * e.g.:
+ * "752.378000" -> "752.378"
+ *"4.0" -> "4"
+ * "97300" -> "97300"
+ */
+static inline void av_ts_strip_trailing_zeros_and_decimal_point(char *str) {
+if (strchr(str, '.'))
+{
+int i;
+for (i = strlen(str) - 1; i >= 0 && str[i] == '0'; i--) {
+str[i] = '\0';
+}
+
+// Remove decimal point if it's the last character
+if (i >= 0 && str[i] == '.') {
+str[i] = '\0';
+}
+
+// String was modified in place; no need for return value.
+}
+}
+
/**
* Fill the provided buffer with a string containing a timestamp time
* representation.
@@ -65,8 +92,30 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
static inline char *av_ts_make_time_string(char *buf, int64_t ts,
const AVRational *tb)
{
-if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
-else snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g",
av_q2d(*tb) * ts);
+if (ts == AV_NOPTS_VALUE)
+{
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+}
+else
+{
+const int max_fraction_digits = 6;
+
+// Convert 64-bit timestamp to double, using rational timebase
+double seconds = av_q2d(*tb) * ts;
+
+int length = snprintf(NULL, 0, "%.*f", max_fraction_digits, seconds);
+if (length <= AV_TS_MAX_STRING_SIZE - 1)
+{
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", max_fraction_digits,
seconds);
+av_ts_strip_trailing_zeros_and_decimal_point(buf);
+}
+else
+{
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.8g", seconds);
+}
+
+}
+
return buf;
}
diff --git a/tests/ref/fate/filter-metadata-scdet
b/tests/ref/fate/filter-metadata-scdet
index ca5dbaaefc..d385920fcd 100644
--- a/tests/ref/fate/filter-metadata-scdet
+++ b/tests/ref/fate/filter-metadata-scdet
@@ -1,11 +1,11 @@
pts=1620|tag:lavfi.scd.score=59.252|tag:lavfi.scd.mafd=60.175|tag:lavfi.scd.time=2.7
pts=4140|tag:lavfi.scd.score=36.070|tag:lavfi.scd.mafd=44.209|tag:lavfi.scd.time=6.9
-pts=5800|tag:lavfi.scd.score=55.819|tag:lavfi.scd.mafd=55.819|tag:lavfi.scd.time=9.7
+pts=5800|tag:lavfi.scd.score=55.819|tag:lavfi.scd.mafd=55.819|tag:lavfi.scd.time=9.67
pts=6720|tag:lavfi.scd.score=18.580|tag:lavfi.scd.mafd=22.505|tag:lavfi.scd.time=11.2
pts=8160|tag:lavfi.scd.score=49.240|tag:lavfi.scd.mafd=49.444|tag:lavfi.scd.time=13.6
-pts=9760|tag:lavfi.scd.score=51.497|tag:lavfi.scd.mafd=51.801|tag:lavfi.scd.time=16.2667
-p
[FFmpeg-devel] [PATCH] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files
When the silencedetect filter is run against long files, the output
timestamps gradually lose precision as the scan proceeds further into
the file. This is because the output is formatted (in
libavutil/timestamp.h) as "%.6g", which limits the total field
length. Eventually, for offsets greater than 10 seconds (about 28
hours), fractions of a second disappear altogether, and the
timestamps are logged as whole seconds.
I propose changing the format to "%.6f", which will
give microsecond precision for all timestamps, regardless of
offset. Trailing zeros can be trimmed from the fraction, without
losing precision. If the length of the fixed-precision formatted
timestamp exceeds the length of the allocated buffer
(AV_TS_MAX_STRING_SIZE, currently 32, less one for the
terminating null), then we can fall back to scientific notation, though
this seems almost certain to never occur, because 32 characters would
allow a maximum timestamp value of (32 - 1 - 6 - 1) = 24 characters.
By my calculation, 10^24 seconds is about six orders of magnitude
greater than the age of the universe.
The fix proposed here follows the following logic:
1) Try formatting the number of seconds using "%.6f". This will
always result in a string with six decimal digits in the fraction,
possibly including trailing zeros. (e.g. "897234.73200").
2) Check if that string would overflow the buffer. If it would, then
format it using scientific notation ("%.8g").
3) If the original fixed-point format fits, then trim any trailing
zeros and decimal point, and return that result.
Making this change broke two fate tests, filter-metadata-scdet,
and filter-metadata-silencedetect. To correct this, I've modified
tests/ref/fate/filter-metadata-scdet and
tests/ref/fate/filter-metadata-silencedetect to match the
new output.
Signed-off-by: Allan Cady
---
libavutil/timestamp.h| 53 +++-
tests/ref/fate/filter-metadata-scdet | 12 ++---
tests/ref/fate/filter-metadata-silencedetect | 2 +-
3 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index 2b37781eba..2f04f9bb2b 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -25,6 +25,7 @@
#define AVUTIL_TIMESTAMP_H
#include "avutil.h"
+#include
#if defined(__cplusplus) && !defined(__STDC_FORMAT_MACROS) && !defined(PRId64)
#error missing -D__STDC_FORMAT_MACROS / #define __STDC_FORMAT_MACROS
@@ -53,6 +54,32 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
*/
#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts)
+/**
+ * Strip trailing zeros and decimal point from a string. Performed
+ * in-place on input buffer. For local use only by av_ts_make_time_string.
+ *
+ * e.g.:
+ * "752.378000" -> "752.378"
+ *"4.0" -> "4"
+ * "97300" -> "97300"
+ */
+static inline void av_ts_strip_trailing_zeros_and_decimal_point(char *str) {
+if (strchr(str, '.'))
+{
+int i;
+for (i = strlen(str) - 1; i >= 0 && str[i] == '0'; i--) {
+str[i] = '\0';
+}
+
+// Remove decimal point if it's the last character
+if (i >= 0 && str[i] == '.') {
+str[i] = '\0';
+}
+
+// String was modified in place; no need for return value.
+}
+}
+
/**
* Fill the provided buffer with a string containing a timestamp time
* representation.
@@ -65,8 +92,30 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
static inline char *av_ts_make_time_string(char *buf, int64_t ts,
const AVRational *tb)
{
-if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
-else snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g",
av_q2d(*tb) * ts);
+if (ts == AV_NOPTS_VALUE)
+{
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+}
+else
+{
+const int max_fraction_digits = 6;
+
+// Convert 64-bit timestamp to double, using rational timebase
+double seconds = av_q2d(*tb) * ts;
+
+int length = snprintf(NULL, 0, "%.*f", max_fraction_digits, seconds);
+if (length <= AV_TS_MAX_STRING_SIZE - 1)
+{
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", max_fraction_digits,
seconds);
+av_ts_strip_trailing_zeros_and_decimal_point(buf);
+}
+else
+{
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.8g", seconds);
+}
+
+}
+
return buf;
}
diff --git a/tests/ref/fate/filter-metadata-scdet
b/tests/ref/fate/filter-metadata-scdet
index ca5dbaaefc..d385920fcd 100644
--- a/tests/ref/fate/filter-metadata-scdet
+++ b/tests/ref/fate/filter-metadata-scdet
@@ -1,11 +1,11 @@
pts=1620|tag:lavfi.scd.score=59.252|tag:lavfi.scd.mafd=60.175|tag:lavfi.scd.time=2.7
pts=4140|tag:lavfi.scd.score=36.070|tag:lavfi.scd.mafd=44.209|tag:lavfi.scd.time=6.9
-pts=5800|tag:lavfi.scd.score=55.819|tag:lav
Re: [FFmpeg-devel] [PATCH] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files
Greetings Martin et al, I've been trying to resubmit this patch based on your earlier suggestions. Most of the tools in the toolchain for this are new to me, so it's been awkward going. I did finally get the email sent with the new patch, but for some reason I haven't been able to figure out yet, it's going to the wrong thread. Here's the link to the message with the patch. https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/323170.html Looking forward to comments and to hopefully getting this approved and into the codebase. Allan On Friday, February 23, 2024 at 02:47:27 PM PST, Marton Balint wrote: On Fri, 23 Feb 2024, Allan Cady via ffmpeg-devel wrote: > [Apologies for the awful mess in the previous email. Trying again with > straight text.] > > On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint > wrote: > >>> For starters, I'm curious why there are two functions & macros: >>> >>> av_ts2str/av_ts_make_string (which used "%" format specifier) >> >> That takes a 64-bit integer timestamp and is actually using "%"PRId64 >> because that is the correct (portable) format string for an int64_t >> variable. >> >>> av_ts2timestr/av_ts_make_time_string (which used "%6g") >> >> That takes an integer timestamp and a rational time base. Float timestamps >> (in seconds) is calculated by multiplying the two, that is what is >> printed. >> >>> >>> Do you know the rationale for that? I see that only av_ts2timestr is used >>> in silencedetect.c. >>> >>> And are you suggesting we should fold those two functions into one? >> >> No, they have different purpose. The first prints out a timestamps which >> can be in any time base. The second prints out a timestamp in seconds. > > > Understood, I think I'm up to speed now. av_ts2str prints a 64-bit integer > timestamp; > av_ts2timestr prints a floating point timestamp in seconds with the timebase > applied. > > > In your previous email, you said: > > >> I'd rather just to fix av_ts_make_string to not limit the number of >> significant digits. Something like: >> >> 1) Print the number in decimal notation with at most 6 fractional digits. >> 2) Use less fractional digits if the first format would not fit into >> AV_TS_MAX_STRING_SIZE. >> 3) Use scientific notation if the second format would not fit into >> AV_TS_MAX_STRINT_SIZE. > > > I think you probably meant to say "I'd rather just to fix > av_ts_make_time_string" (not av_ts_make_string)? > Since it's av_ts_make_time_string() that's formatting floating point. Yes, indeed. > > So it makes sense to me to make the change to av_ts_make_time_string() > for all timestamps, as you suggest. As for how specifically to format them, > I'm fine with whatever you think is best, and I'm happy to work on this, but > the > implementation has me a bit stumped for the moment, and I may need some > help with it. My C language skills are rusty to say the least. The simplest way is to try snprintf() with 6 fractional digits, and check the return value to see how long the string would become. Based on this you can either accept snprintf result and truncate trailing zeros and dots, or try snprintf() with less fractional digits and truncate, or fall back to scientific format. > > It also occurs to me to wonder, would this warrant a formal problem ticket? > I haven't looked into how that works for ffmpeg. Opening a ticket for the problem is not required, but if your patch fixes an existing ticket, then you should mention the ticket number in the commit message. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavc/qsvdec: Do not print warning when draining cached frames
From: Haihao Xiang
When all cached frames are drained, the output mfxSyncPoint pointer is
NULL and MFX_ERR_MORE_DATA is returned, hence needn't print warning for
this expected behavior, otherwise the user might think the output from
qsv decoders are wrong.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvdec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 4f39f6942a..fd9267c6f4 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -762,7 +762,9 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
if (!*sync && !bs.DataOffset) {
bs.DataOffset = avpkt->size;
++q->zero_consume_run;
-if (q->zero_consume_run > 1)
+if (q->zero_consume_run > 1 &&
+(avpkt->size ||
+ret != MFX_ERR_MORE_DATA))
ff_qsv_print_warning(avctx, ret, "A decode call did not consume
any data");
} else {
q->zero_consume_run = 0;
--
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] lavu/hwcontext_qsv: Join the download/upload session to the main session
From: Haihao Xiang
This may reduce the number of internal threads when using hwupload or
hwdownload filter.
Signed-off-by: Haihao Xiang
---
libavutil/hwcontext_qsv.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 378cd5e826..e5e043d2d1 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -55,6 +55,10 @@
(MFX_VERSION_MAJOR > (MAJOR) || \
MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
+#define QSV_RUNTIME_VERSION_ATLEAST(MFX_VERSION, MAJOR, MINOR) \
+((MFX_VERSION.Major > (MAJOR)) || \
+ (MFX_VERSION.Major == (MAJOR) && MFX_VERSION.Minor >= (MINOR)))
+
#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
#define QSV_ONEVPL QSV_VERSION_ATLEAST(2, 0)
#define QSV_HAVE_OPAQUE !QSV_ONEVPL
@@ -1136,6 +1140,17 @@ static int qsv_init_internal_session(AVHWFramesContext
*ctx,
int ret = AVERROR_UNKNOWN;
/* hwctx->loader is non-NULL for oneVPL user and NULL for non-oneVPL user
*/
void **loader = &hwctx->loader;
+mfxSession parent_session = hwctx->session;
+mfxIMPL impl;
+mfxVersion ver;
+
+err = MFXQueryIMPL(parent_session, &impl);
+if (err == MFX_ERR_NONE)
+err = MFXQueryVersion(parent_session, &ver);
+if (err != MFX_ERR_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Error querying the session attributes.\n");
+return AVERROR_UNKNOWN;
+}
#if QSV_HAVE_OPAQUE
QSVFramesContext *s = ctx->hwctx;
@@ -1156,6 +1171,15 @@ static int qsv_init_internal_session(AVHWFramesContext
*ctx,
}
}
+if (QSV_RUNTIME_VERSION_ATLEAST(ver, 1, 25)) {
+err = MFXJoinSession(parent_session, *session);
+if (err != MFX_ERR_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Error joining session.\n");
+ret = AVERROR_UNKNOWN;
+goto fail;
+}
+}
+
if (!opaque) {
err = MFXVideoCORE_SetFrameAllocator(*session, &frame_allocator);
if (err != MFX_ERR_NONE) {
--
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 v5] libavfi/dnn: add LibTorch as one of DNN backend
From: Wenbin Chen
PyTorch is an open source machine learning framework that accelerates
the path from research prototyping to production deployment. Official
website: https://pytorch.org/. We call the C++ library of PyTorch as
LibTorch, the same below.
To build FFmpeg with LibTorch, please take following steps as reference:
1. download LibTorch C++ library in https://pytorch.org/get-started/locally/,
please select C++/Java for language, and other options as your need.
Please download cxx11 ABI version (libtorch-cxx11-abi-shared-with-deps-*.zip).
2. unzip the file to your own dir, with command
unzip libtorch-shared-with-deps-latest.zip -d your_dir
3. export libtorch_root/libtorch/include and
libtorch_root/libtorch/include/torch/csrc/api/include to $PATH
export libtorch_root/libtorch/lib/ to $LD_LIBRARY_PATH
4. config FFmpeg with ../configure --enable-libtorch
--extra-cflag=-I/libtorch_root/libtorch/include
--extra-cflag=-I/libtorch_root/libtorch/include/torch/csrc/api/include
--extra-ldflags=-L/libtorch_root/libtorch/lib/
5. make
To run FFmpeg DNN inference with LibTorch backend:
./ffmpeg -i input.jpg -vf
dnn_processing=dnn_backend=torch:model=LibTorch_model.pt -y output.jpg
The LibTorch_model.pt can be generated by Python with torch.jit.script() api.
Please note, torch.jit.trace() is not recommanded, since it does not support
ambiguous input size.
Signed-off-by: Ting Fu
Signed-off-by: Wenbin Chen
---
configure | 5 +-
libavfilter/dnn/Makefile | 1 +
libavfilter/dnn/dnn_backend_torch.cpp | 597 ++
libavfilter/dnn/dnn_interface.c | 5 +
libavfilter/dnn_filter_common.c | 15 +-
libavfilter/dnn_interface.h | 2 +-
libavfilter/vf_dnn_processing.c | 3 +
7 files changed, 624 insertions(+), 4 deletions(-)
create mode 100644 libavfilter/dnn/dnn_backend_torch.cpp
diff --git a/configure b/configure
index 05f8283af9..3584728464 100755
--- a/configure
+++ b/configure
@@ -281,6 +281,7 @@ External library support:
--enable-libtheora enable Theora encoding via libtheora [no]
--enable-libtls enable LibreSSL (via libtls), needed for https
support
if openssl, gnutls or mbedtls is not used [no]
+ --enable-libtorchenable Torch as one DNN backend [no]
--enable-libtwolame enable MP2 encoding via libtwolame [no]
--enable-libuavs3d enable AVS3 decoding via libuavs3d [no]
--enable-libv4l2 enable libv4l2/v4l-utils [no]
@@ -1905,6 +1906,7 @@ EXTERNAL_LIBRARY_LIST="
libtensorflow
libtesseract
libtheora
+libtorch
libtwolame
libuavs3d
libv4l2
@@ -2785,7 +2787,7 @@ cbs_vp9_select="cbs"
deflate_wrapper_deps="zlib"
dirac_parse_select="golomb"
dovi_rpu_select="golomb"
-dnn_suggest="libtensorflow libopenvino"
+dnn_suggest="libtensorflow libopenvino libtorch"
dnn_deps="avformat swscale"
error_resilience_select="me_cmp"
evcparse_select="golomb"
@@ -6886,6 +6888,7 @@ enabled libtensorflow && require libtensorflow
tensorflow/c/c_api.h TF_Versi
enabled libtesseract && require_pkg_config libtesseract tesseract
tesseract/capi.h TessBaseAPICreate
enabled libtheora && require libtheora theora/theoraenc.h th_info_init
-ltheoraenc -ltheoradec -logg
enabled libtls&& require_pkg_config libtls libtls tls.h
tls_configure
+enabled libtorch && check_cxxflags -std=c++17 && require_cpp libtorch
torch/torch.h "torch::Tensor" -ltorch -lc10 -ltorch_cpu -lstdc++ -lpthread
enabled libtwolame&& require libtwolame twolame.h twolame_init
-ltwolame &&
{ check_lib libtwolame twolame.h
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and
version must be >= 0.3.10"; }
diff --git a/libavfilter/dnn/Makefile b/libavfilter/dnn/Makefile
index 5d5697ea42..3d09927c98 100644
--- a/libavfilter/dnn/Makefile
+++ b/libavfilter/dnn/Makefile
@@ -6,5 +6,6 @@ OBJS-$(CONFIG_DNN) +=
dnn/dnn_backend_common.o
DNN-OBJS-$(CONFIG_LIBTENSORFLOW) += dnn/dnn_backend_tf.o
DNN-OBJS-$(CONFIG_LIBOPENVINO) += dnn/dnn_backend_openvino.o
+DNN-OBJS-$(CONFIG_LIBTORCH) += dnn/dnn_backend_torch.o
OBJS-$(CONFIG_DNN) += $(DNN-OBJS-yes)
diff --git a/libavfilter/dnn/dnn_backend_torch.cpp
b/libavfilter/dnn/dnn_backend_torch.cpp
new file mode 100644
index 00..54d3b309a1
--- /dev/null
+++ b/libavfilter/dnn/dnn_backend_torch.cpp
@@ -0,0 +1,597 @@
+/*
+ * Copyright (c) 2024
+ *
+ * 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
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Michael Niedermayer (2024-03-11 00:37:07) > > > >>> 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. > > > >> > > > >> This is not mpeg4 specific, its just a new additional case that fails > > > > > > > > The case you reported is mpeg4 specific. > > > > > > > >> ./ffmpeg -i mm-small.mpg test.dv > > > >> [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p > > > >> video. Valid DV profiles are: > > > > > > > > There is no mechanism for an encoder to export supported time bases. > > > > > > Could it be added as an extension to AVProfile, or AVCodec? > > > > The two cases are actually pretty different: > > * mpeg4 has a constraint on the range of timebases, and actually does > > some perverted computations with the timestamps > > * DV just needs your video to be CFR, with a list of supported > > framerates; dvenc should probably read AVCodecContext.framerate > > instead of time_base > > > > But most importantly, is there an actual current use case for either of > > those encoders? They have both been obsolete for close to two decades. > > It seems silly to add new API that won't actually be useful to anyone. > > iam not sugesting to add API specific to mpeg4, rather that maybe > it can be done as part of some more generic solution What kind of a solution? As I said above, I don't know of any other encoders that have similar constraints. -- 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".
