Re: [FFmpeg-devel] RFC: opinions on making fftools work like a library

[Anton Khirnov <anton@khirnov.net>]

Quoting Zhao Zhili (2023-03-19 06:04:55)
> 
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Anton Khirnov
> > Sent: 2023年3月18日 2:12
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] RFC: opinions on making fftools work like a library
> > 
> > Quoting Zhao Zhili (2023-03-03 19:15:03)
> > > I'd like to know what do you think about making fftools work like a
> > > library, like what ffmpeg-kit already did, but with built-in support.
> > 
> > Maybe you should first clarify what exactly do you mean by "work like a
> > library". Meaning literally turn it into a library with a C API you can
> > call? That would be a massive amount of work, though my current
> > refactorings are moving in that direction.
> > Or provide stronger guarantees for commandline options? Or something
> > else?
> 
> I mean user can simply rename main() to something like ffmpeg_main() and build
> it as a library, even without directly support in our build system. Sometimes
> user just want to copy-paste and run ffmpeg cmdline on mobile.

I don't really understand where does "mobile" come into this and why
should we bend over backwards to work around crippled platforms.

> Some projects already did this, but they need to tweak the source code to
> reset global states each time, avoiding exit() and so on. These projects cannot
> benefit from your refactor work until they rebase their projects on new version
> of fftools.

While I personally do agree that a well-written program's main() should
be reentrant, this is not exactly a mainstream view. And as I said - the
amount of work to do this properly is immense.
It is technically possible to do this "improperly", meaning just put all
global state into an FFmpegContext that's allocated in main, then pass
it to all functions. But this just papers over the actuall issues, not
to mention that making stability guarantees for such an abomination
would cripple development

-- 
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-request@ffmpeg.org with subject "unsubscribe".