On Mon, 24 Jun 2024 16:44:33 +0200 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Sun, Jun 23, 2024 at 7:57 PM James Almer <jamr...@gmail.com> wrote: > > > On 6/22/2024 7:19 PM, Vittorio Giovara wrote: > > > Needless to say I support the plan of renaming the library so that it can > > > be inline with the other libraries names, and the use of a separate > > header > > > since downstream applications will need to update a lot to use the new > > > library (or the new apis in the existing library) and/or we could > > provide a > > > thin conversion layer when the new lib is finalized. > > > > I don't quite agree with renaming it. As Michael already pointed out, > > the av prefix wouldn't fit a scaling library nor a resampling one, as > > they only handle one or the other. > > > > by that reasoning we should ban all subtitles from all the libraries > > av is a shorthand of multimedia and many people in the industry refer to > ffmpeg libs as "libav*" so it feels a bit odd to push for preserving an > alternative name > > > > There's also the precedent of avresample, which was ultimately dropped > > in favor of swresample, so trying to replace swscale with a new avscale > > library will be both confusing and going against what was already > > established. > > > it's still 4 libraries vs 2... and swr/avr is shrouded in bad history that > is not worth bringing up > > I'd understand opposing a rename just for the sake of renaming, but this is > essentially a new library, i see no value in preserving the old naming > scheme, if not making downstream life worse :x
There is a strong motivating reason to keep <avscale.h> (or whatever name we decide on) and <swscale.h> inside the same *library*, which is that they both will need to access sws' internal implementation (ff_sws_* functions). After a bit of further planning, the current best approach seems to be to build the new abstraction directly on top of ff_sws_init_scale() and ff_sws_init_input/output_funcs(), with wholly new code for dispatching the underlying operations in the correct order. So I am currently no longer planning on directly wrapping SwsContext at all. I am also seeing increasingly more hurdles and less benefits to the idea of directly re-using sws_scale_frame() for the new API. I think that, in the interest of my own sanity, for the initial development phase I will go forward with defining a second header file for the new API; and then only once we've tested it and are confident that it works as intended, we can think about re-defining sws_scale() etc. as a wrapper on top of this new API. > -- > Vittorio > _______________________________________________ > 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".
