pipeline works with filesrc but not udpsrc

[jopado]

I have a very simple pipeline that has been running fine using filesrc:
  gst-launch-1.0 filesrc location=test.ts ! tsdemux ! application/vnd.nitf !
filesink location=/tmp/pid0081.bin

I have added the trivial caps filter to tsdemux to be able to collect this
data. I now need to use a live source so have changed the pipeline to:
  gst-launch-1.0 udpsrc port=44910 ! tsdemux ! application/vnd.nitf !
filesink location=/tmp/pid0081.bin

When run, i get this output as expected:
  Setting pipeline to PAUSED ...
  Pipeline is live and does not need PREROLL ...
  Setting pipeline to PLAYING ...
  New clock: GstSystemClock

I did a run with debug=5 and have provided a snippet below showing that
tsdemux is not linking to the caps sink pad. This occurs after the udp
packets start flowing. I'm not sure why. Any hints appreciated.
 
This is version 1.4.5 (CentOS)

INFO         GST_EVENT gstevent.c:1373:gst_event_new_reconfigure: creating
reconfigure event
DEBUG        GST_EVENT gstevent.c:301:gst_event_new_custom: creating new
event 0x7f0dec004320 reconfigure 61441
DEBUG        GST_EVENT
gstpad.c:5092:gst_pad_send_event_unchecked:<capsfilter1:src> have event type
reconfigure event: 0x7f0dec004320, time 99:99:99.999999999, seq-num 41,
(NULL)
DEBUG    basetransform
gstbasetransform.c:1933:gst_base_transform_src_eventfunc:<capsfilter1>
handling event 0x7f0dec004320 reconfigure event: 0x7f0dec004320, time
99:99:99.999999999, seq-num 41, (NULL)
DEBUG         GST_PADS
gstpad.c:4877:gst_pad_push_event_unchecked:<capsfilter1:sink> Dropping event
reconfigure because pad is not linked
DEBUG         GST_PADS
gstpad.c:5150:gst_pad_send_event_unchecked:<capsfilter1:src> sent event, ret
error
DEBUG          GST_BUS gstbus.c:310:gst_bus_post:<bus0> [msg 0x10ec6a0]
posting on bus structure-change message: 0x10ec6a0, time 99:99:99.999999999,
seq-num 42, element 'sink', GstMessageStructureChange,
type=(GstStructureChangeType)GST_STRUCTURE_CHANGE_TYPE_PAD_LINK,
owner=(GstElement)"\(GstCapsFilter\)\ capsfilter1", busy=(boolean)false;
DEBUG              bin gstbin.c:3409:gst_bin_handle_message_func:<pipeline0>
[msg 0x10ec6a0] handling child sink message of type structure-change
DEBUG              bin gstbin.c:958:bin_remove_messages:<filesink0:sink>
deleting message 0x10ec620 of types 0x00001000
DEBUG              bin gstbin.c:964:bin_remove_messages:<filesink0> not
deleting message 0x10e7520 of type 0x00100000
DEBUG          GST_BUS gstbus.c:341:gst_bus_post:<bus0> [msg 0x10ec6a0]
dropped
DEBUG GST_ELEMENT_PADS gstutils.c:1651:gst_element_link_pads_full: linked
pad capsfilter1:src to pad filesink0:sink
INFO           default gstutils.c:1876:gst_element_link_pads_filtered: Could
not link pads: tsdemux0:(null) - capsfilter:sink
DEBUG       GST_STATES
gstelement.c:2479:gst_element_set_state_func:<capsfilter1> set_state to NULL
DEBUG       GST_STATES
gstelement.c:2504:gst_element_set_state_func:<capsfilter1> setting target
state to NULL
DEBUG       GST_STATES
gstelement.c:2517:gst_element_set_state_func:<capsfilter1> current PLAYING,
old_pending VOID_PENDING, next VOID_PENDING, old return SUCCESS
DEBUG       GST_STATES
gstelement.c:2551:gst_element_set_state_func:<capsfilter1> intermediate:
setting state from PLAYING to PAUSED
DEBUG       GST_STATES
gstelement.c:2636:gst_element_change_state:<capsfilter1> element changed
state SUCCESS
INFO        GST_STATES
gstelement.c:2303:gst_element_continue_state:<capsfilter1> committing state
from PLAYING to PAUSED, pending NULL, next READY
INFO        GST_STATES
gstelement.c:2233:_priv_gst_element_state_changed:<capsfilter1> notifying
about state-changed PLAYING to PAUSED (NULL pending)
DEBUG          GST_BUS gstbus.c:310:gst_bus_post:<bus0> [msg 0x10ec720]
posting on bus state-changed message: 0x10ec720, time 99:99:99.999999999,
seq-num 43, element 'capsfilter1', GstMessageStateChanged,
old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED,
pending-state=(GstState)GST_STATE_NULL;
DEBUG              bin gstbin.c:3409:gst_bin_handle_message_func:<pipeline0>
[msg 0x10ec720] handling child capsfilter1 message of type state-changed
DEBUG              bin gstbin.c:3744:gst_bin_handle_message_func:<pipeline0>
posting message upward



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

[jopado]

Resolved: Need to use dynamic linking of pads for a live source. I got to
used to the ease of filesrc.



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

[Yasushi SHOJI-2]

Hi,

On Fri, Sep 8, 2017 at 5:18 AM, jopado <[hidden email]> wrote:
> Resolved: Need to use dynamic linking of pads for a live source. I got to
> used to the ease of filesrc.

would you mind to elaborate a bit?

I thought you need tsparse before tsdemux.
--
         yashi
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jopado]

Yasushi SHOJI-2 wrote
> Hi,
>
> On Fri, Sep 8, 2017 at 5:18 AM, jopado &lt;

> jopado1@

> &gt; wrote:
>> Resolved: Need to use dynamic linking of pads for a live source. I got to
>> used to the ease of filesrc.
>
> would you mind to elaborate a bit?
>
> I thought you need tsparse before tsdemux.
> --
>          yashi
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

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

My issue when switching from filesrc to udpsrc was that the the pipeline
linkage cannot be completed until data starts flowing (through the udpsrc to
the demux). So I changed my code and added a pad-added callback for the
tsdemux element.  This is discussed here:
https://gstreamer.freedesktop.org/documentation/application-development/basics/pads.html
<https://gstreamer.freedesktop.org/documentation/application-development/basics/pads.html>  

My transport stream contains only one program so I did not have tsparse in
the pipeline.

However now I have a new problem:
http://gstreamer-devel.966125.n4.nabble.com/udpsrc-to-tsdemux-interaction-td4684546.html
<http://gstreamer-devel.966125.n4.nabble.com/udpsrc-to-tsdemux-interaction-td4684546.html>  




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