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 <geo...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Regards, Stephan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
