Unable to get visual window when running gstreamer under Windows (work under Bash for Windows)

Ben Rush ben at ben-rush.net
Tue Apr 9 15:29:27 UTC 2019


For my own edification, can someone please tell me what the difference is,
under the hood, in terms of what finally worked for me and what didn't? I
finally pieced together enough examples to think maybe I needed to add a
"videoconvert" on the client side, right before autovideosink. So, what I
had originally:

.\gst-launch-1.0.exe -v udpsrc port=3000 caps="application/x-rtp" !
application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! decodebin !
autovideosink

Became

.\gst-launch-1.0.exe -v udpsrc port=3000 caps="application/x-rtp" !
application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! decodebin !
*videoconvert* ! autovideosink

In terms of the player expecting certain formats, etc. I can understand it,
and I can likewise imagine that videoconvert smartly identifies what to
convert frames to for the downstream component. However, as noted in an
earlier part of this thread, the following worked for me without any
issues:

.\gst-launch-1.0.exe videotestsrc is-live=true ! openh264enc ! rtph264pay !
rtph264depay ! decodebin ! autovideosink

 Note the absence of ANY videoconvert elements. What is it about sending
over UDP that somehow caused videoconvert to be necessary whereas it wasn't
necessary before? I'm doing all of the same things EXCEPT packetizing the
stream, which I assumed udpsrc and rtph264depay would handle the same.

Thanks.

On Mon, Apr 8, 2019 at 2:03 PM Ben Rush <ben at ben-rush.net> wrote:

> Yes, it works. I mentioned in the earlier part of the first email that I
> could run it with  \gst-launch-1.0.exe videotestsrc is-live=true !
> openh264enc ! rtph264pay ! rtph264depay ! decodebin ! autovideosink. So
> it's basically "looping back" to itself instead of broadcasting over the
> network. That works. The command you mentioned also works.
>
> I can play with logging for a while too, turn up debugging and see if I
> can notice anything which hints at a display problem.
>
> FWIW, I'm on Windows 10, Version 1809. NVIDIA GeForce RTX 2070.
>
> I'm fine digging into this further, but if there's anything else you think
> I should try, or anything I should pay special attention to when looking at
> the logs, please let me know. Thanks again for your help.
>
> On Mon, Apr 8, 2019 at 1:55 PM Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
>
>> Le lundi 08 avril 2019 à 13:29 -0500, Ben Rush a écrit :
>> > With respect to the x264enc: I was mistaken and was able to get it to
>> work under Windows. It must have been an earlier experiment which made me
>> believe it wasn't available. So, I apologize. I tried it, and the behavior
>> was the same: no window was shown.
>> >
>> > Regarding the firewall: turning it off completely also made no
>> difference _visually_. But it might have changed things under the hood;
>> what I mean by that is that I'm seeing more at the console now. Wireshark
>> shows UDP traffic is flowing on the loopback device. This is the kind of
>> output I'm seeing despite no visual window (note: when running under Bash
>> for Windows, I don't see this output). Note that this output displays in
>> bursts, with a period of maybe five seconds where nothing is shown.
>>
>> Can you check the display element works ? e.g. videotestsrc !
>> autovideosink
>>
>> For the burst issues, change you x264enc setting, with tune=zerolatency
>> as an example.
>>
>> >
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstH264Parse:h264parse0.GstPad:sink:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> > /GstPipeline:pipeline0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps =
>> video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> > /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps =
>> video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000568ebec4480,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000568ebec4480,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000568ebec4480,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstH264Parse:h264parse0.GstPad:sink:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000568ebec4480,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000568ebec4480,
>> level=(string)1.3, profile=(string)high-4:4:4
>> > /GstPipeline:pipeline0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps =
>> video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000568ebec4480,
>> level=(string)1.3, profile=(string)high-4:4:4
>> > /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps =
>> video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstH264Parse:h264parse0.GstPad:sink:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink:
>> caps = video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> > /GstPipeline:pipeline0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps =
>> video/x-h264, stream-format=(string)avc, alignment=(string)au,
>> codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d41804150000003001000000303c8f142996001000668ebec448440,
>> level=(string)1.3, profile=(string)high-4:4:4
>> >
>> > On Mon, Apr 8, 2019 at 12:33 PM Ben Rush <ben at ben-rush.net> wrote:
>> > > I will check my firewall, but also note that the bash for Windows
>> scripts that worked ran on the same computer as the Windows scripts that
>> did not.
>> > >
>> > > Different subsystems, but it was the same instance of Windows running
>> on the same computer and with the same networking stack.
>> > >
>> > > On Mon, Apr 8, 2019, 12:27 Nicolas Dufresne <nicolas at ndufresne.ca
>> wrote:
>> > > > Le lundi 08 avril 2019 à 11:49 -0500, Ben Rush a écrit :
>> > > > > I imagine a lot of the community here is using Linux, but I'm
>> bound by Windows because of my work. I mention this because I'm not sure
>> how much traction I'll get asking a Windows-specific question, but I'll
>> try.
>> > > > >
>> > > > > I'm trying to get some basic gst-launch-1.0 commands to work, but
>> thus far have been unable. Moving those same commands over to Bash for
>> Windows and launching them there, I'm able to get the play window to run
>> (I'm running Xming on my Windows machine as an X server). Note that some
>> commands do work and display the interface, so I think it's unlikely to be
>> a bad installation.
>> > > > >
>> > > > > First, this command works just fine when run under windows:
>> > > > >
>> > > > > .\gst-launch-1.0.exe videotestsrc is-live=true ! openh264enc !
>> rtph264pay ! rtph264depay ! decodebin ! autovideosink
>> > > > >
>> > > > > Upon executing it, I get the test video to show up in the video
>> window. But when I try to split this up as a server/client, it fails. First
>> I run the following command to spin up the client:
>> > > > >
>> > > > > .\gst-launch-1.0.exe -v udpsrc port=3000 caps="application/x-rtp"
>> ! application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! decodebin
>> ! autovideosink
>> > > > >
>> > > > > Once running, I then run this command to acts as the server and
>> start pushing UDP packets:
>> > > > >
>> > > > > .\gst-launch-1.0.exe videotestsrc is-live=true ! openh264enc !
>> h264parse ! rtph264pay pt=96 ! udpsink port=3000
>> > > >
>> > > > I've recently hit a IPv6 vs IPv4 issue when not specifying any
>> host/address on the udp elements. You should also check your firewall, udp
>> is often dropped by default.
>> > > >
>> > > > > Nothing crashes, and I don't get any errors, but also no window
>> opens up. I see nothing. However, if I spin up Bash for Windows (with
>> Xming) and run this in one window:
>> > > > >
>> > > > > gst-launch-1.0 -v udpsrc port=3000 caps="application/x-rtp" !
>> application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! decodebin !
>> autovideosink
>> > > > >
>> > > > > Followed by this in another window:
>> > > > >
>> > > > > gst-launch-1.0 videotestsrc is-live=true ! x264enc ! h264parse !
>> rtph264pay pt=96 ! udpsink port=3000
>> > > > >
>> > > > > The only difference is the x264enc instead of the openh264enc.
>> I'm not sure how to get the x264enc to exist under Windows (I cannot find
>> the plugin for Windows).
>> > > >
>> > > > I've check our CI builds and they are present, so it mean
>> libgstx264 should also be in the official builds:
>> > > >
>> > > > https://gstreamer.freedesktop.org/data/pkg/windows/1.14.4/
>> > > >
>> > > > > Any help or input would be appreciated. Thanks in advance.
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > 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
>> >
>> > _______________________________________________
>> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190409/dabd20f8/attachment-0001.html>


More information about the gstreamer-devel mailing list