Overlapping subtitle buffers

[Matej Knopp]

On Mon, Apr 1, 2013 at 7:56 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Sun, 2013-03-31 at 23:15 +0200, Matej Knopp wrote:
>
> Hi,
>
> > I'm not sure if overlapping subtitle buffers are officially supported
> > in gstreamer, but given that some containers specifically request
> > support for this[1] I'm going to assume so.
>
> It's currently neither handled nor supported.


Not sure what this means. Won't MKV demux give you overlapped subtitles if
they are muxed in like that?



>
> > This causes some problems
> >
> > Assuming we have very long subtitle buffers
> >
> > buf 1 - PTS 0s   Duration 25s
> > buf 2 - PTS 50s  Duration 25s
> >
> >
> > So the output from demuxer should look something like this
> > buf 1
> > gap (25 - duration 25)
> > buf 2
>
> I'm not sure if it *should* look like that. Maybe it should send 25 gap
> events with 1 second duration rather than one long one?
>
>
That one big gap event was not really the point. The point is, that if you
have a very long subtitle buffer, you don't know whether you need to wait
for maybe another one that will overlap part of it, or are good to render
it. That is, until you get next buffer or a gap. The problem with gap event
currently is, that it will only be sent after other streams catch up.

I don't know how to explain this better. Example

          0s                  25s
Video:    VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
Audio:    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Subtitle: [Long Subtitle Buffer]GAPGAPGAP[Long Subtitle Buffer]

The first GAP event will be send when demuxer sends 25second of audio and
video. So whatever is rendering the subtitle will not know if it can render
the buffer, or whether another buffer is coming until it gets the first GAP
event. For long subtitles this will cause pipeline stalling.

Of course easiest solution is to say that subtitle buffers can't overlap.
Except in practice they can. Webm has it in specification. SSA allows you
to set rules for collisions.


> Or maybe a muxer could simply assume that for sparse streams it will get
> whatever data there is in good time (so it doesn't have to ever
> wait/block, or at least not for very long).

I guess this would work in most cases, although you probably still want to
block at least until you get the first subtitle buffer. I'm not sure though
 how I feel about expecting things to come in certain time, seems a bit
fragile.

-Matej


> Cheers
>  -Tim
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130401/9af454a1/attachment.html>