Raspberry pi hardware accelerated playback

[David Ventura]

I've recompiled gst-plugins-bad and gst-omx (1.11.1) with your env
variables and it did not work, but then I set:


export CFLAGS="-I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads
-I/opt/vc/include/interface/vmcs_host/linux/ -I/opt/vc/include/IL"
export LDFLAGS="-L/opt/vc/lib"
export 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"
export LIBS="-L/opt/vc/lib"

and it worked. Maybe I fucked up something else, I don't know. It's working
now, so thank you.


On 22 March 2017 at 10:43, Matthew Waters <ystreet00 at gmail.com> wrote:

> 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> 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> 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".
>
>


-- 
*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/33eb0682/attachment-0001.html>