> > Thanks for explaining. I think it is not the best decision. > > The reason the socket API resembles TCP is because all the sockets API > resemble each other, since they are based on the old BSD socket API. And > the protocol handlers of libavformat too. > > Therefore, I think all the trampoline code to allow TCP to call back > another protocol plus all the boilerplate code that you need to make > opensrc callable from TCP amounts to worse than implementing a protocol > directly. > > Furthermore, TCP is the most important network protocol for now, while > opensrt is still rather obscure, so tying one with the other is not a > good idea. > > Also, implementing a real protocol from scratch would possibly allow you > to make use of extra features of the opensrt API: maybe they have a > read-with-timeout function, for example, or something like that. > >
thanks for the feedback. regarding relying on TCP protocol code it's clear - I will implement protocol from scratch next time. regarding re-using functions from network.c (like ff_network_wait_fd, ff_accept, etc) is suggested approach acceptable? is it okay to define such socket_api structure and pass to network.c calls? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
