> On 20 Nov 2017, at 13:35, nablet developer <s...@nablet.com> wrote:
>> 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

Reply via email to