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

[Sergio M. Ammirata, Ph.D.]

Hello Nicolas,

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.
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. 

Regards,

Sergio


---------- Forwarded message ---------
Date: Mon, 28 Dec 2020, 12:24
Subject: Re: [FFmpeg-devel] [PATCH] libavformat: add
librist protocol
To: FFmpeg development discussions and patches <
ffmpeg-devel at ffmpeg.org>


Marton Balint (12020-12-25):

> Actually it should be POLLING_TIME as defined in
libavformat/network.h for

> blocking mode if you want behaviour to be consistent with
other protocols.

> The function cannot block indefinitely even in blocking
mode to be able

> allow generic code in
libavformat/avio.c:retry_transfer_wrapper to abort a

> blocking wait.



You are right, I forgot about it. It should be 0 in non-
blocking mode

and POLLING_TIME in blocking mode. Definitely not 5.



> Other protocols are directly using poll/select to wait
for data with

> POLLING_TIME timeout, but since librist does not provide
a way to poll for



Note that it is far from a perfect solution. In particular,
it makes our

network protocols unsuitable for idle connections with
embedded

applications, because these timeouts prevent the device
from sleeping.

At some point, we will need to redesign our protocols API
around an

event loop. In fact, all our I/O and threading probably
need to be

merged into a single event loop and scheduler.



> data, this is the best we can do (and return EAGAIN even
in blocking mode if

> the POLLING_TIME elapses, because retry_transfer_wrapper
will retry in that

> case anyway)



It looks to me that librist is not ready for prime time. We
could

integrate it as experimental, to help it getting there. But
I do not

know if the people involved would be receptive.



Regards,