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
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr