Closed matthiasbock closed 11 years ago
Maybe it also has to do with the H264 profile mode ? profile=high seems to provide a better picture.
Can I get more debug info from the EGL/GLES sink ? With something like
$ gst-launch-1.0 --gst-debug=eglgles:5 ...
I am trying to compile gstreamer-plugins-bad 1.0.7 with fbdevsink. Requirements:
$ apt-get install libxml2 libxml2-dev libdirectfb-1.2-9 libdirectfb-bin libdirectfb-dev libdirectfb-extra libv4l-dev libxv-dev yasm bison flex linux-headers-3.6-trunk-rpi libgudev-1.0-dev libusb-1.0-0-dev libdirectfb-dev libtool automake autopoint
A patched version of gstreamer-plugins-bad is required to enable fbdevsink in 1.0.7 (fbdev is officially unported to 1.0):
The version as such doesn't compile with gstreamer-1.0.7, but the changes made there can be adapted to gst-plugins-bad-1.0.7.
I compiled it, apparently also fbdevsink from plugins-bad, but it won't show up in gst-inspect-1.0.
Maybe I will have to go back to 0.10 to have a smooth playback. I will try to compile gst-omx-0.10. Requirements:
apt-get install gstreamer0.10-{tools,plugins-{base,good,bad}} libgstreamer0.10-dev libgstreamer-plugins-{base,bad}0.10-dev
Won't compile.
I tried recording a video with my C920, copied it over to my Raspberry and -surprise- suddenly it plays without stuttering. So afterall it may not be a problem of eglglessink at all. Rather with the process of streaming over the network.
Similar problem: http://stackoverflow.com/questions/11397655/streaming-rtp-rtsp-sync-timestamp-problems
If RTP/UDP won't work, maybe I should simply try tcpserversink and tcpclientsrc or just "stdout to stdin".
aaaand stdin/stdout over SSH tunnel works without stuttering :-)
gst-launch-0.10 -q uvch264_src device=/dev/video1 name=src auto-start=true initial-bitrate=400000 src.vfsrc ! queue ! 'video/x-raw-yuv,width=320,height=240' ! fakesink . src.vidsrc ! queue ! 'video/x-h264,width=1280,height=720,framerate=5/1' ! filesink location=/dev/stdout | ssh root@raspberry "gst-launch-1.0 -v filesrc location=/dev/stdin ! h264parse ! omxh264dec ! eglglessink"
it is also a good idea to add
... ! eglglessink sync=false
in order to get rid of the "sink is too late" messages
Read more about the gstreamer display problematic on the Raspberry Pi: http://comments.gmane.org/gmane.comp.video.gstreamer.devel/42246
Re-compiling eglglessink did not help. However a combination of sync=false and queue2 helps a lot to address (however not resolve) the lag issues. Also RTP streaming appears to be more smooth than direct streaming through SSH....
adding rtpjitterbuffer also helps a little (see streaming/play ing latest commit), but when using Wifi instead of cable image distortions occur
My PC has no problems rendering the same video stream. Decoding speed seems fine. There must be something wrong with eglglessink... The problem occurs independent of whether I seed with v4l2src or uvch264_src.