GNOME Bugzilla – Bug 619718
gstrtpbin fail at big resolution
Last modified: 2011-04-12 13:40:49 UTC
Hi, i tried to send a video recorded in UXGA resolution (1600x1200), but i couldn't. My pipelines was the following: Server: gst-launch gstrtpbin name=rtpbin latency=3000 buffer-mode=0 udpsrc name="udp0001" caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay access-unit=true ! h264parse ! ffdec_h264 ! identity ! xvimagesink sync=true udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=127.0.0.1 sync=false async=false Client: gst-launch gstrtpbin name=rtpbin filesrc location="uxga.mkv" ! matroskademux ! h264parse access-unit=true ! queue ! rtph264pay config-interval=1 ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink port=5000 host=127.0.0.1 rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=127.0.0.1 sync=false async=false udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0 I received some packet lost, then a lot of "number of reference frames exceeds max" ffmpeg error. I made the same test with a file recorded in VGA resolution (with the same IP camera), and everything was fine... Maybe the gstrtpbin can't send out so much data? I uploaded the sample videos here: http://dev.edutop.hu/uxga.mkv http://dev.edutop.hu/vga.mkv Regards Tibor
client-server pipelines are replaced, of course :)
increasing the latency property has solved the problem.
Sorry but increasing the latency has solved the problem only with higher fps. With 1 or 2 fps it still fails, tons of packet lost and ffmpeg error messages (reference frames exceeds max) are coming. any ideas?
Hi, this topic is still active. Now i have a very weird workaround for this problem: i put an identity after the rtph264pay and connect a handoff listener that prints out the payloader's "seqnum" property for each calls. I guess there is a side-effect of that property-get call (or of the callback of the handoff itself) that solve the invalid sequence of the outgoing packets, but i can't found the source of this part in the gstreamer code. Maybe it's some synchronization bug... Can one of these side-effects be the solution? (It is, but why?) My application is now working with this workaround but i would be really happy if you can solve the problem inside the gstreamer :) Regards. Tibor
Is there any progress with this issue?
any news with this? it's still not working in the latest release...
I don't know, what's the problem?
(In reply to comment #7) > I don't know, what's the problem? I'm asking because buffer-mode=0 is not a good property to set when doing realtime playback. It causes QoS to kick in an frames to be dropped by the ffmpeg decoder etc.
I tried all kind of buffer-mode, but the result was the same, the picture crashed and a lots of packet lost and ffmpeg error showed up. It's working proper only with the identity-handoff-seqnumgetter-hack (identity is linked between the pay and the gstrtpbin). Btw what's mean "Slave receiver to sender clock"? It's a bit short for me :)
any news for this report?
it seems ok with the latest release (maybe the udp-buffer-size property solved the problem)
k. I'm marking as OBSOLETE.