Odyssey's MediaPlayer thread

@kas1e

When I comment out proto/cyber*, there aren't that many compilation errors, so maybe it's enough to cleanup the browser class at first.

It's best to start a separate git branch for each change and merge to master when done. Branches are great for any experiment.

It might be a good idea to copy the original file for reference as you wrote, and eventually remove all those #ifdefs in the current version. Then file becomes much more readable too.

@all
Ok, with an original file which I show few posts before, and with hacking inline4/cybergraphics so to not use CGX'x lock/unlock bitmaps, but graphics' library one instead, it actually starts to works and didn't crashes, but not in the window and not of the size it should be.

See screenshot (press open in fullsize):



See the image at the left upside of the screen , near of URL-bar, and of very small size. This is a video which is works/plays/etc. Just small one, and scaled wrong.

So it means probably something about left/right stuff borks.

That all without Hans's code, so will try with them.

EDIT: with Hans's code things worse. The same small image, but inside I can see more distortion than with original Ami603's code. But I assume now it should be just a matter of correct left/right/x/y values?

@all
Can't resist to show some almost_done progress done by Ami603 :

https://youtu.be/6YsWkRIXfP8

@kas1e

HOOT !

@kas1e

Cool!

Could it be possible to do fullscreen using the same method?
It could draw a black window with the video scaled over, no?
Otherwise, Fullwindow is a really nice improvement ;)

Keep up the good works guys.

Regards,
Petrol.

@Petrol

Please one step at a time :)

@Petrol
Quote:

That fullwindow already can be fullscreen: just once you hit fullscreen button, hit then "f11" and you will be in fullscreen without window title, links, url-bar and stuff. Through some little line will be visibly (name of tab at top), and control panel at bottom, but at least you will have no needs to resize anything manually.

@All

Ami603 run out of time today, so there is today's version we have:

http://kas1e.mikendezign.com/a/owbbrowserclass2.cpp

Issues we need to deal with at moment can be see on the video few posts above ( https://youtu.be/6YsWkRIXfP8 ). There 4 of them:

1. when move window we flicker
2. aspect ratio (see when we resize video resized wrong)
3. when move outside of left screen (at least left), we have no clipping so some mess on screen.
4. sometime some "black line artifact" appears: http://kas1e.mikendezign.com/aos4/mediaplayer/artifact.jpg


So any help for any of those 4 issues are welcome

@Capehill

So how should we go, just rename owbbrowserclass.cpp as we discuss previously, and in new one remove all ifdefs , etc, just keep only amigaos4 necessary parts ?

Also we need somehow to deal with that CGX stuff in that class. Have you motivation to do so ?:)

@kas1e

Quote:

Are you using a 'legacy parallel' PCI sound card?

I recall an thread about ethernet cards for the X5000 where someone said
that the bottom two PCI slots don't support DMA transfers (can someone confirm this?)
and that it was actually faster and less CPU intensive
to use a PCI Express card even though it uses the exact same PCI chip connected to a PCI to PCI Express
bridge.

There are PCI-E soundcards based on the CMI8738 if the Soundblaster Live! doesn't work out for you.

btw thanks for the updates :)

@kas1e

Quote:

Git repo stores the change history, so it's safe to remove all unneeded code. I would personally do that but it's your project :)

Quote:

Not really but I can try :)

@kas1e, Ami603 & Capehill

Nice progress!

Looking at the problems to fix:
Quote:

What RastPort does _rp(obj) get? Is it actually drawing to the window's bitmap? Or directly to the screen? It looks like it's drawing directly to the screen, or it wouldn't be able to draw outside the window on a screen with compositing effects enabled. That's going to cause flickering when moving, because the intuition.library will be using the window's bitmap to overwrite yours.

Try switching to using the window's rastport instead (OWBBrowser_VideoBlit() has a window pointer). Or, at least double-check what rast-port _rp() gets.

Also, the code should use DoHookClipRects() to composite into the rastport rather than to the window directly (see fillWindowWithBitMap() in CompositeYUVBlitStream.c from the examples I linked to). Doing so will make sure that the rendering is clipped correctly, including on screens with compositing effects disabled. Otherwise, you might draw over something you shouldn't.

Hans

@Hans

Here is some code that was based on your examples: https://github.com/capehill/Odyssey/tree/compositing-experiment

It's not finished of course, supports only 420P, centering of video missing etc.

Awesome progress!!

@all
Some good progress! Thanks to advice from Hans Ami603 fix issues with clipping and flicking, and then we were able to fix aspect ratio correction and all that stuff. Check this out:

https://youtu.be/nna0togcUmI


Plz, if you like the work on this, consider to made donation to Ami603: ami603@terra.es

Also, plz consider making a donation to Capehill at juha.niemimaki@gmail.com , he did a lot too with all that Odyssey stuff now.

So, as you can see on video (especially on youtube), that while we in window mode I hit 100% CPU loading, but when I switch to full screen on the same videos, then it usually 50-60% of loading max.

With "toystory" it also in window mode can hit around 70%, while with fullscreen 40% is max, sometimes even 20.

Probably things can be optimized of course more (as always) but its already pretty good.

Things which still need to fix:

1). When we switch to another tab, video still plays
2). When iconify back from fullscreen, it's iconified to window mode.
3). Need to add checks on the possibility of compositing, and depend on that use it or not use (to avoid crashes on machines which didn't have that).

There is a current file:

http://kas1e.mikendezign.com/a/owbbrowserclass3.cpp

@Capehill

Do you think it is there needs for you to check Ami603's version as one more reference? We just want to make everything clean as possible of course, so if we can mix your and Ami603 work together that will be cool.

I also dunno if Ami603's version does support other than 420P, but I assume it does, as everything I tried works.

@kas1e

Good progress indeed :)
I wonder if we can solve also the blocking audio hardware issue, for now we are limited to the AHI music unit only, so there are problems with multiple audio outputs, this is pretty annoying

@kas1e

It seems that there isn't that much CGX usage after all? Most of it is in the browser class and that's dealt more or less? Started another branch which mostly removes the CGX use: https://github.com/capehill/Odyssey/tree/use-graphics-library (needs review)

I have some doubt regarding WritePixelArrayAlpha, not sure how exactly the global alpha is applied: https://aros.sourceforge.io/documentat ... elopers/autodocs/cgfx.php

So there might be some visual issues but maybe CompositeTags can be used in case alpha blending is needed.

Ps. haven't had time to check your latest patch but video looked nice!

@samo79

I'm not sure why Odyssey uses the low-level / library functions instead of device API. Are there some historical reasons?

@Capehill

Readme of Odyssey says:

Quote:

@kas1e
Quote:
Don't forget to donate to Kas1e as well.

Kas1e's PayPal Link

Caphill's PayPal Link

Ami603 - Couldn't find direct PayPal link. Use email in Kas1e's post above.

A big THANK YOU to all!

@samo79

Even that workround makes my hardware don't play any sound, neither with the "Test Sound" button nor with HTML5 audio.