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

[Nicolas George]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201229/a5122cac/attachment.sig>