Rain Video

[Yincognito]

Updated Rain Video to V 1.2020.09.25

CHANGES
Added New action buttons (action when button is hovered by mouse)
Button visibility can be toggled so only the video shows
Video window can be moved while video is playing (it will remain 'unlinked' to skin position) See next change...
Added 'MiddleMouseUpAction' to refresh positioning (Do this after moving the skin window; this will realign the video window with the skin)
Added 'Refresh Position' to Context Menu
Added 'Repeat' toggle button

First post updated with preview images, links, and code

Very nice! I'm not sure executing the actions on hovering the Toggle Actions areas is the best idea - you get things dissapearing and running wihout an obvious reason, especially if not familiar with how the skin works. Doing them on click might be more natural, after all one moves the mouse a lot on the screen in a normal usage scenario, and hovering over one of those buttons by mistake is a possibility.

[eclectic-tech]

@Yincognito & dvo

Thanks for the feedback, I appreciate your thoughts.

Hover versus Click

As stated earlier, the video window and skin window are completely separate Windows objects. Neither one knows about the other and there is no interaction between them using this method of viewing and control.

In order to have button controls that do not require clicking the FFPlay window first to give it focus, I use an add-on to send key codes without changing focus away from the FFPlay window. The buttons send these key codes to the active window (FFPlay) to achieve the desired action:

ACTION | 'KEY'
Quit Video | 'q' or 'ESC'
Toggle Play/Pause | 'p' or 'Spacebar'
Frame Step | 's'
Back 10 sec | 'Left-Arrow'
Ahead 10 sec | 'Right-Arrow'
Toggle Full Screen | 'f' or 'Double-Left-Click'
Select Stream | 'w'
Vol Up | '0' or 'Asterisk'
Vol Dn | '9' or '/'
Toggle Mute | 'm'

The FFPlay window MUST have focus to respond to the viewer's requested button action. By using hover as the action trigger focus is maintained by the FFPlay window and does not change. Any mouse click outside of the FFPlay window changes the focus and those buttons no longer send the code to FFPlay, but instead, the code goes to the currently active window (which can produce undesirable actions).

Hovering over the top button, toggles the visibility of the entire list of actions.
This removes the possibility of accidentally activating an action or sending a key code to a different window. Rather than having a constantly visible 'Menu' button, I chose to hide the entire button list (my preference). You toggle the visibility by hovering in the upper-left skin area. I am thinking of hiding them after any hover action to prevent inadvertent actions.

I may change this but my reasoning was to try to achieve button controls, while not changing focus, and also reduce the chance of accidental button actions by toggling their visibility which also leaves an uncluttered view window.

An interactive plugin would allow a more conventional interface; this method is my workaround. Ideas an thoughts are welcomed. Thanks.

[Yincognito]

In order to have button controls that do not require clicking the FFPlay window first to give it focus, I use an add-on to send key codes without changing focus away from the FFPlay window. The buttons send these key codes to the active window (FFPlay) to achieve the desired action.

Ah, yes, forgot about that - it makes sense now. A workaround to allow clicking instead of hover would be to "store" the name of the FFPlay active window first, normally use LeftMouseUpAction to get the user's "intention", activate back the FFPlay window based on the stored name, and send the key normally to the recently activated FFPlay window using the send key addon. This would be a bit too complicated though, so the hover action is probably the best solution that doesn't involve having to deal with other issues, and quite ingenious.

[eclectic-tech]

One last update ... V 1.2020.09.27

The skin will only send codes when FFPlay has focus
The buttons have been spaced for easier use
The buttons will 'grey out' when FFPlay does not have focus to indicate they will not work
I expanded the information on the use of the player in the first post
Updated the MediaFire link and the code in the first post

Preview

rainvideo5-1.jpg

[eclectic-tech]

would it be handy to use ffmpeg so you could use chromakey to set transparent and boderless is already in ffplay .. just a idea...

I went a different way with V 1.2020.09.27a by creating separate skins for controls.
This solved the issue of control access in full screen mode; these skins are set to 'Stay Topmost'.
This also let me design other control styles: 'Text' or 'Buttons' (for now) and the end user can arrange the buttons horizontally or vertically.

Update V 1.2020.09.27a

• Separated the control skins from main player; control skins stay topmost and can be positioned anywhere on the screen
• Created a new image 'Button' style controls, 'Text' buttons style is still available; select style from the context menu
• Changed control actions: removed 'full screen' (double-click video to toggle), combined volume up/down as SCROLL actions when hovering
• Added Accent color awareness using SysColor plugin by Brian Ferguson
• All graphics will adjust color based on Windows Accent color; color is based on you main screen wallpaper colors

Since the player now uses multiple skins, I suggest downloading the RMSKIN package from first post.

Preview

rainvideo5-4.jpg

rainvideo5-5.jpg

[Yincognito]

i will test it today .. is ffplay a extention of ffmpeg or are they diffrent ? ffmpeg got a lot of functions like green screen maybe handy to use
with rainmeter in combi with borderless ...
buttons losing focus they got gray instead of white and are not responding if they are light gray ...
had to click on movie to get focus again.

Both ffplay and ffmpeg (and also ffprobe) belong to the same "package", called - you guessed it - FFmpeg. In a nutshell:

- ffmpeg handles processing the media (e.g. extractions, conversions, muxing, demuxing, etc.)
- ffplay handles strictly playing the media (i.e. no other functions besides that, pretty straight-forward)
- ffprobe handles getting all sorts of information on the media (e.g. durations, audio/video/subtitle streams info, FPS, bitrates, etc.)

So basically doing things through ffplay (eclectic-tech's approach) is recommended, easier and lighter on CPU if you just want to play the video. Doing things through ffmpeg (my approach) is trickier, more difficult and heavier on CPU as you have to simulate cursive "playing" yourself, which almost certainly leads to some issues. The ffplay approach has no drawbacks other than not being able to provide 100% integration with Rainmeter, e.g. windows being different, controlling done by keyboard, no graphical "overlay" possible on the video, etc.

Bottom line, eclectic-tech chose the best option for this - it's pragmatic and straight to the point. My desire was to achieve "full integration" with Rainmeter (while also taking advantage of the extensive list of features in ffmpeg), but as you can see if you test my approach, while definitely possible, is not that easy to get it right.

[Yincognito]

your approach is heavy but it would be for me the best option, about the light version (it's oke for use for a movie)
i'm more for the options version so you could use it and blend it in the background (with chroma option)
if i make something with AE this would be nice to use the effects of it in RM.

Ah, I see - you're looking for some post processing as well. Yeah, my approach would be suited for that, as ffmpeg can do LOTS of things with the output. I took a break from developing this for a while (seeing how well eclectic-tech's approach evolved), but knowing myself I'll probably get back to it once I'm "in the mood". Right now I'm dealing with a solar system simulator, so probably once I'm done with it will look at other projects as well.

[Yincognito]

there where some projects with arduino that solar collectors will turn to the light or are you making it big ?

Haha, no - it'll be just an animation of the solar system, not a microchip...

[Yincognito]

oke you have many solar options.... yours is the solar system that's a big job :P

Yep, too big to fit properly.

[eclectic-tech]

...
buttons losing focus they got gray instead of white and are not responding if they are light gray ...
had to click on movie to get focus again.

Yes, that is the way it works; when the video window does not have focus, only the 'Toggle Controls' button will work.
This prevents the control skin from sending the action keys to any other focused window.

In order to allow placement of the controls any where on the screen I opted to not disable mouse actions in the control skins. This action removes focus from the video window. Because the controls simulate key presses, I disable them until the video window regains focus. That is also why the buttons activate with MouseOverAction rather than mouse-clicks so focus is maintained by the video window.