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

Mailing List SVR lists at svrinformatica.it
Tue Jan 12 10:13:34 UTC 2021


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 <gstreamer-devel-bounces at lists.freedesktop.org> de la part de Tim Müller <tim at centricular.com>
> 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
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list