Sergio M. Ammirata, Ph.D. (12020-12-28): > We already had a file descriptor signaling method on a > private branch. Here is the link: > > > https://code.videolan.org/rist/librist/-/commits/descriptor_method/ > > I assume this would work? > > Is the idea to add our file handle to a larger array on a > master select loop inside ffmpeg? > After the select is triggered, is it a requirement that the > data also be read with a standard "read" call on the file > descriptor or is calling an API acceptable? In the solution > above, we use an API to retrieve the data.
IIUC, it adds a function where the application gives one end of a self-pipe (https://cr.yp.to/docs/selfpipe.html) to get notification when something is ready. It should work nicely. Draining the pipe explicitly or through an API call, both are fine, as long as the proper way is documented. You could also just give access to the actual socket file descriptor. It is what Xlib does, for example (https://linux.die.net/man/3/connectionnumber), it gives the socket to the X11 server to the application, the application poll()s it, and when it is readable, it can call XPending() / XNextEvent(). > Sending the data within the file descriptor context would > require serialization of the rist_data_block structure and > having it deserialized by the calling application. Of course, no need for that. As Marton said, FFmpeg is currently underdeveloped in the async protocols department. I want to change that, but that is not for today. But FFmpeg is not the only library around here. To make sure this new library's API is really usable by complex application, I think good advice would be to make sure it works with a few common event loops. I think probably GLib's main event loop (https://developer.gnome.org/glib/2.66/glib-The-Main-Event-Loop.html), because it is at the core of most GNOME applications. And possibly libev (http://software.schmorp.de/pkg/libev.html), because it is lightweight and simple yet efficient. Maybe the best idea would be to have doc/examples/gtk.c and doc/examples/libev.c to show how to properly use the API in an asynchronous application. Anyway, thanks for reacting so efficiently. <rant> What people do not realize is that threads do not make network programming simpler. We often see advice, about network programming, "just use threads", but it is a misconception. Threads are very useful for performance, but when it comes to network programming, they do not help (except for DNS). I must be more accurate: POSIX threads do not help with Unix-style sockets. The issue is that POSIX threads and Unix sockets are completely separate APIs, without any kind of integration. When a thread is blocked on a socket operation, it does not communicate with other threads. To implement things as basic as a timeout with threads, it requires at least another thread, and some kind of asynchronous cancellation operation, which is tricky, both for portability and for concurrency problems. Really, a loop around poll() or equivalent is the only working way to use Unix sockets. When we try to use threads with sockets, we end up having a poll() loop in each thread, and then we might as well have a single loop without threads. Also, event loops scale much better than threads. I write this under the assumption we want to do things properly, i.e. have an application that can sleep when there is nothing on the network. So many applications have a periodic wake-up just to check for timeouts and other interrupts; FFmpeg have one ten times per second. For embedded applications, it is terrible, because it prevents the device from going to deep sleep, and drains the battery. </rant> Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
