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