[Bug 757619] hlsdemux: incorrect segment start value on bitrate switch

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757619

--- Comment #4 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #3)
> Thiago do you remember why you did this change? I think on group switches
> (i.e. switching pads) we will have to update the segment in a way that the
> first buffer coming out there has running time 0 (and stream time according
> to the manifest). It basically should be the same segment you would create
> for a flushing seek to that position.

Why would we have to go back to running time 0? Shouldn't the running time end
up being the same as the last pushed buffer in the previous played segment?
Otherwise the sink will consider late all the buffers up to that time.

I believe the rationale for that patch is that all streams in the manifest
should have an aligned start time, so they all should run under the same
segment. It could also be achieved by adjusting start, base and time in the
segment but having the same segment makes it easier for debugging.

What is the value of the timestamp of the first pushed buffer after the switch?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.