Raspberry pi hardware accelerated playback

[Matthew Waters]

On 23/03/17 00:19, David Ventura wrote:
> My caps seem to be not using zerocopy:
>
> /GstPipeline:pipeline0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0.GstPad:sink:
> caps = video/x-h264, stream-format=(string)byte-stream,
> alignment=(string)au, level=(string)4, profile=(string)high,
> width=(int)1280, height=(int)720, framerate=(fraction)0/1,
> parsed=(boolean)true
> /GstPipeline:pipeline0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0.GstPad:src:
> caps = video/x-raw, format=(string)I420, width=(int)1280,
> height=(int)720, interlace-mode=(string)progressive,
> pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2,
> colorimetry=(string)bt709, framerate=(fraction)0/1
> /GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = video/x-raw,
> format=(string)I420, width=(int)1280, height=(int)720,
> interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1,
> chroma-site=(string)mpeg2, colorimetry=(string)bt709,
> framerate=(fraction)0/1
> /GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps =
> video/x-raw, format=(string)I420, width=(int)1280, height=(int)720,
> interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1,
> chroma-site=(string)mpeg2, colorimetry=(string)bt709,
> framerate=(fraction)0/1
> /GstPipeline:pipeline0/GstGLImageSink:glimagesink0.GstPad:sink: caps =
> video/x-raw, format=(string)I420, width=(int)1280, height=(int)720,
> interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1,
> chroma-site=(string)mpeg2, colorimetry=(string)bt709,
> framerate=(fraction)0/1
>
>
>
> What options did I miss while building gst-plugins-bad / gst-omx ?
>
> In my build script I used:
>
> AUTOGEN_FLAGS=" --with-omx-header-path=/opt/vc/include/IL
> --with-omx-target=rpi --prefix=/usr
> --libdir=/usr/lib/arm-linux-gnueabihf/"
> AUTOGEN_FLAGS="$AUTOGEN_FLAGS
> --disable-{fatal-warnings,gtk-doc,debug,debugutils,tests,examples}"

Make sure you're building gst-omx and gst-plugins-bad from compatible
versions.  Having both gst-omx and gst-plugins-bad be >= 1.10.0 is a
good start.  Using older versions it gets complicated as to which
versions are compatible with each other.

My build setup uses

CPPFLAGS="-I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads
-I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/IL"
LIBS="-L/opt/vc/lib"

In the environment

--disable-x11 --disable-opengl --disable-glx --enable-gles2
--disable-wayland --with-gles2-module-name=/opt/vc/lib/libGLESv2.so
--with-egl-module-name=/opt/vc/lib/libEGL.so

for autogen in gst-plugins-bad and

--with-omx-target=rpi

for autogen in gst-omx

Cheers
-Matt

> On 22 March 2017 at 09:59, Matthew Waters <ystreet00 at gmail.com
> <mailto:ystreet00 at gmail.com>> wrote:
>
>     On 22/03/17 23:35, David Ventura wrote:
>>     While it does help, it's way, way worse than it should be. Is
>>     this 'normal'? Is there any way to play back a gstreamer pipeline
>>     smoothly on a pi? This is 1280x720 at 25. Lowering the source
>>     bitrate helps a little, but it's not even that high to begin with.
>
>     If you actually built gst-omx and gst-plugins-bad correctly, you
>     will just get smooth playback of 1080p at 30 videos.
>
>     Have a look at the caps between omxh264dec and glimagesink if they
>     do not contain video/x-raw(memory:GLMemory) then the zerocopy path
>     is not being used.
>
>     The other thing to double check is the latency setting (10ms) on
>     rtpjitterbuffer be be too low for your network.
>
>     Cheers
>     -Matt
>
>>     David
>>
>>     On 22 March 2017 at 07:56, Matthew Waters <ystreet00 at gmail.com
>>     <mailto:ystreet00 at gmail.com>> wrote:
>>
>>         On 22/03/17 04:15, David Ventura wrote:
>>>         Hi. I've been trying to play either a udp h264 stream or a
>>>         video file with hardware acceleration.
>>>
>>>         With this command I get VERY choppy playback, low cpu usage
>>>         and a lot of banding:
>>>
>>>         gst-launch-1.0 -qe udpsrc port=5002 do-timestamp=true !
>>>         queue ! application/x-rtp, payload=96 ! rtpjitterbuffer
>>>         latency=10 ! rtph264depay ! h264parse ! omxh264dec !
>>>         glimagesink
>>
>>         Adding a small queue after the decoder at least would
>>         decouple video decoding from actual rendering which probably
>>         helps here.
>>
>>         As you have low CPU usage I assume you built gst-omx and
>>         gst-plugins-bad correctly for zerocopy decoding which is good :)
>>
>>         Cheers
>>         -Matt
>>
>>>         adding
>>>
>>>         enable-last-sample=false qos=false
>>>
>>>         to the glimagesink makes it somewhat better, but still horrible.
>>>
>>>         Similar thing (banding, low fps, low cpu usage) happens with:
>>>         gst-launch-1.0 filesrc location=file.mp4 ! qtdemux !
>>>         h264parse ! omxh264dec ! glimagesink
>>>
>>>         I compiled this version on my own, I'm running 1.11.1 right now.
>>>
>>>         What can I do about this?
>>>         -- 
>>>         *Stack* is the new term for "I have no idea what I'm
>>>         actually using".
>>
>>
>>
>>
>>     -- 
>>     *Stack* is the new term for "I have no idea what I'm actually using".
>
>
>
>
> -- 
> *Stack* is the new term for "I have no idea what I'm actually using".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170323/ceab8530/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 516 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170323/ceab8530/attachment-0001.sig>