Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
28 posts
|
Hello.
I'm trying to display video from rtsp camera (SAMSUNG snz-5200) with h264 1280x1024 stream. First I record stream to file: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! legacyh264parse access-unit=true output-format=0 ! mp4mux ! filesink location=test.mp4 After that file is perfectly playable by totem, media player classic and this pipeline: gst-launch -e filesrc location=test.mp4 ! qtdemux ! legacyh264parse ! mfw_vpudecoder ! mfw_v4lsink So I assume, that this stream is playable on hardware that I use (freescale imx53qsb with arm processor and hardware vpu for media decoding) BUT... I try to display video directly from rtsp stream: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! mfw_vpudecoder ! mfw_v4lsink And there is hudge delay and a lot of artefacts whet screen is moving. Every thing is ok when i use lower resolution like 800x600. But on 1024x768 problem starts and getting worse on higher resolutions. I have tryed a lot of configurations for jitterbuffer, decoder, legacyh264parse, and sink (sync=false). I think that it might be timestamping 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??? - 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 I have this warning: ---------------------------- WARNING: from element /GstPipeline:pipeline0/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0: A lot of buffers are being dropped. Additional debug info: gstbasesink.c(2875): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0: There may be a timestamping problem, or this computer is too slow. ---------------------------- Also when I use export GST_DEBUG=2,mfw_vpudecoder:4 I get this cyclic output: ---------------------------- 0:00:16.001583376 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:3466:mfw_gst_vpudec_src_event: The time of decoding is 1784 ms away the system time,Enable L2 strategy 0:00:16.001858001 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2787:mfw_gst_vpudec_render: >>VPU_DEC: Render buff 4, total:266 0:00:16.001932876 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:1527:mfw_gst_avc_fix_nalheader: nal found in avc data 0:00:16.013550626 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2745:mfw_gst_vpudec_render: frame dropping factor is 3. 0:00:16.013701626 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2757:mfw_gst_vpudec_render: Drop the frame before render it:6.status:2 0:00:16.013784501 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:1527:mfw_gst_avc_fix_nalheader: nal found in avc data 0:00:16.040830876 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2745:mfw_gst_vpudec_render: frame dropping factor is 3. 0:00:16.041436876 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:3466:mfw_gst_vpudec_src_event: The time of decoding is 1744 ms away the system time,Enable L2 strategy -------------------------- Does anyone has experiance with HD playback from rtsp stream. Regards Maciek |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
13 posts
|
First thing to look at is packet loss.... With RTSP 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 src and jitterbuffer 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 the bitrate will be fairly low when the image is static (have a look at the bitrate in VLC) once the movement happens the bitrate will shoot up as it will be adapting to the moving images.
Can you change the MAX bitrate on the camera to help debug ?
Regards Marc
From: gstreamer-devel-bounces+marcmltd=[hidden email] [gstreamer-devel-bounces+marcmltd=[hidden email]]
on behalf of bamboosso [[hidden email]]
Sent: 10 December 2012 01:05 To: [hidden email] Subject: h264 stream form filesrc vs from live source (rtsp). HD playback Hello.
I'm trying to display video from rtsp camera (SAMSUNG snz-5200) with h264 1280x1024 stream. First I record stream to file: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! legacyh264parse access-unit=true output-format=0 ! mp4mux ! filesink location=test.mp4 After that file is perfectly playable by totem, media player classic and this pipeline: gst-launch -e filesrc location=test.mp4 ! qtdemux ! legacyh264parse ! mfw_vpudecoder ! mfw_v4lsink So I assume, that this stream is playable on hardware that I use (freescale imx53qsb with arm processor and hardware vpu for media decoding) BUT... I try to display video directly from rtsp stream: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! mfw_vpudecoder ! mfw_v4lsink And there is hudge delay and a lot of artefacts whet screen is moving. Every thing is ok when i use lower resolution like 800x600. But on 1024x768 problem starts and getting worse on higher resolutions. I have tryed a lot of configurations for jitterbuffer, decoder, legacyh264parse, and sink (sync=false). I think that it might be timestamping 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???* - 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 I have this warning: ---------------------------- WARNING: from element /GstPipeline:pipeline0/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0: A lot of buffers are being dropped. Additional debug info: gstbasesink.c(2875): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0: There may be a timestamping problem, or this computer is too slow. ---------------------------- Also when I use export GST_DEBUG=2,mfw_vpudecoder:4 I get this cyclic output: ---------------------------- 0:00:16.001583376 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:3466:mfw_gst_vpudec_src_event: The time of decoding is 1784 ms away the system time,Enable L2 strategy 0:00:16.001858001 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2787:mfw_gst_vpudec_render: >>VPU_DEC: Render buff 4, total:266 0:00:16.001932876 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:1527:mfw_gst_avc_fix_nalheader: nal found in avc data 0:00:16.013550626 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2745:mfw_gst_vpudec_render: frame dropping factor is 3. 0:00:16.013701626 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2757:mfw_gst_vpudec_render: Drop the frame before render it:6.status:2 0:00:16.013784501 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:1527:mfw_gst_avc_fix_nalheader: nal found in avc data 0:00:16.040830876 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:2745:mfw_gst_vpudec_render: frame dropping factor is 3. 0:00:16.041436876 7906 0x107b98 DEBUG mfw_vpudecoder mfw_gst_vpu_decoder.c:3466:mfw_gst_vpudec_src_event: The time of decoding is 1744 ms away the system time,Enable L2 strategy -------------------------- Does anyone has experiance with HD playback from rtsp stream. Regards Maciek -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/h264-stream-form-filesrc-vs-from-live-source-rtsp-HD-playback-tp4657319.html Sent from the GStreamer-devel mailing list archive at Nabble.com. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
28 posts
|
Hello.
Thanks for answer. I will check it immediately after i came back home. The problem is, that video recording is perfect (no packets are lost I assume), and its connected threw cable so there is no reason to lose packets. But I will check. Regards Maciek |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
28 posts
|
Hello,
so, I've made some digging. First this is playback pipeline: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! legacyh264parse output-format=0 access-unit=true ! mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink sync=false And two debug options: First export GST_DEBUG=2,rtspsrc:5 rtspsrc.txt or rtspsrc.txt There are a lot of qos events received by the rtp src pad. But I don't know what they mean. Artefacts on video are from first second of playback. There is one session timeout near 29th second of playback, but I haven't seen it on playback. Second: export GST_DEBUG=2,gstrtpjitterbuffer:5 rtspsrc_jitterbuffer.txt and there is a lot of messages like which looks good: Peeking item Peeked buffer #645, expect #645, timestamp 0:00:01.901759769, now 931 left Pushing buffer 645, timestamp 0:00:01.901759769 Received packet #645 at time 0:00:01.901759769 Pushed packet #645, now 46 packets, tail: 0 And a lot of: Peeking item Peeked buffer #632, expect #631, timestamp 0:00:01.839214240, now 897 left Sequence number GAP detected: expected 631 instead of 632 (1 missing) out_time 0:00:01.839214240, last 0:00:01.839214240 duration 0:00:00.000000000 sync to timestamp 0:00:01.839214240 and: Peeking item Peeked buffer #635, expect #634, timestamp 0:00:01.839214240, now 940 left Sequence number GAP detected: expected 634 instead of 635 (1 missing) out_time 0:00:01.839214240, last 0:00:01.839214240 duration 0:00:00.000000000 sync to timestamp 0:00:01.839214240 Packet #634 lost So, buffers are definetly lost somewhere... Next i have save pipeline: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! legacyh264parse output-format=0 access-unit=true ! mp4mux ! filesink location=h264_1280x1024.mp4 and two outputs with same debug options: rtspsrc_record.txt rtspsrc_gstrtpjitterbuffer_record.txt And here: 1. No more qos events sent to rtspsrc src pad 2. No buffer lost in gstrtpjitterbuffer I'm a little bit confused. Is it a clock propagation, clock source, hardware too slow (bitrate is set to 5120kbps so 100Mb ethernet should be enougth?? Its working for recording.) I'm thinking that mfw_vpudecoder or mfw_v4lsink takes too much time?? But then I would expect, that buffer lost would be somewhere between parser and decoder. Here are aoutputs from other elements of pipeline: rtph264depay.txt legacyh264parse.txt mfw_vpudecoder.txt mfw_v4lsink.txt But I can't see any errors in those files. Next test: record and display video in same time. My pipeline: gst-launch -e rtspsrc location=rtsp://admin:4321@192.168.0.140:554/profile5/media.smp ! gstrtpjitterbuffer ! rtph264depay ! legacyh264parse output-format=0 access-unit=true ! tee name=t t. ! queue ! mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink sync=false t. ! queue ! mp4mux ! filesink location=temp.mp4 Video contains a lot of artefacts and delay. Below I attach 2 videos: 1. Only record pipeline: http://h264_1280x1024.mp4 2. Record and playback pipeline: h264_1280x1024_bad.mp4 So the main question is: What is the difference when using rtsp and filesrc??? From filesrc I can decode h264 stream with 1920x1080 without delays. And I can decode previously recorded stream from rtsp. Regards Maciek |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
28 posts
|
Hello,
I have switched video display from mfw_v4lsink to mfw_isink. mfw_isink is video display plugin based on IPU. And now playback is much better. still there are a lot of artefacsts and buffers are lost in gstrtpjitterbuffer, but not as much as prevoius. So I attached fakesink after mfw_vpudecoder. There is no buffer lost. What am I missing??? Regards Maciek |
Free forum by Nabble | Disable Popup Ads | Edit this page |