[FFmpeg-devel] GSoC

[Nicolas George]

Hi, and welcome back.

Stephan Holljes (2018-02-26):
> seeing that people are already applying for projects, I think I should as well.
> 
> My name is Stephan Holljes, on IRC I go by klaxa. Some may remember me
> from GSoC 2015 where I implemented the (how I later found out
> controversly debated) HTTP-Server API.
> 
> Since someone else already applied for the DICOM project, which I
> would also like to do, maybe instead I could work on an ffserver
> replacement, since it has been dropped recently. Maybe some have
> already seen my mkv-server (https://github.com/klaxa/mkvserver_mk2/)
> which was mentioned a few times on the ML. I think it could serve as a
> starting point, since it already only uses the public API.

I do not know what features you have in mind exactly for this project,
but it reminds me of a pet project that I have: a muxer that acts as a
multi-clients server.

It would work like the tee muxer: frames sent to the muxer are
duplicated and re-muxed into several slave muxers. The difference is be
that the list of slave muxers is not set at the beginning but evolves
when clients connect and disconnect.

I have not given much thought on the way of doing it expressive enough
so that it would not be just a toy. Using programs to allow the server
to provide different streams? Using attachments to send non-live files?

Anyway, if somebody wants to achieve anything in that direction within
the FFmpeg project, I am pretty sure it would require a big cleanup of
the inconsistent mess that is the network code currently.

Due to personal stuff, I do not feel up to offering mentoring this year
either, but I can share my thoughts on the issue and help as much as I
can.

The big but not-that-hard part of the issue would be to design and
implement a real event loop with enough features.

It needs to be able to run things in separate threads when they need to
react with low latency. That is the infamous "UDP thread". Note that a
single thread should be able to handle several low-latency network
streams, if it is not burdened by heavy computation at the same time.

It needs to be able to run things in separate threads to integrate
protocols that have not been integrated with it. Lightweight
collaborative threads could be used, but they do not seem to exist with
an up-to-date portable API.

Protocols that rely on sub-protocols (HTTP→TCP, RTP→UDP, etc.) need to
be updated to make use of the even loop instead of querying directly
their slaves. Protocols will probably need to be attached to an event
loop.

That means having an event loop will be mandatory when using the current
AVIO API: its implementation must be updated to create one on the fly as
needed. But they need to be deprecated too.

Some work need to be done on demuxers to make them non-blocking. I think
the best approach is to keep using the push/pull pattern: instead of
providing an AVIO to a demuxer, push it data as it arrives, and then try
to read the frames, or maybe rely on a callback.

Demuxers that have not been updated for that API and rely heavily on
blocking reads of the exact amount of data they need will probably need
to be run in separate threads (again, if we could have lightweight
threads…).

All this is only the skeleton of the ideas I have accumulated for these
issues. It would make very interesting and stimulating work.
Unfortunately, I do not have the time to work on it at the time. Nor do
I have the energy to fight all the negativity that such an endeavour
would elicit from some people. But if somebody is interested I would be
happy to share details about any part of the plan.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180227/52996724/attachment.sig>