Hi, there is already a gstrtpjitterbuffer inside rtspsrc, so no need for a second one. You can run your gst-launch with GST_DEBUG=3 or 4 or 5 to track the received buffers. Are you sure RTP is sent correctly ? received correctly ? packets are lost in your network ? network card fails ... Check sent packet with wireshark on sending host 10.38.164.205. Check received packet with wireshark on receiving host. wireshark will decode RTP, you will be able to see wether there are packet drops in your network or not. Initial file (water_mpeg4.mp4) contains only video ? How do you find out that a quarter of the stream is received ? Could remaining 3/4 be audio ? You can use "rtpmp4vdepay ! mpeg4videoparse ! ffmux_mov ! filesink" to get a viewable file and see if those dropped buffers are really dropped. Aurelien ----- Message d'origine ---- De : Ting Wang <[hidden email]> À : [hidden email] Envoyé le : Mardi, 12 Août 2008, 11h17mn 54s Objet : [gst-devel] How can I get detailed information about those packets dropped by rtspsrc ? Hi, I'm using Gstreamer to setup a streaming video client using rtspsrc. Thanks to the help from Aurelien, I successfully setup the pipeline and it's rolling good. Now I find that with the packet drop is quite frequent even in locale area network. I have been tried to configure the parameter "latency" on rtspsrc/gstrtpjitterbuffer, but they didn't help. The video source rate is 788kbps, lasts 6 seconds. By dumping the received file to disk, it turned out that only a quarter of the stream was successfully received ("gst-launch -v rtspsrc location=rtsp://10.38.164.205/water_mpeg4.mp4 ! gstrtpjitterbuffer latency=20000 ! rtpmp4vdepay ! filesink location=./stream.m4v"). Most of them was dropped for some reason I don't know. How can I get information regarding those drooped packets? Thank you for your advice :) Best regards -felix Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Aurelien,
Thank you for your help. I enabled GST_DEBUG on gstrtpjitterbuffer and udpsrc. From the log, I can see part of the UDP packets are missing (there exists gap of the packet number between consecutive packets that are pushed into jitterbuffer). If I force rtspsrc to use TCP for all transmissions, then everything is perfect and no packet is dropped thanks to TCP's flow control and retransmission. Since I'm using Darwin Streaming Server, I guess the server is pretty aggresive in sending out UDP packet, my client board cannot catch up the incoming UDP packets and packet drop happens. Maybe I have to find out someway to control the sending rate at the server side when using UDP. Best regards, Felix On Wed, Aug 13, 2008 at 2:33 AM, Aurelien Grimaud <[hidden email]> wrote:
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |