GL Video Scaling

[Samuel Hurst]

Hi All,


I've got a Raspberry Pi 2 running the latest RC (1.7.91) and git latest
gst-omx, but I'm having issues getting the video to run full screen.
There is no X running on the box, just the framebuffer and EGL over the
HDMI video output.

Using the pipeline below or by letting playbin build the pipeline for
me, I can get DASH playback working fine, but it's only in a very small
window in the centre instead of filling the whole screen, and doesn't
change even when the representation resolution increases:

gst-launch-1.0 souphttpsrc location=$MPD_URL ! dashdemux name=d d. !
video/quicktime ! queue ! qtdemux ! h264parse ! omxh264dec ! glimagesink
d. ! audio/x-m4a ! queue ! qtdemux ! aacparse ! avdec_aac ! omxhdmiaudiosink

If I use videoscale, then I can get the video to stretch and fill the
screen, but the performance is so slow (<1 fps) that it's not workable.
A bit of searching later and I found the glcolorscale element, but I
can't get it to work, omxh264dec keeps coming back with a
"not-negotiated" error. Can anyone point me as to where I'm going wrong?
Example pipeline below:

gst-launch-1.0 souphttpsrc location=$MPD_URL ! dashdemux name=d d. !
video/quicktime ! queue ! qtdemux ! h264parse ! omxh264dec !
glcolorscale ! "video/x-raw(memory:GLMemory),width=1920,height=1080"
glimagesink

Looking at the caps for the omxh264dec element when it's going straight
into the glimagesink, it's producing video/x-raw(memory:GLMemory) with
format:RGBA which the glimagesink is happy to accept. But putting the
glcolorscale in the mix too seems to cause the omxh264dec to start
spitting out generic video/x-raw with format:I420 and glcolorscale's
caps are video/x-raw(memory:GLMemory) and format:RGBA respectively. I've
tried adding another caps filter between the omxdec and colorscale
elements, but that doesn't help either; as well as trying autovideoconvert.

I've attached the pipeline dot files for both of those cases, in case it
helps.


Best Regards,
Sam



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

[Pawel Labus]

Hi,

instead of directly linking:

... omxh264dec ! glcolorscale ...

try:
... omxh264dec ! glupload ! glcolorconvert ! glcolorscale ! "video ..

From what I understand

in case of connecting glimagesink directly  ( ... omxh264dec ! glimagesink ... ) glimagesink cares about this dirty work of uploading/converting.

Regards,

Hanczar

On 17 March 2016 at 17:56, Samuel Hurst <[hidden email]> wrote:

Hi All,


I've got a Raspberry Pi 2 running the latest RC (1.7.91) and git latest
gst-omx, but I'm having issues getting the video to run full screen.
There is no X running on the box, just the framebuffer and EGL over the
HDMI video output.

Using the pipeline below or by letting playbin build the pipeline for
me, I can get DASH playback working fine, but it's only in a very small
window in the centre instead of filling the whole screen, and doesn't
change even when the representation resolution increases:

gst-launch-1.0 souphttpsrc location=$MPD_URL ! dashdemux name=d d. !
video/quicktime ! queue ! qtdemux ! h264parse ! omxh264dec ! glimagesink
d. ! audio/x-m4a ! queue ! qtdemux ! aacparse ! avdec_aac ! omxhdmiaudiosink

If I use videoscale, then I can get the video to stretch and fill the
screen, but the performance is so slow (<1 fps) that it's not workable.
A bit of searching later and I found the glcolorscale element, but I
can't get it to work, omxh264dec keeps coming back with a
"not-negotiated" error. Can anyone point me as to where I'm going wrong?
Example pipeline below:

gst-launch-1.0 souphttpsrc location=$MPD_URL ! dashdemux name=d d. !
video/quicktime ! queue ! qtdemux ! h264parse ! omxh264dec !
glcolorscale ! "video/x-raw(memory:GLMemory),width=1920,height=1080"
glimagesink

Looking at the caps for the omxh264dec element when it's going straight
into the glimagesink, it's producing video/x-raw(memory:GLMemory) with
format:RGBA which the glimagesink is happy to accept. But putting the
glcolorscale in the mix too seems to cause the omxh264dec to start
spitting out generic video/x-raw with format:I420 and glcolorscale's
caps are video/x-raw(memory:GLMemory) and format:RGBA respectively. I've
tried adding another caps filter between the omxdec and colorscale
elements, but that doesn't help either; as well as trying autovideoconvert.

I've attached the pipeline dot files for both of those cases, in case it
helps.


Best Regards,
Sam



_______________________________________________
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

[Samuel Hurst]

On 18/03/2016 09:10, Pawel Labus wrote:
> Hi,
> instead of directly linking:
> ... omxh264dec ! glcolorscale ...
>
> try:
> ... omxh264dec ! glupload ! glcolorconvert ! glcolorscale ! "video ..

Thanks very much, that solved my problem!

> From what I understand
> in case of connecting glimagesink directly  ( ... omxh264dec !
> glimagesink ... ) glimagesink cares about this dirty work of
> uploading/converting.

That's good to know! For other people's reference, my new DASH pipeline is:

gst-launch-1.0 souphttpsrc location=$MPD_URL ! dashdemux name=d d. !
video/quicktime ! queue ! qtdemux ! h264parse ! omxh264dec ! glupload !
glcolorconvert ! glcolorscale !
"video/x-raw(memory:GLMemory),width=1280,height=720" ! glimagesink d. !
audio/x-m4a ! queue ! qtdemux ! aacparse ! avdec_aac ! audioconvert !
omxhdmiaudiosink

It gets a bit choppy on the top 720p50 DASH representation when there's
a lot of stuff going on, but I'm guessing this is just in need of some
optimisation.

Cheers,
Sam


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