The VideoLAN Forums

Under Raspbarian, using the included VLC app, playing videos full screen on my 800x480 display works great, at full speed, no frames dropped. But in my app compiled with SDL 1.2 and libvlc, the full screen playback is choppy!

More detail: I'm making an app with video playback in it, and using the SDL1.2 example from the libvlc docs, found here https://wiki.videolan.org/LibVLC_SampleCode_SDL/ NOTE: there are 2 examples given on that page, the first one for SDL 1.2, and the second one for SDL2. Both examples play the video in a small 320x240 picture within side the main window. I'm using the SDL 1.2 one, because the SDL2 one was choppy on the Pi 3. But I've since tweaked the SDL 1.2 one to be fullscreen, and now it is choppy also. I gathered from some prior error messages that it's scaling in software. Here's my code for reference... (it requires the SDL and libvlc libraries)

My question:I was told here that VLC is doing extra things to speed up rendering on the Raspberry Pi. Is it possible for me to get that kind of video playback speed on the Pi in my own application? I don't actually care what libraries or language I have to use (eg. I had some success with the python wrapper), I just need smooth full screen playback on the 800x480 display on my Pi, and the ability to control the playback from within my app. Whatever language / framework I have to write my app in, doesn't matter!

Hi,

using libvlc_video_set_callbacks will perform lots of copy of the image data. The raspberry pi is known to have not a lot of bandwidth.

> VLC is doing extra things to speed up rendering on the Raspberry Pi

yes VLC use a special backend on raspberry (see mmal plugins) which allow to render video using HW acceleration.

I think you might be able to use this module with libvlc, though you might not have a lot of control over it, I don't know if this will suits your needs.

Personally, I don't have a PI. I'm using FreeBSD. From my experience, I got nowhere with SDL, so I decided to stick with pure X11 functions and try to find a workaround. No doubt that it would be awesome if LibVLC had the FULLSCREEN feature.

If your PI system enables you to this kind of stuff, try my FULLSCREEN Workaround tip here:
https://forum.videolan.org/viewtopic.php?f=32&t=148938

Thanks guys! Well based on what you've said, it sounds like using a method where you get to draw the VLC video wherever you want, bypasses the speed optimisations that other implementations use. So I will discard the approach and forego the possibility of drawing my own text over the VLC video playback.

Well when I was trying the Python bindings of VLC (vlc.py) I saw that it plays fast, windowed or full screen, on the Pi (using SDL2!) But once the video starts playing it takes over the window completely. Fine by me. I will design my program so it doesn't need to draw text over the video once it's playing.

Domarius, perhaps you could have another window over the LibVLC window. Best of both worlds!

EDIT: Or even a child window of the LibVLC window.

Hi

Thanks guys! Well based on what you've said, it sounds like using a method where you get to draw the VLC video wherever you want, bypasses the speed optimisations that other implementations use. So I will discard the approach and forego the possibility of drawing my own text over the VLC video playback.

Just for the record, opengl / directX zero copy callbacks are coming into 4.0 but you'll need to handle this at a lower level.

Well when I was trying the Python bindings of VLC (vlc.py) I saw that it plays fast, windowed or full screen, on the Pi (using SDL2!) But once the video starts playing it takes over the window completely. Fine by me. I will design my program so it doesn't need to draw text over the video once it's playing.

You mean with X11 embedding? VLC will use the surface for opengl yes, so if you want to draw something on top, you should create another surface on top of it like fossette said. It's not as easy as wayland with x11 but it might be possible. If you find a clean way to do this, we're also very interested for the new VLC UI.

With opengl callbacks, you'll be able to get a smartly up/downscaled framebuffer instead, blit it into the main framebuffer and do the composition yourself.

Just for the record, opengl / directX zero copy callbacks are coming into 4.0 but you'll need to handle this at a lower level.

Thank you, that is good to know.

You mean with X11 embedding? VLC will use the surface for opengl yes, so if you want to draw something on top, you should create another surface on top of it like fossette said. It's not as easy as wayland with x11 but it might be possible. If you find a clean way to do this, we're also very interested for the new VLC UI.

With opengl callbacks, you'll be able to get a smartly up/downscaled framebuffer instead, blit it into the main framebuffer and do the composition yourself.

I will look into it! But as it's just a hobby project and I have to manage my time right now, I'll probably go for my "plan b" solution which doesn't require me to draw on top of the video. If I get anywhere I'll be sure to let you know.

Domarius, perhaps you could have another window over the LibVLC window. Best of both worlds!

EDIT: Or even a child window of the LibVLC window.

Thanks! Again, worth looking into, I might just avoid having to draw over the top for now though... depends how much time it might take.