RTP H264 stream corrupted

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RTP H264 stream corrupted

omer.tal
This post was updated on .
Hey,

I'm trying to send an RTP stream of my screen (ximagesrc).

I'm streaming this RTP over WiFi. The receiver's side cannot decode it
successfully (many bad frames).
When I'm using x264enc tune=zerolatency, I can see video on the other side, but the quality is really bad.

I don't care about latency, but I want high quality. Can you please share a
pipeline with me?

This is the pipeline I'm using:
"ximagesrc show-pointer=false is-live=true ! video/x-raw,fraterate=30/1 ! "
                          "videoconvert ! x264enc key-int-max=30 bitrate=4000000 ! "
                          "rtph264pay mtu=1400 ! udpsink host=%s port=%d sync=false"


Some follow-up questions:
1. Does rtpjitterbuffer can help here?
2. How can rtpjitterbuffer handle re-transmission. How can the udpsrc
request a re-transmission from the udpsink on the sender's end?
3. rtpjitterbuffer requires caps with clockrate. How can I know my
clockrate?

Thank you...


Here is the error I get on the console:
0:00:10.277839507 14573 0x55a7c36fac50 WARN            videodecoder gstvideodecoder.c:2780:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.000626456 < 0:00:10.030701579)
0:00:20.907746382 14573 0x55a7c36fac50 ERROR                  libav :0:: co located POCs unavailable
0:00:20.954950436 14573 0x55a7c36fac50 ERROR                  libav :0:: mmco: unref short failure
0:00:21.071706906 14573 0x55a7c36fac50 WARN            videodecoder gstvideodecoder.c:2780:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:20.712440177 < 0:00:20.844571215)
0:00:22.780537642 14573 0x55a7c36fac50 ERROR                  libav :0:: co located POCs unavailable
0:00:22.795402636 14573 0x55a7c36fac50 ERROR                  libav :0:: mmco: unref short failure
0:00:22.815169435 14573 0x55a7c36fac50 ERROR                  libav :0:: co located POCs unavailable
0:00:22.984233962 14573 0x55a7c36fac50 WARN            videodecoder gstvideodecoder.c:2780:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:22.603851655 < 0:00:22.737208368)
0:00:23.195948140 14573 0x55a7c36fac50 ERROR                  libav :0:: co located POCs unavailable
0:00:23.220652890 14573 0x55a7c36fac50 ERROR                  libav :0:: mmco: unref short failure
0:00:23.241637377 14573 0x55a7c36fac50 ERROR                  libav :0:: co located POCs unavailable
0:00:23.402052932 14573 0x55a7c36fac50 WARN            videodecoder gstvideodecoder.c:2780:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:23.014351081 < 0:00:23.163673092)

--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: RTP H264 stream corrupted

Olivier Crête-3
Hi,

On Thu, 2020-12-10 at 04:37 -0600, omer.tal wrote:
Hey,

I'm trying to send an RTP stream of my screen (ximagesrc).

I'm streaming this RTP over WiFi. The receiver's side cannot decode it
successfully (many bad frames).

I don't care about latency, but I want high quality. Can you please share a
pipeline with me?


Some follow-up questions:
1. Does rtpjitterbuffer can help here?

Yes, but you should generally using rtpbin which includes the rtpjitterbuffer

2. How can rtpjitterbuffer handle re-transmission. How can the udpsrc
request a re-transmission from the udpsink on the sender's end?

If you want to have retransmissions, in addition to rtpbin on both sender and receiver (to handle the RTCP, you want to add the rtprtxsend on the sender side and rtprtxreceive on the receiver side. 

If you control both sides, you may want to look into using gst-rtsp-server + rtspsrc which does all of those things for you.

3. rtpjitterbuffer requires caps with clockrate. How can I know my
clockrate?

For video, the clock rate is always 90000

Olivier


Thank you...



--
_______________________________________________
gstreamer-devel mailing list

-- 
Olivier Crête


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: RTP H264 stream corrupted

omer.tal
This post was updated on .
Wow

Thank you, Olivier for the detailed response.
I actually know about rtsp server but for this specific application I'm
forced to use rtp.

Thanks again.
Omer



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: RTP H264 stream corrupted

TheGiamig
In reply to this post by omer.tal
Hi, I solved many corrupted frames problems with RTP streaming changing the
buffer-size property of udpsink / udpsrc elements.
I setted it to 150000, just as reference.
Good luck.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel