Login  Register

h264 stream form filesrc vs from live source (rtsp). HD playback

classic Classic list List threaded Threaded
5 messages Options Options
Embed post
Permalink
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

h264 stream form filesrc vs from live source (rtsp). HD playback

bamboosso
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

Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

RE: h264 stream form filesrc vs from live source (rtsp). HD playback

Marc Murphy
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
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

RE: h264 stream form filesrc vs from live source (rtsp). HD playback

bamboosso
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
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

RE: h264 stream form filesrc vs from live source (rtsp). HD playback

bamboosso
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
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

RE: h264 stream form filesrc vs from live source (rtsp). HD playback

bamboosso
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