Ive been looking for sumthing like this... 1 thing though, does it only work with tv strames?... or can it work with all video so that i can use it with the yahoo plugin or when i watch avi's
thx for this plugin! it solves lots of probs for me! just one question, please.
if i enable it, the sound in tv sounds to be a little bit hacked every 3 seconds? could this be? takes it so much cpu time? i just want to detect 4:3 letterbox format and switch to zoom then.
thx!!!
Mario
EDIT: my cpu is a intel 2,1 GHz with 30-40% load in watching TV normally.
Yes. Letterbox detection is really CPU consuming.
What you can try to do its to make the fields that the plugin checks a little bit smaller. But I guess it will not become much better. I the most cases not the detection itself is CPU consuming but the ScreenGrabber function that takes the screen shot that my plugin analyses. Unfortunately I have no influence on that grabber.
I just discovered the existence of this plug-in by chance due to it being mentioned in the EVR support thread.
As Ikuech mentioned, i created the AutoCropper plug-in that 'ships' with MediaPortal (and lives a life of obscurity in the Process Plugins section .
In general i dont think its a good idea to have multiple plug-ins doing the same or similar work unless there is a good reason for it, so i think it would be a good idea to merge with the autocropper plugin, or rather integrate useful bits and pieces of the AutoCropper into the ViewModeSwitcher as the latter seems to have the more general framework and a much nicer interface (i hate making interfaces .
lkuech:
I suppose the most usable part of the AutoCropper would be the FrameAnalyzer itself that computes bounds given a frame, since its a bit more general than just letterbox detection (in Denmark subtitles below or partly below the letterbox are very common). It might also be a bit faster, if i read your code correctly since you seem to examine alot of pixels (might be wrong though, only took a quick look at the code). Finally i have some easily implementable ideas for making it faster yet by searching for the bounds in a binary search like style, and avoiding the use of GetPixel (which is very expensive).
Btw, regarding the frame grabber, i think its performance is very much a question of the video card/ driver. The grab consists of two parts, first converting the video surface to an ARGB surface. This speed of this step probably depends alot on the video hardwares support for the StrechRect operation and the color conversion taking place etc. However, for converting the ARGB surface to a bitmap i relied on the SurfaceLoader.SaveToStream utility method which i wouldnt be surprised to discover is slow as hell. So while you dont have direct control over the grabber, i could certainly look into making it faster.