<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Olivier</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for your answer </div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> on behalf of gstreamer-devel-request@lists.freedesktop.org <gstreamer-devel-request@lists.freedesktop.org><br>
<b>Sent:</b> Saturday, December 18, 2021 8:29 AM<br>
<b>To:</b> gstreamer-devel@lists.freedesktop.org <gstreamer-devel@lists.freedesktop.org><br>
<b>Subject:</b> gstreamer-devel Digest, Vol 131, Issue 24</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Send gstreamer-devel mailing list submissions to<br>
        gstreamer-devel@lists.freedesktop.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
        gstreamer-devel-request@lists.freedesktop.org<br>
<br>
You can reach the person managing the list at<br>
        gstreamer-devel-owner@lists.freedesktop.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gstreamer-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Gstreamer: No RTP protocol present (Olivier Cr?te)<br>
   2. Re: Sunxi NV12 detiling (Nicolas Dufresne)<br>
   3. Re: explain please (vinod kesti)<br>
   4. Re:  Re: Gstreamer: No RTP protocol present (Howling wong)<br>
      (Howling wong)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 17 Dec 2021 10:31:01 -0500<br>
From: Olivier Cr?te <olivier.crete@collabora.com><br>
To: Discussion of the development of and with GStreamer<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Cc: Robert Hensel <vk3eht@gmail.com><br>
Subject: Re: Gstreamer: No RTP protocol present<br>
Message-ID:<br>
        <6fa2bee3a60986a540955de8c83460bb117cf70b.camel@collabora.com><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Hi,<br>
<br>
The payloader requires that you tell it which payload type is assigned<br>
to H.264<br>
<br>
So you'd want something like this:<br>
<br>
gst-launch-1.0 udpsrc port=5555 ! application/x-rtp, encoding-name=H264, payload=96 ! queue ! rtph264depay  ! decodebin  ! autovideosink<br>
<br>
Olivier<br>
<br>
On Fri, 2021-12-17 at 14:21 +1100, Robert Hensel via gstreamer-devel<br>
wrote:<br>
> width=6400?<br>
> Suggest try with width=640<br>
> <br>
> Rob<br>
> <br>
> On Fri, 17 Dec 2021 at 13:55, Howling wong via gstreamer-devel<br>
> <gstreamer-devel@lists.freedesktop.org> wrote:<br>
> > I am having some issues with the following gstreamer command<br>
> > Sender (on embeeded system)<br>
> > gst-launch-1.0 videotestsrc ! video/x-raw, width=6400, height=480 !<br>
> > queue ! vpuenc_h264 ! rtph264pay ! udpsink host=192.168.60.5<br>
> > port=5555<br>
> > <br>
> > Receiver(on windows)<br>
> > gst-launch-1.0 udpsrc port=5555 ! queue ! rtph264depay  ! decodebin<br>
> > ! autovideosink<br>
> > <br>
> > But I have got the following response<br>
> > <br>
> > ? ?Setting pipeline to PAUSED ...<br>
> > ? ? Pipeline is live and does not need PREROLL ...<br>
> > ? ? Got context from element 'autovideosink0':<br>
> > gst.d3d11.device.handle=context,<br>
> > device=(GstD3D11Device)"\(GstD3D11Device\)\ d3d11device4",<br>
> > adapter=(uint)0, device-id=(uint)6429, vendor-id=(uint)32902,<br>
> > hardware=(boolean)true, description=(string)"Intel\(R\)\ HD\<br>
> > Graphics\ P530";<br>
> > ? ? Pipeline is PREROLLED ...<br>
> > ? ? Setting pipeline to PLAYING ...<br>
> > ? ? New clock: GstSystemClock<br>
> > ? ? ?ERROR: from element<br>
> > /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: No RTP format<br>
> > was negotiated.<br>
> > ? ? Additional debug info:<br>
> > ? ? ? ../gst-libs/gst/rtp/gstrtpbasedepayload.c(538):<br>
> > gst_rtp_base_depayload_handle_buffer ():<br>
> > /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0:<br>
> > ? ? ?Input buffers need to have RTP caps set on them. This is<br>
> > usually achieved by setting the 'caps' property of the upstream<br>
> > source element (often udpsrc or appsrc), or by putting a capsfilter<br>
> > element before the depayloader and setting the 'caps' property on<br>
> > that. Also seehttp://cgit.freedesktop.org/gstreamer/gst-plugins-<br>
> > good/tree/gst/rtp/README<br>
> > ? ? ?Execution ended after 0:00:00.019641000<br>
> > ? ? Setting pipeline to NULL ...<br>
> > ? ? ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:<br>
> > Internal data stream error.<br>
> > ? ? Additional debug info:<br>
> > ? ? ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop ():<br>
> > /GstPipeline:pipeline0/GstUDPSrc:udpsrc0<br>
> > ? ? streaming stopped, reason not-negotiated (-4)<br>
> > ? ? Freeing pipeline ..<br>
> > <br>
> > The complaint seem to be about the incoming stream is not in rtp<br>
> > format and the rtpdepayh264 should not be placed in the pipeline.<br>
> > This assumption is proven to be correct when i replaced the whole<br>
> > pipeline with a fakesink<br>
> > <br>
> > Receiver<br>
> > gst-launch-1.0 udpsrc port=5555 ! queue ! fakesink<br>
> > <br>
> > The pipeline work. However when i observed the packets exchange in<br>
> > wireshark, it show the communication exchange but the protocol is<br>
> > in udp. Though I know that RTP could be based upon UDP protocol but<br>
> > have thought that Wireshark is entirely capable of showing protocol<br>
> > in RTP format<br>
> > <br>
> > I have thought that the sender has already wrapped the video in rtp<br>
> > format before sending the package out. Like to have some ideas on<br>
> > what is wrong here and how to proceed<br>
> > Regards<br>
> > <br>
<br>
-- <br>
Olivier Cr?te<br>
olivier.crete@collabora.com<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 17 Dec 2021 10:58:25 -0500<br>
From: Nicolas Dufresne <nicolas.dufresne@collabora.com><br>
To: Discussion of the development of and with GStreamer<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>, Devrim<br>
        GECEGEZER <devrim.gecegezer@genemek.com><br>
Subject: Re: Sunxi NV12 detiling<br>
Message-ID:<br>
        <4f0e669e36f7fb73a4322ef020a580c2e198d4aa.camel@collabora.com><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Le vendredi 17 d?cembre 2021 ? 13:31 +0100, Giulio Benetti via gstreamer-devel a<br>
?crit?:<br>
> Hello Nicolas, All,<br>
> <br>
> I'm dealing with Cedrus on Linux 5.15.7 with Gstreamer 1.19.3.1-git(the <br>
> latest main branch) and I've got to the point that on A13 and A20 I have <br>
<br>
A bit unrelated I suppose, but I have been blocked on the subject since the<br>
decoder only produces green frames for me (I have a Lime2 A20 to test this). If<br>
you could share your kernel branch, and the board DT that works, I could<br>
possibly try and find the difference and unblock this work on my side.<br>
<br>
> to detile the output of Sunxi video-engine, since now it's done in <br>
> software and this causes:<br>
> ```<br>
> videodecoder <br>
> gstvideodecoder.c:3670:gst_video_decoder_clip_and_push_buf:<v4l2slh264dec0> <br>
> Dropping frame due to QoS.<br>
> ```<br>
> using kmssink. And I get an entire frame every 5 seconds.<br>
<br>
Of course all to be expected, the CPUs are not very fast, it is single threaded<br>
by default (see video convert n-threads property), AND this is non-cached CMA<br>
memory, so that is bare metal IOs, very very slow.<br>
<br>
> <br>
> I've found this [1] IRC discussion where you state that kmssink support <br>
> is missing for GST_VIDEO_FORMAT_NV12_32L32. Basically what I understand <br>
> is that we need a special treatment for A13 and A20, since from >= A33 <br>
> we have the support for the untiled output(still not tried, but I have <br>
> to do it with A64).<br>
> <br>
> Where can I begin from to implement the kmssink support for detiling? <br>
> There is something I can imitate?<br>
> Can you or someone else point me more or less where to start working?<br>
<br>
This is all correct, I have a super old patch here that I started for Exynos 4<br>
DRM, but never finished it. I supposed there is likely a helper now for<br>
DrmModeAddFb2 (with modifiers, unless that helpers only exist for the atomic<br>
API, something on my todo). This should be good hint how to translate these<br>
formats to DRM+Modifiers.<br>
<br>
<a href="https://gitlab.freedesktop.org/ndufresne/gst-plugins-bad/-/commit/ac14733163d770499d834bce12863fe6c4b1570c">https://gitlab.freedesktop.org/ndufresne/gst-plugins-bad/-/commit/ac14733163d770499d834bce12863fe6c4b1570c</a><br>
<br>
> <br>
> [1]: <br>
> <a href="https://oftc.irclog.whitequark.org/linux-sunxi/2021-07-13#1626188848-1626188913">
https://oftc.irclog.whitequark.org/linux-sunxi/2021-07-13#1626188848-1626188913</a>;<br>
> <br>
> Thanks in advance<br>
> Best regards<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 17 Dec 2021 16:10:30 +0000 (UTC)<br>
From: vinod kesti <vinodkesti@yahoo.com><br>
To: Discussion of the development of and with GStreamer<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Cc: James <jam@tigger.ws><br>
Subject: Re: explain please<br>
Message-ID: <2103047805.2245484.1639757430572@mail.yahoo.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi?James,<br>
Frame was expected to arrive @?0:02:11.042561535but it arrived on??0:02:11.050640555. Frame arrived late so sink is dropping the frame.<br>
Have you enabled QOS. If you dont want QOS then set QOS property to false on every sink of the pipeline<br>
<br>
<br>
Sent from Yahoo Mail. Get the app <br>
<br>
    On Friday, 17 December, 2021, 09:21:46 am GMT-6, James via gstreamer-devel <gstreamer-devel@lists.freedesktop.org> wrote: 
<br>
 <br>
 Can anybody explain:<br>
<br>
4-0> Dropping frame due to QoS. start:0:02:11.042561535 deadline:0:02:11.042561535 earliest_time:0:02:11.050640555<br>
<br>
James  <br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/6c86ee76/attachment-0001.htm">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/6c86ee76/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sat, 18 Dec 2021 00:29:06 +0000<br>
From: Howling wong <watertreader@hotmail.com><br>
To: "gstreamer-devel@lists.freedesktop.org"<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Subject: Re:  Re: Gstreamer: No RTP protocol present (Howling wong)<br>
Message-ID:<br>
        <SI2PR04MB51823B945A278BC53B5CBE77CB799@SI2PR04MB5182.apcprd04.prod.outlook.com><br>
        <br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi<br>
<br>
I believe that I have figured out where the mistake lies in... is because I failed to fill in the filtercaps for the video in the reciever portion of the pipeline. Would just need to fill in caps=application/x-rtp to do the magic<br>
<br>
Reciever<br>
<br>
         gst-launch-1.0 udpsrc port=5555 caps=application/x-rtp ! rtph264depay ! decodebin  ! autovideosink<br>
<br>
Regards<br>
________________________________<br>
From: gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> on behalf of gstreamer-devel-request@lists.freedesktop.org <gstreamer-devel-request@lists.freedesktop.org><br>
Sent: Friday, December 17, 2021 11:30 PM<br>
To: gstreamer-devel@lists.freedesktop.org <gstreamer-devel@lists.freedesktop.org><br>
Subject: gstreamer-devel Digest, Vol 131, Issue 23<br>
<br>
Send gstreamer-devel mailing list submissions to<br>
        gstreamer-devel@lists.freedesktop.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
        gstreamer-devel-request@lists.freedesktop.org<br>
<br>
You can reach the person managing the list at<br>
        gstreamer-devel-owner@lists.freedesktop.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gstreamer-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Sunxi NV12 detiling (Giulio Benetti)<br>
   2. Re: Gstreamer: No RTP protocol present (Howling wong)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 17 Dec 2021 13:31:05 +0100<br>
From: Giulio Benetti <giulio.benetti@benettiengineering.com><br>
To: gstreamer-devel@lists.freedesktop.org, Nicolas Dufresne<br>
        <nicolas.dufresne@collabora.com><br>
Cc: Devrim GECEGEZER <devrim.gecegezer@genemek.com><br>
Subject: Sunxi NV12 detiling<br>
Message-ID:<br>
        <0362eb7a-7158-c502-eaf6-c61c5c48bcf2@benettiengineering.com><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hello Nicolas, All,<br>
<br>
I'm dealing with Cedrus on Linux 5.15.7 with Gstreamer 1.19.3.1-git(the<br>
latest main branch) and I've got to the point that on A13 and A20 I have<br>
to detile the output of Sunxi video-engine, since now it's done in<br>
software and this causes:<br>
```<br>
videodecoder<br>
gstvideodecoder.c:3670:gst_video_decoder_clip_and_push_buf:<v4l2slh264dec0><br>
Dropping frame due to QoS.<br>
```<br>
using kmssink. And I get an entire frame every 5 seconds.<br>
<br>
I've found this [1] IRC discussion where you state that kmssink support<br>
is missing for GST_VIDEO_FORMAT_NV12_32L32. Basically what I understand<br>
is that we need a special treatment for A13 and A20, since from >= A33<br>
we have the support for the untiled output(still not tried, but I have<br>
to do it with A64).<br>
<br>
Where can I begin from to implement the kmssink support for detiling?<br>
There is something I can imitate?<br>
Can you or someone else point me more or less where to start working?<br>
<br>
[1]:<br>
<a href="https://oftc.irclog.whitequark.org/linux-sunxi/2021-07-13#1626188848-1626188913">https://oftc.irclog.whitequark.org/linux-sunxi/2021-07-13#1626188848-1626188913</a>;<br>
<br>
Thanks in advance<br>
Best regards<br>
--<br>
Giulio Benetti<br>
Benetti Engineering sas<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 17 Dec 2021 15:30:30 +0000<br>
From: Howling wong <watertreader@hotmail.com><br>
To: "gstreamer-devel@lists.freedesktop.org"<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Subject: Re: Gstreamer: No RTP protocol present<br>
Message-ID:<br>
        <SI2PR04MB51826EC9B35083EBD1DA334BCB789@SI2PR04MB5182.apcprd04.prod.outlook.com><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Sorry, I hope I got it right this time<br>
<br>
My message being: My mistake in copying the errorneous pipeline, the sender pipeline should read instead<br>
<br>
   "gst-launch-1.0 videotestsrc ! video/x-raw, width=640, height=480 ! queue ! vpuenc_h264 ! rtph264pay ! udpsink host=192.168.60.5 port=5555"<br>
<br>
Is there a possibility of corrupt gstreamer installation or hardware?<br>
<br>
Additional Information:<br>
<br>
  1.  Sender (Embedded system on Arm on Archlinux  with Gstreamer 1.14)<br>
  2.  Reciever (Windows x86-64 running on Windows 10 running Gstreamer 1.18)<br>
<br>
Would different version of Gstreamer affect the system<br>
<br>
Regards<br>
<br>
________________________________<br>
From: gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> on behalf of gstreamer-devel-request@lists.freedesktop.org <gstreamer-devel-request@lists.freedesktop.org><br>
Sent: Friday, December 17, 2021 7:44 PM<br>
To: gstreamer-devel@lists.freedesktop.org <gstreamer-devel@lists.freedesktop.org><br>
Subject: gstreamer-devel Digest, Vol 131, Issue 22<br>
<br>
Send gstreamer-devel mailing list submissions to<br>
        gstreamer-devel@lists.freedesktop.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
        gstreamer-devel-request@lists.freedesktop.org<br>
<br>
You can reach the person managing the list at<br>
        gstreamer-devel-owner@lists.freedesktop.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gstreamer-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: gstreamer-devel Digest, Vol 131, Issue 21 (Howling wong)<br>
   2. explain please (James)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 17 Dec 2021 09:48:28 +0000<br>
From: Howling wong <watertreader@hotmail.com><br>
To: "gstreamer-devel@lists.freedesktop.org"<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Subject: Re: gstreamer-devel Digest, Vol 131, Issue 21<br>
Message-ID:<br>
        <SI2PR04MB5182F19A20728593C75DA256CB789@SI2PR04MB5182.apcprd04.prod.outlook.com><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi it is my mistake ... it should be width=640 instead of width=6400 in writing the post... the pipeline do not work with width=640<br>
<br>
________________________________<br>
From: gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> on behalf of gstreamer-devel-request@lists.freedesktop.org <gstreamer-devel-request@lists.freedesktop.org><br>
Sent: Friday, December 17, 2021 11:22 AM<br>
To: gstreamer-devel@lists.freedesktop.org <gstreamer-devel@lists.freedesktop.org><br>
Subject: gstreamer-devel Digest, Vol 131, Issue 21<br>
<br>
Send gstreamer-devel mailing list submissions to<br>
        gstreamer-devel@lists.freedesktop.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
        gstreamer-devel-request@lists.freedesktop.org<br>
<br>
You can reach the person managing the list at<br>
        gstreamer-devel-owner@lists.freedesktop.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gstreamer-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Gstreamer: No RTP protocol present (Howling wong)<br>
   2. Re: Gstreamer: No RTP protocol present (Robert Hensel)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 17 Dec 2021 02:55:33 +0000<br>
From: Howling wong <watertreader@hotmail.com><br>
To: "gstreamer-devel@lists.freedesktop.org"<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Subject: Gstreamer: No RTP protocol present<br>
Message-ID:<br>
        <SI2PR04MB5182E8B2DF3B9669E94C5BC1CB789@SI2PR04MB5182.apcprd04.prod.outlook.com><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
I am having some issues with the following gstreamer command<br>
<br>
Sender (on embeeded system)<br>
<br>
gst-launch-1.0 videotestsrc ! video/x-raw, width=6400, height=480 ! queue ! vpuenc_h264 ! rtph264pay ! udpsink host=192.168.60.5 port=5555<br>
<br>
<br>
Receiver(on windows)<br>
<br>
gst-launch-1.0 udpsrc port=5555 ! queue ! rtph264depay  ! decodebin  ! autovideosink<br>
<br>
<br>
But I have got the following response<br>
<br>
<br>
   Setting pipeline to PAUSED ...<br>
<br>
    Pipeline is live and does not need PREROLL ...<br>
<br>
    Got context from element 'autovideosink0': gst.d3d11.device.handle=context, device=(GstD3D11Device)"\(GstD3D11Device\)\ d3d11device4", adapter=(uint)0, device-id=(uint)6429, vendor-id=(uint)32902, hardware=(boolean)true, description=(string)"Intel\(R\)\
 HD\ Graphics\ P530";<br>
<br>
    Pipeline is PREROLLED ...<br>
<br>
    Setting pipeline to PLAYING ...<br>
<br>
    New clock: GstSystemClock<br>
<br>
     ERROR: from element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: No RTP format was negotiated.<br>
<br>
    Additional debug info:<br>
<br>
      ../gst-libs/gst/rtp/gstrtpbasedepayload.c(538): gst_rtp_base_depayload_handle_buffer (): /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0:<br>
<br>
     Input buffers need to have RTP caps set on them. This is usually achieved by setting the 'caps' property of the upstream source element (often udpsrc or appsrc), or by putting a capsfilter element before the depayloader and setting the 'caps' property
 on that. Also see <a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtp/README">
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtp/README</a><br>
<br>
     Execution ended after 0:00:00.019641000<br>
    Setting pipeline to NULL ...<br>
    ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data stream error.<br>
    Additional debug info:<br>
    ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0<br>
    streaming stopped, reason not-negotiated (-4)<br>
    Freeing pipeline ..<br>
<br>
<br>
The complaint seem to be about the incoming stream is not in rtp format and the rtpdepayh264 should not be placed in the pipeline. This assumption is proven to be correct when i replaced the whole pipeline with a fakesink<br>
<br>
<br>
Receiver<br>
<br>
gst-launch-1.0 udpsrc port=5555 ! queue ! fakesink<br>
<br>
<br>
The pipeline work. However when i observed the packets exchange in wireshark, it show the communication exchange but the protocol is in udp. Though I know that RTP could be based upon UDP protocol but have thought that Wireshark is entirely capable of showing
 protocol in RTP format<br>
<br>
<br>
I have thought that the sender has already wrapped the video in rtp format before sending the package out. Like to have some ideas on what is wrong here and how to proceed<br>
<br>
Regards<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/4681e121/attachment-0001.htm">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/4681e121/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 17 Dec 2021 14:21:49 +1100<br>
From: Robert Hensel <vk3eht@gmail.com><br>
To: Discussion of the development of and with GStreamer<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Subject: Re: Gstreamer: No RTP protocol present<br>
Message-ID:<br>
        <CAGRXgDxxb4BrjW+yT9fdudoYdiQjs0JCxpLAJQx6_sMjXHoOMQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
width=6400?<br>
Suggest try with width=640<br>
<br>
Rob<br>
<br>
On Fri, 17 Dec 2021 at 13:55, Howling wong via gstreamer-devel <<br>
gstreamer-devel@lists.freedesktop.org> wrote:<br>
<br>
> I am having some issues with the following gstreamer command<br>
><br>
> Sender (on embeeded system)<br>
><br>
> gst-launch-1.0 videotestsrc ! video/x-raw, width=6400, height=480 ! queue ! vpuenc_h264 ! rtph264pay ! udpsink host=192.168.60.5 port=5555<br>
><br>
> Receiver(on windows)<br>
><br>
> gst-launch-1.0 udpsrc port=5555 ! queue ! rtph264depay  ! decodebin  ! autovideosink<br>
><br>
> But I have got the following response<br>
><br>
><br>
>    Setting pipeline to PAUSED ...<br>
><br>
>     Pipeline is live and does not need PREROLL ...<br>
><br>
>     Got context from element 'autovideosink0':<br>
> gst.d3d11.device.handle=context,<br>
> device=(GstD3D11Device)"\(GstD3D11Device\)\ d3d11device4", adapter=(uint)0,<br>
> device-id=(uint)6429, vendor-id=(uint)32902, hardware=(boolean)true,<br>
> description=(string)"Intel\(R\)\ HD\ Graphics\ P530";<br>
><br>
>     Pipeline is PREROLLED ...<br>
><br>
>     Setting pipeline to PLAYING ...<br>
><br>
>     New clock: GstSystemClock<br>
><br>
>      ERROR: from element<br>
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: No RTP format was<br>
> negotiated.<br>
><br>
>     Additional debug info:<br>
><br>
>       ../gst-libs/gst/rtp/gstrtpbasedepayload.c(538):<br>
> gst_rtp_base_depayload_handle_buffer ():<br>
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0:<br>
><br>
>      Input buffers need to have RTP caps set on them. This is usually<br>
> achieved by setting the 'caps' property of the upstream source element<br>
> (often udpsrc or appsrc), or by putting a capsfilter element before the<br>
> depayloader and setting the 'caps' property on that. Also see<br>
> <a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtp/README">
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtp/README</a><br>
>      Execution ended after 0:00:00.019641000<br>
>     Setting pipeline to NULL ...<br>
>     ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal<br>
> data stream error.<br>
>     Additional debug info:<br>
>     ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop ():<br>
> /GstPipeline:pipeline0/GstUDPSrc:udpsrc0<br>
>     streaming stopped, reason not-negotiated (-4)<br>
>     Freeing pipeline ..<br>
><br>
><br>
> The complaint seem to be about the incoming stream is not in rtp format<br>
> and the rtpdepayh264 should not be placed in the pipeline. This assumption<br>
> is proven to be correct when i replaced the whole pipeline with a fakesink<br>
><br>
><br>
> Receiver<br>
><br>
> gst-launch-1.0 udpsrc port=5555 ! queue ! fakesink<br>
><br>
> The pipeline work. However when i observed the packets exchange in<br>
> wireshark, it show the communication exchange but the protocol is in udp.<br>
> Though I know that RTP could be based upon UDP protocol but have thought<br>
> that Wireshark is entirely capable of showing protocol in RTP format<br>
><br>
><br>
> I have thought that the sender has already wrapped the video in rtp format<br>
> before sending the package out. Like to have some ideas on what is wrong<br>
> here and how to proceed<br>
><br>
> Regards<br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/fa1c5430/attachment.htm">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/fa1c5430/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
gstreamer-devel@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of gstreamer-devel Digest, Vol 131, Issue 21<br>
************************************************<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/82502d7e/attachment-0001.htm">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/82502d7e/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 17 Dec 2021 19:20:20 +0800<br>
From: James <jam@tigger.ws><br>
To: Discussion of the development of and with GStreamer<br>
        <gstreamer-devel@lists.freedesktop.org><br>
Subject: explain please<br>
Message-ID: <9EEBD5CC-E6E7-4E7D-A1F0-7F69CAD77D83@tigger.ws><br>
Content-Type: text/plain;       charset=us-ascii<br>
<br>
Can anybody explain:<br>
<br>
4-0> Dropping frame due to QoS. start:0:02:11.042561535 deadline:0:02:11.042561535 earliest_time:0:02:11.050640555<br>
<br>
James<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
gstreamer-devel@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of gstreamer-devel Digest, Vol 131, Issue 22<br>
************************************************<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/1e03d349/attachment.htm">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211217/1e03d349/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
gstreamer-devel@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of gstreamer-devel Digest, Vol 131, Issue 23<br>
************************************************<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211218/18625000/attachment.htm">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211218/18625000/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
gstreamer-devel@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of gstreamer-devel Digest, Vol 131, Issue 24<br>
************************************************<br>
</div>
</span></font></div>
</div>
</body>
</html>