CoreCodec/H.264 Codec "CoreAVC"

[Killerattacks]

@Dark Shikari, ranpha

Thanks four your answers.
And seems like only time will tell then.

[popper]

DS said:OpenCL doesn't expose the GPU video decoder hardware necessary for playback.

So - will there be ATI support later on or no? Any idea when? Recently purchased a 4870 for myself and gave my wife my 8800GTS - so I have both GPU's at my disposal. Am I gonna have to install CoreAVC on her machine to use the features if I so desire later on? Or will there be support? (redundant with the question I know......)

theres the thing, no one can really know if, or when, not even BetaBoy not unless hes doing one of the below and im pritty sure he's not or something would have been seen by now.

i give you probably all the curent data and quotes needed as a one off, to see the patern ATI/AMD have followed to date and for the last 10 months:

all we can do is take what we know already and conclude most likely NO Never ATI HW UVD decode, and very unlikey anything else OpenCL/using conventional shaders, extending
-- VA-API
-- VDPAU
-- XvBA
-- XvMC
etc for ATI AVC/VC-1,Mkv HW assisted decode .

not unless some 3rd party OSS devs once again try and make the really hard effort to bring something realtime+ usable frame accurate decode and Encode for the most needed parts, sometime sooner than later (and im not talking yet another 12 months with nothing to speak of in the H@L4.1HW assisted Encode department).

as DS said OpenCL doesnt make it any easyer to attach to the 'ATI UVD ASIC' HW found in all current and last gen cards.

bridgman the AMD exec for Linux open and closed dev work and documentation again states 10-29-2009, 09:41 PM
"bridgman said:One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".

and again he stated 10-31-2009, 05:36 PM
"bridgman said: ... that UVD support is likely to come out in the closed driver before the open driver, and that is still our thinking.

In the meantime, the open source work is starting to shift focus to Gallium3D, which is a practical pre-requisite for decode acceleration *without* relying on UVD.

I think all the things you want are happening."


all this goes back to just before i asked him these direct UVD questions back in January 2009 (10 months ago) just after someone mentioned the CUDA ASIC...
in relation to OpenCL were RealNC asked "Hmm. So then OpenCL is not the answer here? Then what is?"


01-05-2009, 01:31 PM "bridgman said: ...
It depends on the question

The ideal solution is to have access to the dedicated hardware we all put in our chips to support BluRay playback. Unfortunately that hardware is also wrapped up in bad scary DRM stuff so making it available on Linux is a slow and painful process.

In the meantime, a lot of the computationally expensive work associated with H.264 decode and encode can be done with shaders, which is where OpenCL comes in. It doesn't *have* to be OpenCL, and the work doesn't have to wait for OpenCL, we're just saying that a year from now anyone writing that kind of code will probably start with OpenCL.

In the meantime, I believe there is enough info publicly available today to write a GPU-accelerated H.264 decoder for Linux on either Intel or ATI hardware using the 3D engine using conventional shaders. Another option for ATI and NVidia hardware would be to write the decoder using Stream or Cuda tools (but without that handy library).

One thing that tools like OpenCL will do is make it possible for more people to get into this kind of programming, without having to first take the plunge into driver development. The CUDA and Stream tools certainly help, but I think OpenCL will help more.

The other obvious benefit of OpenCL is the ability to run the same program on hardware from different vendors, which I guess you could say is "bad for the hardware vendors individually but good for them collectively"
Last edited by bridgman; 01-05-2009 at 02:17 PM.
"

as you can see theres a confusion there were he casually refers to the cuda tools but clearly makes a point of ruling out the library for ATI, then moves on to re-enforce the non UVD documentation hes put out there.

and to be fair, its not all his fault, as he has tryed to encurage 3rd party devs to take whats already available and extend each option as they see fit using the other data he released... such as extending XvMC or one of the others as it existed back then....before the OpenCL really get talked about.. perhaps some have tryed and failed , but it seems most didnt even want to try and write any Proof Of Concept code or extensions to the above API's etc...

"bridgman said:This thread is only debating the urgency of building XvMC (Motion Compensation and optionally IDCT) on top of Xv, to offload more CPU work to the GPU when decoding MPEG2 video streams. Our view is that time would be better spent working on an implementation which could also handle H.264/VC-1 as well as MPEG2, which will require either some extensions to the XvMC API or a different API completely.
"


then on "10-29-2009, 06:20 PM we start to see a shift away from the old options and on to the up and coming Gallium3D
were again it is/was hoped someoone/ANYONE will take the time to try and add the required video decode acceleration OpenCL on top of that sometime in the near future, but noones taken the first steps down that path so far, or at least publicly stated their willingness to try...
see Feature dependency tree
"bridgman said:This is one of those cases where desired priorities don't make much difference -- the development sequence is based on architectural hierarchy :

- dynamic power management will be built on top of kernel modesetting, and decode acceleration will be built on top of Gallium3D drivers.

- Gallium3D drivers, in turn, depend on DRI2 and can leverage most of the code (and nearly all of the painful lessons) from the 3D work done on the classic Mesa 3D drivers

- DRI2 depends on memory management, and the memory management work was driven primarily by kernel modesetting

Completion of new functionality pretty much *has* to follow that dependency tree, no matter what order the work is started. Resistance is futile.

I updated the chart at the end of the RadeonFeature page to make this a bit more clear :

http://www.x.org/wiki/RadeonFeature

Last edited by bridgman; 10-29-2009 at 06:24 PM"


this all goes all way back to January 2009 as replys to my UVD questions etc
"bridgman said: we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


"popper said:thats a shame, we are looking at months at the very least then!"

"bridgman said: For open source, yes, but I expect fglrx will have it sooner.
"

and bridgman does or at least did read this betaboy thread :waves: but doesnt seem to post here and thats a shame, as he could clarify any slight errors if any are made, but essentially this is the pubic information and statements available to date.

http://www.phoronix.com/forums/showpost.php?p=97961&postcount=30
http://www.phoronix.com/forums/showpost.php?p=97711&postcount=11

[khat17]

Long read - and I'll have to do some additional reading up to fully grasp everything.

I noticed in the listing you have there's no DXVA - - - why? Changing from nVidia to ATI using MPC-HC with DXVA I've gotten H264 streams to play through the GPU. A quick browse of what UVD is shows that it should work through DXVA, so why not tackle it from that angle?

[Dark Shikari]

Long read - and I'll have to do some additional reading up to fully grasp everything.

I noticed in the listing you have there's no DXVA - - - why? Changing from nVidia to ATI using MPC-HC with DXVA I've gotten H264 streams to play through the GPU. A quick browse of what UVD is shows that it should work through DXVA, so why not tackle it from that angle?IIRC, DXVA requires control of the output display device too, so a decoder can't do it alone (it requires support in the player).

[BetaBoy]

Ranpha.... I welcome your thoughts/flame. I stand by what I said, in fact OpenCL will come into play at some point but there are obvious things that need to occur first for us to be able to take advantage of what it has to offer as DS has stated is missing.

[popper]

Ranpha.... I welcome your thoughts/flame. I stand by what I said, in fact OpenCL will come into play at some point but there are obvious things that need to occur first for us to be able to take advantage of what it has to offer as DS has stated is missing.

for instance , ATI/AMD NEED to finally make their OpenCL codebase actually use their Gfx chips and not just use your CPU only, some time really soon at the very least OC...

its not even really clear if you could simply get your 3rd party OpenCL code working on say OSx and Nvidia for instance, then later just port it and compile it for a much improved ? future ATI Gfx OpenCL codebase in a simple way...

thats how bad ATI are right now and in the near future it seems... shame.

also, keep in mind that its been said by bridgeman that "decode acceleration will be built on top of Gallium3D drivers." for the OSS linux OS etc.

its also been said by others that although very basic alpha Gallium3D drivers have passed 11-09-2009, 09:30 PM first basic tests for the old ATI R300 only, its expected to take another 12 months from now before Gallium3D is considered stable and feature rich, as in most of the standard, and ALL its supporting code as per the Feature dependency tree is there and works reasonably OK...

so its reasonable to assume unless something changes, that only 12 months or later , will OpenCL open linux drivers will be good enough for your everyday use, i wound Not expect the stable windows side to be much sooner...., perhaps 9 months instead of 12months+ as they seem to run the windows and closed linux drivers together ,(remember BM says he expects the closed driver to get any UVD before open linux if and only if they pass a future review actually allowing access to some of its API) perhaps one revision behind wondows...

[lych_necross]

@BetaBoy,
I just wanted to say, I love CoreAVC and I am eagerly waiting for 2.0 to be released. Ignore the flamers and keep up the good work! :)

[djmasturbeat]

i have posted numerous times in coreavc's forums inquiring about this release. have not been back for awhile, and sorry if it has been touched on in this thread (but it is really long, so i will ask anyhow):
is x64 still going to be supported? as we were told it would when the new x64 haali was released beyond beta, and this was the last hold up, essentially of v2.

i do think there is some good advice to be had in not prematurely announcing things, then having customers getting angry over long waits. being upfront is better than spinnig us.

if hw accel can ever be had for ati cards, i know a lot of us would really appreciate it, but i won't pretend to have any current knowledge of how this is accomplished. it would be a nice addition to a great package.

i look forward to all the current audio formats being better supported as well, with stable releases of splitters and codecs coming out. so thanks to beta boy and the haali and corecodec crews for all of their hardwork.

[Przemek_Sperling]

I do wonder how the author of Mirillis Splash Player http://mirillis.com/splash.html made his software HW decode AVC? I use the software with combination with my Radeon 4550 and it works like a charm (both DVB-T and playing mkvs).

[nm]

I do wonder how the author of Mirillis Splash Player http://mirillis.com/splash.html made his software HW decode AVC?

According to its system requirements, it simply uses DXVA if possible. Like MPC-HC, for example.

[dimitrik]

Constantly evolving? What?

CoreAVC doesn't (nor does basically anyone else) support any of the recent additions to the spec (SVC and MVC). With the exception of Predictive Lossless, everything in the spec that CoreAVC and libavcodec supports is identical to how it was in 2005.

My mistake I must have misunderstood something I read. I was under the impression people were complaining about lack of support for new x264 features which I understand is not the case.

and the flames continue... In the end 2.0 will be out this week. Dark Shikari... Thx was gonna jump in and say something similar.


Betaboy if you're referring to my post...I'm really not sure what part you could possibly interpret as a flame? I was making a simple comment on facts and offering a friendly opinion as a customer. Maybe you could point out what I said that you felt was so negative?

[Dark Shikari]

My mistake I must have misunderstood something I read. I was under the impression people were complaining about lack of support for new x264 features which I understand is not the case.New x264 feature does not mean new H.264 feature.

[dimitrik]

Right, :thanks: for reminding me.

[Disabled]

My mistake I must have misunderstood something I read.
You might have just read Betaboys comment, stating that the AVC specs are changing, implying that weightp is a feature added to the specs and not to one encoder.

The AVC specs today are not the same spec they were 6 months ago no less 2-3 years ago.

@betaboy Youre waiting for OpenCL to expose the GPU decoder hardware right?

[BetaBoy]

Disabled, I've never said that about weightp... Please re-read the thread. On the specs if was stated "AVC specs/profiles changing", but that's not gonna stop the continued flaming is it?

[LoRd_MuldeR]

Youre waiting for OpenCL to expose the GPU decoder hardware right?

As far as I know, OpenCL doesn't expose the built-in hardware video decoder of the Graphics Card at all. It provides an interface to compute devices (this may be a GPU, a Cell Processor or even a "normal" CPU). So you could use OpenCL to implement your own H.264 decoder as an OpenCL kernel, which would run on any OpenCL-enabled device. But that's not what CoreAVC currently does, as far as I know. Instead they simply use the PureVideo-decoder chip, which is available on all recent Nvidia Graphics Cards and which already provides a highly efficient H.264 decoder in hardware. That decoder can be used through the CUDA Video API, but it's not a CUDA kernel and it's not something you could do with OpenCL in a similar way (at the moment). Last but not least writing your own H.264 decoder as a CUDA kernel or as an OpenCL kernel, which would be running on a (more or less) "general purpose" GPU, will never be as efficient as a dedicated decoder hardware, such as the PureVideo decoder chip...

[Disabled]

Disabled, I've never said that about weightp... Please re-read the thread. On the specs if was stated specs/profiles changing

Then tell me how to re-read that:
The harm is done, when you think you bought a decoder for high profile files, while you bought a decoder for files that use 'some' high profile features.
The AVC specs today are not the same spec they were 6 months ago no less 2-3 years ago. As far as changes... you are really talking about encoding...
Of course I was not talking about encoding, because the specs didn't change and you don't have full High profile support.

As far as I know, OpenCL doesn't expose the built-in hardware video decoder of the Graphics Card at all. It provides ....
Yeah, that has been said a thousand times now. I was connecting:

I stand by what I said, in fact OpenCL will come into play at some point but there are obvious things that need to occur first for us to be able to take advantage of what it has to offer as DS has stated is missing.
with the only post from DS about OpenCL (in the last few pages):
OpenCL doesn't expose the GPU video decoder hardware necessary for playback.
I read it like "if OpenCL offers GPU playback in a distant future, were gonna use that. If not, you don't get it." I'm probably wrong with that assumption, but betaboy doesn't tell us otherwise...

[BetaBoy]

I can only say so much with respect to others.... but with support for OpenCL by both ATI and NVIDIA now, its a safe guess that it's only a matter of time before something of value comes for decoding (as you are all touching on as well).

[Jeff Flowerday]

I'm going to wear this thread out checking it to see if the new splitter has been released...

[BetaBoy]

No as we found a few bugs in the splitter, but they are not show stoppers for the CoreAVC 2.0 release either.

[plonk420]

I think clearly when a customer buys a product that product is supposed to do what it says on the box at the time of purchase. If the spec changes a month later that doesn't automatically guarantee it'll be supported but it seems as if CoreCodec have in fact done their best to keep up with the standard specs and I for one have not had to pay for a version upgrade from my initial purchase (I think 1.6).

i don't recall hearing about "CoreAVC Knowledgebase and Feature Limitation" when i bought 1.0 or whatnot. (of course not knowing about its existence-even if it did-isn't really an excuse for end users). i can't even remember if CoreAVC claimed High Profile support (was pretty sure it did). anyone remember?

[Shinigami-Sama]

i don't recall hearing about "CoreAVC Knowledgebase and Feature Limitation" when i bought 1.0 or whatnot. (of course not knowing about its existence-even if it did-isn't really an excuse for end users). i can't even remember if CoreAVC claimed High Profile support (was pretty sure it did). anyone remember?

as I recall it they advertised as the fastest high profile decoder
back when LAVC was slow as sin

[plonk420]

i guess it's down to wording. i'm seeing "H.264 Baseline, Main, High profile support" back to 12/2006 and thru 12/2007. waybackmachine++ :)

[BetaBoy]

No as we found a few bugs in the splitter, but they are not show stoppers for the CoreAVC 2.0 release either.

To that..... I'm gonna sync with Haali now... As we think it might be a good idea to QA the splitter more outside of the small test group now, and ahead of the CoreAVC 2.0 release.

[Cyber-Mav]

wouldnt it be best to delay coreavc 2.0 till next year that way none of these bugs that keep getting found will make poor experience for the users?

[BetaBoy]

Not at all, as stated above this will not effect the release. But with a few more days before 2.0 is out, getting the splitter out earlier could not hurt.

[Cyber-Mav]

so will coreavc 2.0 still have lots of bugs in it when its released in few days? it seems as if your trying to rush coreavc 2.0 out of the door.

[BetaBoy]

No way, In months of testing we have only a handful of bugs in the 2.0 codebase, in fact we are only aware of one bug in 2.0 ATM. Also you need to distinguish the splitter from the filter, while we work with Haali on suggesting features and fixes, we do not directly work on it and as stated CoreAVC is designed to work with any splitter (but we prefer Haali and his splitter).

However that being said, this is a milestone release and does add support for a new OS, new SN/Customer Portal, so we do expect a few bumps... That's a give in.

[Hans Ohlo]

few days? the week has only like two of them left ;)

when using coreavc with windows media center it would be nice to limit the open instances of the decoder like ffdshow can. because in the background for creating thumbnails i get up to 20 open instances at times resulting in poor performance and sometimes crashes.

[BetaBoy]

few days? the week has only like two of them left ;)

when using coreavc with windows media center it would be nice to limit the open instances of the decoder like ffdshow can. because in the background for creating thumbnails i get up to 20 open instances at times resulting in poor performance and sometimes crashes.

Haali has removed all thumbnail support from the new splitter now... so you should not see that anymore. He has also mentioned the possibility to release it as an addon and or as a new app.

[THX-UltraII]

http://haali.su/mkv/ is down at the moment. Think it beeing updated to Haali Splitter 2.0!

[madshi]

@BetaBoy,

will CoreAVC 2.0 (software decoding) fix the artifacts that occur with some Blu-Rays (e.g. Chinese Ghost Story, Chocolate, Der Untergang, just to name a few)? It may be that those Blu-Rays are out of spec, but only CoreAVC shows artifacts with them. And of course it's not nice if I invite guests over to watch movies with me, and then artifacts show up. So in order to make CoreAVC a good choice for me, I'd have to rely on that it doesn't show artifacts even with funny Blu-Rays.

Thanks!

[BetaBoy]

If its related to out of spec Motion Vectors, as Dark Shikari already stated we did not increase the threshold and to do so would come at the cost of speed. We did however a few releases back increase the threshold, but only to the point where it started to slow down decoding.

BTW... I have not sen an recent Blu-Ray releases (past few months) that have MV issues. But that maybe due to my limited time to watch every BR release.

[sneaker_ger]

If its related to out of spec Motion Vectors, as Dark Shikari already stated we did not increase the threshold and to do so would come at the cost of speed. We did however a few releases back increase the threshold, but only to the point where it started to slow down decoding.

BTW... I have not sen an recent Blu-Ray releases (past few months) that have MV issues. But that maybe due to my limited time to watch every BR release.

Will 2.0 support out of spec MV's which could sometimes produce glitches?

All limitations on MV's have been removed in 2.0.

:confused:

[BetaBoy]

:confused:

Please continue... in the follow-up post was where I mentioned that we had not expanded the MV's. Its also not a limitation at all, but should be considered by Mastering Houses when doing the final production encodes. I had already pointed this out to Sony, Paramount and Fox through a third party all of which have since changed how they treat MV's.

[sneaker_ger]

I see. Which means that if people are getting artifacts because of out-of-spec MVs with 1.9.5 they'll also get them with 2.0.(?)

[Snowknight26]

No way, In months of testing we have only a handful of bugs in the 2.0 codebase, in fact we are only aware of one bug in 2.0 ATM.

Out of curiosity, which one is that?

[BetaBoy]

I'll hold off on any report of specifics till it is out with hope that it will be fixed by then.

[madshi]

If its related to out of spec Motion Vectors, as Dark Shikari already stated we did not increase the threshold and to do so would come at the cost of speed. We did however a few releases back increase the threshold, but only to the point where it started to slow down decoding.

BTW... I have not sen an recent Blu-Ray releases (past few months) that have MV issues. But that maybe due to my limited time to watch every BR release.
I've seen it in multiple rather recent Blu-Rays (a list of which you'll find in my previous post). I understand your stance on this. But please understand that from an end user point of view it doesn't matter much whose fault the artifacting is. Couldn't you add an option to CoreAVC to properly handle out of spec motion vectors? I wouldn't mind (at all) if that option came at a speed penalty! But I definitely can't live with artifacts.

[BetaBoy]

This was discussed about 90 pages back... but technically that would require two separate decoders as it not something that can be set dynamically like that.

[Jaja1]

I totally agree with Madshi's remarks on handling out-of-spec MV's. They are more common than you think. I have quite a few BRD's suffering from this. ATM I have to rely on ffdshow to playback the affected BRD's without artefacts, but I would prefer to use CoreAVC as my default decoder. So I hope you can come up with a solution Betaboy

[hakujin]

Fix on "--weightp 2" corrupted frames problem planned for soft decoding?

More info:

http://x264-bb.com/helpdesk/4333-coreavc-later-builds-x264-encoder.html

[BetaBoy]

hakujin... pls read the last few pages of this thread. Thx.

[THX-UltraII]

it s friday, the last day of the week so Haali time! :)

[Snowknight26]

A week includes the weekend...

[leeperry]

it s friday, the last day of the week so Haali time! :)
or else? :devil:

[Shinigami-Sama]

it s friday, the last day of the week so Haali time! :)

theres still two days left...

[BetaBoy]

It's ready when it's ready... weekend or not. Just pinged Haali now for any new changes to the splitter.

[Jeff Flowerday]

http://haali.su/mkv/ is down at the moment. Think it beeing updated to Haali Splitter 2.0!

Site is back. But nothing new...

[THX-UltraII]

yeah, saw this too :(