[FFmpeg-devel] [GSoC] FFserver further development direction
klaxa1337 at googlemail.com
Wed Apr 25 03:50:40 EEST 2018
Thank you for your replies so far.
On Tue, Apr 24, 2018 at 11:46 PM, Nicolas George <george at 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
<tessarek at 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
> 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
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!
More information about the ffmpeg-devel