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