[Bug 781725] New: ttml: Max number of GstMemorys in GstBuffer can be exceeded in live subtitling scenario

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Apr 25 14:59:45 UTC 2017


https://bugzilla.gnome.org/show_bug.cgi?id=781725

            Bug ID: 781725
           Summary: ttml: Max number of GstMemorys in GstBuffer can be
                    exceeded in live subtitling scenario
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: floobleflam at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 350402
  --> https://bugzilla.gnome.org/attachment.cgi?id=350402&action=edit
TTML file containing live-style subtitles

An important subtitling use case is live-generated subtitles, in which each new
word is contained in its own span, and the spans are displayed sequentially,
with the effect that lines of displayed subtitles are built up word-by-word.

This can, however, cause problems with the TTML code when the number of words
in a block is greater than the number of allowed GstMemorys in a GstBuffer,
since ttmlparse will attempt to insert each new span in its own GstMemory.

The attached file (live-subs.xml) demonstrates the problem; run as follows:

gst-launch-1.0 ttmlrender name=r videotestsrc pattern="gradient" !
video/x-raw,width=1280,height=720 ! autovideoconvert ! r.video_sink filesrc
blocksize=16777216 location=live-subs.xml ! ttmlparse ! r.text_sink r. !
ximagesin

Since in this use case each span will have the same styling as adjacent spans,
we can join adjacent spans (and other inline elements, such as breaks) into a
single element containing the concatenated text of each, thus avoiding the
limit of GstMemorys in a GstBuffer and also reducing the amount of
styling/layout metadata that is attached to each buffer.

Patchset to follow...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list