Weird overlay problem

SDL Development
1

Hey all,

I have a quad head radeon FireMV card, that has two M9 chips that both
have two outputs. I managed to configure everything that Xorg works,
with Xinerama as one big screen. Now I am writing an application with
SDL that has to display two videos, one on screen 1 and one on screen 2,
I managed to do that, and in general it works. The video on screen 4 is
perfect, full screen mpeg using SDL_DisplayYUVOverlay no problem at all.
The video on screen also works but it seems that every call to
SDL_DisplayYUVOverlay causes the blue background to be drawn first and
than the actual picture, so it is blinking like crazy.

To test things i stripped down my application to be one windows with one
mpeg, and i can move the windows from screen 1 to 2 to 3 to 4, and on
screen 1 and 2 there is this blue-blinking and one screen 3 and 4 it
works fine. Before you think this is a hardware problem, i tried
mplayer, ffplay and vlc (all in Xv mode) and they play fine on all 4
screens. ffplay is interesting because that actually uses SDL.

I might have been working way to long on this but i can’t find any
differences in how ffplay opens and writes to the overlay and my code.
Also the SDL FAQ didn’t really help much, i tried about every option,
the effect stays the same.

Has anybody an idea what the problem could be, it sounds clearly like an
programming error from my side, since ffplay works, but i really am
stuck at the moment.

TIA,

Erwin

2

OK i seem to have found the problem. My application receives mpegts
streams over the network, and in those streams the actual mpegs can
change size. If the size of the mpeg is changed in need to change the
size of the overlay. Before SDL_CreateYUVOverlay i need to release the
old one with SDL_FreeYUVOverlay. At the SDL_FreeYUVOverlay closes the Xv
"connection" to the Xserver, and this causes the array of the overlay to
turn blue (or what ever the color key is). This would not be so bad
when it is in between two files (i could set the color key to almost
black), the real problem is that my FireMV can have two overlays (or
pretty much every Xinerama setup could). And as soon as one overlay is
released i get a blue frame in my mpeg movie on the other screen.

To make sure i understand right, X11/Xv-SDL was only designed to deal
with one SDL_CreateYUVOverlay + SDL_FreeYUVOverlay at the time. The code
doesn’t like it when you call SDL_CreateYUVOverlay several times without
calling SDL_FreeYUVOverlay ?

After i removed the SDL_FreeYUVOverlay calls from my application things
worked fine (apart from the obvious memory leak of course). Would it be
possible to change SDL so that it keeps a reference could on how many
times it opened a Xv connection, or maybe even just put the Xv in the
Init call? Anny comments are really welcome.

  • Erwin
3

OK i seem to have found the problem. My application receives mpegts
streams over the network, and in those streams the actual mpegs can
change size. If the size of the mpeg is changed in need to change the
size of the overlay. Before SDL_CreateYUVOverlay i need to release the
old one with SDL_FreeYUVOverlay. At the SDL_FreeYUVOverlay closes the Xv
"connection" to the Xserver, and this causes the array of the overlay to
turn blue (or what ever the color key is). This would not be so bad
when it is in between two files (i could set the color key to almost
black), the real problem is that my FireMV can have two overlays (or
pretty much every Xinerama setup could). And as soon as one overlay is
released i get a blue frame in my mpeg movie on the other screen.

To make sure i understand right, X11/Xv-SDL was only designed to deal
with one SDL_CreateYUVOverlay + SDL_FreeYUVOverlay at the time. The code
doesn’t like it when you call SDL_CreateYUVOverlay several times without
calling SDL_FreeYUVOverlay ?

Sure, you should be able to create any number of overlays.

How about freeing the first one after you create the second one?

After i removed the SDL_FreeYUVOverlay calls from my application things
worked fine (apart from the obvious memory leak of course). Would it be
possible to change SDL so that it keeps a reference could on how many
times it opened a Xv connection

If the problem really is that ungrabbing the Xv port is causing the blue
flash, then even if we have a reference count you’d still hit it:

  1. Allocate YUV overlay (ref count 1)

  2. Free YUV overlay (ref count 0, blue flash)

  3. Allocate YUV overlay (ref count 1)
    …

    -Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

4

To make sure i understand right, X11/Xv-SDL was only designed to deal
with one SDL_CreateYUVOverlay + SDL_FreeYUVOverlay at the time. The code
doesn’t like it when you call SDL_CreateYUVOverlay several times without
calling SDL_FreeYUVOverlay ?

Sure, you should be able to create any number of overlays.

How about freeing the first one after you create the second one?

The creation is not the problem, it seems, it is the releasing. And i
need two overlays because i have two videos to play at the same time,
and this also works.

After i removed the SDL_FreeYUVOverlay calls from my application things
worked fine (apart from the obvious memory leak of course). Would it be
possible to change SDL so that it keeps a reference could on how many
times it opened a Xv connection

If the problem really is that ungrabbing the Xv port is causing the blue
flash, then even if we have a reference count you’d still hit it:

  1. Allocate YUV overlay (ref count 1)
  2. Free YUV overlay (ref count 0, blue flash)
  3. Allocate YUV overlay (ref count 1)
    …

Yes i also realized that later :slight_smile: hence the mail about resizing the
overlay (source). Since the only reason i need a new overlay is because
the size of the movie changed. So the idea to add a new call to SDL to
resize the overlay without closing the Xv connection would be a better
solution.

  • ErwinOn Sat, 2006-03-11 at 14:50 -0800, Sam Lantinga wrote:
5

How about freeing the first one after you create the second one?

The creation is not the problem, it seems, it is the releasing. And i
need two overlays because i have two videos to play at the same time,
and this also works.

I am curious how this can possibly work. Nether SDL nor
OpenGL is re-entrant (arggg …). How can you have two
anythings?On Sun, 2006-03-12 at 00:05 +0100, Erwin Rol wrote:

On Sat, 2006-03-11 at 14:50 -0800, Sam Lantinga wrote:

–
John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net

6

Because a FireMV 2400 card is a quadhead card with two M9 chips, both M9
chips have one overlay. And SDL can only open one display, so with
Xinerama enabled you get a quad screen setup that has two possible
overlays, one on screen 1+2 and one on screen 3+4. And that also works
(apart from the blue frame problem). The Radeon M9 has a hardware
limitation that only allows one overland per chip, so a overlay on
screen 1 and another on screen 2 is not possible. This has nothing to do
OpenGL overlays.

  • ErwinOn Sun, 2006-03-12 at 11:56 +1100, skaller wrote:

On Sun, 2006-03-12 at 00:05 +0100, Erwin Rol wrote:

On Sat, 2006-03-11 at 14:50 -0800, Sam Lantinga wrote:

How about freeing the first one after you create the second one?

The creation is not the problem, it seems, it is the releasing. And i
need two overlays because i have two videos to play at the same time,
and this also works.

I am curious how this can possibly work. Nether SDL nor
OpenGL is re-entrant (arggg …). How can you have two
anythings?

7

I am curious how this can possibly work. Nether SDL nor
OpenGL is re-entrant (arggg …). How can you have two
anythings?

Because a FireMV 2400 card is a quadhead card with two M9 chips, both M9
chips have one overlay.

Are you saying, you’re using an overlay as a cheat,
to represent a display?

Still not sure I follow. From a software perspective:

SDL only supports one window, and OpenGL can only
work on one context at a time the API’s cannot support re-entrancy
and so can’t handle multiple objects simultaneously.

Perhaps one can forgive SDL, considering its target,
but not OpenGl whose designers should have known better.

The usual hack for this is to provide a context switch
API which of course really IS a hack, since it doesn’t
work with pre-emptive threads. Then you need to mess
about with TLS which then gets in the way again.

However the SDL API allows you to create multiple
overlay objects. So I’m intrigued how your software
including SDL is handling all this.

BTW: as an example, one may wish to have a heavily
threaded server whose job is to manage instrumentation
displays, for example an aircraft cockpit.

In that case you have multiple ‘screens’ including
probably a heads-up display, and you have lots of
data coming in to display, plus a keyboard, a joystick,
and other sensors for control.

In that kind of context, it’s rather hard to see how
you could work without a re-entrant API. What you’re
doing has the same underlying requirements: multiple
screens, multiple windows, multiple overlays, multiple
objects being drawn …

… so I’m curious how you’re working around the problem
that the underlying API’s simply aren’t capable of supporting
what you’re trying to do.On Sun, 2006-03-12 at 02:16 +0100, Erwin Rol wrote:

On Sun, 2006-03-12 at 11:56 +1100, skaller wrote:

–
John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net