[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Lynne]

On 17/06/2024 20:34, Michael Niedermayer wrote:
> On Tue, Apr 30, 2024 at 07:42:53PM +0200, Michael Niedermayer wrote:
>> On Mon, Apr 22, 2024 at 01:32:27PM +0200, Lynne wrote:
>>> Apr 22, 2024, 13:07 by stefasab at gmail.com:
>>>
>>>> On date Sunday 2024-04-21 22:12:56 -0300, James Almer wrote:
>>>>
>>>>> On 4/17/2024 10:58 AM, Michael Niedermayer wrote:
>>>>>
>>>> [...]
>>>>
>>>>> A full rewrite of ffserver, using only public API, and with modern streaming
>>>>> in mind. It would give a lot of code in lavf some use.
>>>>>
>>>>
>>>> If this is going to happen, my advice is to use "ffstream" to stick to
>>>> the ffVERB convention (with the exeption of ffmpeg, which might still
>>>> be converted to ffconvert with some proper aliasing) and to avoid
>>>> association with the old incompatible tool .
>>>>
>>>
>>> That's basically what txproto is, only that it also does transcoding
>>> and filtering. It can accept incoming streams and output them to
>>> multiple destinations via remux or transcode. It was built as an
>>> ffmpeg.c with a scriptable interface and with dynamic switching.
>>> It doesn't do this out of the box, it's something you have to script,
>>> but that was largely the case that ffserver had.
>>>
>>> What is missing is something that ffserver had, which was that
>>> it was able to express exactly what lavf had in its context on both
>>> the sender and receiver, for which it needed private APIs.
>>> AVTransport can largely fill that niche.
>>
>> hmm
>> how would we (assert(people agreeing)) go from what you describe
>> to a (very easy to use) ffserver "2.0" in something on the ffmpeg.org download page
>> ?
> 
> also if you look at google trends, even today more people search for ffserver
> than txproto. In fact at every point in time more people searched for ffserver
> than txproto.
> 
> https://trends.google.com/trends/explore?date=all&q=txproto,ffserver
> 
> So even though ffserver is dead, removed and unmaintained, it has more
> users
> 
> And this comes back to what i said many times. We should use the name
> FFmpeg, our domain and NOT push every bit of new inovation out into
> sub projects.
> 
> We should put a newly developed ffserver into the main ffmpeg git.
> We should put wasm build support into the main ffmpeg git.
> We should turn ffplay into a fully competetive player.

Forgot to respond to this.
I agree that txproto is a stupid name which stuck around when I 
absolutely had to give it some name, and I hope to change it to a more 
suitable one, one day.

I'm not sure what to call it, as it could partially fulfill the duties 
of ffserver, ffplay and ffmpeg all at once. Its a high level Lua, and C, 
wrapper around all the libraries that simply lets users dynamically link 
and unlink components, while handling the flow of frames and packets 
entirely for you. It still lets you optionally handle low-level packets 
and frames via callbacks, so you can still do frame-precise stuff, like 
applying a filter to only one specific frame.
It provides a C library, and a CLI.

There's even code for GUIs present, though the only functionality that 
code has is to present a stream of AVFrames on screen, and draw a 
rectangle (used for screenshot region selection). It already has 
handling for keyboard/mouse inputs, so it should be easy to integrated 
ImGui or nuklear for something more complete. Everything related to 
displaying is done via libplacebo.

I think its possibly maybe close enough to what users have been asking 
us for, and a little more.

I've written very well integrated backends for interfacing to the OS, so 
it can use them much better than ffmpeg could ever use avdevice, and 
lets the code do much, from local/networked transcoding, relaying, 
monitoring, presenting to screen and recording, which you can check out 
here:
https://github.com/cyanreg/txproto/tree/master/DOCS/examples

It could in theory perform the duties of ffplay and ffserver as well as 
any of them can/could. But not ffmpeg, due to the huge amount of 
specific handling for various cases we have there.

I would be fine with moving the code under a repository administered by 
the project that we can all contribute, work on, and perhaps one day 
officially offer as software alongside all the rest of the projects we 
work on, if there's enough interest and consensus from the community.
The codebase is completely LGPL2+ like ours, and it uses as much of all 
of our libraries as possible, including routines to allocate memory.
I would not merge this into our main repository though, no way.

It is currently used in production, though under controlled and 
predictable circumstances. So its not recommended to general users.
There are many known issues that I'm working on fixing, and error 
handling is quite bad currently.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA2FEA5F03F034464.asc
Type: application/pgp-keys
Size: 624 bytes
Desc: OpenPGP public key
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240619/592e3c36/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240619/592e3c36/attachment.sig>