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