Opened 3 years ago

Closed 3 months ago

#9142 closed defect (fixed)

LIBSRT uses wrong write-readiness epoll on a listener socket

Reported by: Mikołaj Małecki Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: libsrt
Cc: Marton Balint Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


The epoll subscription for a listener socket uses the same method as for other modes, by waiting for write readiness. This works only due to a bug in LIBSRT, which will be fixed at some point. The event that should be checked ready on a listener socket should be the read-readiness, SRT_EPOLL_IN.

This is where the epoll is being created:

ret = write_eid = libsrt_epoll_create(h, fd, 1);

Then it is used in both branches for a listener socket and connected socket. For connecting (and rendezvous) socket it's ok, write-readiness defines connection-ready. For a listener socket it should use read-readiness, so creation of eid for the listener branch should be likely done separately, with "0" last parameter.

Attachments (1)

srt-epoll.patch (2.0 KB ) - added by Marton Balint 3 years ago.

Download all attachments as: .zip

Change History (9)

by Marton Balint, 3 years ago

Attachment: srt-epoll.patch added

comment:1 by Marton Balint, 3 years ago

Cc: Marton Balint added

I have added a patch to the ticket which fixes this, compile tested only, can you check if it works for various modes?

comment:2 by Carl Eugen Hoyos, 3 years ago

Component: undeterminedavformat
Keywords: libsrt added
Version: unspecifiedgit-master

comment:3 by Mikołaj Małecki, 3 months ago

Just a reminder. We would like to fix this bug in SRT, and after we do it the listener mode for SRT in ffmpeg will no longer work.

Let me clarify: the SRT documentation stated it clearly that the epoll flag in the listener socket that triggers the accept-readiness is SRT_EPOLL_IN. If this was done differently, it wasn't done according to the API documentation and it only works thanks to a bug that will soon be fixed.

To test this above fix, simply run ffmpeg with reading or sending a stream in listener mode. To make a transmission over SRT (even within the internal network of one machine) from a media file using ffmpeg -re for sending and the other command for sending it to a file (or simply receive it via ffplay).

comment:4 by Marton Balint, 3 months ago

Can you confirm that the patch attached here fixes the API usage?

comment:5 by Balling, 3 months ago

We would like to fix this bug in SRT, and after we do it the listener mode for SRT in ffmpeg

Fix the bug in LIBSRT.

comment:6 by Mikołaj Małecki, 3 months ago

Alright then. I take it as a good deal.

comment:7 by Max, 3 months ago

To avoid possible misunderstanding, the libSRT triggers the SRT_EPOLL_IN event on the accept-readiness. This means the patch is valid and can be merged without changes to libSRT.
The libSRT, however, also signals the SRT_EPOLL_OUT event on accept-readiness, on which ffmpeg is currently relying. This behavior is wrong and is to be removed from libSRT.

comment:8 by Marton Balint, 3 months ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.