[Bug 667595] [0.11] Subtitle segments have zero base

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=667595
  GStreamer | gstreamer (core) | 0.11.x

--- Comment #10 from Sebastian Dröge <slomo at circular-chaos.org> 2012-01-10 12:19:20 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > What is the problem with not knowing if the segment event is an update to the
> > > > previous segment or not?
> > > 
> > > See for example dvdsubdec as mentioned above.  One might argue whether or not
> > > it is really needed there, but would prefer not to be caught with being able to
> > > convey less info than was possible in 0.10 without considering it a lot more
> > > (rather than solving it by disabling).
> > 
> > You should be able to infer the information (if this segment is an update or
> > not) from the previous and the new segment. If the base is still the same you
> > have an update. Am I missing something?
> 
> The fix to this bug would have to modify base along with increasing (modifying)
> start time (afaik), so that would also be an update (in 0.10) but with changing
> base.  It would feel only the sender 'knows' this is really some new segment
> (concerning other data etc) or has some new/updated info w.r.t. previous
> segment.

Yes, start and base have to be increased for fixing this bug (base is
essentially the same as accum in 0.10 but the accumulator changes were done
implicitely).

The receiver of the segment really seems to have no way to know if this is an
update or not from the information inside the segment, you're right. But does
it have to know? If a new stream starts the next buffer must have the DISCONT
flag set

> > > Also, seeing an event with update=TRUE coming true might then as well signal
> > > that the stream is sparse.
> > 
> > That's not true in all cases, there could be an segment update because the
> > stream now has a new stop position for example.
> 
> True, so one might wonder whether one should signal the 'stream' to be sparse
> or the 'segment' to be sparse, in which case another (optional) field in the
> segment event might convey that.  But that might be a matter of nitpick
> semantics and don't mind either way.

I'm fine with adding that to the segment but really don't care either ;)

-- 
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.