[FFmpeg-devel] Fwd: [PATCH] libavformat: add librist protocol

[Sergio M. Ammirata, Ph.D.]

Understood ... thanks for the advice.

Is there else blocking the integration of the library based
module into ffmpeg? We would prefer not to have it in
"experimental mode".

Regards,

Sergio

On Tue, 2020-12-29 at 23:03 +0100, Nicolas George wrote:
> 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,
> 
>