tcpclientlink not linked
Locked
 
|
Hello G-Streamers
I'm totally new to mailing-lists, so don't where to put my script... So i've put it on Pastebin and a link herehere. I hope someone can help med with this problem that i can't solve. Case: I have one Gst-pipeline running with a tcpserversink to a tcpclientsrc running from command-line and it will work with this launch-cmd: gst-launch-1.0 tcpclientsrc ! host=192.168.0.16 port=9001 ! gdpdepay ! rtph264depay ! h264parse ! decodebin ! videoconvert ! autovideosink Video caps are being set at serverside. I have then tried to make that lanch into a Python-script. But for some reason that i can't figure out, when the script is executet i'll get Gst-masssage: /GstPipeline:player/GstTCPClientSrc:tcpclientsrc_1: streaming task paused, reason not-linked (-1) If server is not running, as expectet: error for not being allowed acces. Do tcpclientsrc need som kind of caps reader, to get caps from stream and that's why is not linked...? I ahve also tried with: player.link(tcpclientsrc_1) So can anyone help me pointing at where or what link did i miss..? I have being all over dev-doc, tutorials, google and moore, but i can't see what i've missed Also script is very simpel, so i.e. I haven't made do-timestamp and so on. But serverside is startet by command launch and have all the Caps, depay config and so on. In advance: thank for your help. Python-script: Python-script on pastebin |
|
|
On Sat, 2016-04-02 at 23:20 -0700, RAJensen wrote:
Hi, Case: > I have one Gst-pipeline running with a tcpserversink to a > tcpclientsrc > running from command-line and it will work with this launch-cmd: > gst-launch-1.0 tcpclientsrc ! host=192.168.0.16 port=9001 ! gdpdepay > ! > rtph264depay ! h264parse ! decodebin ! videoconvert ! autovideosink > > Video caps are being set at serverside. > > I have then tried to make that lanch into a Python-script. > > But for some reason that i can't figure out, when the script is > executet > i'll get Gst-masssage: > /GstPipeline:player/GstTCPClientSrc:tcpclientsrc_1: > streaming task paused, reason not-linked (-1) The problem is that decodebin does not have any source pads yet when the pipeline is built, so this self.decodebin_1.link(self.videoconvert_1) will fail (check return value), and you also don't link it later in response to the "pad-added" signal. The easiest way for now might be to just hard-code an H264 decoder such as avdec_h264. Alternatively, connect to the "pad-added" signal and link in the callback when it gets called (see 'dynamic pads' section in docs). 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 |
|
|
Hej Tim.
Thank you fot the answer. I really appreciate it. That did the trick - Pipeline is rolling, data flow from tcpclientsrc to autovideosink. :-P But picture is frozen a frame and is heavily pixelatet. Player dosen't seem to update next frame or display Any ide? With best Regards Robin Den 04-04-2016 kl. 10:47 skrev Tim Müller: > On Sat, 2016-04-02 at 23:20 -0700, RAJensen wrote: > > Hi, > > Case: >> I have one Gst-pipeline running with a tcpserversink to a >> tcpclientsrc >> running from command-line and it will work with this launch-cmd: >> gst-launch-1.0 tcpclientsrc ! host=192.168.0.16 port=9001 ! gdpdepay >> ! >> rtph264depay ! h264parse ! decodebin ! videoconvert ! autovideosink >> >> Video caps are being set at serverside. >> >> I have then tried to make that lanch into a Python-script. >> >> But for some reason that i can't figure out, when the script is >> executet >> i'll get Gst-masssage: >> /GstPipeline:player/GstTCPClientSrc:tcpclientsrc_1: >> streaming task paused, reason not-linked (-1) > The problem is that decodebin does not have any source pads yet when > the pipeline is built, so this > > self.decodebin_1.link(self.videoconvert_1) > > will fail (check return value), and you also don't link it later in > response to the "pad-added" signal. > > The easiest way for now might be to just hard-code an H264 decoder such > as avdec_h264. > > Alternatively, connect to the "pad-added" signal and link in the > callback when it gets called (see 'dynamic pads' section in docs). > > Cheers > -Tim > _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
UPDATE:
I've removed h264parse and now is the picture clear, but still not running. Seems like 1.frame is decoded and handled all the way and out to videosink. It's like a clock or something is still missing... Robin. Den 04-04-2016 kl. 20:33 skrev Robin A. Jensen: > Hej Tim. > > Thank you fot the answer. I really appreciate it. > That did the trick - Pipeline is rolling, data flow from tcpclientsrc > to autovideosink. :-P > But picture is frozen a frame and is heavily pixelatet. Player dosen't > seem to update next frame or display > > Any ide? > > With best Regards > Robin > > > > Den 04-04-2016 kl. 10:47 skrev Tim Müller: >> On Sat, 2016-04-02 at 23:20 -0700, RAJensen wrote: >> >> Hi, >> >> Case: >>> I have one Gst-pipeline running with a tcpserversink to a >>> tcpclientsrc >>> running from command-line and it will work with this launch-cmd: >>> gst-launch-1.0 tcpclientsrc ! host=192.168.0.16 port=9001 ! gdpdepay >>> ! >>> rtph264depay ! h264parse ! decodebin ! videoconvert ! autovideosink >>> >>> Video caps are being set at serverside. >>> >>> I have then tried to make that lanch into a Python-script. >>> >>> But for some reason that i can't figure out, when the script is >>> executet >>> i'll get Gst-masssage: >>> /GstPipeline:player/GstTCPClientSrc:tcpclientsrc_1: >>> streaming task paused, reason not-linked (-1) >> The problem is that decodebin does not have any source pads yet when >> the pipeline is built, so this >> >> self.decodebin_1.link(self.videoconvert_1) >> >> will fail (check return value), and you also don't link it later in >> response to the "pad-added" signal. >> >> The easiest way for now might be to just hard-code an H264 decoder such >> as avdec_h264. >> >> Alternatively, connect to the "pad-added" signal and link in the >> callback when it gets called (see 'dynamic pads' section in docs). >> >> Cheers >> -Tim >> > > _______________________________________________ > 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 |
|
|
Update:
I've put back h264parse in pibeline. Then change "playbin" with "Pipeline" Createt a pad for "tcpclientsrc - type=src" and link it to the pipeline Now it rolls and pictures is decoded and no more freeze but still dropouts, with grey display, but picture will recover and run. So now is my 2-in-1 question: are caps provided automatic from src to decodebin to videoconverter? Or should they be handlet seperatly after decodebin have found them in stream? Or is it somekind of buffering issue where frames are missing in stream...? With regards Robin. Den 04-04-2016 kl. 21:39 skrev Robin A. Jensen: > UPDATE: > > I've removed h264parse and now is the picture clear, but still not > running. > Seems like 1.frame is decoded and handled all the way and out to > videosink. > It's like a clock or something is still missing... > > Robin. > > Den 04-04-2016 kl. 20:33 skrev Robin A. Jensen: >> Hej Tim. >> >> Thank you fot the answer. I really appreciate it. >> That did the trick - Pipeline is rolling, data flow from tcpclientsrc >> to autovideosink. :-P >> But picture is frozen a frame and is heavily pixelatet. Player >> dosen't seem to update next frame or display >> >> Any ide? >> >> With best Regards >> Robin >> >> >> >> Den 04-04-2016 kl. 10:47 skrev Tim Müller: >>> On Sat, 2016-04-02 at 23:20 -0700, RAJensen wrote: >>> >>> Hi, >>> >>> Case: >>>> I have one Gst-pipeline running with a tcpserversink to a >>>> tcpclientsrc >>>> running from command-line and it will work with this launch-cmd: >>>> gst-launch-1.0 tcpclientsrc ! host=192.168.0.16 port=9001 ! gdpdepay >>>> ! >>>> rtph264depay ! h264parse ! decodebin ! videoconvert ! autovideosink >>>> >>>> Video caps are being set at serverside. >>>> >>>> I have then tried to make that lanch into a Python-script. >>>> >>>> But for some reason that i can't figure out, when the script is >>>> executet >>>> i'll get Gst-masssage: >>>> /GstPipeline:player/GstTCPClientSrc:tcpclientsrc_1: >>>> streaming task paused, reason not-linked (-1) >>> The problem is that decodebin does not have any source pads yet when >>> the pipeline is built, so this >>> >>> self.decodebin_1.link(self.videoconvert_1) >>> >>> will fail (check return value), and you also don't link it later in >>> response to the "pad-added" signal. >>> >>> The easiest way for now might be to just hard-code an H264 decoder such >>> as avdec_h264. >>> >>> Alternatively, connect to the "pad-added" signal and link in the >>> callback when it gets called (see 'dynamic pads' section in docs). >>> >>> Cheers >>> -Tim >>> >> >> _______________________________________________ >> 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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |