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