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

[Marton Balint]

On Mon, 28 Dec 2020, Sergio M. Ammirata, Ph.D. wrote:

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

Just to make it clear, this is only a plan for the replacement of 
the current polling based interrupt logic, and it probably won't happen 
anytime soon.

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

I'd say it is too early to say which method will fit ffmpeg's approach 
best, on the other hand ffmpeg will have to support many protocols with 
different polling capabilities, so I'd expect ffmpeg should be able to 
adapt to both.

And maybe my comment made the impression that fd based polling is needed 
for proper ffmpeg support, but as far as I see it that is not really the 
case, at least not for the current ffmpeg code. We are just used to having 
a poll() call and a read() call, because the read() call does not usually 
provide timeout capability, so we always had to use poll() first. But 
in librist the read() call already have a timeout parameter, so we can 
simply use that instead of poll()+read().

Regards,
Marton

>
> 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,
>
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".