GNOME Bugzilla – Bug 633831
rtsp on windows
Last modified: 2012-10-06 12:00:46 UTC
There are several blocking bugs connecting to live rtsp sources from windows: 1) h264 streams crash after few minutes (rtspsrc ! rtph264depay ! ffdec_h264 ...) 2) mpeg4 stream have syncronization issues, I have this error: "warning first frame is no keyframe" and the video is green until the next keyframe these problems are not present on linux. If from linux, I save an rtsp stream and serve it via http (for example using apache), gstreamer windows client are able to see the streams with no issue (neonhttpsrc seems better that souphttpsrc on windows). If I connect to the live rtsp source from linux, depayload it, payload via gdp and serve it over http (I developed a small gst-http-server) I'm able to see the streams on windows with no issue, so the problem is in rtspsrc *pay on windows
Did this work fine with the previous releases? Are you working on patches?
No the h264 bug is there since the first time I tryed ossbuild (http://code.google.com/p/ossbuild/issues/detail?id=12), the keyframe issue maybe worked in a previuos release, I'll try tomorrow ossbuild 0.10.4 and 0.10.5.1 No sorry, I'm not working on patches, for me is simpler to develop and maintain a gst-http-server that run on linux and make gstreamer on windows happy, my actual demo use appsink and qtcpsocket (yes Qt is simpler and better documented than glib for me)
these problems are present in all gstreamer ossbuild versions I tested: 0.10.5.1 0.10.6 last svn my test environment is the following: - axis camera P3344 (gstreamer inside): h264 stream - axis camera 233D and moxa vport 351: mpeg4 stream
additional tests: server: gst-rtsp server pipeline: rtspsrc location=... ! rtph264depay byte-stream=false ! h264parse ! rtph264pay name=pay0 pt=96 client: gstreamer on windows client pipeline: rtspsrc location=urltogstrtsp ! rtph264depay ! ffdec_h264 ! ... result: crash after about 30 minutes notes: tryed serveral options for rtp264depay and with and without the h264parse element the crash remain server: gst-http server pipeline: rtspsrc location=... ! rtph264depay byte-stream=false ! h264parse ! gdppay ! appsink client: gstreamer on windows (neonhttpsrc ... ! gdpdepay ! ...) result: stable for hours server: gst-rtsp server pipeline: rtspsrc location=... ! rtpmp4vdepay ! mpeg4videoparse ! rtph264pay name=pay0 pt=96 client: gstreamer on windows client pipeline: rtspsrc location=urltogstrtsp ! rtpmp4vdepay ! ffdec_mpeg4 ! ... result: gst-launch doesn't crash but I have frequently this error: :00:00.750000000 3508 00BCA8F0 ERROR ffmpeg .:0:: warning: f irst frame is no keyframe 0:00:01.015625000 3508 00BCA8F0 ERROR ffmpeg .:0:: warning: f irst frame is no keyframe 0:00:01.625000000 3508 00BCA8F0 ERROR ffmpeg .:0:: warning: f irst frame is no keyframe 0:00:03.562500000 3508 00BCA8F0 ERROR ffmpeg .:0:: warning: f irst frame is no keyframe 0:00:06.437500000 3508 00BCA8F0 ERROR ffmpeg .:0:: warning: f irst frame is no keyframe 0:00:07.718750000 3508 00BCA8F0 ERROR ffmpeg .:0:: warning: f irst frame is no keyframe the video is green until the next keyframe, this happen frequently (in the log above 3 times in 7 seconds) notes: tryed with and without mpeg4videoparse (both on server and on client), no changes server: gst-http server pipeline: rtspsrc location=... ! rtpmp4vdepay ! mpeg4videoparse ! gdppay ! appsink client: gstreamer on windows (neonhttpsrc ... ! gdpdepay ! ...) result: stable for hours with no keyframe issue minor issue observed in all cases: - h264 stream: 0:39:10.671875000 1256 00BB6BF0 ERROR ffmpeg .:0:: Missing re ference picture 0:39:10.671875000 1256 00BB6BF0 ERROR ffmpeg .:0:: decode_sli ce_header error 0:39:10.671875000 1256 00BB6BF0 ERROR ffmpeg .:0:: mmco: unre f short failure the effect is visible on the video but is not observed frequently, please note that vlc on windows works fine both with gst-rtsp than directly connected to the cameras
Moving from blocker to major since this is not a regression.
any progress with this bug?
It looks like the patch proposed in https://bugzilla.gnome.org/show_bug.cgi?id=595590 fixes this bug
No Andoni :-(, the crash is only part of this bug if you try to see an rtp/rtsp stream on windows often some keyframes are lost (mpeg4/h264) and this is a visible effect, the same streams work fine on linux
I have been debugging this problem in windows these days without noticiying this bug report. At the end I get the same solution. As avcodec.h says 490 /** 491 * Required number of additionally allocated bytes at the end of the input bitstream for decoding. 492 * This is mainly needed because some optimized bitstream readers read 493 * 32 or 64 bit at once and could read over the end.<br> 494 * Note: If the first 23 bits of the additional bytes are not 0, then damaged 495 * MPEG bitstreams could cause overread and segfault. 496 */ 497 #define FF_INPUT_BUFFER_PADDING_SIZE 8 Also instead of calling do_padding, probably would be better to have a custom allocation buffer function in the sink pad. Also here it is my stack trace: (gdb) bt
+ Trace 226224
(In reply to comment #8) > No Andoni :-(, the crash is only part of this bug if you try to see an rtp/rtsp > stream on windows often some keyframes are lost (mpeg4/h264) and this is a > visible effect, the same streams work fine on linux You are reporting 2 bugs in the same bug report and the first one is related to #595590
What's up with this? Does it still happen? (on 0.10 branch or master?) (network code has been rewritten a fair bit in 0.11/1.0)
not tested in 1.0, I think the patch here: https://bugzilla.gnome.org/show_bug.cgi?id=675444 could solve the problem. I'm not using rtspsrc on windows however I'll do some tests with that patch applied
Nicola, did you have the chance to test?
Hi, sorry for the delay, I did some tests on a vbox virtual machine using xp and an old ossbuild installation (0.10.7 beta4): - the bug can be reproduced using an url like rtsp:// but not rtspt:// so is something related to udp - the patch doesn't solve the issue for me here is my test pipeline: rtspsrc location=rtsp://.... ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! d3dvideosink Nicola
I'm unable to reproduce with gstreamer sdk 2012.09 (tested for about 10 minutes on the same virtual machine) so probably there was something in ossbuild that caused this issue or is something solved in new gstreamer versions