Mplayer running on Polaris cards can not use the comp_yuv2 mode. Is it the fault of the Radeon RX driver? Or maybe the Radeon RX offers exactly the same video support as Radeon HD v2, just need a new customized for Polaris Mplayer compilation?
When using 6.4, check the shell output and see if it's really using comp_yuv2 or just comp_yuv (or just comp).
Altivec or non-Altivec? Does it crash, freeze, or something else? DSI/ISI? Empty window? And do test LiveForIt-MPlayer 6.5.7. It's closest to mickjt-mplayer.
@mufa
You didn't mention which version of mplayer you were trying to run, and whether it's for altivec or not. Paste all the lines that say something like "VO: [somethinghere] text here".
Version 6.4 doesn't have the same checks that later versions do.
In later versions there is a check to see if RadeonHD.chip is being used, and I suspect that check is failing with RadeonRX.
You'd then see something in the shell like:
VO: [comp_yuv2] You need RadeonHD to use this video output.
Edited by MickJT on 2018/11/5 5:33:22 Edited by MickJT on 2018/11/5 5:44:14 Edited by MickJT on 2018/11/5 5:51:04 Edited by MickJT on 2018/11/6 0:06:29
RadeonRX is feature equivalent to RadeonHD.chip v3, so composited video works fine.
@MickJT Quote:
I've not tested this (nor am I able to). I just disabled the check for RadeonHD.chip in comp_yuv2. non-altivec build.
MPlayer has a check for RadeonHD.chip? The correct way to check for composited video, is to call CompositeTags() with a YUV source bitmap and the hardware-only flag set. It'll return an error if YUV source bitmaps aren't supported.
LiveForIt-MPlayer 6.5.7 does not work. Seems to also be failing to detect the hardware capabilities correctly .
VO: [comp_yuv2] Welcome man !. gfx_nodri = 0 VO: [comp_yuv2] You need RadeonHD to use this video output. Error opening/initializing the selected video_out (-vo) device.
LiveForIt-MPlayer 6.4 cli output
VO: [comp_yuv2] Welcome man !.
Edited by Spectre660 on 2018/11/5 9:38:29 Edited by Spectre660 on 2018/11/5 9:42:23
It looks like the test you're talking about is already there. If I hard code "have_readeonhd" to TRUE (typo corrected in my source) as I've done in the test binary above, or was to remove that check altogether, it should still get to "if (have_compositing == FALSE)" and stop on machines that don't support it, however on my Sam Flex machine with a Radeon 9250SE, it passes that bitmap test, so have_bitmap_format and have_compositing are TRUE and I end up with a white window. Is the test being done wrongly?
But taking a second look I wonder if setting BMATags_Friend in the test bitmap is overidng teh requested pixel format resulting in a successful composite?
AS an aside the code is referencing &the_screen->BitMap anybosy who ever read the intuition include would know that that has been strongly discouraged since the 'dawn if time', it should be
/* VERY IMPORTANT NOTE ABOUT Screen->BitMap. In the future, bitmaps * will need to grow. The embedded instance of a bitmap in the screen * will no longer be large enough to hold the whole description of * the bitmap. * * YOU ARE STRONGLY URGED to use Screen->RastPort.BitMap in place of * &Screen->BitMap whenever and whereever possible. */
That is ofcourse aimed at the author of the code not yourself
But as I said I thnk the use of Friend Bitmap and pixelfomat will prefer the friend bitmap , especially since it occurs after the pixel format tag.
It looks like the test you're talking about is already there. If I hard code "have_readeonhd" to TRUE (typo corrected in my source) as I've done in the test binary above, or was to remove that check altogether, it should still get to "if (have_compositing == FALSE)" and stop on machines that don't support it, however on my Sam Flex machine with a Radeon 9250SE, it passes that bitmap test, so have_bitmap_format and have_compositing are TRUE and I end up with a white window. Is the test being done wrongly?
Yes, it is. If you look at the code, it's using the test_bitmap as both source and destination. The destination bitmap should be an RGBA one, and NOT the source bitmap. Since the operation is COMPOSITE_Src, the composite operation is effectively a no-op, which gets discarded.
The test call should closely match what no_clip_composite() does. Use the same operation, and render to a proper RGBA bitmap (e.g., the window itself or a friend bitmap of the screen).
My example code tests for composited video simply by blitting to the window, and checking the return code. You can fill the YUV bitmap with black before the test so it doesn't look ugly (the example code also shows how to write to YUV420p bitmaps). You can download the examples at the bottom of this page.
I'm totally clueless on any of this sort of stuff, so despite it sounding easy, I'll probably get confused on what to do. I'll look at the linked page though.
I recently died a hard disk in my Amiga. Unfortunately, I also lost your version of Mplayer, which supports Polaris cards. The link on sendspace is already expired.
Can you share this version again or just upload the upgrade to OS4Depot?
Bumping this since it doesn't appear to have been fixed.
In the meantime I hacked the MickJT exe's to work with the RadeonRX.
I'm guessing it will get the following link when approved: MickJT-MPlayerRX
And yes, I should use Emotion, but it doesn't have the fine-grained control I need when editing videos. I need my hotkeys for jumping +-/2 secs, +-/10 secs, +-1 minute. OSD with milliseconds or framecount, framestep etc. Emotion is designed to watch moves as far as I can tell and doesn't have any of these controls.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
For those having a problem with MPlayer and other things freezing on Polaris cards and Interrupts=Yes, try this hack I just made that bypasses the non-working WaitTOF and WaitBOVP functions in graphics.library.
Just start the hack in a shell. Stop with Ctrl+C. In s-s: Run >NIL: PatchWaitTOF
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++