[FFmpeg-devel] Controlling the server reply (was: 9/9] doc/example: Add http multi-client) example code

[Stephan Holljes]

Hello, sorry for the delayed response, I somehow overlooked it and
also just entered my exam preparation period.

On Mon, Jul 13, 2015 at 2:13 PM, Nicolas George <george at nsup.org> wrote:
> Le quartidi 24 messidor, an CCXXIII, Stephan Holljes a écrit :
>> the best thing I thought of was some kind of generic communication
>> function that either uses the client's AVOption system to pass around
>> values or just uses an AVDictionary.
>> Giving the application access to the results of the library could be
>> done in a similar way it is being done in http_read_header() by
>> repeatedly calling the communicate function and checking for its error
>> code (return < 0 in case of error, > 0 in case of success, but
>> unfinished processing and 0 on success and finished processing.) Since
>> we have to deal with protocol-specific decisions, each protocol should
>> implement its own communication function with something like a
>> url_comm_params() function added to the URLProtocol struct, which is
>> called like most (all?) other URLProtocol functions with
>> ffurl_comm_params() and avio_comm_params(). I'm not really sure how to
>> tell the application what parameters were negotiated, but maybe this
>> can be done in a similar fashion it has been done with unused_opts,
>> but instead with used_opts.
>
> This is more or less what I had in mind.
>
> To hold the options, I believe the AVOption system is better, because it has
> types: using AVDictionary would require converting everything to strings.
>
> Furthermore, AVOption object have inheritance, that can be used to access
> parameters in nested protocols: if the HTTP context inherits from the TCP
> context, getting the IP address is transparent; the same applies to TLS
> parameters with appropriate inheritance.
>
> As for the communication function, I believe it can just be url_handshake()
> / avio_handshake().
>
> In other words: if avio_handshake() returns 0 that means the handshake is
> finished, it if returns >0 that means the handshake has progressed by one
> step but is not finished, and of course <0 means error.
>
> (We could try maintaining the convention that the return value is
> decreasing: 2+x for the underlying protocol, 1 during the headers. I am not
> sure if this would be very useful. It may also be a bit of trouble to
> maintain if the underlying protocol handshake is not the first step or if
> there are several underlying protocols, but I suspect these cases will not
> happen.)
>
> As for notifying the application of received parameters: this is not
> speed-critical, so the application could just repeatedly check if the option
> is still NULL or any corresponding default value.
>
> Does that sound ok to you?

Yes, I will start work on implementing it. I like the return value
convention, I will stick to that idea.

>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Regards,
Stephan