udpsrc to tsdemux interaction

[jopado]

I have a transport stream with 3 PES's:
  pid 0x11: H.264 video (stream type 27)
  pid 0x21: metadata in PES (stream type 15)
  pid 0x81: still image for which I have added support in tsdemux (stream
type 0x88)

I am only interested in saving off the pid 0x81 data to a file.

My pipeline is simple and looks as follows:
  udpsrc port=44910 ! tsdemux ! filesink location=mydata.bin

I am using dynamic pad linking for the tsdemux to filesink and am using
tcpreplay to playback a pcap file to supply data to the pipeline.  I expect
my tsdemux pad-added callback to be called 3 times, once for each of the
pid's in the transport stream.  However, i only get the callback for the
video and not the other two pid's.

If I use filesrc instead of udpsrc, I do see the pad-added called 3 times as
expected and I linkup the pipeline when pid is 0x81 and my data is collected
successfully.

Am I missing something about how udpsrc works here?  I have tried adding
tsparse into the pipeline before tsdemux and get same behavior.  I have also
verified (via tcpdump) that the tcpreplay is sending the packets containing
the pid 0x21 and pid 0x81 data.

Any suggestions for further testing? This is gstreamer version 1.4.5.  Thank
you.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jopado]

jopado wrote

> I have a transport stream with 3 PES's:
>   pid 0x11: H.264 video (stream type 27)
>   pid 0x21: metadata in PES (stream type 15)
>   pid 0x81: still image for which I have added support in tsdemux (stream
> type 0x88)
>
> I am only interested in saving off the pid 0x81 data to a file.
>
> My pipeline is simple and looks as follows:
>   udpsrc port=44910 ! tsdemux ! filesink location=mydata.bin
>
> I am using dynamic pad linking for the tsdemux to filesink and am using
> tcpreplay to playback a pcap file to supply data to the pipeline.  I
> expect
> my tsdemux pad-added callback to be called 3 times, once for each of the
> pid's in the transport stream.  However, i only get the callback for the
> video and not the other two pid's.
>
> If I use filesrc instead of udpsrc, I do see the pad-added called 3 times
> as
> expected and I linkup the pipeline when pid is 0x81 and my data is
> collected
> successfully.
> . . .
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Just wondering if anybody can comment on this behavior. Is this expected and
I am missing something basic or is this unexpected??? I am in process of
setting up a machine with gstreamer 1.10.4 to try it on but I'm not there
yet.

Here's some additional information on the content of the transport stream. I
have verified pid 0x81 is defined in the PMT throughout the stream. However
the pid 0x81 data is sparse and bursty. It first appears in the stream about
5 seconds from the start. There will be a burst of data then many second
without any pid 0x81 data.  This pattern repeats throughout the TS. Does the
nature of this data explain what I am seeing? Any hints or where to look
further will be greatly appreciated. Thank you.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Gst-Geek]

Hi,

Generally no pads will be generated by the element after "no-more-pads" call
back.
Can you share the stream ??
If 0x81 data is missing for 5 secs and if it is coming in burst that may
lead to issue what you have mntioned.
Can you also check if 0x81 PES is present in the PMT table ??




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jopado]

Vinod Kesti wrote

> Hi,
>
> Generally no pads will be generated by the element after "no-more-pads"
> call
> back.
> Can you share the stream ??
> If 0x81 data is missing for 5 secs and if it is coming in burst that may
> lead to issue what you have mntioned.
> Can you also check if 0x81 PES is present in the PMT table ??
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

I added a no_more_pads handler and it never gets called.  I did add some
prints to tsdemux and I do see that the pad for pid 0x81 is being created
(yeah!). But my pad_added callback still not getting called.  Here's a
shortened log showing the pad getting created. That last bit is output from
my pad_added handler.

FIXME             mpegtsbase mpegtsbase.c:360:mpegts_base_add_program:
Refcounting. Setting twice a PID (0x0010) as known PSI
FIXME             mpegtsbase mpegtsbase.c:694:mpegts_base_activate_program:
Refcounting issue. Setting a known PSI PID (0x0011) as known PES
tsdemux tsdemux.c:1415:gst_ts_demux_stream_added: stream added: id=17;
type=27
tsdemux tsdemux.c:1037:create_pad_for_stream: Attempting to create pad for
stream 0x0011 with stream_type 27
tsdemux tsdemux.c:1103:create_pad_for_stream: Checking non-BluRay stream
types....
tsdemux tsdemux.c:1365:create_pad_for_stream: stream:0x7ffb5000c3a0 creating
pad with name video_0011 and caps video/x-h264,
stream-format=(string)byte-stream, alignment=(string)nal
tsdemux tsdemux.c:1415:gst_ts_demux_stream_added: stream added: id=33;
type=21
tsdemux tsdemux.c:1037:create_pad_for_stream: Attempting to create pad for
stream 0x0021 with stream_type 21
tsdemux tsdemux.c:1103:create_pad_for_stream: Checking non-BluRay stream
types....
tsdemux tsdemux.c:1355:create_pad_for_stream: Non-media stream
(stream_type:0x15). Not creating pad
tsdemux tsdemux.c:1415:gst_ts_demux_stream_added: stream added: id=129;
type=136
tsdemux tsdemux.c:1037:create_pad_for_stream: *Attempting to create pad for
stream 0x0081 with stream_type 136*
tsdemux tsdemux.c:1103:create_pad_for_stream: Checking non-BluRay stream
types....
tsdemux tsdemux.c:1365:create_pad_for_stream: *stream:0x7ffb5002d3f0
creating pad with name hiresimg_0081 and caps application/vnd.nitf*
pad_added_handler() entry
Received new pad 'video_0011' from 'myTsdemux':
Caps for the video_0011 pad:
      video/x-h264
          stream-format: byte-stream
              alignment: nal

Yes the pid 0x81 PES is always in the PMT data. I will check about sharing
the stream. Next step for me is to find where the pad-added callbacks are
made and try to figure out why it is not happening in this case.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jopado]

Moved to 1.6.3 and problem resolved. Yay.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel