autovideosink does not work in native Windows machine for RTP stream but works in VM

[Rigamonti Roberto]

Hello!


I am facing a weird problem on a native Windows 10 machine (with a Geforce GTX 1660 TI graphic card).

I have developed a gstreamer-based program (that runs on an NVIDIA-based custom embedded system) to send a stream of data coming from a camera over UDP, and I usually receive the stream (which is encoded with H.265) with the command:

gst-launch-1.0 udpsrc port=5000 ! "application/x-rtp, encoding-name=H265, payload=96" ! rtph265depay ! h265parse ! decodebin ! autovideosink

Everything works perfectly under Linux (even using an old version of Gstreamer), and I've tried it also in a Windows 10 VM (using Virtualbox on a Linux host).

However, when doing the same on the above-mentioned Windows 10 PC, things do not work anymore...

This is the error I get:

https://ibb.co/Dtc6w46

[https://i.ibb.co/hyQn2sn/error0.png]<https://ibb.co/Dtc6w46>

error0 — ImgBB<https://ibb.co/Dtc6w46>
ibb.co
Image error0 hosted in ImgBB


Increasing the debug level, I get:

https://ibb.co/q1gx11Q

[https://i.ibb.co/Bs6wssM/error1.png]<https://ibb.co/q1gx11Q>

error1 — ImgBB<https://ibb.co/q1gx11Q>
ibb.co
Image error1 hosted in ImgBB


One step further:

https://ibb.co/9bmcGQN

[https://i.ibb.co/hBxLC3y/error3.png]<https://ibb.co/9bmcGQN>

error3 — ImgBB<https://ibb.co/9bmcGQN>
ibb.co
Image error3 hosted in ImgBB


However, VLC is perfectly able to receive and decode the stream on the same machine (I have ditched it since it introduced an unacceptable latency), and even Gstreamer works perfectly when saving the stream to file with the command:

gst-launch-1.0 -e udpsrc port=5000 ! "application/x-rtp, encoding-name=H265, payload=96" ! rtph265depay ! h265parse ! mp4mux ! filesink location=DST_FILENAME.mp4

instead of showing it on the screen.

As an additional test, I've tried running:

gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink

and it shows the expected pattern.

What I see in the last log shown above is that the detected width and height are totally wrong (it should get 360x288). I have updated the NVIDIA drivers to the latest version, but no change in the results.


1) what could be the issue here? How can I solve it?

2) is there a way to disable hardware acceleration in autovideosink? (since I've managed to decode the H.265 stream in the VM with the emulated video card, I see no point in using it if it causes any trouble).


Thanks a lot in advance!!


Best,

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

[Tim Müller]

On Fri, 2021-01-08 at 10:43 +0000, Rigamonti Roberto wrote:

Hi,

> even Gstreamer works perfectly when saving
> the stream to file with the command:
>
> gst-launch-1.0 -e udpsrc port=5000 ! "application/x-rtp, encoding-
> name=H265, payload=96" ! rtph265depay ! h265parse ! mp4mux ! filesink
> location=DST_FILENAME.mp4
>
> instead of showing it on the screen.

What do you mean by "works perfectly" here? That it doesn't complain or
error out, or that the resulting mp4 file plays just fine afterwards?

It appears there's a problem with packet loss or reordered packets
here. Maybe nvh265dec has a start-up delay that blocks the udpsrc for a
bit too long (that's just speculation).

Have you tried putting a queue after udpsrc, like

 udpsrc ! queue max-size-time=0 max-size-buffers=0 max-size-bytes=0

or even better an rtpjitterbuffer like

 udpsrc ! rtpjitterbuffer latency=100 ! ..

Cheers
 Tim

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

[Rigamonti Roberto]

Thanks a lot Tim for the very quick reply! :)
(weird, I haven't received it in my mailbox :S)

By "works perfectly" I mean that both there are no errors/complaints and the generated MP4 file plays nicely.
I'll try your suggestions as soon as the remote system will go online and I'll let you know!

Thanks again and have a nice weekend!
Rob
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Rigamonti Roberto]

Dear Tim,


I've managed to do the tests you've suggested (sorry for the delay, but the emitter is remote (>300km) and I have to wait for someone to turn it on for me...).

Using queue after udpsrc this is what I get: https://ibb.co/hBntcxg

Increasing the debug level, I get:

https://ibb.co/s5kcfFj
https://ibb.co/2F5KvD3
When using an rtpjitterbuffer, things seem to improve a bit (in the sense that at least gstreamer does not halt), but I'm still unable to get any image :(
https://ibb.co/MPqF2kN
https://ibb.co/18s8NMq
https://ibb.co/0nG2n5W
Do you have any further test I could try?
Thanks a lot in advance and have a nice day!
Rob

________________________________
De : gstreamer-devel <[hidden email]> de la part de Tim Müller <[hidden email]>
Envoyé : vendredi, 8 janvier 2021 13:42:39
À : Discussion of the development of and with GStreamer
Objet : Re: autovideosink does not work in native Windows machine for RTP stream but works in VM

On Fri, 2021-01-08 at 10:43 +0000, Rigamonti Roberto wrote:

Hi,

> even Gstreamer works perfectly when saving
> the stream to file with the command:
>
> gst-launch-1.0 -e udpsrc port=5000 ! "application/x-rtp, encoding-
> name=H265, payload=96" ! rtph265depay ! h265parse ! mp4mux ! filesink
> location=DST_FILENAME.mp4
>
> instead of showing it on the screen.

What do you mean by "works perfectly" here? That it doesn't complain or
error out, or that the resulting mp4 file plays just fine afterwards?

It appears there's a problem with packet loss or reordered packets
here. Maybe nvh265dec has a start-up delay that blocks the udpsrc for a
bit too long (that's just speculation).

Have you tried putting a queue after udpsrc, like

 udpsrc ! queue max-size-time=0 max-size-buffers=0 max-size-bytes=0

or even better an rtpjitterbuffer like

 udpsrc ! rtpjitterbuffer latency=100 ! ..

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

[Mailing List SVR]

Hi,

this seems an issue with the hw decoder, please try something like this:

..... ! h265parse ! avdec_h265 ! autovideosink

or specify manually the video sink too.

This will use more CPU since it will use a sw decoder,

regards
Nicola


Il 12/01/21 10:14, Rigamonti Roberto ha scritto:

> Dear Tim,
>
>
> I've managed to do the tests you've suggested (sorry for the delay, but the emitter is remote (>300km) and I have to wait for someone to turn it on for me...).
>
> Using queue after udpsrc this is what I get: https://ibb.co/hBntcxg
>
> Increasing the debug level, I get:
>
> https://ibb.co/s5kcfFj
> https://ibb.co/2F5KvD3
> When using an rtpjitterbuffer, things seem to improve a bit (in the sense that at least gstreamer does not halt), but I'm still unable to get any image :(
> https://ibb.co/MPqF2kN
> https://ibb.co/18s8NMq
> https://ibb.co/0nG2n5W
> Do you have any further test I could try?
> Thanks a lot in advance and have a nice day!
> Rob
>
> ________________________________
> De : gstreamer-devel <[hidden email]> de la part de Tim Müller <[hidden email]>
> Envoyé : vendredi, 8 janvier 2021 13:42:39
> À : Discussion of the development of and with GStreamer
> Objet : Re: autovideosink does not work in native Windows machine for RTP stream but works in VM
>
> On Fri, 2021-01-08 at 10:43 +0000, Rigamonti Roberto wrote:
>
> Hi,
>
>> even Gstreamer works perfectly when saving
>> the stream to file with the command:
>>
>> gst-launch-1.0 -e udpsrc port=5000 ! "application/x-rtp, encoding-
>> name=H265, payload=96" ! rtph265depay ! h265parse ! mp4mux ! filesink
>> location=DST_FILENAME.mp4
>>
>> instead of showing it on the screen.
> What do you mean by "works perfectly" here? That it doesn't complain or
> error out, or that the resulting mp4 file plays just fine afterwards?
>
> It appears there's a problem with packet loss or reordered packets
> here. Maybe nvh265dec has a start-up delay that blocks the udpsrc for a
> bit too long (that's just speculation).
>
> Have you tried putting a queue after udpsrc, like
>
>   udpsrc ! queue max-size-time=0 max-size-buffers=0 max-size-bytes=0
>
> or even better an rtpjitterbuffer like
>
>   udpsrc ! rtpjitterbuffer latency=100 ! ..
>
> 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

[Rigamonti Roberto]

Dear Nicola,


We've just done the test and you're right, that solved the issue! :)

Thanks a lot for your help!!


Rob

________________________________
De : gstreamer-devel <[hidden email]> de la part de Mailing List SVR <[hidden email]>
Envoyé : mardi, 12 janvier 2021 11:13:34
À : [hidden email]
Objet : Re: autovideosink does not work in native Windows machine for RTP stream but works in VM

Hi,

this seems an issue with the hw decoder, please try something like this:

..... ! h265parse ! avdec_h265 ! autovideosink

or specify manually the video sink too.

This will use more CPU since it will use a sw decoder,

regards
Nicola


Il 12/01/21 10:14, Rigamonti Roberto ha scritto:

> Dear Tim,
>
>
> I've managed to do the tests you've suggested (sorry for the delay, but the emitter is remote (>300km) and I have to wait for someone to turn it on for me...).
>
> Using queue after udpsrc this is what I get: https://ibb.co/hBntcxg
>
> Increasing the debug level, I get:
>
> https://ibb.co/s5kcfFj
> https://ibb.co/2F5KvD3
> When using an rtpjitterbuffer, things seem to improve a bit (in the sense that at least gstreamer does not halt), but I'm still unable to get any image :(
> https://ibb.co/MPqF2kN
> https://ibb.co/18s8NMq
> https://ibb.co/0nG2n5W
> Do you have any further test I could try?
> Thanks a lot in advance and have a nice day!
> Rob
>
> ________________________________
> De : gstreamer-devel <[hidden email]> de la part de Tim Müller <[hidden email]>
> Envoyé : vendredi, 8 janvier 2021 13:42:39
> À : Discussion of the development of and with GStreamer
> Objet : Re: autovideosink does not work in native Windows machine for RTP stream but works in VM
>
> On Fri, 2021-01-08 at 10:43 +0000, Rigamonti Roberto wrote:
>
> Hi,
>
>> even Gstreamer works perfectly when saving
>> the stream to file with the command:
>>
>> gst-launch-1.0 -e udpsrc port=5000 ! "application/x-rtp, encoding-
>> name=H265, payload=96" ! rtph265depay ! h265parse ! mp4mux ! filesink
>> location=DST_FILENAME.mp4
>>
>> instead of showing it on the screen.
> What do you mean by "works perfectly" here? That it doesn't complain or
> error out, or that the resulting mp4 file plays just fine afterwards?
>
> It appears there's a problem with packet loss or reordered packets
> here. Maybe nvh265dec has a start-up delay that blocks the udpsrc for a
> bit too long (that's just speculation).
>
> Have you tried putting a queue after udpsrc, like
>
>   udpsrc ! queue max-size-time=0 max-size-buffers=0 max-size-bytes=0
>
> or even better an rtpjitterbuffer like
>
>   udpsrc ! rtpjitterbuffer latency=100 ! ..
>
> 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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 19/01/21 08:46, Rigamonti Roberto ha scritto:
> Dear Nicola,
>
>
> We've just done the test and you're right, that solved the issue! :)

Hi,

I guess this commit could help

https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=46c577222d4577f65914370007052fe22ea080a4

Nicola

>
> Thanks a lot for your help!!
>
>
> Rob
>
> ________________________________
> De : gstreamer-devel <[hidden email]> de la part de Mailing List SVR <[hidden email]>
> Envoyé : mardi, 12 janvier 2021 11:13:34
> À : [hidden email]
> Objet : Re: autovideosink does not work in native Windows machine for RTP stream but works in VM
>
> Hi,
>
> this seems an issue with the hw decoder, please try something like this:
>
> ..... ! h265parse ! avdec_h265 ! autovideosink
>
> or specify manually the video sink too.
>
> This will use more CPU since it will use a sw decoder,
>
> regards
> Nicola
>
>
> Il 12/01/21 10:14, Rigamonti Roberto ha scritto:
>> Dear Tim,
>>
>>
>> I've managed to do the tests you've suggested (sorry for the delay, but the emitter is remote (>300km) and I have to wait for someone to turn it on for me...).
>>
>> Using queue after udpsrc this is what I get: https://ibb.co/hBntcxg
>>
>> Increasing the debug level, I get:
>>
>> https://ibb.co/s5kcfFj
>> https://ibb.co/2F5KvD3
>> When using an rtpjitterbuffer, things seem to improve a bit (in the sense that at least gstreamer does not halt), but I'm still unable to get any image :(
>> https://ibb.co/MPqF2kN
>> https://ibb.co/18s8NMq
>> https://ibb.co/0nG2n5W
>> Do you have any further test I could try?
>> Thanks a lot in advance and have a nice day!
>> Rob
>>
>> ________________________________
>> De : gstreamer-devel <[hidden email]> de la part de Tim Müller <[hidden email]>
>> Envoyé : vendredi, 8 janvier 2021 13:42:39
>> À : Discussion of the development of and with GStreamer
>> Objet : Re: autovideosink does not work in native Windows machine for RTP stream but works in VM
>>
>> On Fri, 2021-01-08 at 10:43 +0000, Rigamonti Roberto wrote:
>>
>> Hi,
>>
>>> even Gstreamer works perfectly when saving
>>> the stream to file with the command:
>>>
>>> gst-launch-1.0 -e udpsrc port=5000 ! "application/x-rtp, encoding-
>>> name=H265, payload=96" ! rtph265depay ! h265parse ! mp4mux ! filesink
>>> location=DST_FILENAME.mp4
>>>
>>> instead of showing it on the screen.
>> What do you mean by "works perfectly" here? That it doesn't complain or
>> error out, or that the resulting mp4 file plays just fine afterwards?
>>
>> It appears there's a problem with packet loss or reordered packets
>> here. Maybe nvh265dec has a start-up delay that blocks the udpsrc for a
>> bit too long (that's just speculation).
>>
>> Have you tried putting a queue after udpsrc, like
>>
>>    udpsrc ! queue max-size-time=0 max-size-buffers=0 max-size-bytes=0
>>
>> or even better an rtpjitterbuffer like
>>
>>    udpsrc ! rtpjitterbuffer latency=100 ! ..
>>
>> 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

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