[Bug 678146] Closed Caption support

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #9 from Edward Hervey <bilboed at gmail.com> 2013-07-22 07:48:04 UTC ---
(In reply to comment #4)
> I created a branch of get-plugins-bad and added elements mpeguserdatademux and
> ccfilter. I modified mpegvparse to add a boolean user-data to its src caps
> (much like system-stream etc).  Autoplug finds mpeguserdatademux based on this
> new cap and plugs after mpegvparse.  mpeguserdatademux has an always src pad
> for video data passthrough which ends up connecting to the decoder via
> multiqueue. It also has a sometimes src pad for MPEG user data (current caps:
> video/x-user-data).  The new ccfilter element autoplugs based on caps
> video/x-user-data and has a sometimes src pad with caps text/vtt.  Updated
> versions of uridecodebin connect to these pads with the assistance of WebKit
> courtesy of Brendan Long.

After more thinking and discussions. This seems like a wrong approach.

Just having the parser expose any user data without any identification/parsing
might cause several problems. It's as if we had mpeg-ts demuxers only expose
data/x-pes and losing any context downstream.

For each parser that sees private data they should:
* identify the type of private data
* Is the user-data metadata (example: AVCHD original recording time) or actual
data (like CC) ? Depending on the type some user-data should be sent as tag
events, and others should have a new pad created.
* Use identifiable caps (subtitle/x-cea-608 for example ?)
* If the type is not identifyable, notify it with GST_FIXME()
* Note: some user_data might also be needed by the parser itself also

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