[FFmpeg-devel] GSoC next steps

[Nicolas George]

Le nonidi 19 thermidor, an CCXXIII, Stephan Holljes a écrit :
> The past days I have been studying the ffserver source and I am at a
> point where I would like some guidance.
> 
> I have started to replace the HTTP code in ffserver with the avformat
> API and I have come across some problems:
> ffserver has its own HTTPContext. Should I merely replace the
> filedescriptors in the struct and the functions by an AVIOContext or
> should I try to replace the custom HTTPContext completely?

I would say: something in between.

In FFserver, as in any HTTP server, there are two sides: talking to the
clients, and doing the job that is expected.

In other words, there are the parts that makes FFserver not Apache, and
there are the part that make FFserver not Postfix.

Apache serves files, runs scripts; FFserver accept streams from some clients
and serves them to other clients respecting multimedia format boundaries.

FFserver understands "GET /foo.mp4", Postfix understands "MAIL FROM <x at y>".

What I have in mind is to move all that makes FFserver not-Postfix in the
library, and keep all that makes FFserver not-Apache in FFserver.

That way, if someone implements another HTTP-like protocol in libavformat,
FFserver can start serving it immediately just by changing a string from
"http" to "foobartp". Well, I do not expect it to be that bump-less at
first, but that is the idea.

At a first glance, the first step would be to remove all the 400+ lines of
the function http_parse_request() and replace them by calls to
avio_handshake() and avio_opt_get().

Of course, you will probably need to expand the AVIO API, exposing more
options (the IP address of the client, for starters). That is the merit of
the project: by using the API in a real, useful server, we make sure the API
is suitable to make real, useful servers.

> Also ffserver uses poll() for simulated parallelism. AFAIK an
> AVIOContext is not poll()able. I am not sure if this would be as
> simple to implement as I am thinking right now and I am not sure if
> that's a good idea.
> An alternative would be to fork() for each client instead of keeping a
> poll-table. I am not sure how well that would behave with shared
> memory if there is any.
> I could also learn how to use pthreads if that is more suited.

Well, there are multiplexed servers, there are threading servers, there are
forking servers. You can not easily turn one into the others, there are
reasons to choose one design over the other.

Forking servers are easy for easy tasks: the accept a client, serve it and
finish. In the nice early days of the nineties, this was the best way. They
lack easy protection against denial-of-service, and they make
client-to-client communication hard. This is Apache, and this is not
suitable for FFserver because FFserver has a lot of client-to-client
communication: the principle of FFserver is that one client publishes a
stream and multiple clients receive it. A forking server would be very
clumsy.

Threading it tricky. Very tricky.

Multiplexed servers are, IMHO, where there is a lot to learn, and what you
want to do if you want to be both efficient and robust.

(Then you can add threads to be even more efficient. But that is tricky. I
already said it, didn't I?)

FFserver is a multiplexed server, and I believe this is the best choice for
this task.

The HTTP features of libavformat must be usable in a multiplexed design,
otherwise they are not much use. Currently, libavformat in general is far
from usable in multiplexed design, but for the HTTP part itself the missing
bits are not that bad.

There is code in FFmpeg that does poll on protocols, look at
url_get_file_handle(). I believe for now, we can make the corresponding
function semi-private (avpriv_*) in order to make it usable by FFserver.

Later a proper API must be designed, but that will come in its own time. And
enhancements done now will help to achieve it (this is not always true, but
in this instance it is).

I hope this answers your questions.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150806/b357d4ff/attachment.sig>