Odyssey's MediaPlayer thread

@kas1e

Is there some setting i have to change?
I don't get sound at all with the test video.

Can you share your Media settings?

hdaudio 6.23 with onboard x1000 audio chip here
everything else works fine

@Raziel
Prefs/media, tick all options.

But i agree, they all should be set by default, imho.

@smf
Yeah, for me that c-media card works evetywhere else fine, that why i think at first it's mediaplayer bug. But maybe mediaplayer just first app which use ahi in some way in which other ahi-based apps not. Hope to check today with sblive

It works well also here on my A1X1000.
I've got the impression that videos in Odyssey windows plays smoother than before now.

Thanks!
Regards,
Petrol.

Nope, no sound for me, ticked all options, "Process all frames" and i even checked the volume level in the video itself

@RazielQuote:
I originally had the same problem with the same setup using AEON enhancer pack (Don't know if issue exist without enhancer pack.) I had to go into the Sound Prefs program and change the Music Unit from hdaudio:HiFi 32 bit stereo++ to Unit0:HiFi 16bit stereo++ and the audio works fine in Odyssey and everywhere else.

Same setup X1000 using motherboard audio chip.

@kas1eQuote:
With a lot of moving the slider around I was able to get it to loose audio but if I clicked Pause, then Play again, the audio came back and worked fine. I did some experiementing and it seems that it is easier to make happen with higher resolution video's that cause more load on the system.

I tried seeking back and forth through the following video with the video set to Webm 160p and 240P. I could not produce the issue. Audio played fine. Switching to 360P Webm I could the audio to dissappear occassionally. At 480P (system struggles to play) it was easier to get it to happen. Even after audio dissappears I could pause then play again to get it back.

https://commons.wikimedia.org/wiki/File:Volcano_Lava_Sample.webm

Seems to me if the audio gets to far out of sync it stops trying to re-sync it.
This may just be an issue of the load on our systems. Might get better with optimized video player.

This is on an X1000 using motherboard audio chip, AEON sound enhancer package. Sound Prefs Music Unit set to: Unit 0:HiFi 16 bit stereo++.

@ktadd

Thanks for the hint, but with your setting the video doesn't even play back anymore.

Worst is that i cannot get any test sound out of Sound Prefs, no matter what setting
I hate this

@RazielQuote:
A couple of things to try. Do you have mixer or NemoSound being loaded in your workbench startup. I've been using mixer. I had some issues with NemoSound but can't remember the details right now. In any case, try disabling both Mixer and NemoSound in you startup if you are using them.

The other issue I've run into is that sometimes from a cold start my sound won't work at all. I have to do a softboot to get it working.

With the settings I suggested the "Play a test sound" button in Sound Prefs does not produce a sound. It will if I set it to the hdaudio: settings but not with Unit0:

If we need futher discussion on this issue please start a new thread as I believe this is probably a non Odyssey issue, since video's play audio fine on my system Wouldn't want to derail this excellent thread to much. If we find something different we can bring the issue back to this thread.

@Capehill
After rereading all the logs with Fab and his answers in 1.23 progress thread, i curious if with compositing we will be able to attach a vlayer on an existing window ?

I quote that what fab says 5 years ago when i thinking about adding real overlay for os4:

Quote:

So, even if later we will add overlay support to odyssey for fullscreen, it mean p96 overlay is limited, and it will be "Real big fullscreen" (while, with attached vlayer on an exiting window, we can have a bigger window inside of the odyssey itself, and it will works fast as expected).

Through i do not know how compositing mode works at all in terms of video layers and their attachements. As i see from the relevant code in owbbrowserclass.cpp it use cgx5's AttachVLayerTags() function, so dunno if graphics.library has something of that sort at all. In worse cas we can create "real big fullscreen" and with compositing too, but then we will need to handle switching back to odyssey window at least.

@kas1e

Quote:

Unfortunely our current p96 still never supported overlay properly, years ago i've rised an improved request in Hyperion forum in order to try "helping" Andreas Falkenhahn to implement this feature in Hollywood, i remember we have also contacted privately a couple of os4's coders asking this, but in end no luck

https://forum.hyperion-entertainment.c ... 5775&hilit=overlay#p35775

Maybe the necessity to add this in owb could be an good incentive to start doing something ... hope

Isn't compositing need to be implemented in cairo also?
If you change page zoom, up or down, CPU load hits always the 100% here, where with a no-zoomed page it is aroud 20% CPU load.
Same goes for video zoomed by the player itself.

A small video

Regards,
Petrol

@kas1e

Compositing in graphics.library is similar to blitting, with source and destination bitmaps. Some links:

http://hdrlab.org.nz/projects/amiga-o ... on-hd-driver-version-2-x/

https://wiki.amigaos.net/wiki/Graphics_Composited_Video (Hans already seems to have posted this)

@Petrol
Quote:

Frederik already adds something in his Cairo port, but it uses a new amiga-native surface for Cairo, while Odyssey uses the image-surface of Cairo (more general surface available everywhere by default). Surfaces, of course, different and need to be initialized, etc differently. They're not that much code in the Odyssey about Cairo in general (i just search over all .h and .cpp/.c files of odyssey on Cairo functions), so it probably can be changed from image surface to amiga surface Fredrik made, but then, I do not know how Frederik changes will help or not for Odyssey. I.e. will it improve rendering speed in whole or not.

Fredrik says that about his port: "There is some h/w acceleration if you use AmigaOS surfaces to draw into. It is just solid-colored shapes though, and if you enable anti-alias only drawing of rectangles is h/w accelerated."

You can see all the code-commits on his work here: https://github.com/salass00/cairo_lib/commits/

I do not know if his work is ready to be used for Odyssey, and will it or not bring any benefits to what we have now. Probably need to check what Cairo does in Odyssey in general, i.e. how it blit stuff. If it blits by "solid colored shapes" or "rectangles" or what Fredrik mean (as I not very well understand it, is it rectangles ? or only colored shaped rectangles ? And what did it mean ?:) ) then we can try to reuse his version of Cairo and have speed up. But it will work only for those who have compositing, as his Cairo port (as can be seen from comments) accelerated via compositing (if I got that right).

What we want to do now, is: usual "window" of MediaPlayer still will be the same as it now (same slow). But when you hit "fullscreen" button, then a window will be much bigger, taking all "rendering" area (but you will see navigation buttons, etc, it still will be an odyssey window, if I understand that well, and if I remember right how it was/is in morphos), and will be hardware accelerated => all will be fast.

Why the same acceleration can't be done for pure small window: I do not know, probably because it too much tied to Cairo-functions and whole blitting of elements we see in render-window done through Cairo when you see more than just video.

Best way of coures is to have "image-surface" be compositing accelerated and all amiga-native stuff hides under the hood. But we don't have that.

Anyway, that all to be seen. Firstly we need that pressing on "fullscreen" in MediaPlayer over that link: http://html5videoplayer.net/html5video/mp4-h-264-video-test/ , will start to change anything like creating a new blitting area of any size and render stuff via compositing to it.

Quote:

Yeah, there compositing will help, but then, how Odyssey render fonts? Probably not by "rectangles", but just as Font. It means then that this is another area that needs compositing acceleration.

In other words, we need to understand Cairo internals in Odyssey better: how it blits things to the page, how it blits fonts, how it blits anything. Maybe there just some general blitting, like rectangles all over the place, then that will be good. But if it renders everything differently: font, video, other Html/dom/java elements, then that some black hole! :)

@Capehill
So it means we can use compositing in any "rectangles" in any area of any app/screen, just choose the size and do blit to. Kind of better in comparison with cgx5's video layer attachment then? Or at least give users the same ability to choose where we will draw the stuff?

@Capehill
Btw, i check how "fullscreen" handled on morphos and that not "real fullscreen in full size", but "full screen in the whole rendering window of odyssey" (so to not have any cairo elements, but still have tabs, navigation, etc, so no needs to recreate a wheel with handling tabs/arrows and stuff).

There is video from my peg2 and odyssey on morphos running mediaplayer on that html5 test page, and swith to fullscreen / back (sorry for jumpy quality, seems my radeon9250 in peg2 a bit weak to be handled by video-recoder properly, but things are visibly)

https://youtu.be/9iZyMH0znLk

See there when we switch to fullscreen, it swith to whole rendering window (that the part in the owbbrowserclass inside of DEFSMETHOD(OWBBrowser_VideoEnterFullPage) method. Not to real-big-fullscreen, but swith to fullscreen of rendering browser window. Which is quite good too, of course and looks tasty.

With Vicente (Ami603), we tried yesterday and today to replace in the BCMediaPlayerPrivateMorphOS.cpp "struct image *imgResize(struct image *image, int destwidth, int destheight, int filter) " function to compositing. And while we very able to do so, it give absolutly no benefits in speed , because it still the same "cairo slow things down".

So the only way probabaly which we can for real implemented at moment with mediaplayer, is that this fullscreen in the owbbrowserclass, via attaching compositing layer the same as done on morphos with cgx5 overlay.

You can see on video its for real speed things up on peg2 for real. Video start to be smooth and all fine.

Probabaly the only thing we can made to speed up video playback inside of browser when it placed together with other web elements, its to find out in Odyssey itself which Cairo functions are used to blit stuff mostly and which are the most time consuming, and add there (in Cairo), for image-surface compositing support. Then we can speed up everything.

But in time being we can add fullscreen only, it seems doable and at least with cgx5's overlay it surely show that things will be faster.

And as i can see, you can resize with overlayed fullscreen odyssey window as much as you want together with overlay window, so you can made real fullscreen as well (via resizing max and pressing f11)

@kas1e

I am not familiar with the code yet but I think we need to find (maybe you know already) the code which decode YUV to RGB and apply compositing to do the heavy lifting for us. Is this done by Cairo library?

Do we have the complete MorphOS OWB source code? I tried to search (using GitHub) where OWBBrowser_VideoBlit is called but cannot see.

@Capehill
Quote:

Can it be that overlay take care about converting from yuv to rgb ?


Quote:

Conversion of YUV to RGB ? Don't know. Maybe done by FFMPEG itself , or by that acinerella.c wrapper or BCMediaPlayerPrivateMorphOS.cpp

Or maybe indeed Cairo (which also use Pixman-1, library which Cairo use). I found some interesting discussion about in 2011 there: https://lists.freedesktop.org/archives/cairo/2011-March/021791.html

Cairo library which we use in Odyssey now pretty easy to build, if there will be needs i can make how_to_build_cairo instructions if we will try to add compositing there.


Quote:

Yes, that one on github are complete MorphOS OWB 1.23 source code + amigaos4 ifdefs/some fixes. I think it still can be build for Morphos as well, as everything done via ifdefs.

Quote:

It's in our belowed main mediplayer's file: BAL/Media/WebCore/MorphOS/BCMediaPlayerPrivateMorphOS.cpp , see void MediaPlayerPrivate::playerPaint(void *c) fucntion.

Basically _everything_ about mediaplayer in BCMediaPlayerPrivateMorphOS.cpp (and acinerella.c in the same direcotry, but this it just ffmpeg functions wrapper). Just some part about fullscreen switch in owbbrowserclass.cpp, because its probaly was easier to handle it here, to make fullscreen be in the "full rendering browse window". Because as Fab says years ago, making "real big fullscreen" will mean one need to take care about handling everything again (like keys/tabs/stuff, which will be mess). And so better to have it just inside of odyssey render window, just bypasing any cairo usage. Because when we play video in a window together with other elements, its all done by cairo and even if we will add compositing in the video part : it all still will be the same slow as it cairo slow things down. The only way for faster playback in the small window together with other web elements, its add compositing to Cairo , exactly for image-surface only. That also will speed up everything too. But for first probabaly "fullscreen" realisation will help and we will understand how things works.



EDIT: github's search functionality suck, it didnt' find it for you because it used as MM_OWBBrowser_VideoBlit (name changed because of macroses/methods/classes name differenes , see MorphOS/include/macros/vapor.h).

@kas1e

Quote:

I don't know, VideoBlit code rather suggest copy from YUV to YUV so maybe CGX handles it or GPU can display YUV directly. I'm not familiar with either overlay or CGX.

At the moment I have more questions than answers but now I at least have an idea where to continue from (with compositing).

Quote:

Ok, thanks. This function suggests that either drawing is done in VideoBlit (accelerated) or by Cairo.

@Capehill

Quote:
With old fashioned overlay, the overlay hardware handles the YUV=>RGB conversion. The overlay bitmap can be YUV.

This is the exact point where you should do the YUV=>RGB conversion. Here's how to do it efficiently:
- Copy the YUV bitmap to another YUV bitmap in VRAM (following the CompositeYUVBlitStream example I linked to in post #2 of this thread)
- Use CompositeTags() to do the YUV=>RGB conversion when blitting to the screen

Hans

@samo79

Quote:
Forget overlay. It's old, obsolete and newer graphics cards don't even support it any more. Other platforms use "textured video," and we have "composited video."

Unlike overlay, composited video can blit YUV bitmaps directly into a screen or window's bitmap (doing YUV=>RGB and scaling on-the-fly). This effectively sidesteps the "cannot attach a vlayer" issue that Fab talked about years ago.

Hans

@Hans
Quote:

Just to note that "cannot attach a vlayer" issue is, of course, P96-overlay only, CGX5-overlay on Morphos can do so of course. So it and overlay old and abandoned, and P96 old and abandoned :)

Btw, are compositing supported by older cards we have like radeon9250, etc? If I remember right it supported as well? (i mean adding compositing acceleration will work everywhere and on new Radeon, and on old ones) ?

Quote:

Just to understand it more, you mean "Use CompositeTags() to do the YUV=>RGB conversion when blitting to the screen" is that "yuv=>rgb conversion and scaling on the fly"?

I.e. just using CompositeTags() by itself mean YUV->RGB conversion will be done, and programmer need to not worry about, and not specify any special flags to fucntion about ?

If so that cool indeed!