[Bug 712597] regression: playbin: buffering of live radio stream never finishes

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=712597
  GStreamer | gstreamer (core) | 1.2.1

--- Comment #7 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2014-01-15 12:09:43 UTC ---
(In reply to comment #6)

Let me give some real data for this particular stream. At the beginning, the
max-size is set to 0, the queue grows until 169 when it is set again. This time
it is set to 5. In the current code, this second value is ignored because it is
smaller than 169, and it will buffer until the bytes/time limit are reached.

> Review of attachment 266326 [details]:
> 
> ::: plugins/elements/gstmultiqueue.c
> @@ +510,2 @@
>          /* do not reduce max size below current level if the single queue has
> grown because of empty queue */
>          if (new_size >= size.visible && size.visible <= mq->max_size.visible)
> 
> I do not understand the second condition there. Why do we only do that if the
> current size is smaller than the maximum size? What should matter is the
> new_size only, no?

Yeah, I also was wondering about that second condition, but didn't want to
touch it.

> 
> @@ +512,3 @@
>            q->max_size.visible = new_size;
> +        else if (new_size != 0 && q->max_size.visible == 0)
> +          q->max_size.visible = MAX (new_size, size.visible);
> 
> Which means that removing the above second condition would fix this too?

I don't think so, new_size is 5 and size.visible is 169, so it would ignore
this new_size. AFAIU, we want to set always the MAX(new_size, size.visible),
taking care with the 0 value that means infinite.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.