[vdr] Re: Re : Bitmap-format of OSD?

[Rene Bartsch <rene@bartschnet.de>]

Am Mon, 2002-06-10 um 19.53 schrieb Andreas Schultz:
> On Monday 10 June 2002 18:23, Rene Bartsch wrote:
> > Am Mon, 2002-06-10 um 09.58 schrieb Markus Schorer:
> > > hi,
> > >
> > > > i do have the code for that, as i was playing with dxr3 support for vdr
> > > > myself. However, it is not that easy! SPU's have only 4 colors and
> > > > vdr's main menu needs more. I belive that the best way to go for the
> > > > dxr3 cards is to implement the main menu not as overlay, but to encode
> > > > it in MPEG1 with a static background and use OSD (SPU in that case)
> > > > only for the osd parts (channel display, progress bar).
> >
> > This seems to be the easiest way, but it will need much CPU load to
> > decode MPEG2 and encode the MPEG1 with OSD from it. Won't matter on my
> > 1,1 GHz server and my client, but I also think about the
> > low-budget-people who can't afford such fast machines.
> 
> That is reason, i said "static background", MPEG1 encoding will only have to 
> happen when the menu content changes.
> 
> > I also favorize the SPU-method as MPEG2-stream with SPU is the most
> > compatible output and any MPEG-player can handle it.
> >
> > What about reducing colors ( X or Y = X)?
> 
> don't know, try to build a version of the main vdr menu that uses only 4 
> colors!
> 
> > You also said in a Mail that background is one color. Do we need a
> > background in SPU or can we drop it?
> 
> there has to be a background, always, even a fully transparent background will 
> count as color.
> the best info i could find on SPU's is at: 
> http://members.aol.com/mpucoder/DVD/spu.html
> 
> > > but as far as i know, even vdr has the 4-color limitation on it's menu.
> > > it does use multiple windows with different color-spaces to display
> > > more colors though. this should be possible with multiple spu-streams
> > > with different color-luts too.
> >
> > Maybe, but I don't know any MPEG-player who can display several SPUs.
> 
> The SPU we are talking about are DVD style SPU's, right? There is no way to 
> layer multiple SPU's with those.
> 
> > > i once had another idea:
> > > get the iframes from the currently playing video stream and overlay
> > > the osd data on these images (and display this as i-frames only).
> > > i think this should result in a quite similar effect to the way
> > > it is displayed now, without using too much cpu.
> >
> > Wrong. MPlayer does this for feeding MPEG-cards like DVB-S or DXR3 and
> > they still need 700 MHz to run it smoothly. Only MPEG1/2 is working with
> > slower CPUs as MPlayer simply passes them by. This would happen with my
> > output idea when using DXR3. But I also want to use FBdev/X/SDL  with
> > Mplayer and, of course, the low-budget-users will do ...
> 
> Something general: I do really like to have DXR3/H+ cards for output, but this 
> should IMHO be build into vdr as a plugin. I HATE the mplayer-4-everything 
> idea.
> 

I thought about a stdout solution which sends the A/V-stream with the
muxed A/V/SPU to stdin of a command-line-specified command (e.g. vdr
-options -o COMMAND (where COMMAND could be 'mplayer -vo xv -ao oss -fs'
or 'DXR3 something' ...). And when the API-structure is working we can
port it to a plugin (and add drivers to that plugin directly). I only
want to define a output-interface with data which can be decoded by
nearly everything.

Rene