Guidance while adding Closed Caption (CEA-708) support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Guidance while adding Closed Caption (CEA-708) support

smaynard
The group I'm working with has created an element that accepts MPEG user data on its sink pad and dissects and compiles that data into CEA-708 CC packets/commands and further digests this information into WebVTT(text/vtt) output on its source pad.

During development I created a bin with a tee and queues that processed in parallel with mpegtsdemux and generated the MPEG user data output with a new mime-type of video/user-data.  The new CC element auto plugged to this output and all was well.  In an attempt to move this code closer to something acceptable to the GStreamer community, I have moved the CC element down into plugins-bad and I had thought I would patch mpegtsdemux to add a new source pad, however mpegtsdemux does not dig deep enough into the video packets to obtain the user data.  It appears that mpegvideoparse however does.  I was planning on modifying mpegvparse, but that would violate its purpose as a parser (adding another output pad).  (apologies for the long-winded set-up for my question)

Should I modify mpegvparse to add "user data" to its out-bound caps and then add another demuxer of-sorts to split out the user data stream for the new CC element?  Or is there yet a better way that currently eludes me?

Thanks,
Steve Maynard


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steve Maynard
Principal Engineer & Partner

Second Stryke Services LLC
8405 West 68th Place
Arvada, CO 80004

303.648.4094 x22 Voice
303.960.6749     Mobile

www.secondstryke.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Guidance while adding Closed Caption (CEA-708) support

Nicolas Dufresne-3
Le mercredi 03 juillet 2013 à 10:22 -0600, Steve Maynard a écrit :
Should I modify mpegvparse to add "user data" to its out-bound caps and then add another demuxer of-sorts to split out the user data stream for the new CC element?  Or is there yet a better way that currently eludes me?
Parser role is to extract metadata, frame the stream, transform the stream format etc. Demuxer role is to split each stream and send them over multiple pads. In general, user data is a stream, so it's demuxer role to demux it and stream it on a separate pads.

Note that when we create new types, we usually respect the x- notation, so data type should be something like video/x-user-data, that being said, video/ is probably not opaque enough to represent user-data in general.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Guidance while adding Closed Caption (CEA-708) support

Edward Hervey
In reply to this post by smaynard
Hi,

  You might want to check
https://bugzilla.gnome.org/show_bug.cgi?id=678146 also

On Wed, 2013-07-03 at 10:22 -0600, Steve Maynard wrote:
> The group I'm working with has created an element that accepts MPEG
> user data on its sink pad and dissects and compiles that data into
> CEA-708 CC packets/commands and further digests this information into
> WebVTT(text/vtt) output on its source pad.

  It would make more sense to handle this at the (existing) parser
level.

>
>
> During development I created a bin with a tee and queues that
> processed in parallel with mpegtsdemux and generated the MPEG user
> data output with a new mime-type of video/user-data.  The new CC
> element auto plugged to this output and all was well.  In an attempt
> to move this code closer to something acceptable to the GStreamer
> community, I have moved the CC element down into plugins-bad and I had
> thought I would patch mpegtsdemux to add a new source pad, however
> mpegtsdemux does not dig deep enough into the video packets to obtain
> the user data.  It appears that mpegvideoparse however does.  I was
> planning on modifying mpegvparse, but that would violate its purpose
> as a parser (adding another output pad).  (apologies for the
> long-winded set-up for my question)
>
>
> Should I modify mpegvparse to add "user data" to its out-bound caps
> and then add another demuxer of-sorts to split out the user data
> stream for the new CC element?  Or is there yet a better way that
> currently eludes me?

  Might want to discuss that on the bug report also.
  *  Having the demuxer handle it feels wrong
  *  Having the parser add a new source pad is tricky

>
>
> Thanks,
> Steve Maynard
>
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Steve Maynard
> Principal Engineer & Partner
>
> Second Stryke Services LLC
> 8405 West 68th Place
> Arvada, CO 80004
>
> 303.648.4094 x22 Voice
> 303.960.6749     Mobile
>
> www.secondstryke.com
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel