Raspberry pi hardware accelerated playback

[David Ventura]

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

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?

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matthew Waters]

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?

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Ventura]

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@25. Lowering the source bitrate helps a little, but it's not even that high to begin with.

David

On 22 March 2017 at 07:56, Matthew Waters <[hidden email]> 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?

--

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matthew Waters]

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@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@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 <[hidden email]> 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?

--

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> 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@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@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 <[hidden email]> 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?

--

--

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> 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@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@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 <[hidden email]> 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?

--

--

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Damien Picard]

How do you see in the logs that zerocopy is not used ? I wonder if I have the same problem...

2017-03-22 14:43 GMT+01:00 Matthew Waters <[hidden email]>:

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 <[hidden email]> 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@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@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 <[hidden email]> 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?

--

--

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 22 mars 2017 à 14:45 +0100, Damien Picard a écrit :
> How do you see in the logs that zerocopy is not used ? I wonder if I have the same problem...
>
> > 2017-03-22 14:43 GMT+01:00 Matthew Waters <[hidden email]>:
> > 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

In zero-copy, the omx decoder src caps should start with:

  video/x-raw(memory:GLMemory),...

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Damien Picard]

Thank you ! So I see that I don't use the zerocopy while encoding too :

/GstPipeline:pipeline0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2, colorimetry=(string)1:4:0:0, framerate=(fraction)30/1

I should have /GstPipeline:pipeline0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0.GstPad:sink: caps = video/x-raw(memory:GLMemory), format=(string)I420, width=(int)1920, height=(int)1080, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2, colorimetry=(string)1:4:0:0, framerate=(fraction)30/1

(Sorry to pollute the thread)

2017-03-22 15:23 GMT+01:00 Nicolas Dufresne <[hidden email]>:

Le mercredi 22 mars 2017 à 14:45 +0100, Damien Picard a écrit :
> How do you see in the logs that zerocopy is not used ? I wonder if I have the same problem...
>
> > 2017-03-22 14:43 GMT+01:00 Matthew Waters <[hidden email]>:
> > 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

In zero-copy, the omx decoder src caps should start with:

  video/x-raw(memory:GLMemory),...

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> 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 <[hidden email]> 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@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@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 <[hidden email]> 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?

--

--

--

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel