Problem with gstreamer using the tsdemux

[Torben]

Hi all,

I have a problem to get the srcipt running in my application. So at first I
tried to compile the following:

gst-launch-1.0 -v udpsrc multicast-group=224.10.10.10 port=8008 ! tsdemux !
h264parse ! avdec_h264 ! d3dvideosink sync=false

It worked and displays the correct video.

But if I try to do this in my application than happens nothing. I think the
problem is that the event linkElements does not get called. So it comes from
the pad-added signal of the tsdemux. I do not get any errors, or at least I
cannot see them. So it seems for me that everything is ok. But the signal is
not getting called...

I run the following code with GST_DEBUG level 4.  gstdebug(4).txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t379676/gstdebug%284%29.txt>  

Can you please tell me what I am doing wrong?

#include <QCoreApplication>
#include <gst/gst.h>
#include <iostream>

typedef struct
{
  GstElement * pipeline = nullptr;
  GstElement * source = nullptr;
  GstElement * tsDemux = nullptr;
  GstElement * h264parse = nullptr;
  GstElement * avdecH264 = nullptr;
  GstElement * sinkVideo = nullptr;
} VideoData;

static void linkElements(GstElement* element,GstPad* sourcePad, gpointer
sinkElement);

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
    GMainLoop *loop;

    if (!g_thread_supported ())
        g_thread_init (nullptr);

    gst_init ( 0, 0 );

    loop = g_main_loop_new (nullptr, FALSE);

    VideoData m_data;

    m_data.pipeline = gst_pipeline_new ("player");
    m_data.source = gst_element_factory_make ("udpsrc", nullptr);
    m_data.tsDemux = gst_element_factory_make("tsdemux", nullptr);
    m_data.h264parse = gst_element_factory_make("h264parse", nullptr);
    m_data.avdecH264 = gst_element_factory_make("avdec_h264", nullptr);
    m_data.sinkVideo = gst_element_factory_make("d3dvideosink", nullptr);

    g_object_set(G_OBJECT (m_data.source), "multicast-group",
"224.10.10.10", nullptr);
    g_object_set(G_OBJECT (m_data.source), "port", 8008, nullptr);
    g_object_set(G_OBJECT (m_data.sinkVideo), "sync", false, nullptr);

    gst_bin_add_many(GST_BIN(m_data.pipeline), m_data.source,
m_data.tsDemux, m_data.h264parse, m_data.avdecH264, m_data.sinkVideo,
nullptr);

    std::cout << "Start linking all elements..." << std::endl;

    if ( gst_element_link (m_data.source, m_data.tsDemux ) != TRUE )
    {
        std::cout << "1: Element could not be linked." << std::endl;
        gst_object_unref (m_data.pipeline);
        return 0;
    }

    g_signal_connect(m_data.tsDemux, "pad-added", G_CALLBACK(linkElements),
nullptr); //nullptr //&m_data

    if ( gst_element_link_many(m_data.h264parse, m_data.avdecH264,
m_data.sinkVideo, nullptr) != TRUE )
    {
        std::cout << "2: Element could not be linked." << std::endl;
        gst_object_unref (m_data.pipeline);
        return 0;
    }

    std::cout << "Linked all elements!" << std::endl;

    GstStateChangeReturn ret = gst_element_set_state(m_data.sinkVideo,
GST_STATE_READY);

    ret = gst_element_set_state (m_data.pipeline, GST_STATE_PLAYING);
    if (ret == GST_STATE_CHANGE_FAILURE)
    {
        std::cout << "Unable to set the pipeline to the playing state." <<
std::endl;
        gst_object_unref (m_data.pipeline);
        return 0;
    }

    g_main_loop_run (loop);

    return a.exec();
}

static void linkElements(GstElement* element,GstPad* sourcePad, gpointer
sinkElement){
    std::cout << "Got here linkElements!" << std::endl; // It will never get
here!
    GstPad*
sinkPad=gst_element_get_static_pad((GstElement*)sinkElement,"sink");
    gst_pad_link(sourcePad,sinkPad);
    gst_object_unref(sinkPad);
}




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

[Tim Müller]

On Tue, 2020-10-06 at 06:02 -0500, Torben wrote:

Hi Torben,

>     g_signal_connect(m_data.tsDemux, "pad-added",
>                      G_CALLBACK(linkElements),
>                      nullptr); //nullptr //&m_data

I think you want to pass m_data.h264parse here.


> static void linkElements(GstElement* element,GstPad* sourcePad,
> gpointer sinkElement){
>     // It will never get here!

The most likely cause would be that it's not receiving data for some
reason.

Does it show packets being received if you run it with GST_DEBUG=*src:6
?

Does it work if you create the pipeline with gst_parse_launch()
instead?

Cheers
 Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

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

[Tony Houghton]

I think tsdemux is badly broken at the moment. I'm having a similar experience to you: sometimes it works, then you change something that should be completely irrelevant (in your case constructing the pipeline in C++ instead of using gst-launch; in my case I've found that just changing the log level can make a difference) and the pipeline freezes. See also issue 1419.

I've just tried adding a queue2 to my manager element where its sink is linked with my internal source (has a single src pad with caps "video/mpegts, systemstream = (boolean) true;") and the queue2's src is the target of my manager's src ghost pad. This made things worse. Highlights from the log of `gst-launch-1.0 playbin uri="htsp://..."`:

0:00:00.088988232 24066 0x5591eb207ea0 INFO     GST_ELEMENT_FACTORY gstelementfactory.c:363:gst_element_factory_create: creating element "tsdemux"
0:00:00.089118072 24066 0x5591eb207ea0 INFO        GST_ELEMENT_PADS gstelement.c:752:gst_element_add_pad:<MpegTSBase@0x7fac2c1d8000> adding pad 'sink'
0:00:00.089291804 24066 0x5591eb207ea0 INFO                GST_PADS gstpad.c:2377:gst_pad_link_prepare: trying to link typefind:src and tsdemux0:sink
0:00:00.089306656 24066 0x5591eb207ea0 INFO                GST_PADS gstpad.c:2585:gst_pad_link_full: linked typefind:src and tsdemux0:sink, successful
0:00:00.089310744 24066 0x5591eb207ea0 INFO               GST_EVENT gstevent.c:1610:gst_event_new_reconfigure: creating reconfigure event
0:00:00.089334061 24066 0x5591eb207ea0 INFO              GST_STATES gstelement.c:2769:gst_element_continue_state:<tsdemux0> completed state change to READY
0:00:00.089340768 24066 0x5591eb207ea0 INFO              GST_STATES gstelement.c:2669:_priv_gst_element_state_changed:<tsdemux0> notifying about state-changed NULL to READY (VOID_PENDING pending)
0:00:00.089424733 24066 0x5591eb207ea0 INFO        GST_ELEMENT_PADS gstelement.c:1006:gst_element_get_static_pad: no such pad 'video_%01x_%05x' in element "tsdemux0"
0:00:00.089433342 24066 0x5591eb207ea0 INFO        GST_ELEMENT_PADS gstelement.c:1006:gst_element_get_static_pad: no such pad 'audio_%01x_%05x' in element "tsdemux0"
0:00:00.089437649 24066 0x5591eb207ea0 INFO        GST_ELEMENT_PADS gstelement.c:1006:gst_element_get_static_pad: no such pad 'subpicture_%01x_%05x' in element "tsdemux0"
0:00:00.089441946 24066 0x5591eb207ea0 INFO        GST_ELEMENT_PADS gstelement.c:1006:gst_element_get_static_pad: no such pad 'private_%01x_%05x' in element "tsdemux0"
0:00:00.089528559 24066 0x5591eb207ea0 WARN                    task gsttask.c:890:gst_task_join:<srcqueue:src> trying to join task from its thread

(gst-launch-1.0:24066): GStreamer-WARNING **: 15:40:38.404:
Trying to join task 0x5591eb225170 from its thread would deadlock.
You cannot change the state of an element from its streaming
thread. Use g_idle_add() or post a GstMessage on the bus to
schedule the state change from the main thread.

I think I'm going to have to give up on gstreamer and try to get my head around something like MSE in a web app :-(.

On Tue, 6 Oct 2020 at 12:30, Torben <[hidden email]> wrote:

Hi all,

I have a problem to get the srcipt running in my application. So at first I
tried to compile the following:

gst-launch-1.0 -v udpsrc multicast-group=224.10.10.10 port=8008 ! tsdemux !
h264parse ! avdec_h264 ! d3dvideosink sync=false

It worked and displays the correct video.

But if I try to do this in my application than happens nothing. I think the
problem is that the event linkElements does not get called. So it comes from
the pad-added signal of the tsdemux. I do not get any errors, or at least I
cannot see them. So it seems for me that everything is ok. But the signal is
not getting called...

I run the following code with GST_DEBUG level 4.  gstdebug(4).txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t379676/gstdebug%284%29.txt> 

Can you please tell me what I am doing wrong?

#include <QCoreApplication>
#include <gst/gst.h>
#include <iostream>

typedef struct
{
  GstElement * pipeline = nullptr;
  GstElement * source = nullptr;
  GstElement * tsDemux = nullptr;
  GstElement * h264parse = nullptr;
  GstElement * avdecH264 = nullptr;
  GstElement * sinkVideo = nullptr;
} VideoData;

static void linkElements(GstElement* element,GstPad* sourcePad, gpointer
sinkElement);

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
    GMainLoop *loop;

    if (!g_thread_supported ())
        g_thread_init (nullptr);

    gst_init ( 0, 0 );

    loop = g_main_loop_new (nullptr, FALSE);

    VideoData m_data;

    m_data.pipeline = gst_pipeline_new ("player");
    m_data.source = gst_element_factory_make ("udpsrc", nullptr);
    m_data.tsDemux = gst_element_factory_make("tsdemux", nullptr);
    m_data.h264parse = gst_element_factory_make("h264parse", nullptr);
    m_data.avdecH264 = gst_element_factory_make("avdec_h264", nullptr);
    m_data.sinkVideo = gst_element_factory_make("d3dvideosink", nullptr);

    g_object_set(G_OBJECT (m_data.source), "multicast-group",
"224.10.10.10", nullptr);
    g_object_set(G_OBJECT (m_data.source), "port", 8008, nullptr);
    g_object_set(G_OBJECT (m_data.sinkVideo), "sync", false, nullptr);

    gst_bin_add_many(GST_BIN(m_data.pipeline), m_data.source,
m_data.tsDemux, m_data.h264parse, m_data.avdecH264, m_data.sinkVideo,
nullptr);

    std::cout << "Start linking all elements..." << std::endl;

    if ( gst_element_link (m_data.source, m_data.tsDemux ) != TRUE )
    {
        std::cout << "1: Element could not be linked." << std::endl;
        gst_object_unref (m_data.pipeline);
        return 0;
    }

    g_signal_connect(m_data.tsDemux, "pad-added", G_CALLBACK(linkElements),
nullptr); //nullptr //&m_data

    if ( gst_element_link_many(m_data.h264parse, m_data.avdecH264,
m_data.sinkVideo, nullptr) != TRUE )
    {
        std::cout << "2: Element could not be linked." << std::endl;
        gst_object_unref (m_data.pipeline);
        return 0;
    }

    std::cout << "Linked all elements!" << std::endl;

    GstStateChangeReturn ret = gst_element_set_state(m_data.sinkVideo,
GST_STATE_READY);

    ret = gst_element_set_state (m_data.pipeline, GST_STATE_PLAYING);
    if (ret == GST_STATE_CHANGE_FAILURE)
    {
        std::cout << "Unable to set the pipeline to the playing state." <<
std::endl;
        gst_object_unref (m_data.pipeline);
        return 0;
    }

    g_main_loop_run (loop);

    return a.exec();
}

static void linkElements(GstElement* element,GstPad* sourcePad, gpointer
sinkElement){
    std::cout << "Got here linkElements!" << std::endl; // It will never get
here!
    GstPad*
sinkPad=gst_element_get_static_pad((GstElement*)sinkElement,"sink");
    gst_pad_link(sourcePad,sinkPad);
    gst_object_unref(sinkPad);
}




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

--

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

[Tim-Philipp Müller-2]

On Tue, 2020-10-06 at 16:33 +0100, Tony Houghton wrote:

Hi Tony,

I appreciate it's frustrating when things don't work as expected, but
please start your own thread for your own issues.

tsdemux appears to work just fine for many other people, but if you are
affected by the tsdemux issue you linked, perhaps you could help
identify the offending commit as per the instructions on the ticket.

The task join warning usually means you're setting pipeline or bin
state from a streaming thread callback, which is not allowed and can
cause deadlocks.

Cheers

 Tim

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

[Torben]

Hi Tim, thank you for answering.

> >     g_signal_connect(m_data.tsDemux, "pad-added",
> >                      G_CALLBACK(linkElements),
> >                      nullptr); //nullptr //&m_data

> I think you want to pass m_data.h264parse here.

Yeah, that is correct. I tried just to give a nullptr to see if than the
answer from the message comes, but it didn't come anyway. I set it now to
the m_data.h264parse.


> Does it show packets being received if you run it with GST_DEBUG=*src:6 ?

I don't think so. I have attached the log file which is generated through
the GST_DEBUG=*src:6.
gstreamer_src6.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t379676/gstreamer_src6.txt>  


> Does it work if you create the pipeline with gst_parse_launch() instead?

What I tried yet, was parsing everything in the QProcess. This works:
m_process.start( QString( "C:\\gstreamer\\1.0\\x86\\bin\\gst-launch-1.0 -v
udpsrc multicast-group=224.10.10.10 port=8008 ! tsdemux ! h264parse !
avdec_h264 ! d3dvideosink sync=false" ) );
Where m_process is a QProcess.
The other way with gst_parse_launch I will try yet.




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

[Torben]

Hi Tim,

> The task join warning usually means you're setting pipeline or bin
> state from a streaming thread callback, which is not allowed and can
> cause deadlocks.

If I understand you correct, this can only be caused by a streaming thread
callback. But the current problem is that I do not get any callbacks. This
is one of my current problems.




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

[Torben]

> > Does it work if you create the pipeline with gst_parse_launch() instead?

> What I tried yet, was parsing everything in the QProcess. This works:
> m_process.start( QString( "C:\\gstreamer\\1.0\\x86\\bin\\gst-launch-1.0 -v
> udpsrc multicast-group=224.10.10.10 port=8008 ! tsdemux ! h264parse !
> avdec_h264 ! d3dvideosink sync=false" ) );
> Where m_process is a QProcess.
> The other way with gst_parse_launch I will try yet.

I tried the way with the gst_parse_launch and even this did not work! The
output of the messages are exactly the same as the above. So in the
gst_parse_launch I did the following, like above:
udpsrc multicast-group=224.10.10.10 port=8008 ! tsdemux ! h264parse !
avdec_h264 ! d3dvideosink sync=false




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

[Tony Houghton]

On Tue, 6 Oct 2020 at 19:29, Tim-Philipp Müller <[hidden email]> wrote:

On Tue, 2020-10-06 at 16:33 +0100, Tony Houghton wrote:

Hi Tony,

I appreciate it's frustrating when things don't work as expected, but
please start your own thread for your own issues.

Sorry about that, but at the moment I'm not entirely sure whether I'm doing something wrong, or whether my problems and these others have the same root cause.

 

tsdemux appears to work just fine for many other people, but if you are
affected by the tsdemux issue you linked, perhaps you could help
identify the offending commit as per the instructions on the ticket.

OK, next time I get blocked by similar symptoms I'll give that a try. 

 

The task join warning usually means you're setting pipeline or bin
state from a streaming thread callback, which is not allowed and can
cause deadlocks.

 The only time my code explicitly sets an element state is when it calls gst_element_sync_state_with_parent() after adding the child elements to my custom manager/bin, during the set_uri handler, and this error occurs some time after that. I've since replaced the queue2 with a queue, and that works just fine.

--

TH

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

[Torben]

I have found the problem!

It is the windows firewall. It just ask if you tried the first time to
connect to something to ask for the firewall. I just said use the Private
Network and evertything worked till now as expected.

But as soon as I tried to connect to the 224.10.10.10 it is getting blocked.
So I had to change this to use also the public network. And it works...
Damn! It costs me a week to find this out...

Can I close this somehow?

With kind regards
Torben



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