GStreamer multicast UDP Streaming not working without 'sprop-parameter-sets' caps set in the client










0















I need some assistance on this guys.



I am using GStreamer 1.0 (14.2) to capture and stream the PC screen (Windows 10) over udp and receive it on Ubuntu 12.4 client. Updating the Ubuntu is not an option.



Server:



gst-launch-1.0 -v gdiscreencapsrc ! queue ! video/x-raw,framerate=30/1 ! decodebin ! videoscale ! videoconvert ! 
openh264enc bitrate=3000000 !
h264parse ! video/x-h264 ! rtph264pay pt=96 config-interval=1
! udpsink host=224.1.1.1 port=5000 auto-multicast=true sync=false


Client:



gst-launch -v udpsrc port=5000 multicast-group=224.1.1.1 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c029, sprop-parameter-sets=(string)"Z0LAKYyNQDwBEvLAPCIRqA==,aM48gA==", payload=(int)96" ! rtph264depay ! h264parse ! queue ! vaapidecode ! vaapisink sync=false


If I get the 'sprop-parameter-sets' from the server output and add it to the client's udpsrc caps, everything is ok. The problems start when I try to stream from another PC with the same script and the same GStreamer version. The 'sprop-parameter-sets' do not match and I see only a grey screen.



I have tried without setting the 'sprop-parameter-sets' and it worked, but only if I start the client before the server. Otherwise, the client receives EOS right after it had been launched and shuts down. Setting the 'sprop-parameter-sets' fixed that issue but brought another.



Any help would be appreciated!



P.S Clients are running on Intel® Desktop Board DN2800MT Innovation Series.










share|improve this question




























    0















    I need some assistance on this guys.



    I am using GStreamer 1.0 (14.2) to capture and stream the PC screen (Windows 10) over udp and receive it on Ubuntu 12.4 client. Updating the Ubuntu is not an option.



    Server:



    gst-launch-1.0 -v gdiscreencapsrc ! queue ! video/x-raw,framerate=30/1 ! decodebin ! videoscale ! videoconvert ! 
    openh264enc bitrate=3000000 !
    h264parse ! video/x-h264 ! rtph264pay pt=96 config-interval=1
    ! udpsink host=224.1.1.1 port=5000 auto-multicast=true sync=false


    Client:



    gst-launch -v udpsrc port=5000 multicast-group=224.1.1.1 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c029, sprop-parameter-sets=(string)"Z0LAKYyNQDwBEvLAPCIRqA==,aM48gA==", payload=(int)96" ! rtph264depay ! h264parse ! queue ! vaapidecode ! vaapisink sync=false


    If I get the 'sprop-parameter-sets' from the server output and add it to the client's udpsrc caps, everything is ok. The problems start when I try to stream from another PC with the same script and the same GStreamer version. The 'sprop-parameter-sets' do not match and I see only a grey screen.



    I have tried without setting the 'sprop-parameter-sets' and it worked, but only if I start the client before the server. Otherwise, the client receives EOS right after it had been launched and shuts down. Setting the 'sprop-parameter-sets' fixed that issue but brought another.



    Any help would be appreciated!



    P.S Clients are running on Intel® Desktop Board DN2800MT Innovation Series.










    share|improve this question


























      0












      0








      0


      2






      I need some assistance on this guys.



      I am using GStreamer 1.0 (14.2) to capture and stream the PC screen (Windows 10) over udp and receive it on Ubuntu 12.4 client. Updating the Ubuntu is not an option.



      Server:



      gst-launch-1.0 -v gdiscreencapsrc ! queue ! video/x-raw,framerate=30/1 ! decodebin ! videoscale ! videoconvert ! 
      openh264enc bitrate=3000000 !
      h264parse ! video/x-h264 ! rtph264pay pt=96 config-interval=1
      ! udpsink host=224.1.1.1 port=5000 auto-multicast=true sync=false


      Client:



      gst-launch -v udpsrc port=5000 multicast-group=224.1.1.1 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c029, sprop-parameter-sets=(string)"Z0LAKYyNQDwBEvLAPCIRqA==,aM48gA==", payload=(int)96" ! rtph264depay ! h264parse ! queue ! vaapidecode ! vaapisink sync=false


      If I get the 'sprop-parameter-sets' from the server output and add it to the client's udpsrc caps, everything is ok. The problems start when I try to stream from another PC with the same script and the same GStreamer version. The 'sprop-parameter-sets' do not match and I see only a grey screen.



      I have tried without setting the 'sprop-parameter-sets' and it worked, but only if I start the client before the server. Otherwise, the client receives EOS right after it had been launched and shuts down. Setting the 'sprop-parameter-sets' fixed that issue but brought another.



      Any help would be appreciated!



      P.S Clients are running on Intel® Desktop Board DN2800MT Innovation Series.










      share|improve this question
















      I need some assistance on this guys.



      I am using GStreamer 1.0 (14.2) to capture and stream the PC screen (Windows 10) over udp and receive it on Ubuntu 12.4 client. Updating the Ubuntu is not an option.



      Server:



      gst-launch-1.0 -v gdiscreencapsrc ! queue ! video/x-raw,framerate=30/1 ! decodebin ! videoscale ! videoconvert ! 
      openh264enc bitrate=3000000 !
      h264parse ! video/x-h264 ! rtph264pay pt=96 config-interval=1
      ! udpsink host=224.1.1.1 port=5000 auto-multicast=true sync=false


      Client:



      gst-launch -v udpsrc port=5000 multicast-group=224.1.1.1 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c029, sprop-parameter-sets=(string)"Z0LAKYyNQDwBEvLAPCIRqA==,aM48gA==", payload=(int)96" ! rtph264depay ! h264parse ! queue ! vaapidecode ! vaapisink sync=false


      If I get the 'sprop-parameter-sets' from the server output and add it to the client's udpsrc caps, everything is ok. The problems start when I try to stream from another PC with the same script and the same GStreamer version. The 'sprop-parameter-sets' do not match and I see only a grey screen.



      I have tried without setting the 'sprop-parameter-sets' and it worked, but only if I start the client before the server. Otherwise, the client receives EOS right after it had been launched and shuts down. Setting the 'sprop-parameter-sets' fixed that issue but brought another.



      Any help would be appreciated!



      P.S Clients are running on Intel® Desktop Board DN2800MT Innovation Series.







      streaming gstreamer multicast






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 13 '18 at 13:11







      Bozhidar Tonchev

















      asked Nov 13 '18 at 13:00









      Bozhidar TonchevBozhidar Tonchev

      12




      12






















          1 Answer
          1






          active

          oldest

          votes


















          0














          sprop-parameter-sets should not be required. You should send SPS and PPS inband. You are already trying to do that for rtph264pay via the config-interval=1 option already. Perhaps you need to add it to the h264parse as well so it does not filter out any SPS/PPS.



          You may want to check on the wire whether you can detect SPS and PPS NAL units being send.



          EDIT: Just noticed - it should be config-interval=-1 so they get inserted before every IDR frame.






          share|improve this answer

























          • I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

            – Bozhidar Tonchev
            Nov 14 '18 at 8:42












          • I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

            – Florian Zwoch
            Nov 14 '18 at 8:58











          • I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

            – Bozhidar Tonchev
            Nov 14 '18 at 9:08











          • On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

            – Florian Zwoch
            Nov 14 '18 at 18:13











          • Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

            – Florian Zwoch
            Nov 14 '18 at 18:18










          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281572%2fgstreamer-multicast-udp-streaming-not-working-without-sprop-parameter-sets-cap%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          sprop-parameter-sets should not be required. You should send SPS and PPS inband. You are already trying to do that for rtph264pay via the config-interval=1 option already. Perhaps you need to add it to the h264parse as well so it does not filter out any SPS/PPS.



          You may want to check on the wire whether you can detect SPS and PPS NAL units being send.



          EDIT: Just noticed - it should be config-interval=-1 so they get inserted before every IDR frame.






          share|improve this answer

























          • I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

            – Bozhidar Tonchev
            Nov 14 '18 at 8:42












          • I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

            – Florian Zwoch
            Nov 14 '18 at 8:58











          • I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

            – Bozhidar Tonchev
            Nov 14 '18 at 9:08











          • On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

            – Florian Zwoch
            Nov 14 '18 at 18:13











          • Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

            – Florian Zwoch
            Nov 14 '18 at 18:18















          0














          sprop-parameter-sets should not be required. You should send SPS and PPS inband. You are already trying to do that for rtph264pay via the config-interval=1 option already. Perhaps you need to add it to the h264parse as well so it does not filter out any SPS/PPS.



          You may want to check on the wire whether you can detect SPS and PPS NAL units being send.



          EDIT: Just noticed - it should be config-interval=-1 so they get inserted before every IDR frame.






          share|improve this answer

























          • I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

            – Bozhidar Tonchev
            Nov 14 '18 at 8:42












          • I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

            – Florian Zwoch
            Nov 14 '18 at 8:58











          • I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

            – Bozhidar Tonchev
            Nov 14 '18 at 9:08











          • On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

            – Florian Zwoch
            Nov 14 '18 at 18:13











          • Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

            – Florian Zwoch
            Nov 14 '18 at 18:18













          0












          0








          0







          sprop-parameter-sets should not be required. You should send SPS and PPS inband. You are already trying to do that for rtph264pay via the config-interval=1 option already. Perhaps you need to add it to the h264parse as well so it does not filter out any SPS/PPS.



          You may want to check on the wire whether you can detect SPS and PPS NAL units being send.



          EDIT: Just noticed - it should be config-interval=-1 so they get inserted before every IDR frame.






          share|improve this answer















          sprop-parameter-sets should not be required. You should send SPS and PPS inband. You are already trying to do that for rtph264pay via the config-interval=1 option already. Perhaps you need to add it to the h264parse as well so it does not filter out any SPS/PPS.



          You may want to check on the wire whether you can detect SPS and PPS NAL units being send.



          EDIT: Just noticed - it should be config-interval=-1 so they get inserted before every IDR frame.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 13 '18 at 21:31

























          answered Nov 13 '18 at 21:20









          Florian ZwochFlorian Zwoch

          1,9982512




          1,9982512












          • I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

            – Bozhidar Tonchev
            Nov 14 '18 at 8:42












          • I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

            – Florian Zwoch
            Nov 14 '18 at 8:58











          • I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

            – Bozhidar Tonchev
            Nov 14 '18 at 9:08











          • On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

            – Florian Zwoch
            Nov 14 '18 at 18:13











          • Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

            – Florian Zwoch
            Nov 14 '18 at 18:18

















          • I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

            – Bozhidar Tonchev
            Nov 14 '18 at 8:42












          • I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

            – Florian Zwoch
            Nov 14 '18 at 8:58











          • I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

            – Bozhidar Tonchev
            Nov 14 '18 at 9:08











          • On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

            – Florian Zwoch
            Nov 14 '18 at 18:13











          • Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

            – Florian Zwoch
            Nov 14 '18 at 18:18
















          I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

          – Bozhidar Tonchev
          Nov 14 '18 at 8:42






          I have added config-interval=-1 to both h264parse and rtph264pay elements on the server and config-interval=1 (in 0.10 it is guint parameter) to h264parse element on the client, but there was no effect. I am attaching the log from the client. Client Log

          – Bozhidar Tonchev
          Nov 14 '18 at 8:42














          I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

          – Florian Zwoch
          Nov 14 '18 at 8:58





          I think you need to figure out where the EOS comes from. Since you don't stop the sender I see no reason why it is there. Perhaps the vaapi decoder chokes because you tune in into random access - not having a clean start. Perhaps try vaapih264dec directly? It should wait and discard data unless you get a SPS/PPS to decode a picture. Really.. the EOS just doesn't seem right.

          – Florian Zwoch
          Nov 14 '18 at 8:58













          I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

          – Bozhidar Tonchev
          Nov 14 '18 at 9:08





          I also noticed there is some problem with the vaapidecode element. Vaapidecode Log You can see the decode error 2, which if I am right should be translated to GST_VAAPI_DECODER_STATUS_ERROR_ALLOCATION_FAILED P.S For some reason I have no vaapih264dec. Could you provide me the plugin name and package, maybe a gst-inspect for this element? Thanks.

          – Bozhidar Tonchev
          Nov 14 '18 at 9:08













          On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

          – Florian Zwoch
          Nov 14 '18 at 18:13





          On my regular system I just do gst-inspect-1.0 vaapi and get all decoder flavors. It may be different on your special board though. I would try to get a software decoder like avdec_h264 and see if the behavior is the same.

          – Florian Zwoch
          Nov 14 '18 at 18:13













          Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

          – Florian Zwoch
          Nov 14 '18 at 18:18





          Also there are GStreamer elements available for the Intel Media SDK. These may worth investigating - they communicate with intel's SDK/hardware directly without the VAAPI layer.

          – Florian Zwoch
          Nov 14 '18 at 18:18



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281572%2fgstreamer-multicast-udp-streaming-not-working-without-sprop-parameter-sets-cap%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Darth Vader #20

          How to how show current date and time by default on contact form 7 in WordPress without taking input from user in datetimepicker

          Ondo