On Tue, Feb 27, 2018 at 8:13 PM, Nicolas George <geo...@nsup.org> wrote:
> Hi, and welcome back.

Thanks you, and thanks for the feedback.

>
> 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.

More protocols than HTTP (presumably RTP and/or RTMP although I cannot
guess how much work that would be) and/or HTTP-based protocols like
DASH or HLS? I recently discussed this with a friend too, who argued
that webservers already do a lot of optimization regarding connection
handling and that implementing it again would be somewhat reinventing
the wheel. So I'm not too sure about the usefulness of that.

>
> 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?

In fact the project I posted already does that, while for the time
being only for video files and only for a single stream, but the
architecture allows for any number of streams to be served.

>
> 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.

Since I have only had somewhat in-depth insight into http and tcp I'll
have to do quite some research on the other protocols.

>
> 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.

I'm not sure I understand. So far I could implement everything just
using the public http api without any modifications.

>
> 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.

So far my project implements an event-loop, in which any number of
(pthreads-)threads can be used to process data transfer from the
server to the client. The state of each client transfer is stored in a
struct which is protected by pthread_mutex locks during modification.
Each of these worker threads is stateless and does work depending on
the state of the client structs. A separate thread handles accepting
the connection and sending the muxed header. Yet another separate
thread reads the input file.

>
> 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…).

Again I'll probably have to do quite some research on this. So far
things have worked pretty okay-ish with blocking calls, but I guess
that's also because threads are kind of a giant hack?

>
> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Again thanks for your thoughts!

Regards,
Stephan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to