The attached patch obviously breaks seeking in hls as it modifies the upstream time segment send by hlsdemux. From what I understand, in this case, the upstream time segment should not be modified as the decoder must receive the original segment so it can discard the frames that are out of the segment.

What exactly are you trying to solve ?

Getting an incoming segment with a start value equal to the first internal PTS of the stream is ... rare (make that almost impossible, PCR/PTS/DTS aren't meant to be predictable.).

The _incoming_ segment start value is to provide the basis of the running time for the _incoming_ stream.

If you have the beginning of a non-live TIME stream (from hlsdemux, or dlna sources), then your incoming stream is *starting* at running-time 0 (unless you purposefully want to shift/delay the rendering of that stream).
=> Your incoming segment.start and initial buffer should have identical running time (0, 5000, whatever, doesn't matter).

Note that those streams are not *live* per-se. Not every buffer will be timestamped. Heck, you don't even *need* to timestamp any buffer. If there are no timestamps => That incoming stream implicitely starts at running-time 0.

The only time where you will have timestamps on every/most incoming buffers is when it comes from an actual live source (DVB or RTP) where several things will happen:
1) the running-time of incoming buffers will not start at zero (there's a delay between the moment the pipeline goes to PLAYING and the moment the first buffer is captured by the sources). We need to propagate that running-time downstream, otherwise we'll end up with data always arriving late in the sinks (if your pipeline is live).
2) we need precise capture time on every buffers to correlate it with the internal PCR values (remote clock observations) to estimate the clock skew/drift (the remote clock might be going faster/slower than are local clock).

(In reply to comment #2)
> What exactly are you trying to solve ?

What is doing that particular element (which is proprietary) is pushing a TIME segment with segment.start equals to the first PTS of the mpegts stream.
In my example it was 16:30:00.00~

But it was also affecting the buffers PTS to values not within the TIME segment it is emitting (it was starting at around 00:01:00.00~ which looks like the computation of the running time -> currentPts-basePts).
That was making tsdemux having a clock base of 00:01:00.00 instead of 16:30:00.00, and the mpegts PTS/DTS was shifted to that base.
I modified this element so the PTS/DTS are the current one corresponding to the buffer and so it falls in the TIME segment the element emits.

The element is used to push recorded mpegts streams.

Can you confirm it is OK to do that ?

> 
> Getting an incoming segment with a start value equal to the first internal PTS
> of the stream is ... rare (make that almost impossible, PCR/PTS/DTS aren't
> meant to be predictable.).
> 
> The _incoming_ segment start value is to provide the basis of the running time
> for the _incoming_ stream.
> 
> If you have the beginning of a non-live TIME stream (from hlsdemux, or dlna
> sources), then your incoming stream is *starting* at running-time 0 (unless you
> purposefully want to shift/delay the rendering of that stream).
> => Your incoming segment.start and initial buffer should have identical running
> time (0, 5000, whatever, doesn't matter).
> 
> Note that those streams are not *live* per-se. Not every buffer will be
> timestamped. Heck, you don't even *need* to timestamp any buffer. If there are
> no timestamps => That incoming stream implicitely starts at running-time 0.
> 
> The only time where you will have timestamps on every/most incoming buffers is
> when it comes from an actual live source (DVB or RTP) where several things will
> happen:
> 1) the running-time of incoming buffers will not start at zero (there's a delay
> between the moment the pipeline goes to PLAYING and the moment the first buffer
> is captured by the sources). We need to propagate that running-time downstream,
> otherwise we'll end up with data always arriving late in the sinks (if your
> pipeline is live).
> 2) we need precise capture time on every buffers to correlate it with the
> internal PCR values (remote clock observations) to estimate the clock
> skew/drift (the remote clock might be going faster/slower than are local
> clock).

Thanks for those explanation, it is really helpful !

(In reply to comment #3)
> (In reply to comment #2)
> > What exactly are you trying to solve ?
> 
> What is doing that particular element (which is proprietary) is pushing a TIME
> segment with segment.start equals to the first PTS of the mpegts stream.
> In my example it was 16:30:00.00~
> 
> But it was also affecting the buffers PTS to values not within the TIME segment
> it is emitting (it was starting at around 00:01:00.00~ which looks like the
> computation of the running time -> currentPts-basePts).

 Stop. That's your problem.

 In your segment, you're saying "the valid range of buffers to follow will be from 16:30:00.00 onward" ... and then you give buffers which are not within that range.

 If you want to convey a specific stream time (which is maybe what you want if that element is handling seeks), use the segment.time field for that, and then just set segment.start to 0 and the first buffer PTS to 0.

Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!