Created attachment 197234 [details] [review]
basesink: take segment start into account in position reporting

This fixes position reporting on files starting at a non 0 offset.

(In reply to comment #1)
> Created an attachment (id=197234) [details] [review]
> basesink: take segment start into account in position reporting
> 
> This fixes position reporting on files starting at a non 0 offset.

This should not be the way to go.  The segment 'time' field is (conceptually) in a different timeline than start/stop (buffer) timeline, and so there should not be arithmetic (in this way).

It is probably up to upstream to send the proper stuff in 'time' field, which actually determines the stream_time/position timeline.

Ah, I thought time was the "where are we" position between start and stop.
Thanks for the clarification, I'll hunt the cause of bad time then.

Btw/fwiw, a good bet for the cause is a demuxer that sends (S, E, S) in the segment event where 0 != S := first buffer ts (or so).  That will already lead to a position (stream_time) starting at S (but running_time at 0).  For 'nice human reading', it should probably send (start, stop, 0).

It could also not mind and send (0, duration, 0) and position will start at 0, though there would not be much playback happening for some time as the running_time will not start at 0 then.

Some demuxers are (already) aware of this and do 'initial offset corrections', asfdemux iirc, others may not (and others need not care anyway, e.g. avidemux).