Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

[Tomas Härdin]

fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez:
> Before this patch, the FFmpeg MXF parser correctly detects content
> with 
> 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg JPEG
> 2000 decoder reads the JPEG 2000 SIZ header without understanding
> that 
> the indicated height is the height of 1 field only so overwrites the 
> frame size info with e.g. 720x243, and also completely discards the 
> second frame, which lead to the decoding of only half of the stored 
> content as "progressive" 720x243 flagged interlaced.

Is the decoder really the right place to do this? Surely this happens
with more codecs than just j2k. Isnt it also a parser's job to do this
kind of stuff?

The logic that scans the packet for two SOI markers shouldn't be
necessary if the relevant information is carried over from the MXF
demuxer. It also makes the j2k decoder harder to ||ize. You might also
need the StoredF2Offset

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@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/5] avutil/channel_layout: add av_channel_layout_retype()

[Anton Khirnov]

Quoting James Almer (2024-02-02 13:56:31)
> I wrote a function like this some time ago, but i lost the patch by 
> accident during a migration.
> 
> The way i approached it was making the return codes reflect if the 
> conversion was lossless or not, as in, custom -> native is lossless only 
> if channels have no custom names (and possible only if the ids are 
> within UINT64_MAX and in order).

> Anything to Unspec is always lossy, etc.

Unless the source is custom with every channel unknown.

> Custom -> Ambi: Possible only if it contains ambi channels. Lossless.
> Custom -> Native: Possible only if has no ambi channels and all ids < 64 
> and in order. Lossy if it has custom names, otherwise lossless.
> Ambi -> Custom: Lossless.
> Ambi -> Native: Not possible.
> Native -> Custom: Lossless.
> Native -> Ambi: Not possible.
> Any -> Unspec: Possible but lossy.
> 
> So 0 for lossless, 1 for lossy, ENOSYS for not possible.

That sounds good to me.

Might also have a flags argument that forces lossless, and for future
extensions.

-- 
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] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

[Jerome Martinez]

On 03/02/2024 11:00, Tomas Härdin wrote:

fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez:

Before this patch, the FFmpeg MXF parser correctly detects content
with
2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg JPEG
2000 decoder reads the JPEG 2000 SIZ header without understanding
that
the indicated height is the height of 1 field only so overwrites the
frame size info with e.g. 720x243, and also completely discards the
second frame, which lead to the decoding of only half of the stored
content as "progressive" 720x243 flagged interlaced.

Is the decoder really the right place to do this? Surely this happens
with more codecs than just j2k. Isnt it also a parser's job to do this
kind of stuff?


Both solutions have pro and con:
- Doing it in the decoder fixes the issue for all containers and only 
one codec

- Doing it in the demuxer fixes the issue for one container and all codecs
And currently I know only one container and only one codec having this 
issue.


My choice to implement in the decoder comes from the idea that it seems 
more hacky to decode 2 AVPackets (crafted from a single MXF packet), 
then do a RAM copy of the decoded (so huge) content for interleaving 
fields into 1 frame (pressure on RAM bandwidth) in the MXF demuxer + 
adapt frame metadata (height is overwritten by the decoder then need to 
overwrite again the value), doing it in the decoder seems less intrusive.


If moving to the demuxer is the only acceptable solution, I will do it 
but I would like to be sure that there is a consensus on that by FFmpeg 
developers before doing it, in order to not have this extra work 
rejected due to a future disagreement about where it should go.



The logic that scans the packet for two SOI markers shouldn't be
necessary if the relevant information is carried over from the MXF
demuxer.


As far as I know there is nothing in the MXF file saying where is the 
second field in the packet, at which MXF metadata do you think?




  It also makes the j2k decoder harder to ||ize. You might also
need the StoredF2Offset


I don't change the field order detection by current FFmpeg code, I rely 
on FFmpeg code directly.
In my opinion if MXF field order detection needs to be changed, it would 
be in a separate patch dedicated to that (the field order detection in 
MXF) and it does not impact this patch as it is independent from which 
container is used, using AVCodecContext field order information. Jérôme

___
ffmpeg-devel mailing list
ffmpeg-devel@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/vvcdec: fix seeking for open GOP

[Nuo Mi]

how to reproduce:
wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
vvencapp --input students_cif.y4m --preset faster --output students.266
MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4
ffplay testudents.mp4
---
 libavcodec/vvc/vvc_refs.c | 6 ++
 libavcodec/vvc/vvc_refs.h | 1 +
 libavcodec/vvc/vvcdec.c   | 6 ++
 3 files changed, 13 insertions(+)

diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c
index bf503e429e..e1895d1cca 100644
--- a/libavcodec/vvc/vvc_refs.c
+++ b/libavcodec/vvc/vvc_refs.c
@@ -80,6 +80,12 @@ void ff_vvc_clear_refs(VVCFrameContext *fc)
 VVC_FRAME_FLAG_SHORT_REF | VVC_FRAME_FLAG_LONG_REF);
 }
 
+void ff_vvc_flush_dpb(VVCFrameContext *fc)
+{
+for (int i = 0; i < FF_ARRAY_ELEMS(fc->DPB); i++)
+ff_vvc_unref_frame(fc, &fc->DPB[i], ~0);
+}
+
 static void free_progress(FFRefStructOpaque unused, void *obj)
 {
 FrameProgress *p = (FrameProgress *)obj;
diff --git a/libavcodec/vvc/vvc_refs.h b/libavcodec/vvc/vvc_refs.h
index cd3b5f5632..eba4422fb4 100644
--- a/libavcodec/vvc/vvc_refs.h
+++ b/libavcodec/vvc/vvc_refs.h
@@ -33,6 +33,7 @@ int ff_vvc_frame_rpl(VVCContext *s, VVCFrameContext *fc, 
SliceContext *sc);
 int ff_vvc_slice_rpl(VVCContext *s, VVCFrameContext *fc, SliceContext *sc);
 void ff_vvc_unref_frame(VVCFrameContext *fc, VVCFrame *frame, int flags);
 void ff_vvc_clear_refs(VVCFrameContext *fc);
+void ff_vvc_flush_dpb(VVCFrameContext *fc);
 
 typedef enum VVCProgress {
 VVC_PROGRESS_MV,
diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
index 83ee472ce6..1a050600eb 100644
--- a/libavcodec/vvc/vvcdec.c
+++ b/libavcodec/vvc/vvcdec.c
@@ -922,9 +922,15 @@ static av_cold void vvc_decode_flush(AVCodecContext *avctx)
 {
 VVCContext *s  = avctx->priv_data;
 int got_output = 0;
+VVCFrameContext *last;
 
 while (s->nb_delayed)
 wait_delayed_frame(s, NULL, &got_output);
+
+last = get_frame_context(s, s->fcs, s->nb_frames - 1);
+ff_vvc_flush_dpb(last);
+
+s->eos = 1;
 }
 
 static av_cold int vvc_decode_free(AVCodecContext *avctx)
-- 
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 v2 1/1] avfilter/vf_vpp_qsv: apply 3D LUT from file.

[Chen Yufei]

On Tue, Jan 30, 2024 at 10:59 AM Chen Yufei  wrote:
>
> On Tue, Jan 30, 2024 at 1:07 AM Anton Khirnov  wrote:
> >
> > Quoting Chen Yufei (2024-01-29 04:01:51)
> > > On Sun, Jan 28, 2024 at 10:10 PM Anton Khirnov  wrote:
> > > >
> > > > Quoting Zhao Zhili (2024-01-28 14:51:58)
> > > > >
> > > > >
> > > > > > On Jan 28, 2024, at 18:31, Anton Khirnov  wrote:
> > > > > >
> > > > > > Quoting Chen Yufei (2024-01-25 17:16:46)
> > > > > >> On Wed, Jan 24, 2024 at 7:39 PM Anton Khirnov  
> > > > > >> wrote:
> > > > > >>>
> > > > > >>> Quoting Chen Yufei (2024-01-20 16:14:29)
> > > > >  Usage: "vpp_qsv=lut3d_file="
> > > > > >>>
> > > > > >>> Passing file paths to a filter and having the filter load the 
> > > > > >>> file is
> > > > > >>> not recommended, it is generally preferable to have an
> > > > > >>> AV_OPT_TYPE_BINARY option, with IO performed by the caller.
> > >
> > > "is not recommended, it is generally preferable"
> > > I take this as using `AV_OPT_TYPE_BINARY` is not a MUST.
> > >
> > > I'm not an English native speaker, correct me If I'm wrong.
> > >
> > > > > >>>
> > > > > >>> E.g. in ffmpeg CLI you can do
> > > > > >>> -filter vpp_qsv=/lut3d=
> > > > > >>> to load the option value from a file.
> > > > > >>
> > > > > >> I searched for code using `AV_OPT_TYPE_BINARY`.
> > > > > >> `vf_libplacebo.c` gives me a good example.
> > > > > >>
> > > > > >> The LUT parsing code is took from `libavfilter/vf_lut3d.c`.
> > > > > >> It's mainly text processing which calls functions on `FILE*`.
> > > > > >> Using `AV_OPT_TYPE_BINARY` would require many changes in LUT paring
> > > > > >> code, and also need to change the command line option of 
> > > > > >> `vf_lut3d`.
> > > > > >> So I'd keep the lut file option as is.
> > > > > >
> > > > > > Your patch is rejected then.
> > >
> > > Now I understand using `AV_OPT_TYPE_BINARY` is a must.
> >
> > Okay, sorry for being unclear. When I say 'recommended', it means it
> > must be done this way unless there is a strong technical reason to do it
> > otherwise. But then please provide a detailed explanation, not
> > something vague like "didn't seem appropriate".
>
> After taking more time looking into how to use `AV_OPT_TYPE_BINARY`,
> I'll give more details.
>
> 1. For LUT file parsing, I'm not writing new code, it's taken from
> existing vf_lut3d.c.
> I avoid making unnecessary modifications to avoid breaking things.
>
> 2. The original code relies on file name to detect LUT file type, uses
> `fgets` and the like.
> From my understanding, `AV_OPT_TYPE_BINARY` does not give the file
> name to the calling filter.
> If we use `AV_OPT_TYPE_BINARY`, then how to do file type detection?
> Adding other cmdline option would require changing vf_lut3d's
> cmdline option.

I've spent some time this weekend trying to use `AV_OPT_TYPE_BINARY`.
Got an idea from vf_libplacebo.c.

It's possible to still use `AV_OPT_TYPE_STRING` in vf_lut3d.c, use
`av_file_map` to load text into a buffer, so that all the LUT parsing
functions can work on buffers instead of `FILE*`. But this is still
reading file in filter code.

It's more work than I expected and I don't know if this change will
meet the standards to be accepted.

I'll stop here.

If someone's interested in this feature, feel free to use my patch
https://github.com/cyfdecyf/FFmpeg/tree/vpp_qsv_lut_sysmem

>
> 3. I tried to find basic text processing utils in FFmpeg to avoid
> writing ad-hoc text processing code in lut3d.c
> I've found `FFTextReader` in libavformat/subtitles.h, but I don't
> think I should use it in filter code.
> I'm not sure if it's OK to follow the code in `FFTextReader` and
> duplicate read line logic in lut3d.c.
>
> Besides, there's `BINARY` in the name of `AV_OPT_TYPE_BINARY`, but
> what I'm specifying here is text file.
> This is not a big problem, but seem like an option name like
> `AV_OPT_TYPE_TEXT` can express the usage of the option more clear in
> code.
>

-- 
Best regards,
Chen Yufei
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] avformat/avformat: Remove obsolete comment

[Andreas Rheinhardt]

Forgotten in 3f991325b5ef472cf51b7d8433a2380bef2c94ff,
obsolete since 3749eede66c3774799766b1f246afae8a6ffc9bb.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 1a99598d6f..41b1c4e7d9 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -821,7 +821,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 AVRational av_stream_get_codec_timebase(const AVStream *st)
 {
-// See avformat_transfer_internal_stream_timing_info() TODO.
 return cffstream(st)->avctx->time_base;
 }
 
-- 
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 3/3] avformat/options: Only allocate AVCodecContext for demuxers

[Andreas Rheinhardt]

The muxer's AVCodecContext is currently used for exactly one thing:
To store a time base in it that has been derived via heuristics
in avformat_transfer_internal_stream_timing_info(); said time base
can then be read back via av_stream_get_codec_timebase().
But one does not need a whole AVCodecContext for that, a simple
AVRational is enough.

Signed-off-by: Andreas Rheinhardt 
---
If it were not for lavd, I would add a ff_demux_add_stream()
to be used internally for demuxers instead of avformat_new_stream().

 libavformat/avformat.c | 59 +++---
 libavformat/dump.c | 14 +-
 libavformat/internal.h |  2 ++
 libavformat/options.c  |  8 +++---
 4 files changed, 47 insertions(+), 36 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 41b1c4e7d9..9cacaef87d 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -729,8 +729,6 @@ AVRational av_guess_frame_rate(AVFormatContext *format, 
AVStream *st, AVFrame *f
 {
 AVRational fr = st->r_frame_rate;
 const AVCodecDescriptor *desc = cffstream(st)->codec_desc;
-AVCodecContext *const avctx = ffstream(st)->avctx;
-AVRational codec_fr = avctx->framerate;
 AVRational   avg_fr = st->avg_frame_rate;
 
 if (avg_fr.num > 0 && avg_fr.den > 0 && fr.num > 0 && fr.den > 0 &&
@@ -739,6 +737,9 @@ AVRational av_guess_frame_rate(AVFormatContext *format, 
AVStream *st, AVFrame *f
 }
 
 if (desc && (desc->props & AV_CODEC_PROP_FIELDS)) {
+const AVCodecContext *const avctx = ffstream(st)->avctx;
+AVRational codec_fr = avctx->framerate;
+
 if (   codec_fr.num > 0 && codec_fr.den > 0 &&
 (fr.num == 0 || av_q2d(codec_fr) < av_q2d(fr)*0.7 && fabs(1.0 - 
av_q2d(av_div_q(avg_fr, fr))) > 0.1))
 fr = codec_fr;
@@ -753,13 +754,19 @@ int avformat_transfer_internal_stream_timing_info(const 
AVOutputFormat *ofmt,
 {
 const AVCodecDescriptor   *desc = cffstream(ist)->codec_desc;
 const AVCodecContext *const dec_ctx = cffstream(ist)->avctx;
-AVCodecContext   *const enc_ctx =  ffstream(ost)->avctx;
 
 AVRational mul = (AVRational){ desc && (desc->props & 
AV_CODEC_PROP_FIELDS) ? 2 : 1, 1 };
-AVRational dec_ctx_tb = dec_ctx->framerate.num ? 
av_inv_q(av_mul_q(dec_ctx->framerate, mul))
+AVRational dec_ctx_framerate = dec_ctx ? dec_ctx->framerate : 
(AVRational){ 0, 0 };
+AVRational dec_ctx_tb = dec_ctx_framerate.num ? 
av_inv_q(av_mul_q(dec_ctx_framerate, mul))
: 
(ist->codecpar->codec_type == AVMEDIA_TYPE_AUDIO ? (AVRational){0, 1}

   : ist->time_base);
-enc_ctx->time_base = ist->time_base;
+AVRational enc_tb = ist->time_base;
+#if FF_API_TICKS_PER_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+int ticks_per_frame = dec_ctx ? dec_ctx->ticks_per_frame : 1;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
 /*
  * Avi is a special case here because it supports variable fps but
  * having the fps and timebase differe significantly adds quite some
@@ -773,35 +780,31 @@ int avformat_transfer_internal_stream_timing_info(const 
AVOutputFormat *ofmt,
 && 0.5/av_q2d(ist->r_frame_rate) > av_q2d(dec_ctx_tb)
 && av_q2d(ist->time_base) < 1.0/500 && av_q2d(dec_ctx_tb) < 1.0/500
 || copy_tb == AVFMT_TBCF_R_FRAMERATE) {
-enc_ctx->time_base.num = ist->r_frame_rate.den;
-enc_ctx->time_base.den = 2*ist->r_frame_rate.num;
+enc_tb.num = ist->r_frame_rate.den;
+enc_tb.den = 2*ist->r_frame_rate.num;
 } else
 #endif
-if (copy_tb == AVFMT_TBCF_AUTO && dec_ctx->framerate.num &&
-av_q2d(av_inv_q(dec_ctx->framerate)) > 2*av_q2d(ist->time_base)
+if (copy_tb == AVFMT_TBCF_AUTO && dec_ctx_framerate.num &&
+av_q2d(av_inv_q(dec_ctx_framerate)) > 2*av_q2d(ist->time_base)
&& av_q2d(ist->time_base) < 1.0/500
|| (copy_tb == AVFMT_TBCF_DECODER &&
-   (dec_ctx->framerate.num || ist->codecpar->codec_type == 
AVMEDIA_TYPE_AUDIO))) {
-enc_ctx->time_base = dec_ctx_tb;
-enc_ctx->time_base.den *= 2;
+   (dec_ctx_framerate.num || ist->codecpar->codec_type == 
AVMEDIA_TYPE_AUDIO))) {
+enc_tb = dec_ctx_tb;
+enc_tb.den *= 2;
 #if FF_API_TICKS_PER_FRAME
-FF_DISABLE_DEPRECATION_WARNINGS
-enc_ctx->time_base.num *= dec_ctx->ticks_per_frame;
-FF_ENABLE_DEPRECATION_WARNINGS
+enc_tb.num *= ticks_per_frame;
 #endif
 }
 } else if (!(ofmt->flags & AVFMT_VARIABLE_FPS)
&& !av_match_name(ofmt->name, 
"mov,mp4,3gp,3g2,psp,ipod,ismv,f4v")) {
-if (copy_tb == AVFMT_TBCF_AUTO && dec_ctx->framerate.num
-&& av_q2d(av_inv_q(dec_ctx->framerate)) > av_q2d(ist->time_base)
+

Re: [FFmpeg-devel] [PATCH] avcodec/vvcdec: fix seeking for open GOP

[James Almer]

On 2/3/2024 7:34 AM, Nuo Mi wrote:

how to reproduce:
wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
vvencapp --input students_cif.y4m --preset faster --output students.266
MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4


Can't you do this with ffmpeg? mp4 muxing support was added recently, 
and we have a parser to find frame boundaries from raw bitstreams.



ffplay testudents.mp4
---
  libavcodec/vvc/vvc_refs.c | 6 ++
  libavcodec/vvc/vvc_refs.h | 1 +
  libavcodec/vvc/vvcdec.c   | 6 ++
  3 files changed, 13 insertions(+)

diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c
index bf503e429e..e1895d1cca 100644
--- a/libavcodec/vvc/vvc_refs.c
+++ b/libavcodec/vvc/vvc_refs.c
@@ -80,6 +80,12 @@ void ff_vvc_clear_refs(VVCFrameContext *fc)
  VVC_FRAME_FLAG_SHORT_REF | VVC_FRAME_FLAG_LONG_REF);
  }
  
+void ff_vvc_flush_dpb(VVCFrameContext *fc)

+{
+for (int i = 0; i < FF_ARRAY_ELEMS(fc->DPB); i++)
+ff_vvc_unref_frame(fc, &fc->DPB[i], ~0);
+}
+
  static void free_progress(FFRefStructOpaque unused, void *obj)
  {
  FrameProgress *p = (FrameProgress *)obj;
diff --git a/libavcodec/vvc/vvc_refs.h b/libavcodec/vvc/vvc_refs.h
index cd3b5f5632..eba4422fb4 100644
--- a/libavcodec/vvc/vvc_refs.h
+++ b/libavcodec/vvc/vvc_refs.h
@@ -33,6 +33,7 @@ int ff_vvc_frame_rpl(VVCContext *s, VVCFrameContext *fc, 
SliceContext *sc);
  int ff_vvc_slice_rpl(VVCContext *s, VVCFrameContext *fc, SliceContext *sc);
  void ff_vvc_unref_frame(VVCFrameContext *fc, VVCFrame *frame, int flags);
  void ff_vvc_clear_refs(VVCFrameContext *fc);
+void ff_vvc_flush_dpb(VVCFrameContext *fc);
  
  typedef enum VVCProgress {

  VVC_PROGRESS_MV,
diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
index 83ee472ce6..1a050600eb 100644
--- a/libavcodec/vvc/vvcdec.c
+++ b/libavcodec/vvc/vvcdec.c
@@ -922,9 +922,15 @@ static av_cold void vvc_decode_flush(AVCodecContext *avctx)
  {
  VVCContext *s  = avctx->priv_data;
  int got_output = 0;
+VVCFrameContext *last;
  
  while (s->nb_delayed)

  wait_delayed_frame(s, NULL, &got_output);
+
+last = get_frame_context(s, s->fcs, s->nb_frames - 1);
+ff_vvc_flush_dpb(last);
+
+s->eos = 1;
  }
  
  static av_cold int vvc_decode_free(AVCodecContext *avctx)

___
ffmpeg-devel mailing list
ffmpeg-devel@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/avlanguage: add the 6 deprecated DVD languages

[Stefano Sabatini]

On date Sunday 2024-01-28 23:27:10 +0100, Stefano Sabatini wrote:
> On date Tuesday 2024-01-23 20:03:19 -0600, Marth64 wrote:
> > There are 6 deprecated ISO language codes that are still valid for DVDs.
> > This patch allows avlanguage to recognize them correctly. The codes are:
> > (1) "in" - legacy code for Indonesian, mapped to the modern code
> > (2) "iw" - legacy code for Hebrew, mapped to the modern code
> > (3) "ji" - legacy code for Yiddish, mapped to the modern code
> > (4) "jw" - legacy code for Javanese, published and used as a typoed version 
> > of "jv"
> > (5) "mo" - legacy code for Moldavian, mapped to the inclusive code
> > (6) "sh" - legacy code for Serbo-Croatian, no modern inclusive code so it 
> > is left alone
> > 
> > All of this can be verified from several sources including:
> > https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes
> > 
> > I split this off from the DVD demuxer patch to simplify it a bit.
> > Sent with git send-email and passes fate, pls let me know if there are 
> > issues.
> > 
> > Thank you,
> > 
> > Signed-off-by: Marth64 
> > ---
> >  libavformat/avlanguage.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> LGTM, will apply in a few days if I see no comments.

Applied, thanks again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] avformat/avformat: Remove dead check, write-only assignment

[Andreas Rheinhardt]

For muxers, the internal AVCodecContext is basically unused
except in avformat_transfer_internal_stream_timing_info()
(which sets time_base and ticks_per_frame) and
av_stream_get_codec_timebase() (a getter for time_base).
This makes ticks_per_frame write-only, so don't set it.

Also remove an always-false check for the AVCodecContext's
codec_tag.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..1a99598d6f 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -775,11 +775,6 @@ int avformat_transfer_internal_stream_timing_info(const 
AVOutputFormat *ofmt,
 || copy_tb == AVFMT_TBCF_R_FRAMERATE) {
 enc_ctx->time_base.num = ist->r_frame_rate.den;
 enc_ctx->time_base.den = 2*ist->r_frame_rate.num;
-#if FF_API_TICKS_PER_FRAME
-FF_DISABLE_DEPRECATION_WARNINGS
-enc_ctx->ticks_per_frame = 2;
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
 } else
 #endif
 if (copy_tb == AVFMT_TBCF_AUTO && dec_ctx->framerate.num &&
@@ -792,7 +787,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if FF_API_TICKS_PER_FRAME
 FF_DISABLE_DEPRECATION_WARNINGS
 enc_ctx->time_base.num *= dec_ctx->ticks_per_frame;
-enc_ctx->ticks_per_frame = 2;
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
@@ -812,7 +806,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
-if ((enc_ctx->codec_tag == AV_RL32("tmcd") || ost->codecpar->codec_tag == 
AV_RL32("tmcd"))
+if (ost->codecpar->codec_tag == AV_RL32("tmcd")
 && dec_ctx_tb.num < dec_ctx_tb.den
 && dec_ctx_tb.num > 0
 && 121LL*dec_ctx_tb.num > dec_ctx_tb.den) {
-- 
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] [RFC] Vote STF/SPI 2024-02

[Stefano Sabatini]

On date Saturday 2024-02-03 04:37:54 +0100, Michael Niedermayer wrote:
> On Thu, Feb 01, 2024 at 05:29:26AM +0100, Michael Niedermayer wrote:
> > Hi all
> > 
> > To do the STF/SPI thing properly, and make sure we do what the Community 
> > wants.
> > We should do this vote: (unless lots of people reply and say we should skip 
> > the vote)
> > (i am also CCing jonatan to make sure the option in the vote actually ask 
> > the GA the
> >  right question)
> > 
> > The vote description will be as follows:
> > The STF/SPI has suggested us to submit an Application / Scope of work 
> > before their february meeting.
> > There are about 2 weeks left.
> > The minimum grant is 150 000 €
> > The next STF meeting is expected to be in may. If we submit in february and 
> > are not selected
> > we can probably try again in may. Which would increase our chances
> > If we do not submit in february we can probably submit in may.
> > There is no guarantee that money will be available in may, for example 
> > between october 2023
> > and february 2024 no funds where available AFAIK.
> > Wiki page is here: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> > 
> > 

> > Option A. The Application and Scope of Work from the WIKI shall be
> > submitted to STF/SPI before the february 2024 meeting,
> > disagreements in it shall be decided by the TC. To achieve
> > continuity, submission shall be done by the same person as
> > previous if possible.


> > 
> > Option B. No Application and Scope of Work shall be submitted in
> > february 2024

> > 
> > 
> > This is a RFC, so if you see errors in it please suggest changes

Looks good to me.

I was wondering it it would make sense to consider the next deadline
as a different option, but this would add complexity to the vote and
we don't even know if the grant would still be available by then, so
it's best not to consider it for the moment.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/vvcdec: fix seeking for open GOP

[Nuo Mi]

On Sat, Feb 3, 2024 at 7:54 PM James Almer  wrote:

> On 2/3/2024 7:34 AM, Nuo Mi wrote:
> > how to reproduce:
> > wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
> > vvencapp --input students_cif.y4m --preset faster --output students.266
> > MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4
>
> Can't you do this with ffmpeg? mp4 muxing support was added recently,
> and we have a parser to find frame boundaries from raw bitstreams.
>
> Yes, we can
ffmpeg -i students.266 -c:v copy students.mp4
But the reporter used the mp4box
see:  https://github.com/ffvvc/FFmpeg/issues/190#issuecomment-1924169765
___
ffmpeg-devel mailing list
ffmpeg-devel@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/vvcdec: fix seeking for open GOP

[James Almer]

On 2/3/2024 9:17 AM, Nuo Mi wrote:

On Sat, Feb 3, 2024 at 7:54 PM James Almer  wrote:


On 2/3/2024 7:34 AM, Nuo Mi wrote:

how to reproduce:
wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
vvencapp --input students_cif.y4m --preset faster --output students.266
MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4


Can't you do this with ffmpeg? mp4 muxing support was added recently,
and we have a parser to find frame boundaries from raw bitstreams.

Yes, we can

ffmpeg -i students.266 -c:v copy students.mp4
But the reporter used the mp4box
see:  https://github.com/ffvvc/FFmpeg/issues/190#issuecomment-1924169765


That's ok, just wanted to know why not use ffmpeg for this. If it 
couldn't remux the file, then that'd be something we should fix.

___
ffmpeg-devel mailing list
ffmpeg-devel@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/vvcdec: fix seeking for open GOP

[Nuo Mi]

On Sat, Feb 3, 2024 at 8:21 PM James Almer  wrote:

> On 2/3/2024 9:17 AM, Nuo Mi wrote:
> > On Sat, Feb 3, 2024 at 7:54 PM James Almer  wrote:
> >
> >> On 2/3/2024 7:34 AM, Nuo Mi wrote:
> >>> how to reproduce:
> >>> wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
> >>> vvencapp --input students_cif.y4m --preset faster --output students.266
> >>> MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4
> >>
> >> Can't you do this with ffmpeg? mp4 muxing support was added recently,
> >> and we have a parser to find frame boundaries from raw bitstreams.
> >>
> >> Yes, we can
> > ffmpeg -i students.266 -c:v copy students.mp4
> > But the reporter used the mp4box
> > see:  https://github.com/ffvvc/FFmpeg/issues/190#issuecomment-1924169765
>
> That's ok, just wanted to know why not use ffmpeg for this. If it
> couldn't remux the file, then that'd be something we should fix.
>
Ts demux has an issue for both HEVC and VVC. If you use ffplay on a TS
file, you will see corrupted frames after a seek.
The main reason is that the demuxer does not send the key frame after a
seek; instead, it sends many frames before the key frame.
Not sure if it's a feature or a bug in the demuxer

you can reproduce it with
wget https://s3.amazonaws.com/x265.org/video/Tears_400_x265.mp4 && ffmpeg
-i Tears_400_x265.mp4 -c:v copy tos.ts
ffplay tos.ts

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 4/5] avutil/channel_layout: add av_channel_layout_retype()

[James Almer]

On 2/3/2024 7:38 AM, Anton Khirnov wrote:

Quoting James Almer (2024-02-02 13:56:31)

I wrote a function like this some time ago, but i lost the patch by
accident during a migration.

The way i approached it was making the return codes reflect if the
conversion was lossless or not, as in, custom -> native is lossless only
if channels have no custom names (and possible only if the ids are
within UINT64_MAX and in order).



Anything to Unspec is always lossy, etc.


Unless the source is custom with every channel unknown.


True, and Unspec -> Custom is possible by doing the inverse.




Custom -> Ambi: Possible only if it contains ambi channels. Lossless.
Custom -> Native: Possible only if has no ambi channels and all ids < 64
and in order. Lossy if it has custom names, otherwise lossless.
Ambi -> Custom: Lossless.
Ambi -> Native: Not possible.
Native -> Custom: Lossless.
Native -> Ambi: Not possible.
Any -> Unspec: Possible but lossy.

So 0 for lossless, 1 for lossy, ENOSYS for not possible.


That sounds good to me.

Might also have a flags argument that forces lossless, and for future
extensions.


Agree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avfilter/ccfifo: Inline trivial functions

[Andreas Rheinhardt]

Besides being extremly simple this also avoids including
ff_ccfifo_ccdetected() unnecessarily (it is only used by decklink).
This is possible because this is not avpriv, but duplicated into
lavd if necessary.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/ccfifo.c | 11 ---
 libavfilter/ccfifo.h | 13 +++--
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
index 6ae61a4b15..29108822be 100644
--- a/libavfilter/ccfifo.c
+++ b/libavfilter/ccfifo.c
@@ -24,7 +24,6 @@
 #include "ccfifo.h"
 
 #define MAX_CC_ELEMENTS 128
-#define CC_BYTES_PER_ENTRY 3
 
 struct cc_lookup {
 int num;
@@ -89,16 +88,6 @@ error:
 return AVERROR(ENOMEM);
 }
 
-int ff_ccfifo_getoutputsize(const CCFifo *ccf)
-{
-return ccf->expected_cc_count * CC_BYTES_PER_ENTRY;
-}
-
-int ff_ccfifo_ccdetected(const CCFifo *ccf)
-{
-return ccf->cc_detected;
-}
-
 int ff_ccfifo_injectbytes(CCFifo *ccf, uint8_t *cc_data, size_t len)
 {
 int cc_608_tuples = 0;
diff --git a/libavfilter/ccfifo.h b/libavfilter/ccfifo.h
index a3c302b6b2..565a837a00 100644
--- a/libavfilter/ccfifo.h
+++ b/libavfilter/ccfifo.h
@@ -33,6 +33,8 @@
 #include "libavutil/frame.h"
 #include "libavutil/fifo.h"
 
+#define CC_BYTES_PER_ENTRY 3
+
 typedef struct CCFifo {
 AVFifo *cc_608_fifo;
 AVFifo *cc_708_fifo;
@@ -88,7 +90,11 @@ int ff_ccfifo_extractbytes(CCFifo *ccf, uint8_t *data, 
size_t len);
  * an appropriately sized buffer and pass it to ff_ccfifo_injectbytes()
  *
  */
-int ff_ccfifo_getoutputsize(const CCFifo *ccf);
+static inline int ff_ccfifo_getoutputsize(const CCFifo *ccf)
+{
+return ccf->expected_cc_count * CC_BYTES_PER_ENTRY;
+}
+
 
 /**
  * Insert CC data from the FIFO into an AVFrame (as side data)
@@ -113,6 +119,9 @@ int ff_ccfifo_injectbytes(CCFifo *ccf, uint8_t *data, 
size_t len);
  * Returns 1 if captions have been found as a prior call
  * to ff_ccfifo_extract() or ff_ccfifo_extractbytes()
  */
-int ff_ccfifo_ccdetected(const CCFifo *ccf);
+static inline int ff_ccfifo_ccdetected(const CCFifo *ccf)
+{
+return ccf->cc_detected;
+}
 
 #endif /* AVFILTER_CCFIFO_H */
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avfilter/ccfifo: Improve included headers

[Andreas Rheinhardt]

We don't need to include fifo.h, because we don't need AVFifo
as a complete type. Also add the other used headers directly.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/ccfifo.c |  1 +
 libavfilter/ccfifo.h | 10 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
index 29108822be..d76dbff149 100644
--- a/libavfilter/ccfifo.c
+++ b/libavfilter/ccfifo.c
@@ -22,6 +22,7 @@
  */
 
 #include "ccfifo.h"
+#include "libavutil/fifo.h"
 
 #define MAX_CC_ELEMENTS 128
 
diff --git a/libavfilter/ccfifo.h b/libavfilter/ccfifo.h
index 565a837a00..d3f8a52cc1 100644
--- a/libavfilter/ccfifo.h
+++ b/libavfilter/ccfifo.h
@@ -29,15 +29,17 @@
 #ifndef AVFILTER_CCFIFO_H
 #define AVFILTER_CCFIFO_H
 
-#include "libavutil/avutil.h"
+#include 
+#include 
+
 #include "libavutil/frame.h"
-#include "libavutil/fifo.h"
+#include "libavutil/rational.h"
 
 #define CC_BYTES_PER_ENTRY 3
 
 typedef struct CCFifo {
-AVFifo *cc_608_fifo;
-AVFifo *cc_708_fifo;
+struct AVFifo *cc_608_fifo;
+struct AVFifo *cc_708_fifo;
 AVRational framerate;
 int expected_cc_count;
 int expected_608;
-- 
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 v9 2/6] avcodec/webp: separate VP8 decoding

[Andreas Rheinhardt]

Thilo Borgmann via ffmpeg-devel:
> Am 28.01.24 um 11:29 schrieb Anton Khirnov:
>> Quoting Thilo Borgmann via ffmpeg-devel (2024-01-25 16:39:19)
>>> Am 25.01.24 um 11:04 schrieb Anton Khirnov:
 Quoting Thilo Borgmann via ffmpeg-devel (2023-12-31 13:30:14)
> ---
>    libavcodec/webp.c | 50
> +--
>    1 file changed, 44 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> index 4fd107aa0c..58a20b73da 100644
> --- a/libavcodec/webp.c
> +++ b/libavcodec/webp.c
> @@ -194,6 +194,7 @@ typedef struct WebPContext {
>    AVFrame *alpha_frame;   /* AVFrame for alpha
> data decompressed from VP8L */
>    AVPacket *pkt;  /* AVPacket to be passed
> to the underlying VP8 decoder */
>    AVCodecContext *avctx;  /* parent AVCodecContext */
> +    AVCodecContext *avctx_vp8;  /* wrapper context for VP8
> decoder */

 Nested codec contexts are in general highly undesirable and should be
 avoided whenever possible.
>>>
>>> AFAICT we do it that way in the other codecs as well (cri, ftr, imm5,
>>> tdsc, tiff). So what do you suggest to do to avoid having it nested?
>>
>> Integrating the two decoders directly, as is done now.
>>
>> With nesting it is very tricky to handle all the corner cases properly,
>> especially passing through all the options to the innner decoder, like
>> direct rendering, other user callbacks, etc. It should only be done as a
>> last resort and there should be a strong argument to do it this way.
> 
> IIUC that was what the patch still did some some versions ago.
> It brought us the data races in animated files, decoupling the decoder
> solving the issue.
> 

If one keeps the codecs integrated, then one needs at the very least
change the check for whether to call ff_thread_finish_setup() as I did:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320490.html
This will not be enough: E.g. changing the dimensions in VP8 code and
then reverting that change in WebP (as has been done in the earlier
version of your patch which made me propose that these decoders should
be separated) will have to be avoided.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/vvc: Error pps_single_slice_per_subpic_flag

[Frank Plowman]

On 02/02/2024 14:39, Nuo Mi wrote:

On Thu, Feb 1, 2024 at 10:01 PM  wrote:


From: Frank Plowman 

pps_single_slice_per_subpic_flag is not yet supported.  Support is WIP,
but in the meantime throw an error when trying to decode a bitstream
with it set, avoiding an out-of-bounds array access.

Fixes: out-of-bounds array access for conformance bitstreams
SUBPIC_C_ERICSSON_1, SUBPIC_D_ERICSSON_1, MNUT_A_Nokia_4 and
MNUT_B_Nokia_3.

Signed-off-by: Frank Plowman 
---
  libavcodec/vvc/vvc_ps.c | 21 -
  1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 2cf156b323..bd81d70e71 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -381,11 +381,16 @@ static void pps_multi_tiles_slice(VVCPPS *pps, const
int tile_idx, const int i,
  }
  }

-static void pps_rect_slice(VVCPPS* pps)
+static int pps_rect_slice(VVCPPS* pps)
  {
  const H266RawPPS* r = pps->r;
  int tile_idx = 0, off = 0;

+if (r->pps_single_slice_per_subpic_flag) {
+avpriv_report_missing_feature(NULL,
"pps_single_slice_per_subpic_flag");
+return AVERROR_PATCHWELCOME;
+}
+
  for (int i = 0; i < r->pps_num_slices_in_pic_minus1 + 1; i++) {
  if (!r->pps_slice_width_in_tiles_minus1[i] &&
  !r->pps_slice_height_in_tiles_minus1[i]) {
@@ -396,9 +401,11 @@ static void pps_rect_slice(VVCPPS* pps)
  }
  tile_idx = next_tile_idx(tile_idx, i, r);
  }
+
+return 0;
  }

-static void pps_no_rect_slice(VVCPPS* pps)
+static int pps_no_rect_slice(VVCPPS* pps)
  {
  const H266RawPPS* r = pps->r;
  int ctu_x, ctu_y, off = 0;
@@ -409,20 +416,24 @@ static void pps_no_rect_slice(VVCPPS* pps)
  pps_add_ctus(pps, &off, ctu_x, ctu_y,
r->col_width_val[tile_x], r->row_height_val[tile_y]);
  }
  }
+
+return 0;
  }

  static int pps_slice_map(VVCPPS *pps)
  {
+int ret;
+
  pps->ctb_addr_in_slice = av_calloc(pps->ctb_count,
sizeof(*pps->ctb_addr_in_slice));
  if (!pps->ctb_addr_in_slice)
  return AVERROR(ENOMEM);

  if (pps->r->pps_rect_slice_flag)
-pps_rect_slice(pps);
+ret = pps_rect_slice(pps);
  else
-pps_no_rect_slice(pps);
+ret = pps_no_rect_slice(pps);

-return 0;
+return ret;
  }


Thank you Frank. This changed  too much code.
How about we only check the sps_num_subpics_minus1 in decode_sps.


I wrote it like this so that the avpriv_report_missing_feature is where 
the feature would need to be, helping readability and searchability.  I 
could remove the return from pps_rect_slice and pps_no_rect_slice which 
would get rid of a handful of changed lines but the changes are trivial 
so it is not a big deal imo.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp8: Enforce key-frame only for WebP

[Andreas Rheinhardt]

Andreas Rheinhardt:
> VP8-in-WebP only uses key frame encoding (see [1]), yet this
> is currently not enforced. This commit does so in order to
> make output reproducible with frame-threading as the VP8 decoder's
> update_thread_context is not called at all when using decoding
> VP8-in-WebP (as this is unnecessary for key frame-only streams).
> 
> [1]: https://developers.google.com/speed/webp/docs/riff_container
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/vp8.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index 83c60adeb0..7972775a1c 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -2665,7 +2665,11 @@ int vp78_decode_frame(AVCodecContext *avctx, AVFrame 
> *rframe, int *got_frame,
>  if (ret < 0)
>  goto err;
>  
> -if (s->actually_webp) {
> +if (!is_vp7 && s->actually_webp) {
> +// VP8 in WebP is supposed to be intra-only. Enforce this here
> +// to ensure that output is reproducible with frame-threading.
> +if (!s->keyframe)
> +return AVERROR_INVALIDDATA;
>  // avctx->pix_fmt already set in caller.
>  } else if (!is_vp7 && s->pix_fmt == AV_PIX_FMT_NONE) {
>  s->pix_fmt = get_pixel_format(s);

Will apply this patchset tomorrow unless there are objections.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/vvc: Error pps_single_slice_per_subpic_flag

[Nuo Mi]

On Sat, Feb 3, 2024 at 9:54 PM Frank Plowman  wrote:

> On 02/02/2024 14:39, Nuo Mi wrote:
> > On Thu, Feb 1, 2024 at 10:01 PM  wrote:
> >
> >> From: Frank Plowman 
> >>
> >> pps_single_slice_per_subpic_flag is not yet supported.  Support is WIP,
> >> but in the meantime throw an error when trying to decode a bitstream
> >> with it set, avoiding an out-of-bounds array access.
> >>
> >> Fixes: out-of-bounds array access for conformance bitstreams
> >> SUBPIC_C_ERICSSON_1, SUBPIC_D_ERICSSON_1, MNUT_A_Nokia_4 and
> >> MNUT_B_Nokia_3.
> >>
> >> Signed-off-by: Frank Plowman 
> >> ---
> >>   libavcodec/vvc/vvc_ps.c | 21 -
> >>   1 file changed, 16 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
> >> index 2cf156b323..bd81d70e71 100644
> >> --- a/libavcodec/vvc/vvc_ps.c
> >> +++ b/libavcodec/vvc/vvc_ps.c
> >> @@ -381,11 +381,16 @@ static void pps_multi_tiles_slice(VVCPPS *pps,
> const
> >> int tile_idx, const int i,
> >>   }
> >>   }
> >>
> >> -static void pps_rect_slice(VVCPPS* pps)
> >> +static int pps_rect_slice(VVCPPS* pps)
> >>   {
> >>   const H266RawPPS* r = pps->r;
> >>   int tile_idx = 0, off = 0;
> >>
> >> +if (r->pps_single_slice_per_subpic_flag) {
> >> +avpriv_report_missing_feature(NULL,
> >> "pps_single_slice_per_subpic_flag");
> >> +return AVERROR_PATCHWELCOME;
> >> +}
> >> +
> >>   for (int i = 0; i < r->pps_num_slices_in_pic_minus1 + 1; i++) {
> >>   if (!r->pps_slice_width_in_tiles_minus1[i] &&
> >>   !r->pps_slice_height_in_tiles_minus1[i]) {
> >> @@ -396,9 +401,11 @@ static void pps_rect_slice(VVCPPS* pps)
> >>   }
> >>   tile_idx = next_tile_idx(tile_idx, i, r);
> >>   }
> >> +
> >> +return 0;
> >>   }
> >>
> >> -static void pps_no_rect_slice(VVCPPS* pps)
> >> +static int pps_no_rect_slice(VVCPPS* pps)
> >>   {
> >>   const H266RawPPS* r = pps->r;
> >>   int ctu_x, ctu_y, off = 0;
> >> @@ -409,20 +416,24 @@ static void pps_no_rect_slice(VVCPPS* pps)
> >>   pps_add_ctus(pps, &off, ctu_x, ctu_y,
> >> r->col_width_val[tile_x], r->row_height_val[tile_y]);
> >>   }
> >>   }
> >> +
> >> +return 0;
> >>   }
> >>
> >>   static int pps_slice_map(VVCPPS *pps)
> >>   {
> >> +int ret;
> >> +
> >>   pps->ctb_addr_in_slice = av_calloc(pps->ctb_count,
> >> sizeof(*pps->ctb_addr_in_slice));
> >>   if (!pps->ctb_addr_in_slice)
> >>   return AVERROR(ENOMEM);
> >>
> >>   if (pps->r->pps_rect_slice_flag)
> >> -pps_rect_slice(pps);
> >> +ret = pps_rect_slice(pps);
> >>   else
> >> -pps_no_rect_slice(pps);
> >> +ret = pps_no_rect_slice(pps);
> >>
> >> -return 0;
> >> +return ret;
> >>   }
> >>
> > Thank you Frank. This changed  too much code.
> > How about we only check the sps_num_subpics_minus1 in decode_sps.
>
> I wrote it like this so that the avpriv_report_missing_feature is where
> the feature would need to be, helping readability and searchability.

We need to make changes to both the cbs and the decoder for subpic support.
pps_slice_map is not the first place.

> I
> could remove the return from pps_rect_slice and pps_no_rect_slice which
> would get rid of a handful of changed lines but the changes are trivial
> so it is not a big deal imo.
>
Once we implemented subpic, both pps_rect_slice and pps_no_rect_slice are
not supposed to return a value. We need to change it back


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF

[Andreas Rheinhardt]

James Almer:
> Signed-off-by: James Almer 
> ---
>  configure|   2 +-
>  libavformat/movenc.c | 323 ++-
>  libavformat/movenc.h |   7 +
>  3 files changed, 269 insertions(+), 63 deletions(-)
> 
> diff --git a/configure b/configure
> index 42ba5ec502..6cdd101487 100755
> --- a/configure
> +++ b/configure
> @@ -3547,7 +3547,7 @@ mlp_demuxer_select="mlp_parser"
>  mmf_muxer_select="riffenc"
>  mov_demuxer_select="iso_media riffdec iamf_frame_split_bsf"
>  mov_demuxer_suggest="zlib"
> -mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf 
> aac_adtstoasc_bsf ac3_parser"
> +mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf 
> aac_adtstoasc_bsf iamf_frame_merge_bsf ac3_parser"
>  mp3_demuxer_select="mpegaudio_parser"
>  mp3_muxer_select="mpegaudioheader"
>  mp4_muxer_select="mov_muxer"
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index b724bd5ebc..dfa8b6b04e 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -32,6 +32,7 @@
>  #include "dovi_isom.h"
>  #include "riff.h"
>  #include "avio.h"
> +#include "iamf_writer.h"
>  #include "isom.h"
>  #include "av1.h"
>  #include "avc.h"
> @@ -47,6 +48,7 @@
>  #include "libavcodec/raw.h"
>  #include "internal.h"
>  #include "libavutil/avstring.h"
> +#include "libavutil/bprint.h"
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/csp.h"
>  #include "libavutil/intfloat.h"
> @@ -316,6 +318,32 @@ static int mov_write_sdtp_tag(AVIOContext *pb, MOVTrack 
> *track)
>  return update_size(pb, pos);
>  }
>  
> +static int mov_write_iacb_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
> *track)
> +{
> +AVIOContext *dyn_bc;
> +int64_t pos = avio_tell(pb);
> +uint8_t *dyn_buf = NULL;
> +int dyn_size;
> +int ret = avio_open_dyn_buf(&dyn_bc);
> +if (ret < 0)
> +return ret;
> +
> +avio_wb32(pb, 0);
> +ffio_wfourcc(pb, "iacb");
> +avio_w8(pb, 1); // configurationVersion
> +
> +ret = ff_iamf_write_descriptors(track->iamf, dyn_bc, s);
> +if (ret < 0)
> +return ret;
> +
> +dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf);
> +ffio_write_leb(pb, dyn_size);
> +avio_write(pb, dyn_buf, dyn_size);
> +av_free(dyn_buf);
> +
> +return update_size(pb, pos);
> +}
> +
>  static int mov_write_amr_tag(AVIOContext *pb, MOVTrack *track)
>  {
>  avio_wb32(pb, 0x11); /* size */
> @@ -1358,6 +1386,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVMuxContex
>  ret = mov_write_wave_tag(s, pb, track);
>  else if (track->tag == MKTAG('m','p','4','a'))
>  ret = mov_write_esds_tag(pb, track);
> +else if (track->tag == MKTAG('i','a','m','f'))
> +ret = mov_write_iacb_tag(mov->fc, pb, track);
>  else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)
>  ret = mov_write_amr_tag(pb, track);
>  else if (track->par->codec_id == AV_CODEC_ID_AC3)
> @@ -2501,7 +2531,7 @@ static int mov_write_video_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVMuxContex
>  
>  if (track->mode == MODE_AVIF) {
>  mov_write_ccst_tag(pb);
> -if (s->nb_streams > 0 && track == &mov->tracks[1])
> +if (mov->nb_streams > 0 && track == &mov->tracks[1])
>  mov_write_aux_tag(pb, "auxi");
>  }
>  
> @@ -3096,9 +3126,9 @@ static int mov_write_iloc_tag(AVIOContext *pb, 
> MOVMuxContext *mov, AVFormatConte
>  avio_wb32(pb, 0); /* Version & flags */
>  avio_w8(pb, (4 << 4) + 4); /* offset_size(4) and length_size(4) */
>  avio_w8(pb, 0); /* base_offset_size(4) and reserved(4) */
> -avio_wb16(pb, s->nb_streams); /* item_count */
> +avio_wb16(pb, mov->nb_streams); /* item_count */
>  
> -for (int i = 0; i < s->nb_streams; i++) {
> +for (int i = 0; i < mov->nb_streams; i++) {
>  avio_wb16(pb, i + 1); /* item_id */
>  avio_wb16(pb, 0); /* data_reference_index */
>  avio_wb16(pb, 1); /* extent_count */
> @@ -3117,9 +3147,9 @@ static int mov_write_iinf_tag(AVIOContext *pb, 
> MOVMuxContext *mov, AVFormatConte
>  avio_wb32(pb, 0); /* size */
>  ffio_wfourcc(pb, "iinf");
>  avio_wb32(pb, 0); /* Version & flags */
> -avio_wb16(pb, s->nb_streams); /* entry_count */
> +avio_wb16(pb, mov->nb_streams); /* entry_count */
>  
> -for (int i = 0; i < s->nb_streams; i++) {
> +for (int i = 0; i < mov->nb_streams; i++) {
>  int64_t infe_pos = avio_tell(pb);
>  avio_wb32(pb, 0); /* size */
>  ffio_wfourcc(pb, "infe");
> @@ -3188,7 +3218,7 @@ static int mov_write_ipco_tag(AVIOContext *pb, 
> MOVMuxContext *mov, AVFormatConte
>  int64_t pos = avio_tell(pb);
>  avio_wb32(pb, 0); /* size */
>  ffio_wfourcc(pb, "ipco");
> -for (int i = 0; i < s->nb_streams; i++) {
> +for (int i = 0; i < mov->nb_streams; i++) {
>  mov_write_ispe_tag(pb, mov, s, i);
>  mov_write_pixi_tag(pb, mov, s, i);
>  mov_write_av1c_tag(

Re: [FFmpeg-devel] [PATCH 1/7 v2] avcodec: add an Immersive Audio Model and Formats frame split bsf

[Andreas Rheinhardt]

James Almer:
> On 1/30/2024 7:11 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 1/30/2024 6:47 PM, Andreas Rheinhardt wrote:
> +    *obu_size = get_leb(&gb);
 This stuff here should not a GetBitContext at all, as basically
 everything is byte-aligned (and the flags above are in known bits).
>>>
>>> I'm not going to write yet another leb() reading function to work on raw
>>> bytes. We have enough scattered around and in fact we should try to
>>> remove most.
>>>
> +static const enum AVCodecID iamf_stream_split_codec_ids[] = {
> +    AV_CODEC_ID_PCM_S16LE, AV_CODEC_ID_PCM_S16BE,
> +    AV_CODEC_ID_PCM_S24LE, AV_CODEC_ID_PCM_S24BE,
> +    AV_CODEC_ID_PCM_S32LE, AV_CODEC_ID_PCM_S32BE,
> +    AV_CODEC_ID_OPUS,  AV_CODEC_ID_AAC,
> +    AV_CODEC_ID_FLAC,  AV_CODEC_ID_NONE,
> +};
> +
> +const FFBitStreamFilter ff_iamf_stream_split_bsf = {
> +    .p.name = "iamf_stream_split",
> +    .p.codec_ids    = iamf_stream_split_codec_ids,
> +    .p.priv_class   = &iamf_stream_split_class,
> +    .priv_data_size = sizeof(IAMFSplitContext),
> +    .init   = iamf_stream_split_init,
> +    .flush  = iamf_stream_split_flush,
> +    .close  = iamf_stream_split_close,
> +    .filter = iamf_stream_split_filter,
> +};

 This needs to add documentation for what this BSF is actually supposed
 to do. Right now it seems crazy: It parses the packet's data and
 expects
 to find OBU headers, although the input data is supposed to be PCM,
 Opus, AAC or Flac.
>>>
>>> It's not too different than aac_adtstoasc in that it takes audio from
>>> those codecs listed above encapsulated in one form and returns it in
>>> another form.
>>> In this case, it takes OBUs containing one or more audio frames, removes
>>> the OBU encapsulation, and propagates each raw audio frame in separate
>>> packets.
>>>
>>
>> Then these packets do not really contain PCM, Opus or Flac at all.
> 
> It does, encapsulated in OBU. Not really different than AAC in ADTS,
> like i said.
> I can remove the iamf_stream_split_codec_ids[] array in any case.

I disagree with this: While there are some codecs where several
different encapsulations are widely used and supported (in which case
one can actually find out information about the packetization by looking
at the extradata (H.26x) or the packets (AAC)), the aforementioned ones
are not among them. Your PCM-in-OBU is just not PCM.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/vvc: Error pps_single_slice_per_subpic_flag

[Frank Plowman]

On 03/02/2024 15:46, Nuo Mi wrote:

On Sat, Feb 3, 2024 at 9:54 PM Frank Plowman  wrote:


On 02/02/2024 14:39, Nuo Mi wrote:

On Thu, Feb 1, 2024 at 10:01 PM  wrote:


From: Frank Plowman 

pps_single_slice_per_subpic_flag is not yet supported.  Support is WIP,
but in the meantime throw an error when trying to decode a bitstream
with it set, avoiding an out-of-bounds array access.

Fixes: out-of-bounds array access for conformance bitstreams
SUBPIC_C_ERICSSON_1, SUBPIC_D_ERICSSON_1, MNUT_A_Nokia_4 and
MNUT_B_Nokia_3.

Signed-off-by: Frank Plowman 
---
   libavcodec/vvc/vvc_ps.c | 21 -
   1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 2cf156b323..bd81d70e71 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -381,11 +381,16 @@ static void pps_multi_tiles_slice(VVCPPS *pps,

const

int tile_idx, const int i,
   }
   }

-static void pps_rect_slice(VVCPPS* pps)
+static int pps_rect_slice(VVCPPS* pps)
   {
   const H266RawPPS* r = pps->r;
   int tile_idx = 0, off = 0;

+if (r->pps_single_slice_per_subpic_flag) {
+avpriv_report_missing_feature(NULL,
"pps_single_slice_per_subpic_flag");
+return AVERROR_PATCHWELCOME;
+}
+
   for (int i = 0; i < r->pps_num_slices_in_pic_minus1 + 1; i++) {
   if (!r->pps_slice_width_in_tiles_minus1[i] &&
   !r->pps_slice_height_in_tiles_minus1[i]) {
@@ -396,9 +401,11 @@ static void pps_rect_slice(VVCPPS* pps)
   }
   tile_idx = next_tile_idx(tile_idx, i, r);
   }
+
+return 0;
   }

-static void pps_no_rect_slice(VVCPPS* pps)
+static int pps_no_rect_slice(VVCPPS* pps)
   {
   const H266RawPPS* r = pps->r;
   int ctu_x, ctu_y, off = 0;
@@ -409,20 +416,24 @@ static void pps_no_rect_slice(VVCPPS* pps)
   pps_add_ctus(pps, &off, ctu_x, ctu_y,
r->col_width_val[tile_x], r->row_height_val[tile_y]);
   }
   }
+
+return 0;
   }

   static int pps_slice_map(VVCPPS *pps)
   {
+int ret;
+
   pps->ctb_addr_in_slice = av_calloc(pps->ctb_count,
sizeof(*pps->ctb_addr_in_slice));
   if (!pps->ctb_addr_in_slice)
   return AVERROR(ENOMEM);

   if (pps->r->pps_rect_slice_flag)
-pps_rect_slice(pps);
+ret = pps_rect_slice(pps);
   else
-pps_no_rect_slice(pps);
+ret = pps_no_rect_slice(pps);

-return 0;
+return ret;
   }


Thank you Frank. This changed  too much code.
How about we only check the sps_num_subpics_minus1 in decode_sps.


I wrote it like this so that the avpriv_report_missing_feature is where
the feature would need to be, helping readability and searchability.


We need to make changes to both the cbs and the decoder for subpic support.
pps_slice_map is not the first place.


There is nothing strictly missing in the CBS, only the derivation of 
NumSlicesInSub needs to be moved which is quite subtle;  I think the 
putting the error in the parameter set parser is clearer.


How is the patch below as an alternative?

diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 2cf156b323..4ef8f9f9b9 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -413,13 +413,20 @@ static void pps_no_rect_slice(VVCPPS* pps)

 static int pps_slice_map(VVCPPS *pps)
 {
+const H266RawPPS* r = pps->r;
+
 pps->ctb_addr_in_slice = av_calloc(pps->ctb_count, 
sizeof(*pps->ctb_addr_in_slice));

 if (!pps->ctb_addr_in_slice)
 return AVERROR(ENOMEM);

-if (pps->r->pps_rect_slice_flag)
+if (pps->r->pps_rect_slice_flag) {
+if (r->pps_single_slice_per_subpic_flag) {
+avpriv_report_missing_feature(NULL, 
"pps_single_slice_per_subpic_flag");

+return AVERROR_PATCHWELCOME;
+}
+
 pps_rect_slice(pps);
-else
+} else
 pps_no_rect_slice(pps);

 return 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] lavc/vvc: Error pps_single_slice_per_subpic_flag

[Nuo Mi]

On Sat, Feb 3, 2024 at 11:51 PM Frank Plowman  wrote:

> On 03/02/2024 15:46, Nuo Mi wrote:
> > On Sat, Feb 3, 2024 at 9:54 PM Frank Plowman 
> wrote:
> >
> >> On 02/02/2024 14:39, Nuo Mi wrote:
> >>> On Thu, Feb 1, 2024 at 10:01 PM  wrote:
> >>>
>  From: Frank Plowman 
> 
>  pps_single_slice_per_subpic_flag is not yet supported.  Support is
> WIP,
>  but in the meantime throw an error when trying to decode a bitstream
>  with it set, avoiding an out-of-bounds array access.
> 
>  Fixes: out-of-bounds array access for conformance bitstreams
>  SUBPIC_C_ERICSSON_1, SUBPIC_D_ERICSSON_1, MNUT_A_Nokia_4 and
>  MNUT_B_Nokia_3.
> 
>  Signed-off-by: Frank Plowman 
>  ---
> libavcodec/vvc/vvc_ps.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
> 
>  diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
>  index 2cf156b323..bd81d70e71 100644
>  --- a/libavcodec/vvc/vvc_ps.c
>  +++ b/libavcodec/vvc/vvc_ps.c
>  @@ -381,11 +381,16 @@ static void pps_multi_tiles_slice(VVCPPS *pps,
> >> const
>  int tile_idx, const int i,
> }
> }
> 
>  -static void pps_rect_slice(VVCPPS* pps)
>  +static int pps_rect_slice(VVCPPS* pps)
> {
> const H266RawPPS* r = pps->r;
> int tile_idx = 0, off = 0;
> 
>  +if (r->pps_single_slice_per_subpic_flag) {
>  +avpriv_report_missing_feature(NULL,
>  "pps_single_slice_per_subpic_flag");
>  +return AVERROR_PATCHWELCOME;
>  +}
>  +
> for (int i = 0; i < r->pps_num_slices_in_pic_minus1 + 1; i++) {
> if (!r->pps_slice_width_in_tiles_minus1[i] &&
> !r->pps_slice_height_in_tiles_minus1[i]) {
>  @@ -396,9 +401,11 @@ static void pps_rect_slice(VVCPPS* pps)
> }
> tile_idx = next_tile_idx(tile_idx, i, r);
> }
>  +
>  +return 0;
> }
> 
>  -static void pps_no_rect_slice(VVCPPS* pps)
>  +static int pps_no_rect_slice(VVCPPS* pps)
> {
> const H266RawPPS* r = pps->r;
> int ctu_x, ctu_y, off = 0;
>  @@ -409,20 +416,24 @@ static void pps_no_rect_slice(VVCPPS* pps)
> pps_add_ctus(pps, &off, ctu_x, ctu_y,
>  r->col_width_val[tile_x], r->row_height_val[tile_y]);
> }
> }
>  +
>  +return 0;
> }
> 
> static int pps_slice_map(VVCPPS *pps)
> {
>  +int ret;
>  +
> pps->ctb_addr_in_slice = av_calloc(pps->ctb_count,
>  sizeof(*pps->ctb_addr_in_slice));
> if (!pps->ctb_addr_in_slice)
> return AVERROR(ENOMEM);
> 
> if (pps->r->pps_rect_slice_flag)
>  -pps_rect_slice(pps);
>  +ret = pps_rect_slice(pps);
> else
>  -pps_no_rect_slice(pps);
>  +ret = pps_no_rect_slice(pps);
> 
>  -return 0;
>  +return ret;
> }
> 
> >>> Thank you Frank. This changed  too much code.
> >>> How about we only check the sps_num_subpics_minus1 in decode_sps.
> >>
> >> I wrote it like this so that the avpriv_report_missing_feature is where
> >> the feature would need to be, helping readability and searchability.
> >
> > We need to make changes to both the cbs and the decoder for subpic
> support.
> > pps_slice_map is not the first place.
>
> There is nothing strictly missing in the CBS, only the derivation of
> NumSlicesInSub needs to be moved which is quite subtle;  I think the
> putting the error in the parameter set parser is clearer.
>
> How is the patch below as an alternative?
>
This fixes the single_slice_per_subpic_flag.
But fuzzer may find another subpic-related issue. Highly possible they will
crash too. :)
check sub picture number is a safer way

>
> diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
> index 2cf156b323..4ef8f9f9b9 100644
> --- a/libavcodec/vvc/vvc_ps.c
> +++ b/libavcodec/vvc/vvc_ps.c
> @@ -413,13 +413,20 @@ static void pps_no_rect_slice(VVCPPS* pps)
>
>   static int pps_slice_map(VVCPPS *pps)
>   {
> +const H266RawPPS* r = pps->r;
> +
>   pps->ctb_addr_in_slice = av_calloc(pps->ctb_count,
> sizeof(*pps->ctb_addr_in_slice));
>   if (!pps->ctb_addr_in_slice)
>   return AVERROR(ENOMEM);
>
> -if (pps->r->pps_rect_slice_flag)
> +if (pps->r->pps_rect_slice_flag) {
> +if (r->pps_single_slice_per_subpic_flag) {
> +avpriv_report_missing_feature(NULL,
> "pps_single_slice_per_subpic_flag");
> +return AVERROR_PATCHWELCOME;
> +}
> +
>   pps_rect_slice(pps);
> -else
> +} else
>   pps_no_rect_slice(pps);
>
>   return 0;
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To u

Re: [FFmpeg-devel] [PATCH] avcodec/cbs_h266_syntax_template: check aps_adaptation_parameter_set_id

[Nuo Mi]

On Sat, Jan 27, 2024 at 11:13 AM Michael Niedermayer 
wrote:

> From: James Almer 
>
> "When aps_params_type is equal to ALF_APS or SCALING_APS, the value of
> aps_adaptation_parameter_set_id shall be
> in the range of 0 to 7, inclusive.
> When aps_params_type is equal to LMCS_APS, the value of
> aps_adaptation_parameter_set_id shall be in the range of 0
> to 3, inclusive."
>
> Fixes: out of array accesses
> Fixes:
> 65932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-4563412340244480
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/cbs_h266_syntax_template.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index 9e479c9c314..21da8195556 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -2457,6 +2457,7 @@ static int
> FUNC(scaling_list_data)(CodedBitstreamContext *ctx, RWContext *rw,
>  static int FUNC(aps)(CodedBitstreamContext *ctx, RWContext *rw,
>   H266RawAPS *current, int prefix)
>  {
> +int aps_id_max = MAX_UINT_BITS(5);
>  int err;
>
>  if (prefix)
> @@ -2469,7 +2470,12 @@ static int FUNC(aps)(CodedBitstreamContext *ctx,
> RWContext *rw,
> : VVC_SUFFIX_APS_NUT));
>
>  ub(3, aps_params_type);
> -ub(5, aps_adaptation_parameter_set_id);
> +if (current->aps_params_type == VVC_ASP_TYPE_ALF ||
> +current->aps_params_type == VVC_ASP_TYPE_SCALING)
> +aps_id_max = 7;
> +else if (current->aps_params_type == VVC_ASP_TYPE_LMCS)
> +aps_id_max = 3;
> +u(5, aps_adaptation_parameter_set_id, 0, aps_id_max);
>  flag(aps_chroma_present_flag);
>  if (current->aps_params_type == VVC_ASP_TYPE_ALF)
>  CHECK(FUNC(alf_data)(ctx, rw, current));
> --

applied,
thanks, James and Michael

>
> 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".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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/avlanguage: add the 6 deprecated DVD languages

[Marth64]

Thank you Stefano.
Respectfully,

On Sat, Feb 3, 2024 at 05:57 Stefano Sabatini  wrote:

> On date Sunday 2024-01-28 23:27:10 +0100, Stefano Sabatini wrote:
> > On date Tuesday 2024-01-23 20:03:19 -0600, Marth64 wrote:
> > > There are 6 deprecated ISO language codes that are still valid for
> DVDs.
> > > This patch allows avlanguage to recognize them correctly. The codes
> are:
> > > (1) "in" - legacy code for Indonesian, mapped to the modern code
> > > (2) "iw" - legacy code for Hebrew, mapped to the modern code
> > > (3) "ji" - legacy code for Yiddish, mapped to the modern code
> > > (4) "jw" - legacy code for Javanese, published and used as a typoed
> version of "jv"
> > > (5) "mo" - legacy code for Moldavian, mapped to the inclusive code
> > > (6) "sh" - legacy code for Serbo-Croatian, no modern inclusive code so
> it is left alone
> > >
> > > All of this can be verified from several sources including:
> > > https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes
> > >
> > > I split this off from the DVD demuxer patch to simplify it a bit.
> > > Sent with git send-email and passes fate, pls let me know if there are
> issues.
> > >
> > > Thank you,
> > >
> > > Signed-off-by: Marth64 
> > > ---
> > >  libavformat/avlanguage.c | 10 --
> > >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > LGTM, will apply in a few days if I see no comments.
>
> Applied, thanks again.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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 4/5] avutil/channel_layout: add av_channel_layout_retype()

[Anton Khirnov]

Quoting Marton Balint (2024-02-01 21:36:31)
> > What exactly is the rule for when the change succeeds or not? I would
> > expect it to be when all the channels can be represented in the new
> > order, but that is not the case for conversion to unspec.
> 
> Yes, you are right. Converting to unspec indeed makes you lose the 
> channel designations, so the conversion will not be lossless. On the other 
> hand, when you specify UNSPEC as a target, you don't actually expect to 
> keep the designations, so what is the point of returning an error...
> 
> I think this is one of those cases when both behaviour (always doing the 
> conversion, or returning a failure in case the source order is not already 
> unspec) can make sense. We have to decide though if a custom layout with 
> all channels as UNKNOWN can be losslessly converted to UNSPEC layout or 
> not. And if yes, then would not that conflict with 
> av_channel_layout_channel_from_index() which returns AV_CHAN_NONE and not 
> AV_CHAN_UNKNOWN for UNSPEC layouts...

Huh, that might actually considered a bug, returning UNKNOWN certainly
makes more sense to me.

> >
> >> + *
> >> + * @param channel_layout channel layout which will be changed
> >> + * @param order the desired channel layout order
> >> + * @return 0 on success or if the channel layout is already in the 
> >> desired order
> >> + * 1 if using the desired order is not possible for the specified 
> >> layout
> >
> > AVERROR(ENOSYS) seems more consistent to me
> 
> By using a positive result all negative return values can be considered 
> serious errors which have to be propagated back to the user.
> 
> In the next patch I try to simplify a custom channel layout:
> 
> +ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE);
> +if (ret < 0)
> +goto out;
> 
> I can do simply this, because I don't care if the simplification was 
> successful.

IMO policy like what errors are to be considered serious should be up to
the caller. If you asked it to get a certain order and it failed to
deliver, then I'd consider that an error state.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [RFC/PATCH] Require compilers to support C11.

[Anton Khirnov]

It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
---
As discussed at the developer meeting at FOSDEM, and also in various
places before that. The main blocker until now was MSVC, which should
now support C11.

Only tested on Linux with GCC/clang, so more testing is welcome.
---
 configure  | 19 +--
 doc/developer.texi | 10 ++
 2 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/configure b/configure
index 68f675a4bc..ae340b703b 100755
--- a/configure
+++ b/configure
@@ -4702,7 +4702,7 @@ msvc_common_flags(){
 # generic catch all at the bottom will print the original flag.
 -Wall);;
 -Wextra)  ;;
--std=c*)  ;;
+-std=c*)  echo /std:${flag#-std=};;
 # Common flags
 -fomit-frame-pointer) ;;
 -g)   echo -Z7 ;;
@@ -4747,7 +4747,7 @@ icl_flags(){
 # Despite what Intel's documentation says -Wall, which is supported
 # on Windows, does enable remarks so disable them here.
 -Wall)echo $flag -Qdiag-disable:remark ;;
--std=c99) echo -Qstd=c99 ;;
+-std=c11) echo -Qstd=c11 ;;
 -flto*)   echo -ipo ;;
 esac
 done
@@ -4795,7 +4795,7 @@ suncc_flags(){
 athlon*)   echo -xarch=pentium_proa  ;;
 esac
 ;;
--std=c99) echo -xc99  ;;
+-std=c11) echo -xc11  ;;
 -fomit-frame-pointer) echo -xregs=frameptr;;
 -fPIC)echo -KPIC -xcode=pic32 ;;
 -W*,*)echo $flag  ;;
@@ -4884,8 +4884,8 @@ probe_cc(){
 _type=suncc
 _ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
 _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e 
"1s,^.*: ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
-_DEPFLAGS='-xM1 -xc99'
-_ldflags='-std=c99'
+_DEPFLAGS='-xM1 -xc11'
+_ldflags='-std=c11'
 _cflags_speed='-O5'
 _cflags_size='-O5 -xspace'
 _flags_filter=suncc_flags
@@ -5514,21 +5514,20 @@ if test "$?" != 0; then
 die "C compiler test failed."
 fi
 
-add_cppflags -D_ISOC99_SOURCE
+add_cppflags -D_ISOC11_SOURCE
 add_cxxflags -D__STDC_CONSTANT_MACROS
 check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
 
 # some compilers silently accept -std=c11, so we also need to check that the
 # version macro is defined properly
 test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
-add_cflags -std=c11 ||
-check_cflags -std=c99
+add_cflags -std=c11 || die "Compiler lacks C11 support"
 
 check_cppflags -D_FILE_OFFSET_BITS=64
 check_cppflags -D_LARGEFILE_SOURCE
 
-add_host_cppflags -D_ISOC99_SOURCE
-check_host_cflags -std=c99
+add_host_cppflags -D_ISOC11_SOURCE
+check_host_cflags -std=c11
 check_host_cflags -Wall
 check_host_cflags $host_cflags_speed
 
diff --git a/doc/developer.texi b/doc/developer.texi
index eed0ee4915..c86bb5820c 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -56,14 +56,8 @@ and should try to fix issues their commit causes.
 
 @section Language
 
-FFmpeg is mainly programmed in the ISO C99 language, extended with:
-@itemize @bullet
-@item
-Atomic operations from C11 @file{stdatomic.h}. They are emulated on
-architectures/compilers that do not support them, so all FFmpeg-internal code
-may use atomics without any extra checks. However, @file{stdatomic.h} must not
-be included in public headers, so they stay C99-compatible.
-@end itemize
+FFmpeg is mainly programmed in the ISO C11 language, except for the public
+headers which must stay C99 compatible.
 
 Compiler-specific extensions may be used with good reason, but must not be
 depended on, i.e. the code must still compile and work with compilers lacking
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/vvc: Validate alf_list indexes

[post]

From: Frank Plowman 

Fixes crashes when decoding illegal bitstreams found by fuzzing.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/vvc_ctu.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
index d166b16a19..f601c6c95e 100644
--- a/libavcodec/vvc/vvc_ctu.c
+++ b/libavcodec/vvc/vvc_ctu.c
@@ -2207,7 +2207,7 @@ static void hls_sao(VVCLocalContext *lc, const int rx, 
const int ry)
 }
 }
 
-static void alf_params(VVCLocalContext *lc, const int rx, const int ry)
+static int alf_params(VVCLocalContext *lc, const int rx, const int ry)
 {
 const VVCFrameContext *fc = lc->fc;
 const H266RawSliceHeader *sh  = lc->sc->sh.r;
@@ -2233,6 +2233,11 @@ static void alf_params(VVCLocalContext *lc, const int 
rx, const int ry)
 c_idx == CB ? sh->sh_alf_cb_enabled_flag : 
sh->sh_alf_cr_enabled_flag;
 if (alf_enabled_flag) {
 const VVCALF *aps = fc->ps.alf_list[sh->sh_alf_aps_id_chroma];
+if (!aps) {
+// Slice header refers to an APS which does not exist
+return AVERROR_INVALIDDATA;
+}
+
 alf->ctb_flag[c_idx] = ff_vvc_alf_ctb_flag(lc, rx, ry, c_idx);
 alf->alf_ctb_filter_alt_idx[c_idx - 1] = 0;
 if (alf->ctb_flag[c_idx] && aps->num_chroma_filters > 1)
@@ -2247,10 +2252,16 @@ static void alf_params(VVCLocalContext *lc, const int 
rx, const int ry)
 alf->ctb_cc_idc[i] = 0;
 if (cc_enabled[i]) {
 const VVCALF *aps = fc->ps.alf_list[cc_aps_id[i]];
+if (!aps) {
+// Slice header refers to an APS which does not exist
+return AVERROR_INVALIDDATA;
+}
 alf->ctb_cc_idc[i] = ff_vvc_alf_ctb_cc_idc(lc, rx, ry, i, 
aps->num_cc_filters[i]);
 }
 }
 }
+
+return 0;
 }
 
 static void deblock_params(VVCLocalContext *lc, const int rx, const int ry)
@@ -2274,7 +2285,9 @@ static int hls_coding_tree_unit(VVCLocalContext *lc,
 memset(lc->parse.chroma_qp_offset, 0, sizeof(lc->parse.chroma_qp_offset));
 
 hls_sao(lc, x0 >> sps->ctb_log2_size_y, y0 >> sps->ctb_log2_size_y);
-alf_params(lc, x0 >> sps->ctb_log2_size_y, y0 >> sps->ctb_log2_size_y);
+ret = alf_params(lc, x0 >> sps->ctb_log2_size_y, y0 >> 
sps->ctb_log2_size_y);
+if (ret < 0)
+return ret;
 deblock_params(lc, x0 >> sps->ctb_log2_size_y, y0 >> sps->ctb_log2_size_y);
 
 if (IS_I(rsh) && sps->r->sps_qtbtt_dual_tree_intra_flag)
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/nutenc: Fix indentation

[Andreas Rheinhardt]

Forgotten after 82beb46e65e5f820b187355bf757725c22a59c45.
Also use loop-scope for iterators while at it.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/nutenc.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index a5198c7ca9..5e0e36babe 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -1063,21 +1063,21 @@ static int nut_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 ffio_free_dyn_buf(&dyn_bc);
 
 if (nut->write_index) {
-if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/, 
pkt->dts)) < 0)
-goto fail;
-
-if ((1ll<<60) % nut->sp_count == 0)
-for (i=0; inb_streams; i++) {
-int j;
-StreamContext *nus = &nut->stream[i];
-av_reallocp_array(&nus->keyframe_pts, 2*nut->sp_count, 
sizeof(*nus->keyframe_pts));
-if (!nus->keyframe_pts) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-for (j=nut->sp_count == 1 ? 0 : nut->sp_count; 
j<2*nut->sp_count; j++)
-nus->keyframe_pts[j] = AV_NOPTS_VALUE;
-}
+if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 
/*unused*/, pkt->dts)) < 0)
+goto fail;
+
+if ((1ll<<60) % nut->sp_count == 0)
+for (unsigned i = 0; i < s->nb_streams; i++) {
+StreamContext *nus = &nut->stream[i];
+av_reallocp_array(&nus->keyframe_pts, 2*nut->sp_count, 
sizeof(*nus->keyframe_pts));
+if (!nus->keyframe_pts) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+for (int j = nut->sp_count == 1 ? 0 : nut->sp_count;
+ j < 2 * nut->sp_count; j++)
+nus->keyframe_pts[j] = AV_NOPTS_VALUE;
+}
 }
 }
 av_assert0(nus->last_pts != AV_NOPTS_VALUE);
-- 
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 3/3] avfilter/yadif_common: fix timestamps with very small timebases

[Marton Balint]

On Thu, 1 Feb 2024, Marton Balint wrote:



On Thu, 1 Feb 2024, Michael Niedermayer wrote:


 On Wed, Jan 31, 2024 at 03:42:46AM +0100, Marton Balint wrote:



 On Wed, 31 Jan 2024, Michael Niedermayer wrote:


 On Sun, Jan 28, 2024 at 04:01:36AM +0100, Marton Balint wrote:

 Yadif filter assumed that the output timebase is always half of the
 input
 timebase. This is not true if halving the input time base is not
 representable
 as an AVRational causing the output timestamps to be invalidly scaled
 in such a
 case.

 So let's use av_reduce instead of av_mul_q when calculating the output
 time
 base and if the conversion is inexact then let's fall back to the
 original
 timebase which probably makes more parctical sense than using
 x/INT_MAX.

 Fixes invalidly scaled pts_time values in this command line:
 ffmpeg -f lavfi -i testsrc -vf settb=tb=1/20,yadif,showinfo -f
 null none

 Signed-off-by: Marton Balint 
 ---
  libavfilter/yadif.h|  2 ++
  libavfilter/yadif_common.c | 20 ++--
  2 files changed, 16 insertions(+), 6 deletions(-)

 diff --git a/libavfilter/yadif.h b/libavfilter/yadif.h
 index 2c4fed62d2..c144568242 100644
 --- a/libavfilter/yadif.h
 +++ b/libavfilter/yadif.h
 @@ -86,6 +86,8 @@ typedef struct YADIFContext {
   * the first field.
   */
  int current_field;  ///< YADIFCurrentField
 +
 +int pts_divisor;
  } YADIFContext;

 void ff_yadif_init_x86(YADIFContext *yadif);
 diff --git a/libavfilter/yadif_common.c b/libavfilter/yadif_common.c
 index 933372529e..90a5cffc2d 100644
 --- a/libavfilter/yadif_common.c
 +++ b/libavfilter/yadif_common.c
 @@ -61,7 +61,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
  int64_t next_pts = yadif->next->pts;

  if (next_pts != AV_NOPTS_VALUE && cur_pts != AV_NOPTS_VALUE) {
 -yadif->out->pts = cur_pts + next_pts;
 +yadif->out->pts = (cur_pts + next_pts) /
 yadif->pts_divisor;
  } else {
  yadif->out->pts = AV_NOPTS_VALUE;
  }
 @@ -150,8 +150,8 @@ int ff_yadif_filter_frame(AVFilterLink *link,
 AVFrame *frame)
  ff_ccfifo_inject(&yadif->cc_fifo, yadif->out);
  av_frame_free(&yadif->prev);
  if (yadif->out->pts != AV_NOPTS_VALUE)
 -yadif->out->pts *= 2;
 -yadif->out->duration *= 2;
 +yadif->out->pts *= 2 / yadif->pts_divisor;
 +yadif->out->duration *= 2 / yadif->pts_divisor;
  return ff_filter_frame(ctx->outputs[0], yadif->out);
  }

 @@ -168,9 +168,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
  yadif->out->flags &= ~AV_FRAME_FLAG_INTERLACED;

  if (yadif->out->pts != AV_NOPTS_VALUE)
 -yadif->out->pts *= 2;
 +yadif->out->pts *= 2 / yadif->pts_divisor;
  if (!(yadif->mode & 1))
 -yadif->out->duration *= 2;
 +yadif->out->duration *= 2 / yadif->pts_divisor;


 you can use >> instead of division for all above


 Even for the first case? Because the right shift would be implementation
 defined for negative timestamps.


 we are only supporting twos-complement systems
 i thought that was somewhete in teh docs


Ok, I will change the /= 2 divisions to >>= 1 shifts in v2 patch then.


Will apply the series.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/indeo3: Round dimensions up in allocate_frame_buffers()

[Michael Niedermayer]

Fixes: Ticket6581

Signed-off-by: Michael Niedermayer 
---
 libavcodec/indeo3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/indeo3.c b/libavcodec/indeo3.c
index 5f1014f0d49..7bb0235bdb5 100644
--- a/libavcodec/indeo3.c
+++ b/libavcodec/indeo3.c
@@ -171,6 +171,9 @@ static av_cold int 
allocate_frame_buffers(Indeo3DecodeContext *ctx,
 int luma_size, chroma_size;
 ptrdiff_t luma_pitch, chroma_pitch;
 
+luma_width  = FFALIGN(luma_width , 2);
+luma_height = FFALIGN(luma_height, 2);
+
 if (luma_width  < 16 || luma_width  > 640 ||
 luma_height < 16 || luma_height > 480 ||
 luma_width  &  1 || luma_height &   1) {
-- 
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".

[FFmpeg-devel] [PATCH 5/5] avformat/mux: Don't allocate priv_pts separately

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.c  |  1 -
 libavformat/internal.h  |  2 +-
 libavformat/mux.c   | 17 ++---
 libavformat/mux_utils.c |  5 +
 4 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index ae79ee6ef7..ca31d3dc56 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -63,7 +63,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 av_parser_close(sti->parser);
 avcodec_free_context(&sti->avctx);
 av_bsf_free(&sti->bsfc);
-av_freep(&sti->priv_pts);
 av_freep(&sti->index_entries);
 av_freep(&sti->probe_data.buf);
 
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 520f1a5229..c66f959e9f 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -245,7 +245,7 @@ typedef struct FFStream {
 
 int is_intra_only;
 
-FFFrac *priv_pts;
+FFFrac priv_pts;
 
 /**
  * Stream information used internally by avformat_find_stream_info()
diff --git a/libavformat/mux.c b/libavformat/mux.c
index de10d2c008..93280f9047 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -406,16 +406,11 @@ static int init_pts(AVFormatContext *s)
 break;
 }
 
-if (!sti->priv_pts)
-sti->priv_pts = av_mallocz(sizeof(*sti->priv_pts));
-if (!sti->priv_pts)
-return AVERROR(ENOMEM);
-
 if (den != AV_NOPTS_VALUE) {
 if (den <= 0)
 return AVERROR_INVALIDDATA;
 
-frac_init(sti->priv_pts, 0, 0, den);
+frac_init(&sti->priv_pts, 0, 0, den);
 }
 }
 
@@ -550,7 +545,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 }
 pkt->dts =
 //pkt->pts= st->cur_dts;
-pkt->pts = sti->priv_pts->val;
+pkt->pts = sti->priv_pts.val;
 }
 
 //calculate dts from pts
@@ -587,7 +582,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 av_ts2str(pkt->pts), av_ts2str(pkt->dts));
 
 sti->cur_dts  = pkt->dts;
-sti->priv_pts->val = pkt->dts;
+sti->priv_pts.val = pkt->dts;
 
 /* update pts */
 switch (st->codecpar->codec_type) {
@@ -599,12 +594,12 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 /* HACK/FIXME, we skip the initial 0 size packets as they are most
  * likely equal to the encoder delay, but it would be better if we
  * had the real timestamps from the encoder */
-if (frame_size >= 0 && (pkt->size || sti->priv_pts->num != 
sti->priv_pts->den >> 1 || sti->priv_pts->val)) {
-frac_add(sti->priv_pts, (int64_t)st->time_base.den * frame_size);
+if (frame_size >= 0 && (pkt->size || sti->priv_pts.num != 
sti->priv_pts.den >> 1 || sti->priv_pts.val)) {
+frac_add(&sti->priv_pts, (int64_t)st->time_base.den * frame_size);
 }
 break;
 case AVMEDIA_TYPE_VIDEO:
-frac_add(sti->priv_pts, (int64_t)st->time_base.den * 
st->time_base.num);
+frac_add(&sti->priv_pts, (int64_t)st->time_base.den * 
st->time_base.num);
 break;
 }
 return 0;
diff --git a/libavformat/mux_utils.c b/libavformat/mux_utils.c
index 3e63b8039a..c7ac2a9c97 100644
--- a/libavformat/mux_utils.c
+++ b/libavformat/mux_utils.c
@@ -33,10 +33,7 @@
 #if FF_API_GET_END_PTS
 int64_t av_stream_get_end_pts(const AVStream *st)
 {
-if (cffstream(st)->priv_pts) {
-return cffstream(st)->priv_pts->val;
-} else
-return AV_NOPTS_VALUE;
+return cffstream(st)->priv_pts.val;
 }
 #endif
 
-- 
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 4/5] avformat/avformat: Avoid av_strdup(NULL)

[Andreas Rheinhardt]

It is not documented to be safe.
Also copy these lists in a more generic manner.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 9cacaef87d..ae79ee6ef7 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -875,20 +875,28 @@ const AVCodec *ff_find_decoder(AVFormatContext *s, const 
AVStream *st,
 
 int ff_copy_whiteblacklists(AVFormatContext *dst, const AVFormatContext *src)
 {
+#define OFF(field) offsetof(AVFormatContext, field)
+static const unsigned offsets[] = {
+OFF(codec_whitelist),OFF(format_whitelist),
+OFF(protocol_whitelist), OFF(protocol_blacklist),
+};
+#undef OFF
 av_assert0(!dst->codec_whitelist &&
!dst->format_whitelist &&
!dst->protocol_whitelist &&
!dst->protocol_blacklist);
-dst-> codec_whitelist = av_strdup(src->codec_whitelist);
-dst->format_whitelist = av_strdup(src->format_whitelist);
-dst->protocol_whitelist = av_strdup(src->protocol_whitelist);
-dst->protocol_blacklist = av_strdup(src->protocol_blacklist);
-if (   (src-> codec_whitelist && !dst-> codec_whitelist)
-|| (src->  format_whitelist && !dst->  format_whitelist)
-|| (src->protocol_whitelist && !dst->protocol_whitelist)
-|| (src->protocol_blacklist && !dst->protocol_blacklist)) {
-av_log(dst, AV_LOG_ERROR, "Failed to duplicate black/whitelist\n");
-return AVERROR(ENOMEM);
+for (unsigned i = 0; i < FF_ARRAY_ELEMS(offsets); i++) {
+const char *src_str = *(char *const*)((const char*)src + offsets[i]);
+
+if (src_str) {
+char *dst_str = av_strdup(src_str);
+if (!dst_str) {
+av_log(dst, AV_LOG_ERROR, "Failed to duplicate 
black/whitelist\n");
+return AVERROR(ENOMEM);
+}
+
+*(char **)((char*)dst + offsets[i]) = dst_str;
+}
 }
 return 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".

Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

[Tomas Härdin]

lör 2024-02-03 klockan 11:51 +0100 skrev Jerome Martinez:
> On 03/02/2024 11:00, Tomas Härdin wrote:
> > fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez:
> > > Before this patch, the FFmpeg MXF parser correctly detects
> > > content
> > > with
> > > 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg
> > > JPEG
> > > 2000 decoder reads the JPEG 2000 SIZ header without understanding
> > > that
> > > the indicated height is the height of 1 field only so overwrites
> > > the
> > > frame size info with e.g. 720x243, and also completely discards
> > > the
> > > second frame, which lead to the decoding of only half of the
> > > stored
> > > content as "progressive" 720x243 flagged interlaced.
> > Is the decoder really the right place to do this? Surely this
> > happens
> > with more codecs than just j2k. Isnt it also a parser's job to do
> > this
> > kind of stuff?
> 
> Both solutions have pro and con:
> - Doing it in the decoder fixes the issue for all containers and only
> one codec
> - Doing it in the demuxer fixes the issue for one container and all
> codecs
> And currently I know only one container and only one codec having
> this 
> issue.

A more proper fix might be to auto-insert a deinterleave filter in
ffmpeg.

> My choice to implement in the decoder comes from the idea that it
> seems 
> more hacky to decode 2 AVPackets (crafted from a single MXF packet), 
> then do a RAM copy of the decoded (so huge) content for interleaving 
> fields into 1 frame (pressure on RAM bandwidth) in the MXF demuxer + 
> adapt frame metadata (height is overwritten by the decoder then need
> to 
> overwrite again the value), doing it in the decoder seems less
> intrusive.

The fastest way, in a player, is probably to do it with a shader. That
should be the least amount of copies and the most cache coherent.

> If moving to the demuxer is the only acceptable solution, I will do
> it 
> but I would like to be sure that there is a consensus on that by
> FFmpeg 
> developers before doing it, in order to not have this extra work 
> rejected due to a future disagreement about where it should go.
> 
> > The logic that scans the packet for two SOI markers shouldn't be
> > necessary if the relevant information is carried over from the MXF
> > demuxer.
> 
> As far as I know there is nothing in the MXF file saying where is the
> second field in the packet, at which MXF metadata do you think?

Well, FrameLayout == SEPARATE_FIELDS, EditRate = 3/1001 and
FieldDominance == 2. DisplayHeight is the field height as S377 says it
should be for SEPARATE_FIELDS.

Annoyingly EditRate could be the field rate rather than the frame rate.
So there may be no way to a priori know how many fields an essence
element contains.

I think people with knowledge how interlacing is handled in other
formats and codecs might want to chime in.

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@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/jpeg2000dec: support of 2 fields in 1 AVPacket

[Tomas Härdin]

lör 2024-02-03 klockan 20:58 +0100 skrev Tomas Härdin:
> lör 2024-02-03 klockan 11:51 +0100 skrev Jerome Martinez:
> > On 03/02/2024 11:00, Tomas Härdin wrote:
> > > fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez:
> > > > Before this patch, the FFmpeg MXF parser correctly detects
> > > > content
> > > > with
> > > > 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the
> > > > FFmpeg
> > > > JPEG
> > > > 2000 decoder reads the JPEG 2000 SIZ header without
> > > > understanding
> > > > that
> > > > the indicated height is the height of 1 field only so
> > > > overwrites
> > > > the
> > > > frame size info with e.g. 720x243, and also completely discards
> > > > the
> > > > second frame, which lead to the decoding of only half of the
> > > > stored
> > > > content as "progressive" 720x243 flagged interlaced.
> > > Is the decoder really the right place to do this? Surely this
> > > happens
> > > with more codecs than just j2k. Isnt it also a parser's job to do
> > > this
> > > kind of stuff?
> > 
> > Both solutions have pro and con:
> > - Doing it in the decoder fixes the issue for all containers and
> > only
> > one codec
> > - Doing it in the demuxer fixes the issue for one container and all
> > codecs
> > And currently I know only one container and only one codec having
> > this 
> > issue.
> 
> A more proper fix might be to auto-insert a deinterleave filter in
> ffmpeg.
> 
> > My choice to implement in the decoder comes from the idea that it
> > seems 
> > more hacky to decode 2 AVPackets (crafted from a single MXF
> > packet), 
> > then do a RAM copy of the decoded (so huge) content for
> > interleaving 
> > fields into 1 frame (pressure on RAM bandwidth) in the MXF demuxer
> > + 
> > adapt frame metadata (height is overwritten by the decoder then
> > need
> > to 
> > overwrite again the value), doing it in the decoder seems less
> > intrusive.
> 
> The fastest way, in a player, is probably to do it with a shader.
> That
> should be the least amount of copies and the most cache coherent.
> 
> > If moving to the demuxer is the only acceptable solution, I will do
> > it 
> > but I would like to be sure that there is a consensus on that by
> > FFmpeg 
> > developers before doing it, in order to not have this extra work 
> > rejected due to a future disagreement about where it should go.
> > 
> > > The logic that scans the packet for two SOI markers shouldn't be
> > > necessary if the relevant information is carried over from the
> > > MXF
> > > demuxer.
> > 
> > As far as I know there is nothing in the MXF file saying where is
> > the
> > second field in the packet, at which MXF metadata do you think?
> 
> Well, FrameLayout == SEPARATE_FIELDS, EditRate = 3/1001 and
> FieldDominance == 2. DisplayHeight is the field height as S377 says
> it
> should be for SEPARATE_FIELDS.

It should also be said that what this patch effectively does is
silently convert SEPARATE_FIELDS to MIXED_FIELDS. What if I want to
transcode J2K to lower bitrate but keep it SEPARATE_FIELDS?

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_mux: fix terminating muxer on streamcopy with -t

[Anton Khirnov]

Reported-by: Andreas Rheinhardt
---
 fftools/ffmpeg_mux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index ab86abee14..962d0b2882 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -300,6 +300,7 @@ static int mux_packet_filter(Muxer *mux, MuxThreadContext 
*mt,
 av_packet_unref(pkt);
 pkt = NULL;
 ret = 0;
+*stream_eof = 1;
 } else if (ret < 0)
 goto fail;
 }
@@ -352,14 +353,13 @@ static int mux_packet_filter(Muxer *mux, MuxThreadContext 
*mt,
 goto mux_fail;
 }
 *stream_eof = 1;
-return AVERROR_EOF;
 } else {
 ret = sync_queue_process(mux, ms, pkt, stream_eof);
 if (ret < 0)
 goto mux_fail;
 }
 
-return 0;
+return *stream_eof ? AVERROR_EOF : 0;
 
 mux_fail:
 err_msg = "submitting a packet to the muxer";
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] tests/fate/ffmpeg: add a test for the issue fixed in previous commit

[Anton Khirnov]

---
 tests/fate/ffmpeg.mak | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 8c2f008d04..3f21815ba2 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -271,3 +271,11 @@ fate-ffmpeg-filter-in-eof: CMD = framecrc
 -f rawvideo -s 352x288 -pix_fmt yuv420p -t 1 -i 
$(TARGET_PATH)/tests/data/vsynth_lena.yuv  \
 -filter_complex "[0][1]concat" -c:v rawvideo
 FATE_FFMPEG-$(call FRAMECRC, RAWVIDEO, RAWVIDEO, CONCAT_FILTER) += 
fate-ffmpeg-filter-in-eof
+
+# Test termination on streamcopy with -t as an output option.
+fate-ffmpeg-streamcopy-t: tests/data/vsynth_lena.yuv
+fate-ffmpeg-streamcopy-t: CMP = null
+fate-ffmpeg-streamcopy-t: CMD = ffmpeg 
   \
+-stream_loop -1 -f rawvideo -s 352x288 -pix_fmt yuv420p -i 
$(TARGET_PATH)/tests/data/vsynth_lena.yuv  \
+-c copy -f null -t 1 -
+FATE_FFMPEG-$(call REMUX, RAWVIDEO) += fate-ffmpeg-streamcopy-t
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] lavc/dxv: move tag definitions to common header

[Connor Worley]

Any objections to merging this series?

-- 
Connor Worley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] GA changes

[Michael Niedermayer]

Hi all

before doing the vote about the STF/SPI id like to document that the GA
changed according to our script this way:
(I presume this must have happened on january 1st and we should probably
 do a vote about adding the removed people as extra members, but there
 is not enough time before teh STF deadline)

-Andriy Gelman
-Carl Eugen Hoyos
+Logan Lyu

(Theres also a wrong (@ffmpeg.org)  address appearing for wenbin chen,
 i will continue to use the correct one, thats clearly a bug)

(I will also update the ga ffmpeg.org alias)

PS: Iam ccing the 2 removed people so they understand why they will not
receive a vote mail in the next vote(s)

thx
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


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] GA changes

[Michael Niedermayer]

On Sat, Feb 03, 2024 at 11:21:53PM +0100, Michael Niedermayer wrote:
> Hi all
> 
> before doing the vote about the STF/SPI id like to document that the GA
> changed according to our script this way:
> (I presume this must have happened on january 1st and we should probably
>  do a vote about adding the removed people as extra members, but there
>  is not enough time before teh STF deadline)
> 
> -Andriy Gelman
> -Carl Eugen Hoyos
> +Logan Lyu
> 
> (Theres also a wrong (@ffmpeg.org)  address appearing for wenbin chen,
>  i will continue to use the correct one, thats clearly a bug)
> 
> (I will also update the ga ffmpeg.org alias)

The previous GA is reachable under old-ga ffmpeg.org

not sure if its useful but it was easy to keep for reference

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Vote STF/SPI 2024-02

[Michael Niedermayer]

On Sat, Feb 03, 2024 at 04:37:54AM +0100, Michael Niedermayer wrote:
> On Thu, Feb 01, 2024 at 05:29:26AM +0100, Michael Niedermayer wrote:
> > Hi all
> > 
> > To do the STF/SPI thing properly, and make sure we do what the Community 
> > wants.
> > We should do this vote: (unless lots of people reply and say we should skip 
> > the vote)
> > (i am also CCing jonatan to make sure the option in the vote actually ask 
> > the GA the
> >  right question)
> > 
> > The vote description will be as follows:
> > The STF/SPI has suggested us to submit an Application / Scope of work 
> > before their february meeting.
> > There are about 2 weeks left.
> > The minimum grant is 150 000 €
> > The next STF meeting is expected to be in may. If we submit in february and 
> > are not selected
> > we can probably try again in may. Which would increase our chances
> > If we do not submit in february we can probably submit in may.
> > There is no guarantee that money will be available in may, for example 
> > between october 2023
> > and february 2024 no funds where available AFAIK.
> > Wiki page is here: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> > 
> > 
> > Option A. The Application and Scope of Work from the WIKI shall be 
> > submitted to STF/SPI before the february 2024 meeting, disagreements in it 
> > shall be decided by the TC. To achieve continuity, submission shall be done 
> > by the same person as previous if possible.
> > 
> > Option B. No Application and Scope of Work shall be submitted in february 
> > 2024
> > 
> > 
> > This is a RFC, so if you see errors in it please suggest changes
> 
> I intend to start the vote in teh next 24h or so.

Vote started, you should have received a mail if you are in the GA
and you should not have received a mail if you are not in the GA
50 mails where sent and there are 50 in the script output.
I hope that no messup happened in this vote

Please Vote!

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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 1/3 v7] avformat: add a Tile Grid stream group type

[James Almer]

This will be used to support tiled image formats like HEIF.

Signed-off-by: James Almer 
---
Fixed comment about sizeof(AVStreamGroupTileGrid).

 libavformat/avformat.c |   5 +++
 libavformat/avformat.h | 100 +
 libavformat/dump.c |  29 
 libavformat/options.c  |  32 +
 4 files changed, 166 insertions(+)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..32ef440207 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
 av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
 break;
 }
+case AV_STREAM_GROUP_PARAMS_TILE_GRID:
+av_opt_free(stg->params.tile_grid);
+av_freep(&stg->params.tile_grid->offsets);
+av_freep(&stg->params.tile_grid);
+break;
 default:
 break;
 }
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..0b1c2e46b5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,10 +1018,109 @@ typedef struct AVStream {
 int pts_wrap_bits;
 } AVStream;
 
+/**
+ * AVStreamGroupTileGrid holds information on how to combine several
+ * independent images on a single grid for presentation. None of the tiles may
+ * overlap inside the grid.
+ *
+ * The following is an example of a simple grid with 3 rows and 4 columns:
+ *
+ * +---+---+---+---+
+ * | 0 | 1 | 2 | 3 |
+ * +---+---+---+---+
+ * | 4 | 5 | 6 | 7 |
+ * +---+---+---+---+
+ * | 8 | 9 |10 |11 |
+ * +---+---+---+---+
+ *
+ * Assuming all tiles have a dimension of 512x512, the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the first @ref AVStreamGroup.streams "stream" in the group is "0,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the second @ref AVStreamGroup.streams "stream" in the group is "512,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the fifth @ref AVStreamGroup.streams "stream" in the group is "0,512", the
+ * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
+ * the sixth @ref AVStreamGroup.streams "stream" in the group is "512,512",
+ * etc.
+ *
+ * sizeof(AVStreamGroupTileGrid) is not a part of the ABI and may only be
+ * allocated by avformat_stream_group_create().
+ */
+typedef struct AVStreamGroupTileGrid {
+const AVClass *av_class;
+
+/**
+ * Width of the final image in the grid.
+ *
+ * Must be > 0.
+ */
+int coded_width;
+/**
+ * Width of the final image in the grid.
+ *
+ * Must be > 0.
+ */
+int coded_height;
+
+/**
+ * An @ref AVStreamGroup.nb_streams "nb_streams" sized array of offsets in
+ * pixels from the topleft edge of the grid, indicating where each stream
+ * should be placed.
+ * It must be allocated with the av_malloc() family of functions.
+ *
+ * - demuxing: set by libavformat, must not be modified by the caller.
+ * - muxing: set by the caller before avformat_write_header().
+ *
+ * Freed by libavformat in avformat_free_context().
+ */
+struct {
+int x;
+int y;
+} *offsets;
+
+/**
+ * Offset in pixels from the left edge of the grid where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and <= @ref coded_width.
+ */
+int horizontal_offset;
+/**
+ * Offset in pixels from the top edge of the grid where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and <= @ref coded_height.
+ */
+int vertical_offset;
+
+/**
+ * Width of the final image for presentation.
+ *
+ * Must be > 0 and <= (@ref coded_width - @ref horizontal_offset).
+ * When it's not equal to (@ref coded_width - @ref horizontal_offset), the
+ * result of (@ref coded_width - width - @ref horizontal_offset) is the
+ * amount amount of pixels to be cropped from the right edge of the
+ * final image before presentation.
+ */
+int width;
+/**
+ * Height of the final image for presentation.
+ *
+ * Must be > 0 and <= (@ref coded_height - @ref vertical_offset).
+ * When it's not equal to (@ref coded_height - @ref vertical_offset), the
+ * result of (@ref coded_height - height - @ref vertical_offset) is the
+ * amount amount of pixels to be cropped from the bottom edge of the
+ * final image before presentation.
+ */
+int height;
+} AVStreamGroupTileGrid;
+
 enum AVStreamGroupParamsType {
 AV_STREAM_GROUP_PARAMS_NONE,
 AV_STREAM_GROUP_PARAMS_IAMF_AUDIO_ELEMENT,
 AV_STREAM_GROUP_PARAMS_IAMF_MIX_PRESENTATION,
+AV_STREAM_GROUP_PARAMS_TILE_GRID,
 };
 
 struct AVIAMFAudioElement;
@@ -1062,6 +1161,7 @@ typedef struct AVStreamGroup {
 union {
 struct AVIAMFAudioElement *iamf_audio_element;
 stru

[FFmpeg-devel] [PATCH 2/3 v5] avformat/mov: add support for tile HEIF still images

[James Almer]

Export each tile as its own stream, and the grid information as a Stream Group
of type TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too. For those, the primary stream will be
tagged with the default disposition.

Based on a patch by Swaraj Hota

Signed-off-by: James Almer 
---
Now supports exporting more than one grid if present, as well as the item name
for the grid as stream group metadata.

 libavformat/avformat.h |   6 +
 libavformat/dump.c |   2 +
 libavformat/isom.h |  15 +-
 libavformat/mov.c  | 343 +
 4 files changed, 339 insertions(+), 27 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 0b1c2e46b5..ad95306efb 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -811,6 +811,12 @@ typedef struct AVIndexEntry {
  * The video stream contains still images.
  */
 #define AV_DISPOSITION_STILL_IMAGE  (1 << 20)
+/**
+ * The video stream is intended to be merged with another stream before
+ * presentation.
+ * Used for example to signal the stream contains a tile from a HEIF grid.
+ */
+#define AV_DISPOSITION_TILE (1 << 21)
 
 /**
  * @return The AV_DISPOSITION_* flag corresponding to disp or a negative error
diff --git a/libavformat/dump.c b/libavformat/dump.c
index c9b7369bcd..de0e1d8b39 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -640,6 +640,8 @@ static void dump_stream_format(const AVFormatContext *ic, 
int i,
 av_log(NULL, log_level, " (still image)");
 if (st->disposition & AV_DISPOSITION_NON_DIEGETIC)
 av_log(NULL, log_level, " (non-diegetic)");
+if (st->disposition & AV_DISPOSITION_TILE)
+av_log(NULL, log_level, " (tile)");
 av_log(NULL, log_level, "\n");
 
 dump_metadata(NULL, st->metadata, extra_indent, log_level);
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 77221d06e4..cedbd237d6 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -264,15 +264,24 @@ typedef struct MOVStreamContext {
 
 typedef struct HEIFItem {
 AVStream *st;
+char *name;
 int item_id;
 int64_t extent_length;
 int64_t extent_offset;
-int64_t size;
+int tile_rows;
+int tile_cols;
 int width;
 int height;
 int type;
+int is_idat_relative;
 } HEIFItem;
 
+typedef struct HEIFGrid {
+HEIFItem *item;
+int16_t *tile_id_list;
+int nb_tiles;
+} HEIFGrid;
+
 typedef struct MOVContext {
 const AVClass *class; ///< class for private options
 AVFormatContext *fc;
@@ -336,6 +345,10 @@ typedef struct MOVContext {
 int cur_item_id;
 HEIFItem *heif_item;
 int nb_heif_item;
+HEIFGrid *heif_grid;
+int nb_heif_grid;
+int thmb_item_id;
+int64_t idat_offset;
 int interleaved_read;
 } MOVContext;
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5fae777adb..237516ed0a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -185,6 +185,30 @@ static int mov_read_mac_string(MOVContext *c, AVIOContext 
*pb, int len,
 return p - dst;
 }
 
+static AVStream *get_curr_st(MOVContext *c)
+{
+AVStream *st = NULL;
+
+if (c->fc->nb_streams < 1)
+return NULL;
+
+for (int i = 0; i < c->nb_heif_item; i++) {
+HEIFItem *item = &c->heif_item[i];
+
+if (!item->st)
+continue;
+if (item->st->id != c->cur_item_id)
+continue;
+
+st = item->st;
+break;
+}
+if (!st)
+st = c->fc->streams[c->fc->nb_streams-1];
+
+return st;
+}
+
 static int mov_read_covr(MOVContext *c, AVIOContext *pb, int type, int len)
 {
 AVStream *st;
@@ -1767,9 +1791,9 @@ static int mov_read_colr(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 uint16_t color_primaries, color_trc, color_matrix;
 int ret;
 
-if (c->fc->nb_streams < 1)
+st = get_curr_st(c);
+if (!st)
 return 0;
-st = c->fc->streams[c->fc->nb_streams - 1];
 
 ret = ffio_read_size(pb, color_parameter_type, 4);
 if (ret < 0)
@@ -2117,9 +2141,9 @@ static int mov_read_glbl(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 AVStream *st;
 int ret;
 
-if (c->fc->nb_streams < 1)
+st = get_curr_st(c);
+if (!st)
 return 0;
-st = c->fc->streams[c->fc->nb_streams-1];
 
 if ((uint64_t)atom.size > (1<<30))
 return AVERROR_INVALIDDATA;
@@ -4951,12 +4975,10 @@ static int heif_add_stream(MOVContext *c, HEIFItem 
*item)
 st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
 st->codecpar->codec_id = mov_codec_id(st, item->type);
 sc->ffindex = st->index;
-c->trak_index = st->index;
 st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
 st->time_base.num = st->time_base.den = 1;
 st->nb_frames = 1;
 sc->time_scale = 1;
-sc = st->priv_data;
 sc->pb = c->fc->pb;
 sc->pb_is_copied = 1;
 
@@ -7784,11 +7806,55 @@ static int mov_read_pitm(MOVContext *c, AVIOCont

[FFmpeg-devel] [PATCH 3/3 v4] fate/mov: test remuxing all stream heif items

[James Almer]

Signed-off-by: James Almer 
---
No changes since last version.

 tests/fate/mov.mak   | 2 +-
 tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index f202f36d96..f549ae33d7 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -156,7 +156,7 @@ fate-mov-heic-demux-still-image-1-item: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif
 
 FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \
+= fate-mov-heic-demux-still-image-multiple-items
-fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy
+fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy -map 0
 
 # Resulting remux should have:
 # 1. first audio stream with AV_DISPOSITION_HEARING_IMPAIRED
diff --git a/tests/ref/fate/mov-heic-demux-still-image-multiple-items 
b/tests/ref/fate/mov-heic-demux-still-image-multiple-items
index c850c1ff9c..753cef267a 100644
--- a/tests/ref/fate/mov-heic-demux-still-image-multiple-items
+++ b/tests/ref/fate/mov-heic-demux-still-image-multiple-items
@@ -2,10 +2,17 @@
 #version: 2
 #hash: MD5
 #extradata 0, 100, 5444bf01e03182c73ae957179d560f4d
+#extradata 1, 100, 5444bf01e03182c73ae957179d560f4d
 #tb 0: 1/1
 #media_type 0: video
 #codec_id 0: hevc
 #dimensions 0: 1280x720
 #sar 0: 0/1
+#tb 1: 1/1
+#media_type 1: video
+#codec_id 1: hevc
+#dimensions 1: 1280x720
+#sar 1: 0/1
 #stream#, dts,pts, duration, size, hash
 0,  0,  0,1,   111554, 03ceabfab39afd2e2e796b9362111f32
+1,  0,  0,1,   112393, daa001d351c088a5bc328459e2501c95
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/nutenc: Fix indentation

[Leo Izen]

On 2/3/24 14:20, Andreas Rheinhardt wrote:

Forgotten after 82beb46e65e5f820b187355bf757725c22a59c45.
Also use loop-scope for iterators while at it.

Signed-off-by: Andreas Rheinhardt 
---
  libavformat/nutenc.c | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index a5198c7ca9..5e0e36babe 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -1063,21 +1063,21 @@ static int nut_write_packet(AVFormatContext *s, 
AVPacket *pkt)
  ffio_free_dyn_buf(&dyn_bc);
  
  if (nut->write_index) {

-if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/, 
pkt->dts)) < 0)
-goto fail;
-
-if ((1ll<<60) % nut->sp_count == 0)
-for (i=0; inb_streams; i++) {
-int j;
-StreamContext *nus = &nut->stream[i];
-av_reallocp_array(&nus->keyframe_pts, 2*nut->sp_count, 
sizeof(*nus->keyframe_pts));
-if (!nus->keyframe_pts) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-for (j=nut->sp_count == 1 ? 0 : nut->sp_count; 
j<2*nut->sp_count; j++)
-nus->keyframe_pts[j] = AV_NOPTS_VALUE;
-}
+if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/, 
pkt->dts)) < 0)
+goto fail;
+
+if ((1ll<<60) % nut->sp_count == 0)
+for (unsigned i = 0; i < s->nb_streams; i++) {
+StreamContext *nus = &nut->stream[i];
+av_reallocp_array(&nus->keyframe_pts, 2*nut->sp_count, 
sizeof(*nus->keyframe_pts));
+if (!nus->keyframe_pts) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+for (int j = nut->sp_count == 1 ? 0 : nut->sp_count;
+ j < 2 * nut->sp_count; j++)
+nus->keyframe_pts[j] = AV_NOPTS_VALUE;
+}
  }
  }
  av_assert0(nus->last_pts != AV_NOPTS_VALUE);


If we're changing this block of code anyway, could we possibly replace 
this line:


if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 
/*unused*/, pkt->dts)) < 0)

goto fail;

With something like this?

ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/, pkt->dts);
if (ret < 0)
goto fail;

It's a bit cleaner.



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".