On Fri, 06 Dec 2024 20:57:54 +0100 Michael Niedermayer <mich...@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 > > <mich...@niedermayer.cc> wrote: > > > Hi > > > > > > On Mon, Nov 25, 2024 at 10:11:49AM +0000, Niklas Haas wrote: > > > > ffmpeg | branch: master | Niklas Haas <g...@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 <g...@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@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".
