Raspberry pi hardware accelerated playback

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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?
--
Stack is the new term for "I have no idea what I'm actually using".

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

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?
--
Stack is the new term for "I have no idea what I'm actually using".


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

signature.asc (527 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

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

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

signature.asc (527 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[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?
--
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".

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[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?
--
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".

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

signature.asc (527 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

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

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




--
Damien Picard
Expert GWT
Mob : 06 11 51 47 78

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

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

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

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




--
Damien Picard
Expert GWT
Mob : 06 11 51 47 78

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raspberry pi hardware accelerated playback

David Ventura
In reply to this post by Matthew Waters
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?
--
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".

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