On 10-Nov-17 03:35, Nicolas George wrote:
Can you explain the logic of the implementation? I have a hard time
understanding why you call the tcp protocol from here after forcing it
to call back here.
Regards,
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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
