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 developers 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 CanScaleVideo(). ///< If this device can't scale the video, nothing happens. ///< To restore full screen video, call this function with a Null rectangle.

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.

Klaus