[FFmpeg-devel] [GSoC] FFserver further development direction

[Josh de Kock]

On 2018/04/24 22:33, Stephan Holljes wrote:
> Hi all,
> 
> I've discussed this on IRC a bit, but I don't want to exclude those
> views that are not present there.
> 
> The consensus seems to be that there are more disadvantages in using
> the http server of libavformat than there are advantages.

I honestly think that it was misguided to add an HTTP server in its 
current form to FFmpeg and this isn't a job for libavformat.

> This arose partly out of the discussion that there is no way to get a
> connected peer's address through the public API (as the filedescriptor
> is hidden in private structs).

Generally, adding more things to public API is a bad move, but I am 
unsure in this case (how would it work cross-platform anyway?)

> The alternatives that were discussed were libmicrohttpd or writing the
> whole project as an nginx module.

There is already an nginx module (with a more permissive 2-Clause BSD 
license, see: https://github.com/arut/nginx-rtmp-module) which seemingly 
does most of what you would want from a streaming server:

- RTMP/HLS/MPEG-DASH live streaming
- Stream relay support for distributed streaming: push & pull models
- Online transcoding with FFmpeg
- Recording streams

> Both have their share of advantages and disadvantages. While I have
> started to read the documentation on both of these, I can't clearly
> point out which is the better choice.

It may be a good idea to make a list (or point me to one you've already 
made if I have missed it) which highlights all the features which an 
ideal FFserver would have, then look again at both of these options. 
Check how far this ideal is from the current nginx module.

> Most people (including my mentor) spoke out in favor of utilizing nginx
As others have pointed out before, this, of course, excludes users who 
would like to use something like Apache, or even not run a separate 
web-server at all--however, how many users this affect and the actual 
impact not directly supporting those would have is debatable. There are 
already guides on how to use the nginx-rtmp module + Apache together in 
a streaming setup, for those whose setups are so large they must 
continue to use Apache.

> I'd like to know what the rest of the developers think is best for the
> project. Any pointers to good alternatives to look at or things to
> think of we are missing are appreciated!

My suggestion would be to revisit all the current HTTP code in FFmpeg, 
and evaluate how much of it *actually* needs to be within the libraries, 
and how much of it can be delegated to good external libraries. (Someone 
recently made me aware of https://github.com/nodejs/http-parser it may 
be useful in some regards).

> I am already not sure how to incorporate rtp into an nginx module
> (since it is one of the goals on the roadmap). Maybe someone knows how
> to either work around it or knows a project where that was done?

There doesn't seem to be any current project which implemented RTSP as a 
nginx module, but remember that nginx is a reverse proxy in itself and 
if it cannot be done within nginx as a module then you could implement a 
RTSP server which is then sent through nginx (I'm unsure why RTSP 
couldn't be implemented as a module though, but whatever). As for how to 
write an nginx module to do it, I honestly have no idea, but I would be 
happy to learn and support you along with your official mentor if you wish.

-- 
Josh