[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 #11 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-01-10 12:35:17 UTC ---
(In reply to comment #10)
> (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

But one can also have DISCONT without having a new stream or segment. 
Furthermore, the semantics of DISCONT on a sparse stream are a bit shady in
that (almost) every subsequent buffer is possibly discontinuous w.r.t. previous
one.  And even otherwise, it is not clear/certain that a plugin's
response/actions when about to deal with a (really) new segment (exactly) match
those that are appropriate for a (minor?) stream discontinuity.  The former
might involve finishing up some delayed stuff from current segment, the latter
might involve discarding such anyway (?)

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