Raspberry pi hardware accelerated playback

[David Ventura]

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



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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170322/7ca5ba83/attachment.html>