On Sun, 28 Feb 2021, Paul B Mahol wrote:
On Sun, Feb 28, 2021 at 11:14 PM Marton Balint <c...@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 <one...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
