[FFmpeg-devel] [PATCH 3/3] avformat/opensrt: add Haivision Open SRT protocol
george at nsup.org
Thu Nov 16 13:07:35 EET 2017
Le decadi 20 brumaire, an CCXXVI, nablet developer a écrit :
> the idea is to avoid code duplication as much as possible, and try to re-use
> existing, well-maintained and well-tested code.
> this time I've chosen tcp.c rather udp.c for two reasons:
> 1. SRT socket API actually resembles tcp, as it uses connection and related
> methods (connect/listen/accept)
> 2. tcp.c code is much more clean and straightforward rather udp.c
> the first thing which obviously differs between tcp and srt are socket api
> calls, but there is direct mapping for most of them, e.g.:
> socket -> srt_socket
> connect -> srt_connect
> listen -> srt_listen
> very few of srt socket calls are different, e.g. srt doesn't provide
> send/recv, but provides sendmsg/recvmsg, also it doesn't provide poll, but
> has epoll_wait.
> with simple wrappers, it allows to use existing logic of tcp.c and network.c
> without modifications.
> for calling back srt from tcp, that's the second difference - srt has lots
> of additional socket options,
> and some of these socket options has to be set prior to connection, others
> after connection (called pre and post options in srt).
> Haivision explicitly requested to add these options into ffmpeg component.
> so, there are two calls back in tcp_open - to set options just before
> connection, and to set options right after connections.
> if you have some advice on how it can be implemented better, I am open for
> suggestions and advises.
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel