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

[Marton Balint]

On Sun, 28 Feb 2021, Paul B Mahol wrote:

> On Sun, Feb 28, 2021 at 11:14 PM Marton Balint <cus at passwd.hu> wrote:
>
>>
>>
>> On Sun, 28 Feb 2021, Paul B Mahol wrote:
>>
>> > This work is sponsored by Open Broadcast Systems.
>> >
>> > Signed-off-by: Paul B Mahol <onemda at gmail.com>
>> > ---
>> > configure               |   5 +
>> > doc/protocols.texi      |  29 +++++
>> > libavformat/Makefile    |   1 +
>> > libavformat/librist.c   | 236 ++++++++++++++++++++++++++++++++++++++++
>> > libavformat/protocols.c |   1 +
>> > 5 files changed, 272 insertions(+)
>> > create mode 100644 libavformat/librist.c
>> >
>>
>> [...]
>>
>> > +static int librist_read(URLContext *h, uint8_t *buf, int size)
>> > +{
>> > +    RISTContext *s = h->priv_data;
>> > +    const struct rist_data_block *data_block;
>> > +    int ret;
>> > +
>> > +    ret = rist_receiver_data_read(s->ctx, &data_block, s->queue_count
>> <= 0 ? POLLING_TIME : 0);
>>
>> Use POLLING_TIME unconditionally. If there are packets in the queue,
>> POLLING_TIME should not matter. This also means that keeping track of
>> queue_count is useless.
>>
>
>
> Not possible, that would cause fifo filling up.

But why?

Here is the code directly from librist:

ssize_t num = 0;
// Select the flow with highest queue count to minimize jitter for calling app
struct rist_flow *f = rist_get_longest_flow(ctx, &num);
if (!num && timeout > 0)
{
         pthread_mutex_lock(&(ctx->mutex));
         pthread_cond_timedwait_ms(&(ctx->condition), &(ctx->mutex), timeout);
         pthread_mutex_unlock(&(ctx->mutex));
         f = rist_get_longest_flow(ctx, &num);
}

timeout should only matter, if queue is empty.

>
> I give up. FFmpeg protocols API is utterly useless.

Please, don't, if using a constant POLLING_TIME indeed makes a difference 
then you are on the right track of finding the core bug.

Regards,
Marton