Odyssey's MediaPlayer thread

@kas1e

For simple refresh with compositing disabled you have to refresh any custom rendering you have done to the window on receiving a IDCMP_REFRESHWINDOW message (this happens when previously hidden parts of the window are revealed).

See "Refreshing Intuition Windows" on this page for more information.

An easier but more memory hungry solution is to set the window to use the smart refresh method.

@Salas00
SMART_REFRESH looks like what we need there ! I assume "more memory hungry" mean just a very little? At least in terms of browser on today's hardware.

Will try to find out how to set SMART_REFRESH to mui window in odyssey.


EDIT: Oh, MUI preferences have settings for : Prefs/Window/RefreshType , can be "smart" and "simple". Yeah once i set there "smart", then with compositing being off there no that effect i show on video.

But all of this mean that probabaly indeed there no nees to worry about. If anyone by any unknown reasson wish to disable composite effects in prefs/gui, but have compositing video works in odyssey, then they can just use "smart" refresh type in the MUI settings for Odyssey itself.

Thanks for explain on that issue :)

@kas1e

Yeah, just use the code if it works. I haven't had time to test looping but I think it's not related to AHI code, unless some difference in buffer sizes plays a part. AHI code itself doesn't have media looping feature, it just plays the audio that is fed to it, alternating 2 smaller buffers.

@Capehill
Yeah, merged: https://github.com/kas1e/Odyssey/commi ... 7bcf38122e6ef994e503406e4

Another issue i find which is interesting as well (not related to audio) : when we in fullscreen mode, and then hit f11 , i can see left border of the window 1 pixel size. While right border and bottom border (when hit middle mouse button to hide gui of player) not visibly.

So, to workaround this, in the owbrowserclass's DEFMMETHOD(Backfill), i add "-1" to all MinX, like:



And left line are gone. But i need to understand what happens, and is it bug somewhere in OS or in Odyssey's MUI code.

I do test morphos version, and there i can see and left border, and right one, and even bottom one when hide gui of player via middle-mouse-button. And their code for backfill are:



So they have +1 everywhere as well, and no -1. So at least "left" border line visibly in both cases, that ok, but then why we didn't see right border line and bottom one in os4 version.

Maybe CGX's FillPixelArray() vs graphics's RectFillColor() have differences in that terms ? Or just when things render to overlay window over CGX it somehow different, and +1 added there for some their reassons ?

I remember initially when we start to remove CGX support, you firstly remove those +1 things, maybe for reassons too ?

In other words, i can just add -1 everywhere, so no left border line will be visibly, but want to understand why there differences between os4's and morphos's ways.

@Kas1e

In fact what you see on the left side is the shine border of the window.
If you take a screenshot of the player in fullscreen mode, you'll see it at the top also! You'll see the shadow border too on right and bottom of the screen, but as they are black, the are merged with the window background and screen border, less visible.

Maybe offset code need to be adjusted.

@Petrol
Quote:

Of course is it border of window. That what i talk about (sorry if wasn't clear enough in previous post).

Quote:

You mean under the tabs ?


Quote:


Hm interesting.. On morphos all the border's of window visibly (and right ones, and bottoms ones). Maybe that something about shadow effects enabled when compositing effects enabled .. Need to check that one too.

Quote:

Firstly need to understand how it was supposed to be at all and if there is no bug somewhere and why there differences with morphos's look where they have borders visibly everywhere.

@kas1e

Look at this picture.

@kas1e

FillPixelArray seems to use width and height params, while RectFillColor needs maxX and maxY instead of.

To cover 100*100 window, using FillPixelArray we should use something like 0, 0, 100, 100. Using RectFillColor we should use something like 0, 0, 99, 99.

Found the commit: https://github.com/capehill/Odyssey/co ... 0eccd192768fde90a9daa8e0c

I guess my assumption was that those coordinates are correctly calculated. I haven't checked has the calculation code changed since that.

@kas1e

Found probably a bug in video menu
When you right click in a video, the options "mute" and "unmute" doesn't switch correctly ...
The "unmute" seems always selected whetever you enable or disable the audio on the fly

@samo
Tested on that "html5videoplayer.net" toystory test, and there all fine for sure. Through i don't have any "unmute" option in RMB menu. It always named "mute", but i can see how it switch mute/unmute in the player's control panel.

@samo79

IIRC, the images on "resources" drawer are fixed on kas1es' latest betas archives.
Try to unpack one of latest beta to RAM:, run for RAM and see if there is everything ok.

@kas1e

Tested on this video:

http://www.html5videoplayer.net/html5video/mp4-h-264-video-test/

By default the audio is of course activated, so i can see the "Mute" option in menu when i do a right-click into a video ...
Then if i click on it, i can see that even graphically the button of the audio will be pressed, and the audio will muted as it should be

But if i open again the menu to reactivate the sound, menu still showing the same "Mute" option instead of the "Unmute" one as it logical should be

Definively that menu should handle both "mute" and "unmute" options in menu, atleast that 2 options are in the catalog

@Javier

Quote:

The images are both present and owb will switch correctly between the two, the activated and the disactivated one
Problem is only the option in menu that will not be updated .. only the muted still

Here the both options availible in owb.cd

Quote:

So, or this thing was never worked/finished by Fab, or is there a bug somewhere in our port ?


P.S.
As a reference check how it works for the "Play" and "Pause" mode
That two options will cycled fine in between .. mute and unmute should works in the same way

@samo
Yeah, menu always show only "Mute" option. Need to check how it on morphos to be sure if that the same there or not. But anyway, even if it the same (and probably is it), that can be deal with, yes.

@kas1e

Not sure, but maybe such strings are in "..\BAL\Internationalization\WebCore\MorphOS\BCLocalizedStringsMorphOS.cpp"

String localizedMediaControlElementString(const String& name)
{
...
}

@kas1e

Ok, meanwhille i opened a ticket on github so it will not forgotten

@kas1e

Can you check this branch https://github.com/capehill/Odyssey/tree/fix-rectfillcolor

I just removed those +1. If you decrease the minX, you will overwrite something on the left. Also if you +1 the maxX, you will overwrite something on the right.

@Capehill
Quote:

Now it seeems the same as on morphos : all borders visbily, left, right and bottom ones. Through left one seems 2 pixel width , while bottom and right are one. But it mean that you were rigth about differences with fillpixel and rectfill


But now, after we understand that its just initially programmed like this, i assume when we want watch a fullscreen video (real fullscreen), then we don't need any borders, rigth ?

Quote:

Yes, that the point : we specially need to add -1 and +1 everywhere , so to overwrite borders of the main window (only when we watch video in fullscreen, yep). So, video will looks better, like real fullscreen.

But question is : can we do so like this, or there something bad can be possible because of that ? Like some different themes which have different border size of windowses, etc. Or maybe overwriting it like this just trash memory, etc ?

@kas1e

Quote:

Wouldn't it be better to open a borderless window that covers the whole display, instead of drawing inside some MUI object?

Quote:

https://github.com/kas1e/Odyssey/blob/ ... owbbrowserclass.cpp#L3729 Area comes from the backfill hook message. I think we are not supposed to exceed the boundaries. On the other hand, damage should be only cosmetic.

@Capehill
Quote:

Yeah, but are we open new window when hit f11 ? Or just resize original one ? We only need borderless window when hit f11 (and when we in video fullscreen mode)

Will be indeed good to have border less window when we just hit f11. It through will still have tabs on top (dunno if we can hack it somehow to hide them when we in f11-fullscreen, because they there for reassons probabaly)

It also will be good to catch if we in fullscreen video mode when hit f11, and then after 2-3 seconds of inactivity mimic video-player behaviour: hide mouse pointer and gui of player (that one hided when we hit middle mouse button) and back it all when move mouse or switch back to window mode.

I asked Frank how he do this in Emotion, and in mainloop he did:

int64_t curTime = gettime();
int64_t diffTime = curTime - startPosTimer;
performeControlWindow(diffTime);
startPosTimer = curTime;

Then in performeControlWindow he move control window up
(IIntuition->MoveWindow(controlWindow, 0, -2) or down
(IIntuition->MoveWindow(controlWindow, 0, 2)).

The diffTime counts up an internal timer variable, this timer is reset when the user makes an input. If this timer variable reaches 2 seconds, the window moves down and when
it reaches the end position, code hide the window and pointer:

IIntuition->HideWindow(controlWindow)
IIntuition->SetPointer(windows[WID_MAIN], EmptyPointer, 1, 16, 0, 0)
(EmptyPointer points to a 12 byte memory area cleared with 0)

If the user makes an input than:
IIntuition->ShowWindow(controlWindow, windows[WID_MAIN])
IIntuition->ClearPointer(windows[WID_MAIN])
window moves up