Thank you for your replies so far. On Tue, Apr 24, 2018 at 11:46 PM, Nicolas George <geo...@nsup.org> wrote: > Stephan Holljes (2018-04-24): >> The consensus seems to be that there are more disadvantages in using >> the http server of libavformat than there are advantages. > > I completely disagree. There is no point in having the HTTP server in > libavformat if it cannot be used to implement exactly that kind of > thing. Implementing ffserver with it is just the test bed that it > requires to become mature. > > The HTTP server in libavformat was accepted three years ago, and you > worked hard for it. Do not let people tell you it was for nothing. They > had their chance to discuss this three years ago. >
Thank you for these encouraging words. I personally agree, but I am afraid to make the wrong call here, because I think other developers are more experienced and know better what works and what doesn't. >> 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). > > Well, then, let us add the functions that are needed in the public API. > It does not seem that difficult to design. > I think so too, more comments below. On Wed, Apr 25, 2018 at 2:24 AM, Helmut K. C. Tessarek <tessa...@evermeet.cx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I'm not an ffmpeg developer, but I do have experience in software > engineering and ddesign. > > On 2018-04-24 17:33, Stephan Holljes wrote: >> 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). > > How about adding this to the public API then? This was my initial question in the channel. I asked what would be the apropriate place to add the address. Adding it as a metadata AVDict (to AVIOContext or URLContext? that was never clearly discussed) came up as a suggestion. Maybe there is an even more elegant way? > >> Most people (including my mentor) spoke out in favor of utilizing >> nginx. > > This makes no sense at all. So now people who are using Apache are > supposed to use nginx to get a working ffserver implementation? > This is definitely a big downside of pulling in the nginx dependency. I would actually also prefer to have a "standalone" program. Maybe it's not out of the question to design ffserver's API in a way that can be exposed in a library and writing an nginx module becomes "trivial"? I'm not sure if this might be too big of a task or not hard at all. I have the feeling that it should not be impossible at least? Again thank you for your thoughts! Stephan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
