[Bug 704881] New: Partial ATSC_user_data and CEA-708 Closed Captions Support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704881
  GStreamer | gst-plugins-bad | git

           Summary: Partial ATSC_user_data and CEA-708 Closed Captions
                    Support
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: steve at secondstryke.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=250128)
 View: https://bugzilla.gnome.org/attachment.cgi?id=250128
 Review: https://bugzilla.gnome.org/review?bug=704881&attachment=250128

CEA-708 support attempt #2

In an effort to begin support for Closed Captions (see bug #678146), a proposal
was made to create an element to auto-plug after mpegvideoparse that would pass
thru video and split out user_data packets (see ATSC A/53 Part 4) and send them
to yet another new element that would decode the user_data into MPEG_cc_data.

After discussions with the maintainers it was decided this was not the correct
path and mpegvideoparse itself should be modified to add new "sometimes" source
pad(s) that would have subtitle/x-cea-708  (or 608) capabilities.  Then new
elements could be added to decode the respective input caps and generate
text/x-raw output (which in-turn could be handled with elements to convert to
text/vtt if so desired)...

An initial pass at this is enclosed in a patch against master as of the
creation of this issue.  It seems that running this code with a stream that has
user_data actually prevents the video portion of the pipe from running, while
audio and text portions do run to completion.

While comparing the PNGs of the original test and the current implementation it
appears that a multiqueue was added after the original element but not after
mpegvparse now (could this be a part of the problem?)

I'm testing with the following command line (you'll have to insert your
favorite MPEG2-TS in place of mine):

rm *.dot; GST_DEBUG_DUMP_DOT_DIR=./  gst-launch-1.0  --gst-debug-no-color
--gst-debug-level=3 --gst-debug="playbin:4,ccfilter:4,mpegvideoparse:4" playbin
uri=file:///home/smaynard/Videos/mpeg2ts_cea708.mpg text-sink="capsfilter
caps=text/x-raw ! filesink location=out.txt" 2>&1 | tee test.log

NOTE: defining DROP_USER_DATA in mpegvideoparse.c will allow normal
operation...

Any assistance or comments are welcomed...

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