Re: [FFmpeg-devel] [PATCH 4/4] avcodec/ffv1enc: avoid slices larger than 360x288 if no value is specified

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3227 bytes --]

On Sun, Apr 06, 2025 at 10:13:23PM -0300, James Almer wrote:
> On 4/6/2025 8:44 PM, Michael Niedermayer wrote:
> > On Sun, Apr 06, 2025 at 08:29:42PM -0300, James Almer wrote:
> > > On 4/3/2025 7:50 AM, Michael Niedermayer wrote:
> > > > This improves speed by providing more independent things for more CPUs
> > > > 
> > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > > ---
> > > >    libavcodec/ffv1enc.c                             |  6 +++++-
> > > >    .../ref/fate/matroska-mastering-display-metadata | 16 ++++++++--------
> > > >    2 files changed, 13 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
> > > > index ce3f8e023e5..221344794e2 100644
> > > > --- a/libavcodec/ffv1enc.c
> > > > +++ b/libavcodec/ffv1enc.c
> > > > @@ -581,7 +581,11 @@ int ff_ffv1_encode_determine_slices(AVCodecContext *avctx)
> > > >                    if (  ff_need_new_slices(avctx->width , s->num_h_slices, s->chroma_h_shift)
> > > >                        ||ff_need_new_slices(avctx->height, s->num_v_slices, s->chroma_v_shift))
> > > >                        continue;
> > > > -            if (avctx->slices == s->num_h_slices * s->num_v_slices && avctx->slices <= MAX_SLICES || !avctx->slices)
> > > > +            if (avctx->slices == s->num_h_slices * s->num_v_slices && avctx->slices <= MAX_SLICES)
> > > > +                return 0;
> > > > +            if (maxw*maxh > 360*288)
> > > > +                continue;
> > > > +            if (!avctx->slices)
> > > >                    return 0;
> > > >            }
> > > >        }
> > > > diff --git a/tests/ref/fate/matroska-mastering-display-metadata b/tests/ref/fate/matroska-mastering-display-metadata
> > > > index 91ce6a05584..6a2ff15b1b2 100644
> > > > --- a/tests/ref/fate/matroska-mastering-display-metadata
> > > > +++ b/tests/ref/fate/matroska-mastering-display-metadata
> > > > @@ -1,7 +1,7 @@
> > > > -ad5e3c4e338599c81ef7d0f9ae25f871 *tests/data/fate/matroska-mastering-display-metadata.matroska
> > > > -1669589 tests/data/fate/matroska-mastering-display-metadata.matroska
> > > > +c1e5e2ecf433cf05af8556debc7d4d0b *tests/data/fate/matroska-mastering-display-metadata.matroska
> > > > +1669773 tests/data/fate/matroska-mastering-display-metadata.matroska
> > > >    #extradata 0:        4, 0x040901a3
> > > > -#extradata 3:      200, 0x506463a8
> > > > +#extradata 3:      202, 0xfce96279
> > > 
> > > Why did extradata change? Slice dimension value changes?
> > 
> > yes, any reason you belive theres an issue ?
> 
> No, just wanted to know why the size of extradata changed.

yes, 1280x720 used 2x2 slice configuration before and now uses 3x3
2x2 is stored as storing the value 1 twice
and 3x3 stores the value 2 twice
thats 4 range coded binary values more in the bitstream.
Its a bit surprising that these end up needing 2 bytes more though
but its possible if most of the other stuff is "1" and not "2" values
than the cost of storing a "2" can be higher

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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