CoreCodec/H.264 Codec "CoreAVC" [Archive] - Page 105

Cyber-Mav

21st November 2009, 19:39

if coreavc was free i can understand releasing a buggy version for users. but since coreavc is not free i dont understand why your rushing to get this 2.0 release out, in my opinion it would be wise to hold back release till next year since your finding out more bugs all the time.

again this is just my opinion on this. last thing you want is this thread going an extra 100 pages long with nothing but complaints.

Keiyakusha

21st November 2009, 20:04

In my opinion exactly because CoreAVC is not free (and because of weightp of course), they should release 2.0 as fast as possible. Check PM if you want to know more about my point of view.

BetaBoy

21st November 2009, 20:47

Keiyakusha that is the plan to get it out when its ready (minus my remark about 'this week' with this last minute bug), in fact as I've already stated that the only CORE changes has been to the add support for the multi-dupe additions to x264. But over the past few weeks/months it has been about the Windows 7 changes, 64bit additions, Installer, New SN/Customer Portal (for users to self-serve there own downloads/SN's), which are all ready to go.

Last was Haali's splitter changes to ensure directshow playback in WMP and MC and not MediaFoundation. We already know that with this first splitter release that its to ensure it works under Windows 7 properly and post forward, its going to be about playing nice with MediaFoundation to make Directshow the priority over it (without the DLL hacks that are out there).

Cyber-Mav... If you have a CUDA Enabled GPU.. out of spec MV's videos will play fine in CoreAVC.

Cyber-Mav

21st November 2009, 21:56

ahh nice to know cuda acceleration has the ability to play out of spec MV's. betaboy does coreavc 2.0 make any changes to cuda decoding? or is it kept the same as 1.9.5

the_corona

22nd November 2009, 00:13

Wait, only core change is "multi-dupe additions"?

Isn't it also going to be faster, beating out the free competitors (divx/diavc) finally in all configurations? If not, why should I buy a new licence for 2.0? Divx supports the latest x264 stuff just fine.

I think I'll personally wait to see benchmarks, before deciding to renew my licence. Just saying. Not being able to use coreAVC lately due to the x264 blocky thingy, I find divx to be a viable alternative TBH. Waiting to be impressed by speed.

BetaBoy

22nd November 2009, 01:26

ahh nice to know cuda acceleration has the ability to play out of spec MV's. betaboy does coreavc 2.0 make any changes to cuda decoding? or is it kept the same as 1.9.5
CUDA support in CoreAVC 2.0 has been devel'd against the latest SDK and there is several changes that affect it. The one that most ppl will want, is that it removes the need to have directshow as a requirement for native playback on Windows.

A great example of this is in 2.0 is that it now allows Windows Media Center to work with CUDA without it losing focus.

THX-UltraII

22nd November 2009, 09:01

will Haali Splitter and Core 2.0 be released today?

Astrophizz

22nd November 2009, 11:28

This is getting a little annoying (I'm sure even more so for others). Are you working on some time-sensitive project that requires these things within a short time frame? Are you going to ask if it's ready today every day?

Cyber-Mav

22nd November 2009, 12:06

whoa if i can play mkv's in windows media center on my vista x64 machine using cuda then coreavc 2.0 will be worth the purchase just for that feature alone. would this also work on windows 7 media center 32 and 64bit versions?

leeperry

23rd November 2009, 02:34

CUDA support in CoreAVC 2.0 has been devel'd against the latest SDK and there is several changes
shortening the CUDA initialization time sure would be fantastic.

Cyber-Mav

24th November 2009, 16:40

CUDA support in CoreAVC 2.0 has been devel'd against the latest SDK and there is several changes that affect it. The one that most ppl will want, is that it removes the need to have directshow as a requirement for native playback on Windows.

A great example of this is in 2.0 is that it now allows Windows Media Center to work with CUDA without it losing focus.

would this require a newer nvidia driver installed? i currently use the 186.18 driver but i think higher level cuda support was introduced in the 191.07 driver.

G_M_C

24th November 2009, 16:53

Hmmm, CUDA ... CUDA ... CUDA ....

Personnally i'm getting annoyed with this CUDA stuff. Is CoreAVC finally becoming vendor-neutral with V2.0, i.e. are the other 75% of computer-users finally getting H/W assistance too ?

(Yes, including all the Intel on-board IGP-users, more than 75% of users DON'T use Nv ! source (http://digital.venturebeat.com/2009/10/26/nvidia-sees-big-loss-of-market-share-in-third-quarter-as-graphics-chip-sales-boomed/)).

Relevant question, as an Ati-user; Other than the multi-dupe-p-refs or what not, is there any reason for me to get CoreAVC ? Cause ffdshow seems to be doing fine since i went back to the recent (non-experimental) version.

Cyber-Mav

24th November 2009, 17:58

G_M_C

24th November 2009, 18:00

i guess its because cuda can do things no other api can. cuda allows direct access to the video processor on nvidia cards, and for me and others its a brilliant solution. you can use media player classic home cinema with general dxva acceleration for all other cards but from my experience cuda seems to playback more video types that have higher ref frames etc.

why not just get a cheap cuda capable card these days they are real cheapo at around 20 quid for a 8 series.

Yup, like many of us are likely to downgrade from a HD5xxx series card, just for CUDA :rolleyes:

WE're at DX11 these days; DirectCompute, OpenCL etc. Why not switch to that. Nv will come to support that in the future too.

BetaBoy

24th November 2009, 18:13

leeperry... yes we have reported the initialization delay to NVIDIA.

Cyber-Mav.. anyone after 185 will work but I'd use the latest one (even Beta) as they do continue to address issues fast (The NVIDIA Team has been great about that!).

G_M_C.... Each user will be different. My rule of thumb on any device I have owned is to try almost everything first to see what works best on it... (noting that we first designed CoreAVC to work best on ARM/MIPS based Mobile devices with CorePlayer). On being 'neutral.... later 1.9.x releases and now the upcoming 2.0 release finally brings it into the desktop space with the CPU optimizations and will continue into 2.x for more of the 'neutral' stance you mentioned. Our belief is still that CUDA is a great technology and has only begun to scratch the surface of what's possible with it.... that being said, we will support DXVA as well, although I do not want to get into that now.

Snake91

24th November 2009, 20:38

Yup, like many of us are likely to downgrade from a HD5xxx series card, just for CUDA :rolleyes:

WE're at DX11 these days; DirectCompute, OpenCL etc. Why not switch to that. Nv will come to support that in the future too.
Let me understand, you have a hd5xxxx and not a 1080p-capable cpu? LOL

G_M_C

24th November 2009, 21:04

Let me understand, you have a hd5xxxx and not a 1080p-capable cpu? LOL

What's the argument you' re trying to make ? As a matter of fact; I have both (and even have a Asus Xonar HDAV Slim, that might become less useful when Ati/AMD finally gets HD-audio streaming right i.e. without PowerDVD, which i detest).

It's the argument that counts here. Supporting CUDA only, leaves out the vast majority of PC-owners that want GPU assisted decoding. All of these users are potential customers for CoreCodec.

It would be "good buissness" to be vendor-neutral, or to at least support DXVA. It is possible, look at MPC-HT; It supports DXVA for a long time now.

Furthermore; It is my opinion that DirectCompute/OpenCL gives CoreCodec possibilities. They could "stick with" their original concept of a software-decoder (without DXVA/CUDA, like the original CoreAVC's). DirectCompute/OpenCL opens up the shaders of a GPU for parallel computing by implementing C(++) libraries. It might be an idea to thy to adapt the software-CorecAVC with/using/implementing those libraries, and so getting GPU power implemented. This is a "vendor neutral" approach, but on the other hand it has disadvantages is. It is not the most energy-efficient idea (since the GPU's will "power up" when using shaders).

Jeff Flowerday

24th November 2009, 21:19

I'm a little confused about all the no ATI hardware support complaining. Is DXVA acceleration via MPC-HC's standalone filters not good enough?

Cyber-Mav

24th November 2009, 21:42

shon3i

24th November 2009, 21:48

Is DXVA acceleration via MPC-HC's standalone filters not good enough? DXVA have special limitations, stream must follow AVC specification for Level 4.1 and lower, while CUDA decode everything even "broken" streams.

Cyber-Mav

24th November 2009, 21:52

DXVA have special limitations, stream must follow AVC specification for Level 4.1 and lower, while CUDA decode everything even "broken" streams.

correct, also to mention ati's uvd hardware decoder is said to be limited to level 4.1 streams so it will not benefit over nvidia's video decoder implementation which decodes level 5.1 streams.

G_M_C

24th November 2009, 22:15

i dont understand why someone would go out and buy a graphics card these days that doesnt even support cuda?
i also dont understand why the said person would then come onto this forum and complain about the lack of support for thier graphics card in coreavc. if you had purchased a cuda capable card in the first place then you wont need to complain about this. and as mentioned above if you need gpu acceleration there are a number of alternatives for you such as media player classic home cinema or powerdvd and a few others. only one that is of no use to you is coreavc, for now.....

If I neutrally look at the graphics card market today, without knowing about CoreAVC or what not, i'd sooner get an Ati/AMD than i would get a Nv-card. All review sites agree, Ati/AMD cards give more features, more speed and are simply more bang for the buck. Almost all review sites agree. Nv is running behind, and they even seem to have problems keeping up production, even while loosing market share. CUDA isnt even a major selling point; Having DX11 is a much bigger argument. And Ati has that, Nv doesnt.

But as i said; From a business standpoint, i would be more profitable to "not chose sides" for CoreCodec. But thats my $ 0,02.

ajp_anton

24th November 2009, 22:24

and they even seem to have problems keeping up productionAnd AMD doesn't?

G_M_C

24th November 2009, 22:28

And AMD doesn't?

Yeah, getting hold a a 5xxx gpu isnt easy, but it gets delivered. Nv cards seem to be running "out of stock" fast lately, and some dont seem to be replaced. But this is based on "what i heard / read" on several tech-forums; I'm not in the market for Nv cards atm :p

EDIT: But this another subject for discussion. I made the argument that i'd hope to see that CC became more vendor-neutral i.e. not being CUDA only any more.

pankov

25th November 2009, 00:17

i dont understand why someone would go out and buy a graphics card these days that doesnt even support cuda?
The answer is very simple
DX11 and 8-channel LPCM, TrueHD & DTS-HD MA Bitstreaming

BetaBoy

25th November 2009, 00:23

EDIT: But this another subject for discussion. I made the argument that i'd hope to see that CC became more vendor-neutral i.e. not being CUDA only any more.
Sure... we've been saying that, but I also want to point out that we do have fundamental issues with DXVA as I've stated here a few times.

Long term, we see many advantages if CUDA combines its power with OpenCL, but when/if that happens, it will not stop us with DXVA (noting that we support more GPU's in CorePlayer then any other media platform and DXVA has always been a goal there).

Mixer73

25th November 2009, 00:25

EDIT: But this another subject for discussion. I made the argument that i'd hope to see that CC became more vendor-neutral i.e. not being CUDA only any more.

You don't seem to understand - its not the CoreCodec isn't supporting ATI, ATI do not provide access to their UVD hardware through their API, so DXVA is all you're going to get with ATI.

Unless eventually CoreCodec becomes code that actually runs on the GPU hardware, which I think is a bit of a stretch.

jakor

25th November 2009, 03:30

DXVA have special limitations, stream must follow AVC specification for Level 4.1 and lower, while CUDA decode everything even "broken" streams.
You are fundamentally wrong.
Speaking of h.264 decoding CUDA and DXVA are just interfaces to the same dedicated chip on a videocard.
The only difference in implementing them is that there is a code sample how to decode h.264 thru CUDA, and no such a sample for DXVA ;-))

saint-francis

25th November 2009, 04:44

From my understanding DXVA only works where there are no filters inline aside from the DXVA decoder. Which is why we aren't all using DSS2 with the stand alone MPC HC decoder for video encoding. How corecodec is planning on accomplishing this, I have no idea. But more power to them. And all of this bitterness about corecodec not supporting ATI because they have a CUDA implementation......? It's available..... Why not use it? They aren't siding with one hardware manufacturer because ATI doesn't have CUDA. They aren't siding with any manufacturer. Just taking what's given to them.

G_M_C

25th November 2009, 05:46

[...]
And all of this bitterness about corecodec not supporting ATI because they have a CUDA implementation......?
[...]

You seem to misread and/or misinterpret. I have no bitterness whatsoever, i just make an observation (CUDA only being for max 25% of all PC users worldwide, so 75% of potential CoreAVC customers dont have a use for CUDA support).

Personally, i dont give a damn about CUDA or Nv. Reading one of BetaBoy's previous post, i decided that i for myself dont need CoreAVC anymore. My QX9650 does fine without it.

I might have been tempted to try V2.x out if it had OpenCL or such, but alas it's not there yet. So it is (and frankly already was) unnecessary for me to upgrade. And there will probably be more people that weigh the same arguments i've used.

And so you read the reason why i posted the OpenCL -vendor-neutral- argument in the first place; Supporting CUDA only can prove to be "bad for business"; See it more as an observation/general idea and so forth.

me7

25th November 2009, 11:29

You seem to misread and/or misinterpret. I have no bitterness whatsoever, i just make an observation (CUDA only being for max 25% of all PC users worldwide, so 75% of potential CoreAVC customers dont have a use for CUDA support).

Personally, i dont give a damn about CUDA or Nv. Reading one of BetaBoy's previous post, i decided that i for myself dont need CoreAVC anymore. My QX9650 does fine without it.

I might have been tempted to try V2.x out if it had OpenCL or such, but alas it's not there yet. So it is (and frankly already was) unnecessary for me to upgrade. And there will probably be more people that weigh the same arguments i've used.

And so you read the reason why i posted the OpenCL -vendor-neutral- argument in the first place; Supporting CUDA only can prove to be "bad for business"; See it more as an observation/general idea and so forth.

You don't get it: CUDA is not a subset of OpenCL, both provide access to different components of the GPU. OpenCL can not be used to access the video decoder.

G_M_C

25th November 2009, 12:21

You don't get it: CUDA is not a subset of OpenCL, both provide access to different components of the GPU. OpenCL can not be used to access the video decoder.

Again: This is actually a seperate discussion. But I do want to answer this. Cause i'm noty the one that doesnt understand, you seem to be.

OpenCL is an cross-platform/cross-device open code-model. CUDA is NOT cross-device nor is it open. So developing for CUDA means developing for Nv-users only; Users of other vendor-devices are left out.

Nv claims that anything that runs CUDA will run OpenCL. That would also mean that if CC develops for OpenCL "(maybe "translates" their CUDA code to the equivalent OpenCL-code), they can support all HW vendors; Cause it'll support CUDA, but also Ati, Intel or S3 hardware (i.e. "vendor neutral") as long as the device has the abillity to run a certain version/level of OpenCL.

Mixer73

25th November 2009, 12:50

OpenCL is an cross-platform/cross-device open code-model. CUDA is NOT cross-device nor is it open. So developing for CUDA means developing for Nv-users only; Users of other vendor-devices are left out.

OpenCL does not provide the same functionality CoreAVC uses in CUDA. Its VERY simple. CUDA provides direct access to the decoding operations of the GPU and enables CoreAVC to use the hardware to decode the video while having less limitations than a native DXVA implementation.

OpenCL in its current state on ATI graphics cards is not suitable for a similar implementation to what is currently enjoyed by Nvidia owners. ATI could very simply provide access to the video processing but they have chosen not to.

Take your issue up with ATI for not providing access to the video decoding hardware through their API.

25th November 2009, 13:05

That would also mean that if CC develops for OpenCL "(maybe "translates" their CUDA code to the equivalent OpenCL-code), they can support all HW vendors
As people told you, the current CoreAVC CUDA code can't be ported to OpenCL because OpenCL doesn't have the equivalent of NVCUVID interface that provides access to the hardware video decoder.

Developing a fully functional OpenCL decoder is a huge task -- about as large as getting the CoreAVC software decoder up to the point where it is today. There would also be several downsides to it when compared against a dedicated hardware decoder:

Part of the decoding (at least CABAC) would need to be done on the CPU, so it would cause a higher CPU load
A fast GPU would be required to decode HD video instead of a low-end card like GeForce G210 that can decode 1080p60 H.264 video on its dedicated chip.
Much higher energy consumption and more heat.

The positive features are hardware-independence (as long as the hardware supports OpenCL) and avoiding limitations set by the hardware decoder.

Cyber-Mav

25th November 2009, 14:05

OpenCL is an cross-platform/cross-device open code-model. CUDA is NOT cross-device nor is it open. So developing for CUDA means developing for Nv-users only; Users of other vendor-devices are left out.

as mentioned above opencl cant provide access to the video decoder on the graphics chip like CUDA can. the strange thing is that ati do have something like CUDA and they call it Ati STREAM, however even in ati's own api it still doesnt provide access to the video decoder. so this is a problem with ATi and not coreavc.

as long as opencl doesnt provide direct access to a gpu's video decoder i cant see opencl being of any use to us in the video decoding segment of the market.

leeperry

25th November 2009, 14:22

leeperry... yes we have reported the initialization delay to NVIDIA.
very nice! so CoreAVC 2.0 will include this improvement? :cool:

G_M_C

25th November 2009, 16:09

I already said that i dont really care myself. My QX9659 copes fine without C-AVC or CUDA. It is only a suggestion to CC/BetaBoy that OpenCL might be a way to significantly increase possible customer-base. The latter isnt even an argument for all of you, you mostly only focus on CUDA and what it can or cant do.

And the possible negative influence on power-consumption when using OpenCL? I already posted that too.

But enough of this; I don't need CC, so discuss for yourself what you want.

Guest

25th November 2009, 16:21

This discussion is getting boring, repetitive, inflammatory, and borderline OT. Let's drop it guys. You've all made your points (several times!).

dimitrik

26th November 2009, 14:07

Personally I think the most important things for v2.0 in terms of new features are (a) support for Windows 7 including Windows Media Foundation to enable CoreAVC to work inside Media Center and (b) support for x64 Windows 7/vista.

These two are significant stoppers right now for an increasing number of people Win7's adoption rate is very high, and x64 adoption is also growing extremely fast.

Mixer73

26th November 2009, 23:04

These two are significant stoppers right now for an increasing number of people Win7's adoption rate is very high, and x64 adoption is also growing extremely fast.

Well.... I disagree.

CoreAVC already works on x64 just fine, my desktop rig is such. Its not a 64bit component but then you have to have every filter in the chain being 64bit which complicates matters, even if you wanted to use 64bit MPC-HC with CoreAVC 64bit when its out, you can do that but I just don't see any real benefit. 64bit seems to me to be the revolution that never was.

If it wasn't for the large amounts of cheap RAM I'm not sure anybody would be rushing out to get x64 OS.

And CoreAVC isn't as critical to 7 as it was to Vista IMO, with 7 having a working default h.264 codec built in. Vista was much harder to get to play DXVA in MCE. CoreAVC 'may' be better on 7 but even as an owner of CoreAVC I'm not sure if I will install it on my 7 rig.

BetaBoy

27th November 2009, 02:58

While I have not talked a lot about it, we posted a video on YouTube showing CoreAVC 2.0 64bit w/Haali 64bit bypassing MediaFoundation in favor of Directshow (no hacking required) for any MKV files in Windows 7 64bit.

Snowknight26

27th November 2009, 03:09

Awfully strange file names you're testing in that video..

BetaBoy

27th November 2009, 03:18

Mixer73... Depending on which method used for DXVA, it will always use less CPU over CUDA. RAM usage in our testing is negligible outside of the GPU, but the wave in recent months has been an increasing number of apps going 64bit. Windows 7 (and cheap ram) imho is driving this and that's a good thing, although technically there are not many advantages for decoding.

Stephen R. Savage

27th November 2009, 05:17

http://img338.imageshack.us/img338/4155/rule6violation.png

I believe that BetaBoy's link should be removed due to rule 6 violation since it shows obviously stolen content.

BetaBoy

27th November 2009, 05:48

Said the person with 6 posts.... and pls with the accusations since we (CoreCodec) do have promotional rights for content through our partnerships. But if the link is in question, its been removed.

BetaBoy

27th November 2009, 06:04

And CoreAVC isn't as critical to 7 as it was to Vista IMO, with 7 having a working default h.264 codec built in. Vista was much harder to get to play DXVA in MCE. CoreAVC 'may' be better on 7 but even as an owner of CoreAVC I'm not sure if I will install it on my 7 rig.

The issue with Windows 7 is that I fear there will be a battle for codec and splitter priorities and you can only go back and blame MS for creating MediaFoundation which is really not needed (in our opinion) unless you want to push EVR/DXVA, DRM, or finite Codec/Splitter control (although some would argue this point). Does anyone see a compelling reason to switch after seeing this comp chart? http://msdn.microsoft.com/en-us/library/aa468614.aspx#appendix_feature_comparisons__zftb

DivX for example has chosen to go the MF compatible route while we are steadfast in sticking with Directshow for Matroska. As stated, CoreAVC 2.0 w/Haali splitter now makes MKV the default for directshow and I really see no work around that Microsoft can do to prevent this if the filter/splitter is installed unless they intentionally change, block our registry settings or for DivX unless they ask the user who is installing it if they want the current splitter/filter to be removed prior to having theirs installed.

This is gonna be fun.... MF or DS? It might have to come down to a tool to be able to switch/change defaults at will.

Guest

27th November 2009, 06:07

I believe that BetaBoy's link should be removed due to rule 6 violation since it shows obviously stolen content. Next time you have a concern report the post. Do not post about it per rule 17.

If it is a sample as indicated in the filename then it is OK under the fair use clause. Further discussion to PM.