I'm trying to write an application which is able to extract (and process/convert) KLV metadata from a TS file or stream.
I found KLV support in private section of tsdemux, and I succeeded to extract them (in file for example) with this pipeline:
(gst-launch-1.0) filesrc location=mytsfile ! tsparse ! tsdemux ! meta/x-klv ! filesink location=klvextract.log
But, this only works with asynchronous TS file (no synchronization between AVC stream and KLV stream).
When I try with synchronous file from command line (gst-launch-1.0), i got this error:
./grammar.y(506): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
failed delayed linking some pad of GstTSDemux named tsdemux0 to some pad of GstFileSink named filesink0
ERROR: from element /GstPipeline:pipeline0/MpegTSParse2:mpegtsparse2-0: Internal data stream error.
When i try to do same in an application like this:
GstElement *pipeline, *filesrc, *ts_parser, *demuxer, *filter_caps_mtd, *filesink;
filesrc = gst_element_factory_make ("multifilesrc", "multifilesrc");
g_print ("Filesrc not created.\n");
g_object_set(G_OBJECT (filesrc), "location", argv, NULL);
ts_parser = gst_element_factory_make("tsparse", "ts_parser");
g_print("Unable to created tsparse.\n");
I have not been able to get tsdemux to work either. I finally took look at
the code and sure enough tsdemux (1.16.1) only sends asynchronous metadata
out the private pad, synchronous metadata is discarded. I supposes that is
why it is still in the "bad" plugins; it is incomplete. So I think I am
going to have to roll my own. Right now I'm thinking that the easiest thing
would be to extend the capabilities of tsdemux. Or maybe I should write my
own plugin to parse out only the meta/x-kvl packets. Can someone with more
familiarity with gstreamer comment on what they would do? I don't want to
march off in the wrong direction and have to change direction two months
Been working with this as well, using 1.17
As noted, Async comes through on private klv pad and looks pretty much
straight forward to decode.
I would seem (and I could be wrong) that in Sync the klv is embedded in the
PES packets of the video,
at least on the Mpeg2s that I have dumped, the H264 looks much different and
still have not confirmed how that is done. Sure wish there was clear
documentation on gstreamer somewhere...
On 5/10/19 11:42 am, scottca wrote:
> Been working with this as well, using 1.17
> As noted, Async comes through on private klv pad and looks pretty much
> straight forward to decode.
> I would seem (and I could be wrong) that in Sync the klv is embedded in the
> PES packets of the video,
Synchronous mode is a different mapping of the KLV data into a PES
stream, but it's not embedded in the video stream - it's still a
separate parallel in the MPEG-TS. I don't think implementing the mapping
to get tsdemux to output the data usefully is difficult, just missing.
Jan Schmidt-6 wrote
> If anyone has / can make some redistributable sample files, those could
> be used to help get that patch merged, and for use in the gst-validate
> test-suite to ensure things keep working.
Jan thanks, Not sure I am following, "separate parallel" ? I know the
asynchronous KLV from the TS come through on the separate pad on the demux,
( it has no PST, and can contain one to many key values embedded) I have no
problem with these data blocks, they all have SMPTE start descriptors. I
just assumed the synchronous KLV was somehow in the PES of the video stream
(mpeg/264) since the klv pad does not trigger, Was figuring they came
through with just different ID values ( tagged private) so as not to be
confused as video and could identify them by parsing them from the PES
blocks.. Are you saying that is not the case? That the demux should be
feeding these through onto the klv pad? Thanks