On 28.11.2012 10:41, Lucian Muresan wrote:
Hi there,

let me start with the background of this, in the last few weeks, a very promising new 
true color skin raised some attention on the german speaking VDR-Portal, namely 
"nOpacity" ([1] and [2]). The layout of some of the screens quickly brought up 
the idea that it would be nice to have the video
properly scaled to the available size (smaller than the actual screen), which I tried to 
already patch with some (but only some) success ([3]). The patch is based on an old hack, 
called "YaEPG patch", which introduces a member of type tArea in cOsd, which 
then can be filled with geometry
information, whose "bpp" member is abused as a hint weather or not to scale by 
some skin or plugin which wants to scale down the video material, and you got it, it's as 
ugly as can be. The problems which we encountered where that the output plugin (in this 
case softhddevice) knows much more about
the video material (like if it is for example 4:3 letterboxed, if the user 
selected some zooming, some cropping, and so on) than a skin or any other 
plugin can cope with, in order to get the video scaled right, and there are 
cases where the scaling is simply wrong. It is and should remain the job of
the output plugin to do this right with all the information it has access to, other 
plugins should only have to ask them to "properly" scale inside an available 
rectangle, possibly with the hint to just scale (back) full-size of the output device 
(which could also be an X window).
Now, my question, is this issue worth an API extension in cDevice, for example 
something like

bool ScaleVideo(tArea availableRectangle);
bool ScaleVideoFullScreen();

which could return true only if the output plugin is capable of doing this, or 
should plugin developers rather agree upon a custom service which output 
plugins may provide and skins or other plugins may ask for?

I think this should be done by cDevice and not by some obscure "service" plugin 
happen to agree upon.

The interface I would suggest looks like this:

  virtual cRect cDevice::CanScaleVideo(const cRect &Rect, eTextAlignment 
Alignment = taCenter) { return cRect::Null; }
      ///< Asks the output device whether it can scale the currently shown 
video in such a way that
      ///< it fits into the given Rect. If the scaled video doesn't exactly fit 
into Rect,
      ///< Alignment is used to determine how to align the actual rectangle 
with the requested one.
      ///< The actual rectangle can be smaller, larger or the same size as the 
given Rect.
      ///< Returns the rectangle that can actually be used when scaling the 
video. A skin plugin
      ///< using this function should rearrange its content according to the 
rectangle returned
      ///< from calling this function, and should especially be prepared for 
cases where the
      ///< returned rectangle is way off the requested Rect, or even Null. In 
such cases, the skin
      ///< may want to fall back to working with full screen video.
      ///< If this device can't scale the video, a Null rectangle is returned 
(this is also the
      ///< default implementation).
  virtual void cDevice::ScaleVideo(const cRect &Rect = cRect::Null) {}
      ///< Scales the currently shown video in such a way that it fits into the 
given Rect.
      ///< Rect must have been retrieved through a previous call to 
      ///< If this device can't scale the video, nothing happens.
      ///< To restore full screen video, call this function with a Null 

eTextAlignment is somewhat abused here, maybe we should rename that to a more 
general eAlignment.
Since this API extension doesn't have any further impact on any existing VDR 
functions, I would
be willing to add it even before version 2.0.


vdr mailing list

Reply via email to