<div dir="ltr">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.<div>
<br></div><div>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)</div>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks,</div><div>Steve Maynard</div><div><br clear="all"><div><br></div>-- <br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<br>Steve Maynard<br>Principal Engineer & Partner<br><br>Second Stryke Services LLC<br>
8405 West 68th Place<br>Arvada, CO 80004<br><br>303.648.4094 x22 Voice<br>303.960.6749     Mobile<br><br><a href="http://www.secondstryke.com" target="_blank">www.secondstryke.com</a><br>
</div></div>