> On Jun 9, 2021, at 6:04 AM, Marton Balint <c...@passwd.hu> wrote: > > > On Tue, 1 Jun 2021, Zhao Zhili wrote: > >> It's useful for test client which pass streamid to ffmpeg/ffplay. >> For example, use ffmpeg to test streamid support in VLC: >> ./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener >> srt://127.0.0.1:9000 >> ./vlc srt://127.0.0.1:9000?streamid=foobar >> --- >> libavformat/libsrt.c | 22 +++++++++++++--------- >> 1 file changed, 13 insertions(+), 9 deletions(-) >> >> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c >> index c1e96f700e..613997c501 100644 >> --- a/libavformat/libsrt.c >> +++ b/libavformat/libsrt.c >> @@ -153,6 +153,15 @@ static int libsrt_neterrno(URLContext *h) >> return os_errno ? AVERROR(os_errno) : AVERROR_UNKNOWN; >> } >> >> +static int libsrt_getsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, >> const char * optnamestr, void * optval, int * optlen) >> +{ >> + if (srt_getsockopt(fd, 0, optname, optval, optlen) < 0) { >> + av_log(h, AV_LOG_ERROR, "failed to get option %s on socket: %s\n", >> optnamestr, srt_getlasterror_str()); >> + return AVERROR(EIO); >> + } >> + return 0; >> +} >> + >> static int libsrt_socket_nonblock(int socket, int enable) >> { >> int ret, blocking = enable ? 0 : 1; >> @@ -224,6 +233,8 @@ static int libsrt_listen(int eid, int fd, const struct >> sockaddr *addr, socklen_t >> { >> int ret; >> int reuse = 1; >> + char streamid[512] = {}; >> + int streamid_len = sizeof(streamid); >> if (srt_setsockopt(fd, SOL_SOCKET, SRTO_REUSEADDR, &reuse, >> sizeof(reuse))) { >> av_log(h, AV_LOG_WARNING, "setsockopt(SRTO_REUSEADDR) failed\n"); >> } >> @@ -242,6 +253,8 @@ static int libsrt_listen(int eid, int fd, const struct >> sockaddr *addr, socklen_t >> return libsrt_neterrno(h); >> if (libsrt_socket_nonblock(ret, 1) < 0) >> av_log(h, AV_LOG_DEBUG, "libsrt_socket_nonblock failed\n"); >> + if (!libsrt_getsockopt(h, ret, SRTO_STREAMID, "SRTO_STREAMID", >> streamid, &streamid_len)) >> + av_log(h, AV_LOG_VERBOSE, "accept streamid [%s], length %d\n", >> streamid, streamid_len); > > Does it make sense to print the length? Shouldn't this be > > ("accepted streamid [%.*s]\n", streamid_len, streamid) > > instead to avoid overreads at 512 byte streamids, or dumping garbage if it is > not 0 terminated? (You can also avoid 0 initialization that way).
srt_getsockopt() is guaranteed to return ‘\0’ terminated string on success, so the 0 initialization is unnecessary. I made another mistake: the length of streamid array should be 513: https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#SRTO_STREAMID > string - a C string. When setting an option, a const char* character array > pointer is expected to be passed in optval and the array length in optlen > without the terminating NULL character. When getting, an array is expected to > be passed in optval with a sufficient size with an extra space for the > terminating NULL character provided in optlen. The return value of optlen > does not count the terminating NULL character. Print the streamid_len has some usercase. For example, to test the corner case of upper bound of streamid length, the caller can send streamid made from 512 ‘x'. Print the streamid_len so I don’t need to count or compare the received streamid to verify the integrity. > > Thanks, > Marton > >> >> return ret; >> } >> @@ -276,15 +289,6 @@ static int libsrt_setsockopt(URLContext *h, int fd, >> SRT_SOCKOPT optname, const c >> return 0; >> } >> >> -static int libsrt_getsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, >> const char * optnamestr, void * optval, int * optlen) >> -{ >> - if (srt_getsockopt(fd, 0, optname, optval, optlen) < 0) { >> - av_log(h, AV_LOG_ERROR, "failed to get option %s on socket: %s\n", >> optnamestr, srt_getlasterror_str()); >> - return AVERROR(EIO); >> - } >> - return 0; >> -} >> - >> /* - The "POST" options can be altered any time on a connected socket. >> They MAY have also some meaning when set prior to connecting; such >> option is SRTO_RCVSYN, which makes connect/accept call asynchronous. >> -- >> 2.25.1 >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".