<html dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style>.EmailQuote { BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt } </style><style id="owaParaStyle">P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } </style> </head> <body ocsi="0" fPStyle="1"> <div style="FONT-FAMILY: Calibri; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 12pt"> First thing to look at is packet loss.... With RTSP<a target="_blank"></a> it is server driven delivery, so once the session is started the server starts to fire the packets at the client. If you switch on the debugging on the UDP<a target="_blank"></a> src<a target="_blank"></a> and jitterbuffer<a target="_blank"></a> you will see if there are any missing packets. I would be looking in this area first as you see the issue when the image is moving. With h264<a target="_blank"></a> the bitrate<a target="_blank"></a> will be fairly low when the image is static (have a look at the bitrate<a target="_blank"></a> in VLC<a target="_blank"></a>) once the movement happens the bitrate<a target="_blank"></a> will shoot up as it will be adapting to the moving images. Can you change the MAX bitrate<a target="_blank"></a> on the camera to help debug ? Regards Marc <div> <div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px"> <div> <hr tabindex="-1"> </div> </div> </div> <div> <div id="x_divRplyFwdMsg">From: gstreamer-devel-bounces+marcmltd=marcm.co.uk@lists.freedesktop.org<a target="_blank"></a> [gstreamer-devel-bounces+marcmltd<a target="_blank"></a>=marcm.co.uk@lists.freedesktop.org<a target="_blank"></a>] on behalf of bamboosso<a target="_blank"></a> [laski.maciej@gmail.com<a target="_blank"></a>] Sent: 10 December 2012 01:05 To: gstreamer-devel@lists.freedesktop.org<a target="_blank"></a> Subject: h264<a target="_blank"></a> stream form filesrc<a target="_blank"></a> vs<a target="_blank"></a> from live source (rtsp<a target="_blank"></a>). HD playback </div> <div></div> </div> <div class="PlainText">Hello. I'm trying to display video from rtsp<a target="_blank"></a> camera (SAMSUNG snz<a target="_blank"></a>-5200) with h264<a target="_blank"></a> 1280x1024<a target="_blank"></a> stream. First I record stream to file: gst<a target="_blank"></a>-launch -e rtspsrc<a target="_blank"></a> location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer<a target="_blank"></a> ! rtph264depay<a target="_blank"></a> ! legacyh264parse<a target="_blank"></a> access-unit=true output-format=0 ! mp4mux<a target="_blank"></a> ! filesink<a target="_blank"></a> location=test.mp4<a target="_blank"></a> After that file is perfectly playable by totem, media player classic and this pipeline: gst<a target="_blank"></a>-launch -e filesrc<a target="_blank"></a> location=test.mp4<a target="_blank"></a> ! qtdemux<a target="_blank"></a> ! legacyh264parse<a target="_blank"></a> ! mfw_vpudecoder<a target="_blank"></a> ! mfw_v4lsink<a target="_blank"></a> So I assume, that this stream is playable on hardware that I use (freescale<a target="_blank"></a> imx53qsb<a target="_blank"></a> with arm processor and hardware vpu<a target="_blank"></a> for media decoding) BUT... I try to display video directly from rtsp<a target="_blank"></a> stream: gst<a target="_blank"></a>-launch -e rtspsrc<a target="_blank"></a> location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer<a target="_blank"></a> ! rtph264depay<a target="_blank"></a> ! mfw_vpudecoder<a target="_blank"></a> ! mfw_v4lsink<a target="_blank"></a> And there is hudge<a target="_blank"></a> delay and a lot of artefacts whet screen is moving. Every thing is ok when i<a target="_blank"></a> use lower resolution like 800x600<a target="_blank"></a>. But on 1024x768<a target="_blank"></a> problem starts and getting worse on higher resolutions. I have tryed<a target="_blank"></a> a lot of configurations for jitterbuffer<a target="_blank"></a>, decoder, legacyh264parse<a target="_blank"></a>, and sink (sync=false). I think that it might be timestamping<a target="_blank"></a> problem, or buffers that goes to decoder sink are not representing correct frames. *What is difference with handling this stream from live source and from filesrc<a target="_blank"></a>???* - I think, that problem is in source. *Where should I start to search the error.* when I do not provide sync=false to mfw_v4lsink<a target="_blank"></a> I have this warning: ---------------------------- WARNING: from element /GstPipeline:pipeline0<a target="_blank"></a>/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0<a target="_blank"></a>: A lot of buffers are being dropped. Additional debug info: gstbasesink.c<a target="_blank"></a>(2875): gst_base_sink_is_too_late<a target="_blank"></a> (): /GstPipeline:pipeline0<a target="_blank"></a>/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0<a target="_blank"></a>: There may be a timestamping<a target="_blank"></a> problem, or this computer is too slow. ---------------------------- Also when I use export GST_DEBUG<a target="_blank"></a>=2,mfw_vpudecoder:4<a target="_blank"></a> I get this cyclic output: ---------------------------- 0:00:16.001583376 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:3466:mfw_gst_vpudec_src_event<a target="_blank"></a>: The time of decoding is 1784 ms away the system time,Enable<a target="_blank"></a> L2<a target="_blank"></a> strategy 0:00:16.001858001 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:2787:mfw_gst_vpudec_render<a target="_blank"></a>: >>VPU_DEC<a target="_blank"></a>: Render buff 4, total:266<a target="_blank"></a> 0:00:16.001932876 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:1527:mfw_gst_avc_fix_nalheader<a target="_blank"></a>: nal<a target="_blank"></a> found in avc<a target="_blank"></a> data 0:00:16.013550626 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:2745:mfw_gst_vpudec_render<a target="_blank"></a>: frame dropping factor is 3. 0:00:16.013701626 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:2757:mfw_gst_vpudec_render<a target="_blank"></a>: Drop the frame before render it:6.status:2<a target="_blank"></a> 0:00:16.013784501 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:1527:mfw_gst_avc_fix_nalheader<a target="_blank"></a>: nal<a target="_blank"></a> found in avc<a target="_blank"></a> data 0:00:16.040830876 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:2745:mfw_gst_vpudec_render<a target="_blank"></a>: frame dropping factor is 3. 0:00:16.041436876 7906 0x107b98<a target="_blank"></a> DEBUG mfw_vpudecoder<a target="_blank"></a> mfw_gst_vpu_decoder.c:3466:mfw_gst_vpudec_src_event<a target="_blank"></a>: The time of decoding is 1744 ms away the system time,Enable<a target="_blank"></a> L2<a target="_blank"></a> strategy -------------------------- Does anyone has experiance<a target="_blank"></a> with HD playback from rtsp<a target="_blank"></a> stream. Regards Maciek<a target="_blank"></a> -- View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/h264-stream-form-filesrc-vs-from-live-source-rtsp-HD-playback-tp4657319.html" target="_blank"> http://gstreamer-devel.966125.n4.nabble.com/h264-stream-form-filesrc-vs-from-live-source-rtsp-HD-playback-tp4657319.html</a> Sent from the GStreamer-devel<a target="_blank"></a> mailing list archive at Nabble.com<a target="_blank"></a>. _______________________________________________ gstreamer-devel<a target="_blank"></a> mailing list gstreamer-devel@lists.freedesktop.org<a target="_blank"></a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </div> </div> </body> </html>