GNOME Bugzilla – Bug 611194
[segments] gst_segment_set_newsegment_full() should allow negative updates to segment start
Last modified: 2011-05-23 15:09:51 UTC
See summary, this is required for bug #610906 at least. Situation there is: Subtitle stream is at 13.6s, Video stream at 14.4. This is larger than 500ms, a filler segment is sent on the subtitle stream. Now unfortunately a new subtitle buffer is found inside the file, which has a timestamp of 14.2. This is before the segment start and will be dropped. To fix this it's required to send update newsegment events which decrease the start time.
The reason why it's not implemented is because something like this is tricky: The initial segment goes like this: (segment update,rate,start,stop): FALSE, 1.0, 0, 10, 0 Then an update is set (and the rate changed) (segment update,rate,start,stop): TRUE, 2.0, 5, 10, 5 -> accumulated time is now 5 Then the previous update was considered wrong and the start is decreased: (segment update,rate,start,stop): TRUE, 2.0, 3, 10, 3 -> accumulated time (implementing backwards start) is now 1 (instead of 3) The last segment update doesn't know that the previous increase caused an accumulated time of 5 using a rate of 1.0. so it decreases with 2*2.0 instead of the expected 2. Not sure it's a real problem but something to consider.
The problem I see here is that the running times would change, let's take a buffer with timestamp 6 as example. 1) (6-0)/1.0 + 0 = 6 2) (6-5)/2 + 5 = 5.5 3) (6-3)/2 + 3 = 4.5 The difference between 1) and 2) is correct because of the rate change, the difference between 2) and 3) will be a problem because the running time should really be the same.
yes, exactly. If you are careful that this problem does not occur in your demuxer then it could be worth adding backwards start to the segment handling. The docs probably should have a big warning about it or something..
Not a problem with 0.11 anymore