As Liveforit says "H.264 does not take advantage of DRI."
I totally missed this. It's a bit disappointing that one of the latest codecs doesn't support direct rendering. Hopefully the mplayer/ffmpeg team will fix this in a future update.
Before merging P96 into other libs making it native, did you think about it's design first? Meaning is the P96 was the best way to implement RTG or is it just a first step for compatibility with a "plan" to improve RTG later?
"I can only say that I'm very much looking forward to this. While I can't use this for debugging graphics drivers, it will be great to be able to debug applications without riddling it with temporary print statements."
I suppose that something like SofIce for OS4 would help? Too bad there's no low level debugger like in Amiga Classic that could track anything.
BTW, "composited video" is our variation of textured video, which I mentioned multiple times as being the replacement for overlay. Overlay which is restricted to displaying video in up to one or two windows. Composited video, on the other hand, allows YUV video frames to be rendered, scaled, rotated, warped, alpha-blended, etc., anywhere. So, not only does it speed up video playback, it frees us from the restrictions of overlay (unlimited video anywhere on-screen), and could be used for more too (e.g., cross-fades & other video effects).
I hope that Odyssey's (HTML5/YouTube) video playback is enhanced to support this, as it would presumably give a great speed boost, especially on non-X1000 machines.
No, it doesn't and I doubt it ever will. That would mean that workarounds might need to be made for possible bugs in WinUAE's PPC emulation which makes no sense whatsoever to me at least.
Also last time I looked Toni Wilen was not really interested in making his PPC emulation compatible with AmigaOS 4.x. His main interest seemed to be in just getting PowerUp and WarpOS working.
Quote:
If not official, then I'd have thought running OS4 on WinUAE breaks OS4's EULA?
EULAs are not actually legally binding in most countries I would think (with the exception of USA maybe).
Plenty of good news from Amiwest this time. Just managed to install os4.1 on my peg2 few weeks ago, along with those millions of updates and now they've got 4.1 final coming. Good timing :)
Quote:
don't forget the news that A-EON has acquired the rights to octamed soundstudio and plan a native AOS4 version. that's a nice bit of news right there.
It would be interesting to know if it's really the same Amiga version of Octamed SS or the newer pc-version they have rights to. I guess it's the first mentioned one which few people have tried to port earlier. Hope it's going to happen this time :)
Any inside info who's doing the porting? It's good to see that Lyle has offered help already so I know that MIDI support will be in good hands \o/
Does Candi play "only" looped animation files in the wb-background or does it support rendering of code generated content?
I suppose that something like SofIce for OS4 would help? Too bad there's no low level debugger like in Amiga Classic that could track anything.
I'd forgotten that GDB does have the ability to do remote debugging via a network. So, I might be able to use it for some things.
However, some things in the driver are timing-critical (as in "set this register during the vblank period, or else...)
@ChrisH
Quote:
I hope that Odyssey's (HTML5/YouTube) video playback is enhanced to support this, as it would presumably give a great speed boost, especially on non-X1000 machines.
I hope so too, as composited video is much better suited to rendering video in browser windows than overlay.
It's a matter of finding someone able and willing to do the work. Kas1e's did the OS 4.x Odyssey port, but his Pegasos II can't handle Radeon HD cards.
So, if someone is interested in implementing this, we'd love to hear from you.
How about asking Liveforit(Kjetil)? Maybe setting up a small bounty for motivation? He has knowledge about composition. Quote:
It's a matter of finding someone able and willing to do the work. Kas1e's did the OS 4.x Odyssey port, but his Pegasos II can't handle Radeon HD cards.
So, if someone is interested in implementing this, we'd love to hear from you.
I know that Roman will get a X5000. Maybe he can implement MPlayer for default video playback in Odyssey. He can sale it in Amistore as new plugin. Nobody should do it for free
For me the problem is to get Odyssey to compile, and its not easy I have tried and failed before. I will also need the source code to latest changes from Roman. So I need a lot of help.
If Roman gets a X5000, I think it be quicker for him to look at my changes to MPlayer and back port this into the Odyssey Video Player, both video players are based on FFMPEG, so I think it should not be a problem.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Quote: I totally missed this. It's a bit disappointing that one of the latest codecs doesn't support direct rendering.
Yes I know, but then again Xv (X-Windows video is old technology)
Quote: Hopefully the mplayer/ffmpeg team will fix this in a future update.?
I don't think so, its all about UVD/VDPAU now.
Why do we have to wait for that to be fixed / implemented "upstream" if we have the mpeg code as an example surely we can recreate the approach for the mp4 code? Then maybe submit the result to the mplayer svn ourselves if it works?
Why do we have to wait for that to be fixed / implemented "upstream" if we have the mpeg code as an example surely we can recreate the approach for the mp4 code? Then maybe submit the result to the mplayer svn ourselves if it works?
I have not looked that deep into the decoder code, I can't answer this right now.
But anyway I try to put some prespective on it, a codec has buffer that can be part of a picture (a slice), or it can be a full image, I'm not sure what it uses.
To support DRI I think it has to support a full image decode buffer, or else you need work around this some how.
Many of my changes in FFMPEG / MPlayer wont be accepted by repositories because removed typedef off_t as it was not support correct in AmigaOS4 (not supporting 64bit version of it), besides is already a few months out of sync.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Why do we have to wait for that to be fixed / implemented "upstream" if we have the mpeg code as an example surely we can recreate the approach for the mp4 code? Then maybe submit the result to the mplayer svn ourselves if it works?
In theory, yes. But, is anyone going to actually do it?
How easy/hard it is, will depend on how much in the codec is hardcoded. There may be multiple locations in the code where assumptions are made about the target buffer's location and stride (bytes-per-row).
When looking for details about direct rendering, I stumbled on code that disables direct rendering for certain codecs (including H.264). According to the comments, once codec can't use direct rendering simply because "it uses its own stride" instead of the stride specified by the target buffer.
@LiveForIt
Quote:
Yes I know, but then again Xv (X-Windows video is old technology)
Old technology or not, it's still newer than the method that the codec uses. AFAIK, it's the newest technologyavailable when HW decoding isn't available.
How easy/hard it is, will depend on how much in the codec is hardcoded. There may be multiple locations in the code where assumptions are made about the target buffer's location and stride (bytes-per-row).
I've just discovered that VLC (VideoLan) has direct-rendering switched on for H.264. Doesn't VLC use ffmpeg's codecs as well? If so, then maybe it'll be relatively easy to fix.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
