GStreamer multicast UDP Streaming not working without 'sprop-parameter-sets' caps set in the client
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
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
add a comment |
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
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
add a comment |
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
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
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
streaming gstreamer multicast
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
edited Nov 13 '18 at 13:11
Bozhidar Tonchev
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
asked Nov 13 '18 at 13:00
Bozhidar TonchevBozhidar Tonchev
12
12
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
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 tryvaapih264decdirectly? 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 novaapih264dec. 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 dogst-inspect-1.0 vaapiand get all decoder flavors. It may be different on your special board though. I would try to get a software decoder likeavdec_h264and 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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
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 tryvaapih264decdirectly? 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 novaapih264dec. 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 dogst-inspect-1.0 vaapiand get all decoder flavors. It may be different on your special board though. I would try to get a software decoder likeavdec_h264and 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
add a comment |
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.
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
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 tryvaapih264decdirectly? 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 novaapih264dec. 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 dogst-inspect-1.0 vaapiand get all decoder flavors. It may be different on your special board though. I would try to get a software decoder likeavdec_h264and 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
add a comment |
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.
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
1,9982512
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.
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
1,9982512
edited Nov 13 '18 at 21:31
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
1,9982512
answered Nov 13 '18 at 21:20
Florian ZwochFlorian Zwoch
1,9982512
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 tryvaapih264decdirectly? 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 novaapih264dec. 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 dogst-inspect-1.0 vaapiand get all decoder flavors. It may be different on your special board though. I would try to get a software decoder likeavdec_h264and 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
add a comment |
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 tryvaapih264decdirectly? 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 novaapih264dec. 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 dogst-inspect-1.0 vaapiand get all decoder flavors. It may be different on your special board though. I would try to get a software decoder likeavdec_h264and 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
