Video Backgrounds

edited February 2013 in Development
Hello all, new to the forums. Just wanted to document my experience with video backgrounds in openlp. We usually apply the video background to what is on the screen by going to media and clicking on the replace live background button as opposed to using a transparent theme as is usually recommended. This is easily done but we have had mixed results. Some videos play great in the background while others are choppy. So I started doing some testing with different types of videos and then went into testing my different themes. I can now get my video backgrounds to work without being choppy 100% of the time. The offending setting I found was in my theme itself. If I choose to apply an outline to the text of the theme I get choppy backgrounds. As long as I stay away from outlines everything is great. I can even see this happen when I have a theme with outline on the text that if I hit the Blank to Theme button, as soon as the text goes away the choppy video goes away. If I hit the button again to bring back the text the choppy video comes back.

I'm a developer by trade but have no experience with Python so I'm lacking suggestions as to how to fix it, but I thought this might point one of you fine devs down the right path.



  • Thanks for the detailed investigation @mvsaltteam, I'm sure others will find this helpful.

    An alternative is to use a transparent theme and then put VLC up behind the OpenLP display. This works well even with the outlined text.

    From a development perspective, I'm not surprised the outlines cause the choppiness. We are investigating what good cross-platform technologies are out there which we can use to improve how things are displayed. If you have any ideas, we'd love to hear them.
  • The outline choppiness is because we have to display the text twice.. one larger version in the outline colour, and then a smaller one inside it in the text colour. Therefore twice as much work.

    A more recent version of the rendering engine we use does support outline, but sadly this version completely broke support for background video for everyone on Windows. Therefore we were stuck between a rock and a hard place until such time we can redo background video support.
  • gushie and raoul I don't mean to sound mean but 2 twice as much rendering work on text really should not be the cause of choppiness alone there has to be a bug in method openlp is using.   This sound like you don't have a foreground image as a buffer independent to the video/background.

    Most people think double buffering.  What you need more like triple/quad buffering.

    Foreground buffers for all the text parts to render into.   The active buffer in the foreground buffer from that becomes the overlay buffer for the video/background this another double buffer.   This way no matter how complex the text the cpu time merging the two buffers for present to screen is a constant.  Effect of complex graphics in this case would be a little more lag.

    So yes 4 buffers is what is required for smooth to be possible.   You create over 4 buffers when you run vlc in background with a transparent theme.  Yes what is rendered for a transparent theme has to go to a foreground buffer.

    Its not like the text from openlp is animated.  So one per slide change prep the image to merge.  In fact the foreground images can be done up in advance.

    By description its falling apart because you are tempting to merge a video that cannot take lag with many individual screen draw operations.   Video has very limited time frames.  Image merge over top is normally all you barely have time for.

    gushie and rauol buffering the text processing to a foreground buffer pair means you don't need to redo this every video frame change.  That is where I think the choppiness is coming from a key buffer pair is missing.  Cost is extra cpu/gpu usage resulting in choppiness because you don't have enough time.

    Yes since you are going to have to redo the support anyhow if this is the issue its now time to fix it.
  • oiaohm,

    We don't do any buffering ourselves - we leave the hard work to the Qt4 / Webkit engine.

    However thank you for volunteering to fix this now, I look forward to seeing your code submission.

  • gushie I have to get my head around python to be able todo it.  The buffering stuff I knew from doing it in a C++ program with QT4.

    Yes I bring bad news.  QT default buffering is so so.  If you don't want flickering/lagging you are required to setup buffering  of some form inside your QT application in areas of heavy work so they can be either spun off into independent threads to the event loop or used static so not redone many times.  QPixmap x 2 at min for overlay over video/background.

    Thanks gushie I was right in what I was thinking.   Openlp contains a classic QT program bug.  Really its lucky it just choppy.

    Choppy video playback will be coming from QT default buffering.  Next frame of video is attempted to be got after the frame is completed and displayed.

    Without going a static buffer.  The other option inside QT is QWidget overlay.  Result still ends up with 4+  QPixmap buffers QT managed.   The overlay and the background in this case would get to maintain own event loop.

    Personally I normally avoid the Widget overlay path if I can.  Synced resizing is fun.

    As you can see I have not touched QT fully for a while I am not up on QT Quick.  Most of what I am thinking is deprecated methods.
  • Kia Ora 
    If it is possible for you to show us a video of you doing that would be helpful, I've tried to do it but it starts to glitch.
    Thank you
Sign In or Register to comment.