[FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_scale: switch to new swscale API

[Niklas Haas]

On Fri, 06 Dec 2024 20:57:54 +0100 Michael Niedermayer <michael at niedermayer.cc> wrote:
> Hi
>
> On Fri, Dec 06, 2024 at 02:40:06PM +0100, Niklas Haas wrote:
> > On Fri, 06 Dec 2024 14:31:43 +0100 Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > Hi
> > >
> > > On Mon, Nov 25, 2024 at 10:11:49AM +0000, Niklas Haas wrote:
> > > > ffmpeg | branch: master | Niklas Haas <git at haasn.dev> | Fri Jun 28 21:42:23 2024 +0200| [04ce01df0bb2d66e143bcfcea439afc2a1b8d96e] | committer: Niklas Haas
> > > >
> > > > avfilter/vf_scale: switch to new swscale API
> > > >
> > > > Most logic from this filter has been co-opted into swscale itself,
> > > > allowing the resulting filter to be substantially simpler as it no
> > > > longer has to worry about context initialization, interlacing, etc.
> > > >
> > > > Sponsored-by: Sovereign Tech Fund
> > > > Signed-off-by: Niklas Haas <git at haasn.dev>
> > > >
> > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=04ce01df0bb2d66e143bcfcea439afc2a1b8d96e
> > > > ---
> > > >
> > > >  libavfilter/vf_scale.c | 351 +++++++++++--------------------------------------
> > > >  1 file changed, 77 insertions(+), 274 deletions(-)
> > >
> > > It seems this broke:
> > >
> > > ./ffmpeg -i mm-short.mpg -vcodec prores -vframes 3 -bitexact -an prores.mkv
> > > ./ffplay prores.mkv
> > >
> > > [swscaler @ 0x7f76380068c0] Unsupported input (Operation not supported): fmt:yuv422p10le csp:gbr prim:reserved trc:reserved -> fmt:yuv420p csp:bt709 prim:reserved trc:reserved
> >
> > What is the meaning of AVCOL_*_RESERVED and why should we accept it here?
> >
> > If you look at e.g. H.273, it clearly reserves these values for future use,
> > and so IMHO treatind them as invalid inputs is not entirely incorrect.
> >
> > Could we fix the prores decoder to instead output UNSPECIFIED?
>
> the decoder should probably output the value stored in the file.
>
> I have to say its a little odd a file generated by ffmpeg contains a
> reserved value but how do i know without a prores spec ...
>
> Now even if theres an argument for the prores decoder not to output that
> value here. Another decoder and other file could still have exactly that
> reserved value. And in that case that decoder should output that

Should we:

1) Treat RESERVED as UNSPECIFIED
2) Accept RESERVED only when no tranformation is needed (i.e. keep the input
   as RESERVED, fail if the user requests a conversion to a specific csp)
3) Preserve the current behavior of rejecting RESERVED outright
?

What makes this a bit annoying is that we typically reject RESERVED inside
the lavfi filter chain; and I was certainly hoping to add e.g. transfer
function support to the filter negotiation code at some point.

>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".