CoreCodec/H.264 Codec "CoreAVC"

[BetaBoy]

betaboy, can we expect a 1.9.1 version with all the bugs reported fixed next week?

No timetables but as I've said we expected a few 1.9.x releases... we are working hard on issues reported and have already fixed a number of them.

[chros]

The 181.22 driver by itself does not contain all the needed components. Perhaps you've installed one of the DG***IndexNV programs.
and @ Malow: indeed ... Thanks for clarifying this ...

[leeperry]

we are working hard on issues reported and have already fixed a number of them.
indeed you have, no more banding/blockiness and very rare artifacts on seeking in KMPlayer w/ the latest beta I've been given.

way to go :cool:

[Inventive Software]

Those decoder figures are interesting: seems software decoding is still the way to go!

[nm]

Those decoder figures are interesting: seems software decoding is still the way to go!
Certainly in some situations, if you need a high throughput or if the video exceeds some limitations of the hardware decoder. However, dedicated hardware is much more energy-efficient (and therefore requires less cooling).

[leeperry]

Those decoder figures are interesting: seems software decoding is still the way to go!
well, it still offloads the CPU........for whatever x264 encoding or avisynth PP in ffdshow :p

[BetaBoy]

Those decoder figures are interesting: seems software decoding is still the way to go!

In some cases sure... but I'd also hold off in any decision of what do use till we release a few of the next 1.9.x bug fixes releases, with interlaced support being the most important.

[Disabled]

(2) Or you could use the general purpose CUDA stuff to let NVidia accelerate only some specific parts of your software decoding code. (Probably this would be run by the shader hardware [...]).
madshi... more of the #2 approach. That has been the basis for all our goals with GPU... obviously more so with CorePlayer (xScale, ATI, Marvell, Qualcomm/QTv, RMI and next CUDA) then with CoreAVC to this point.
initial tests show that there is no decoding speed difference between a 8600gt and a 8800gt i have. [...], but thats to be expected since both of the cards use the same VP2 processor.
Ok, so CoreaAvc 1.9 doesn't really have decoding "CUDA-code", but rather tries to use VP via CUDA API instead of DxVA API? That's all?
BetaBoy can you comment on this?

I'd really like to get an honest answer: Are you using shaders to do your acceleration? If yes, why is there a need for the VP2 decoding engine, and there is no speedup with better cards? Either way: Is there a plan to extend the support and get rid of the VP2 need? Bonus: If ever ATI plans do have a compelling API and support and such, will you support them too, will the upgrade be free for 1.x owners?

[BetaBoy]

Disabled... I'm not going to go into a detailed explanation of CUDA. Also, the need is 'no need' at all (from what I remember being told), VP2, VPx are are independent generations and we do not require one generation to work with the next (I'll confirm this). Read this if you want to know the other answers on shading and CUDA vs. other solutions: http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_ImageVideoCUDA_web.pdf

On ATI.... we have no plans for supporting their hardware anytime soon.

[dansus]

indeed you have, no more banding/blockiness and very rare artifacts on seeking in KMPlayer w/ the latest beta I've been given.

way to go :cool:

Where? how?

I would like to join the beta game too... :p

[lexor]

Disabled... I'm not going to go into a detailed explanation of CUDA. Also, the need is 'no need' at all (from what I remember being told), VP2, VPx are are independent generations and we do not require one generation to work with the next (I'll confirm this).

I think what everyone was getting at, was the claim made by Leak in MPC-HC thread. The claim was that CoreAVC-CUDA uses shaders and not ASIC of VP2, thus card kicks all the shader units into high gear, power consumption kicks into high gear, fans kick into high gear. So, Leak claimed that CUDA solution is louder and more power hungry than DXVA in MPC-HC.

All those people quoted above probably wanted to know if that's true.

[hajj_3]

if thats true it would be nice to have a "maximum acceleration" and "low power acceleration" as my cpu is a quad core overclocked to 3.5ghz so my pc is fast anyway but less cpu usage when playing 1080p is always welcome but i dont want it to make my electricity bills go up.

[Cyber-Mav]

I think what everyone was getting at, was the claim made by Leak in MPC-HC thread. The claim was that CoreAVC-CUDA uses shaders and not ASIC of VP2, thus card kicks all the shader units into high gear, power consumption kicks into high gear, fans kick into high gear. So, Leak claimed that CUDA solution is louder and more power hungry than DXVA in MPC-HC.

All those people quoted above probably wanted to know if that's true.

not true since both my 8600gt and 8800gt stay at idle temps when using coreavc in cuda mode which means there is hardly any load on the gfx card.

[STaRGaZeR]

not true since both my 8600gt and 8800gt stay at idle temps when using coreavc in cuda mode which means there is hardly any load on the gfx card.

That's because CoreAVC is NOT using the shaders. The power consumption of VPx is negligible.

[lexor]

not true since both my 8600gt and 8800gt stay at idle temps when using coreavc in cuda mode which means there is hardly any load on the gfx card.

Hey, you don't have to convince me. But when I said Core was using vp2 as well (by analogy with neuron2's work)... I was called a fool and told to read some wiki articles. At that point I left that discussion. Dunno if they settled it or not... don't much care.

[Disabled]

I asked this, because Betaboy said they were using "more of the #2 [shader] approach. That has been the basis for all our goals with GPU".
But quite obviously, they are not using a shader, but a vp2 approach.
And maybe its my english, but I don't quite understand the following sentence:
Also, the need is 'no need' at all (from what I remember being told), VP2, VPx are are independent generations and we do not require one generation to work with the next (I'll confirm this).
Are you implying you don't need VP2?

[DeepBeepMeep]

I asked this, because Betaboy said they were using "more of the #2 [shader] approach. That has been the basis for all our goals with GPU".
But quite obviously, they are not using a shader, but a vp2 approach.
And maybe its my english, but I don't quite understand the following sentence:

Are you implying you don't need VP2?

According to the document mentioned by Betaboy (see p30/31), you can access the H264 video decoder through the CUDA API, so this should explain how CoreAVC Cuda support works...

[STaRGaZeR]

And maybe its my english, but I don't quite understand the following sentence:

Are you implying you don't need VP2?

The same goes for me. I don't know if that was intentional but it sounded like a very good evasive, dunno why. Is that hard to say "hey, CoreAVC doesn't use the shaders, it uses the VPx unit present in the following GPUs: ... "?

[Sulik]

Both CoreAVC and neuron2's DGAVCDecNV use nvcuvid.dll which allows access to VPx HW from CUDA applications (technically, it probably uses both VPx and shaders to some extent)

[CiNcH]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)

On ATI.... we have no plans for supporting their hardware anytime soon.
Obvious.

[neuron2]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions If you think it is simple, you need to read this:

http://neuron2.net/dgavcdecnv/cuda/cuda.html

[jj666]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)


Obvious.

Actually, I've found Donalds utilities very helpful and given the support and frequency of updates, I think the $15 is extremely cheap. Given the compatibility is much better than the libav counterparts (I'm encoding a few things ripped with my Dreambox, where DGAVCDEC fails and DGAVCDECNV doesn't).

In the past, I thought exactly the opposite regarding CoreAVC as (despite being a paid user here), the updates are few and far between and I've never felt the details given here on the forum were detailed enough, or supportive enough (especially in the state of the Haali muxer). However, with the new CUDA decoding issues I experienced fast and extremely helpful service to solve all of my found issues. Now would wholeheartedly recommend this software to everyone.

I'm guessing most of the negativety is coming from ATI users, where they found they're somewhat out in the cold regarding such innovative software.

Cheers,

-jj-

[STaRGaZeR]

However, with the new CUDA decoding issues I experienced fast and extremely helpful service to solve all of my found issues. Now would wholeheartedly recommend this software to everyone.

Honestly, I don't know how almost everyone is having decoding issues and still the product is released. How did it pass QA? It gives the impression of using normal users as betatesters. Also as you say they seem completely centered in CUDA, which is understandable given how popular it is from a marketing and business point of view.

I'm guessing most of the negativety is coming from ATI users, where they found they're somewhat out in the cold regarding such innovative software.

That's far from the truth. It's hard to be impressed when you can get the same from DXVA, without the current bugs and for free. The only situation where CoreAVC CUDA offers any innovation is when the user wants to insert any kind of filters like ffdshow for postprocessing purposes between CoreAVC and the renderer while maintaining hardware decoding, something 99,9% of users will never do, NV or ATI.

[BetaBoy]

Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)

4 months of engineering, and like neuron2 working directly with the NVIDIA engineers is far from a 'simple' addition.

[BetaBoy]

That's far from the truth. It's hard to be impressed when you can get the same from DXVA, without the current bugs and for free.
Well given that DXVA is on 2.x and been out for at least 3+ years and CUDA video decoding is officially only 7 days old ;-)

STaRGaZeR... point taken but I disagree. I'm not sure you see the full picture. CoreAVC 2.0 will shed even more light on this.

[TheShadowRunner]

Well, you can NOT get the same from DXVA.
Add any filter after the decoder and it'll break DXVA. Adding a filter after CoreAVC in CUDA mode doesn't break CUDA. (hint: VSFilter ^^)
Later,

TSR

[CiNcH]

4 months of engineering, and like neuron2 working directly with the NVIDIA engineers is far from a 'simple' addition.
I did not say that it is easy or simple, but that some people may think that it is. Those who know nothing but always only talk... You know them... Maybe because of them a clear statement that the decoder is not based on shaders was not given... You preferred to hang about...

[squid_80]

Are you implying you don't need VP2?
CoreAVC doesn't specifically do any sort of check for VPx. It asks the card (CUDA device) if it supports Compute Capability 1.1, since that is the minimum required for the nvcuvid component to work.
CoreAVC uses lower-level calls than both MPC-HC's DXVA filter and DGAVCIndexNV. This lets it do a few things more efficiently in the CPU, and also avoid a few bugs.
Are you using shaders to do your acceleration? If yes, why is there a need for the VP2 decoding engine, and there is no speedup with better cards? Shaders are not used directly. They may become important later if we add some new features.
If ever ATI plans do have a compelling API and support and such, will you support them too, will the upgrade be free for 1.x owners? Sure, if they open up UVD in a similar way to NVIDIA. I heard (not official in any way) at the start of this month that they plan to, but it will be a while before anything is released - probably at least 6 months.
Well, maybe some would feel like 15$ is too much if they knew that the filter was only calling some pretty simple API functions... ;)
It's not like we added $15 to the price when CUDA support was added. The price remained exactly the same and CUDA was added as an additional feature. Can't see how that is bad value for money.
Honestly, I don't know how almost everyone is having decoding issues and still the product is released. How did it pass QA? It gives the impression of using normal users as betatesters.
With CUDA enabled on a direct BD Rip ("Hostage") at 25Mb birate only 3%-14% CPU. Great job!! (http://forum.corecodec.com/viewtopic.php?f=3&t=1750)
I tried it and it works perfectly! The CPU usage dropped from 25-30% to 5-10%. Nice job guys ! (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=60#p8972)
Just threw a 720p copy of Indiana Jones and the Crystal Skull at it, uh, 3-5% CPU usage with CUDA working, WOW :) (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=30#p8889)
Shockingly the transformers rip i made played fine and thats using the unrestricted profile. (http://forum.doom9.org/showthread.php?p=1248171#post1248171)
Not everyone is experiencing problems. Generally with software you will get feedback from 10% of the happy users and 90% of the unhappy users.
Also as you say they seem completely centered in CUDA, which is understandable given how popular it is from a marketing and business point of view.Not really true, as jj666 and leeperry have noted the CUDA issues have been sorted but a new release isn't out yet because there's some small unrelated things to fix/add.
It's hard to be impressed when you can get the same from DXVA, without the current bugs and for free. The only situation where CoreAVC CUDA offers any innovation is when the user wants to insert any kind of filters like ffdshow for postprocessing purposes between CoreAVC and the renderer while maintaining hardware decoding, something 99,9% of users will never do, NV or ATI.
Additionally:
- Supports up to 15 reference frames (I have asked several people who say this isn't working for samples, and have received none. Please contact me via PM if you think you have such a sample).
- Can be used when a renderer isn't in the directshow graph at all, such as in an avisynth script feeding x264 or any other application that supports generic directshow filters (i.e. virtualdub directshow plugin)
- Doesn't rely on the directshow architecture, so companies licensing the CoreAVC library can still use it
There are also the post-processing options that are built into the filter, such as output colorspace selection, software deinterlacing, input/output levels selection and the brightness/contrast/saturation settings.

[Disabled]

Thanks squid for your good reply!
Two comments though: Afaik, there is no compute shaders 1.1 without VP>=2, so the checks are the same. Sure Nvidia could do a driver for the 8800 GTS/GTX with cs1.1 and implement VP2 in the shaders, but thats not gonna happen.
Second, its not like you added an additional feature, because you felt like it. I paid for GPU support 3 years back, so it was your duty do deliver it.

[BetaBoy]

Second, its not like you added an additional feature, because you felt like it. I paid for GPU support 3 years back, so it was your duty do deliver it.
Sure, we wanted to deliver on the promise! Noting that 3 years ago CUDA was just on the drawing board and that our goals we not aligned with that of the DXVA approach. We are very happy with the decision to wait and with the help of the NVIDIA team (thank you NVIDA Devs!) we are just as excited to see whats on the 2.0 horizon.

We continue to thank everyone for their support (and patience).

[jj666]

Honestly, I don't know how almost everyone is having decoding issues and still the product is released. How did it pass QA? It gives the impression of using normal users as betatesters. Also as you say they seem completely centered in CUDA, which is understandable given how popular it is from a marketing and business point of view.


I tested over 2tb of Blu-ray remuxes and posted 3 incorrectly displayed movies, of which two were fixed in one day and the last a day later. I'd hardly call three out of approx seventy movies with errors a gross incompatibility. I'm only aware of Rectal Prolapse with similar issues, rather than the entire thread being in an outcry?

I must admit that I've not tried this DVXA method, apart from several months ago attempting to use MPC-HC which wouldn't even play back a VC-1 stream correctly, so stuck with MPC and ffdshow for VC-1/Mpeg-2 and CoreAVC for H264.

Cheers,

-jj-

[Cyber-Mav]

iv tried the MPC HT DXVA approach and it failed miserably half the stuff i tried to run would resort to software based decoding.

CUDA is the best way since everything iv thrown at it works in hardware accelerated mode, some videos which arent compliant show up artifacts and blockyness but are still hardware accelerated. that shows the robustness of coreavc cuda.

im sure in the up comming bug fix versions these minor problems will be addressed, i treat coreavc 1.9.0 as a taster of whats to come, and thanks to the power of CUDA a lot of the old systems i have in the house wont need to be replaced for HD video acceleration, just a cuda card to do the business.

excellent work Betaboy on your continued support for coreavc, at $15 its a bargain that no HD viewer should pass up on.

[Rectal Prolapse]

I'm only aware of Rectal Prolapse with similar issues, rather than the entire thread being in an outcry?

Funnily enough, the first two titles I tried with the new CoreAVC had those blocking issues. At that time, it would be a 100% failure rate. :)

I later tried 2 more titles and those were okay (lower bitrate titles incidentally). So now the failure rate is 50% from my point of view. That's not so good hahaha! But hey, I was expecting this so am not too bothered by it. It isn't like PowerDVD's h264 decoder (with h/w acceleration) which is 100% reliable for me - it would be unreasonable for me to expect coreavc to even be close to that at this point in time. CUDA is very new, and there WILL be titles it will not work on.

[me7]

Is the CUDA acceleration incompatible with the Windows 7 beta? I just installed CoreAVC 1.9 and the newest nVidia drivers that add CUDA support (179.48_notebook_winvista_32bit_beta) on my notebook. It has a 8400M GS that is supposed to support CUDA but the option in CoreAVC is greyed out.

[STaRGaZeR]

STaRGaZeR... point taken but I disagree. I'm not sure you see the full picture. CoreAVC 2.0 will shed even more light on this.

I don't know what CoreAVC 2.0 will be or will do, and more importantly when (given your past historial), so please accept the complaints until then :p. The current product is like people in this thread is describing, when the bugs are ironed out don't worry, everybody will say how great and bug free CoreAVC is like with everything else.

With CUDA enabled on a direct BD Rip ("Hostage") at 25Mb birate only 3%-14% CPU. Great job!! (http://forum.corecodec.com/viewtopic.php?f=3&t=1750)
I tried it and it works perfectly! The CPU usage dropped from 25-30% to 5-10%. Nice job guys ! (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=60#p8972)
Just threw a 720p copy of Indiana Jones and the Crystal Skull at it, uh, 3-5% CPU usage with CUDA working, WOW :) (http://forum.corecodec.com/viewtopic.php?f=3&t=1724&st=0&sk=t&sd=a&start=30#p8889)
Shockingly the transformers rip i made played fine and thats using the unrestricted profile. (http://forum.doom9.org/showthread.php?p=1248171#post1248171)
Not everyone is experiencing problems. Generally with software you will get feedback from 10% of the happy users and 90% of the unhappy users.
Not really true, as jj666 and leeperry have noted the CUDA issues have been sorted but a new release isn't out yet because there's some small unrelated things to fix/add.

It's the same for DXVA. You're using the same piece of hardware in the end, just accessed through different APIs. If there are issues in one side and in the other don't it's probably because of a faulty implementation, drivers or whatever.
Also what feedback do you need from the happy users? That's obvious.
Is the field order issue in your list? Because it's been said over and over, you keep saying it's not a problem when it is and BetaBoy has never responded to it AFAIK.

Additionally:
- Supports up to 15 reference frames (I have asked several people who say this isn't working for samples, and have received none. Please contact me via PM if you think you have such a sample).

It's the same for DXVA, ask MPC developers about how they removed the ref frames limitation when the driver for L5.1 support was released. There are still problems though, you can find samples in the MPC thread. But still there are people that just max out x264 and just can't get hardware decoders to work with their encodes, and they're within the H.264 specification and played perfectly by software decoders. That's THE limitation of DXVA and CoreAVC CUDA.

- Can be used when a renderer isn't in the directshow graph at all, such as in an avisynth script feeding x264 or any other application that supports generic directshow filters (i.e. virtualdub directshow plugin)
- Doesn't rely on the directshow architecture, so companies licensing the CoreAVC library can still use it
There are also the post-processing options that are built into the filter, such as output colorspace selection, software deinterlacing, input/output levels selection and the brightness/contrast/saturation settings.

Indeed, that's THE advantage of CoreAVC, as I wrote in my previous post. You can get the same and more postprocessing options with ffdshow or any other filter. On a side note CoreAVC doesn't do proper chroma upsampling when outputting RGB32, something that can be easily achieved with ffdshow. In my book that makes the option useless.

I tested over 2tb of Blu-ray remuxes and posted 3 incorrectly displayed movies, of which two were fixed in one day and the last a day later.

Actually that's funny, because Blu-ray should be error free since the beginning. There is nothing problematic in there that the VPx can't handle. Try some strange x264 options and you'll find the limitations very fast.

CUDA is the best way since everything iv thrown at it works in hardware accelerated mode, some videos which arent compliant show up artifacts and blockyness but are still hardware accelerated. that shows the robustness of coreavc cuda.

Just in case you don't know, that's done on purpose. The MPC devs don't want any kind of blokiness if possible, so for those situations it falls back to software decoding. Who cares if it's accelerated if half the stuff that is accelerated is bloky or something? If you want to do an apples to apples comparison try Cyberlink's decoder or similar, those will use DXVA regardless of the source. That or you can compile your own MPC without the limitations and force DXVA always.

[squid_80]

It's the same for DXVA, ask MPC developers about how they removed the ref frames limitation when the driver for L5.1 support was released. There are still problems though, you can find samples in the MPC thread. But still there are people that just max out x264 and just can't get hardware decoders to work with their encodes, and they're within the H.264 specification and played perfectly by software decoders. That's THE limitation of DXVA and CoreAVC CUDA.
The MPC devs don't want any kind of blokiness if possible, so for those situations it falls back to software decoding.
I'm not really following here, you seem to say the MPC developers removed the reference frame limitation but then say it falls back to software in certain situations. I was under the impression that the reference frame limitation is enforced in the DXVA filter and this is the primary reason it falls back to software.
Also as I said if anyone has any samples with 15 ref frames or less that are failing with CoreAVC+CUDA (freezing or showing green blocks) I would like to see them.

[Sulik]

Also, a lot of so-called "DXVA" issues are actually DPB management problems in MPC-HC (I've said this from the beginning). Anything that uses MMCO and/or long-term references will not decode correctly in MPC-HC, due to the way MPC-HC manages reference frames.

[ranpha]

I'm not really following here, you seem to say the MPC developers removed the reference frame limitation but then say it falls back to software in certain situations. I was under the impression that the reference frame limitation is enforced in the DXVA filter and this is the primary reason it falls back to software.
Also as I said if anyone has any samples with 15 ref frames or less that are failing with CoreAVC+CUDA (freezing or showing green blocks) I would like to see them.

I have already PM'ed you the links to sample files that has freezing and green flashings. For me CoreAVC CUDA is at best, alpha version. It fails with so many of my test files (north of 90%) that works with MPC-HC DXVA it wasn't even funny. I expect this to improve with the next iterations of CoreAVC 1.9.x.x or else it may well affect my plans to buy an upgrade to 2.0.

[MatMaul]

Also, a lot of so-called "DXVA" issues are actually DPB management problems in MPC-HC (I've said this from the beginning). Anything that uses MMCO and/or long-term references will not decode correctly in MPC-HC, due to the way MPC-HC manages reference frames.
can we have complete explanation on what is the problem in the MPC-HC thread so we can fix it ?
thanks in advance :)

[paulvdb]

Is the CUDA acceleration incompatible with the Windows 7 beta? I just installed CoreAVC 1.9 and the newest nVidia drivers that add CUDA support (179.48_notebook_winvista_32bit_beta) on my notebook. It has a 8400M GS that is supposed to support CUDA but the option in CoreAVC is greyed out.
CUDA is enabled for me in Windows 7 x64. I have a 9400 GT card. But is it not supposed to work for all h264 content? The tray icon turned green to indicate that it uses CUDA when I played a 720p mkv that was encoded with x264. But it did not use CUDA on a ts that I recorded from BBC HD.

[TheShadowRunner]

Currently, interlaced contents decoding falls back to full software mode afaik.

[me7]

CUDA is enabled for me in Windows 7 x64. I have a 9400 GT card. But is it not supposed to work for all h264 content? The tray icon turned green to indicate that it uses CUDA when I played a 720p mkv that was encoded with x264. But it did not use CUDA on a ts that I recorded from BBC HD.

I mean the settings, not the tray icon
http://img179.imageshack.us/img179/726/screenshotvq8.th.jpg (http://img179.imageshack.us/my.php?image=screenshotvq8.jpg)
CUDA is greyed out here although I have the 179.48 driver from February 11th and the nvcuda.dll is in my System32 folder. Seems like Win 7 is not the issue.
nVidia says (http://www.nvidia.com/object/geforce_8400M.html) that the 8400M supports PureVideo HD, and according to wikipedia (http://en.wikipedia.org/wiki/Purevideo) the G84 supports VP2. What could be wrong?

[Cyber-Mav]

just a heads up for everyone, Nvidia have released the latest official WHQL driver version 182.06 now, im gonna grab that and see what version of the cudavid library it uses.


got the new driver installed now not done any testing yet but the nvcuvid.dll file is a different version, only slightly though.
driver 182.05 beta had file version 6.14.11.8205 and the new driver has nvcuvid.dll version 6.14.11.8206 and vista is using version 7.15.11.8206

[paulvdb]

Thanks, TheShadowRunner. That explains why BBC HD and also ITV HD don't work with CUDA.

me7, I think you need a newer version of the Nvidia drivers. I don't think 179.48 included nvcuvid.dll. I think until now only the beta drivers included that file. But if 182.06 is now the latest non-beta release you can use that.

[me7]

me7, I think you need a newer version of the Nvidia drivers. I don't think 179.48 included nvcuvid.dll. I think until now only the beta drivers included that file. But if 182.06 is now the latest non-beta release you can use that.

182.06 is desktop only, 179.48 (http://www.nvidia.com/object/geforce_notebook_winvista_179.48_beta.html) is the newest laptop beta version from February 11th that does include CUDA support (see link) and the nvcuda.dll was installed to my System32 directory.

@BetaBoy: are mobile drivers maybe unsupported?

[nm]

182.06 is desktop only, 179.48 (http://www.nvidia.com/object/geforce_notebook_winvista_179.48_beta.html) is the newest laptop beta version from February 11th that does include CUDA support (see link) and the nvcuda.dll was installed to my System32 directory.
And what about nvcuvid.dll, was it installed too?

[STaRGaZeR]

I'm not really following here, you seem to say the MPC developers removed the reference frame limitation but then say it falls back to software in certain situations. I was under the impression that the reference frame limitation is enforced in the DXVA filter and this is the primary reason it falls back to software.
Also as I said if anyone has any samples with 15 ref frames or less that are failing with CoreAVC+CUDA (freezing or showing green blocks) I would like to see them.

The removed the limitation only for NVIDIA cards and only if the driver with L5.1 support or newer was installed. That was several months ago. MPC-HC is 1-1,5 years old. I can't know when Cyber-Mav tested DXVA and was so disappointed because it fell back to software mode, so I answered in consequence. And yes, number of reference frames is usually why DXVA is not used. For other cards there is an absolute ref frame limit at 11 (or 12, can't remember) imposed by the devs, but that's because MPC's DXVA decoder can't properly handle them and it's not a hardware or DXVA limitation.

[squid_80]

The removed the limitation only for NVIDIA cards and only if the driver with L5.1 support or newer was installed. That was several months ago.
I can't verify this since using build 998 it falls back to software for any stream with more than 11 references (9600GT).

[me7]

And what about nvcuvid.dll, was it installed too?

No, that .dll is missing. Sounds like a definitive NO for mobile cards (at least until nVidia updates their drivers) :mad:

[STaRGaZeR]

I can't verify this since using build 998 it falls back to software for any stream with more than 11 references (9600GT).

I stand corrected with exceptions:

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=867

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=857

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=975

The 11 ref frames limit is still there even for NV cards with L5.1 support in certain scenarios, here (http://forum.doom9.org/showpost.php?p=1251180&postcount=4537) is the explanation.

[Cyber-Mav]

iv installed media player classic last week and was doing more testing on it this week. one thing is sure though, MPC HC does have lower cpu usage than coreavc cuda and it does not get blocky/artifacting in videos like coreavc cuda does. however 3 videos i tried have resorted to software playback on MPC whereas they stay hardware accelerated with coreavc cuda but have few blocking/artifacting issues.

version of MPCHC i use is: MPC-HC v1.2.908.0 / 32 bits November 29, 2008

nothing newer on the sourceforge site. and mpc seems to have massive memory usage, dunno if its a memory leak or something.

[STaRGaZeR]

Yep, the memory leak is impressive.

Try the newest builds available at http://www.xvidvideo.ru/content/category/1/1/2/, you can also try the standalone DXVA filter in your player of choice.

[Cyber-Mav]

my word that link you gave stargazer is got a far newer version that what im using.

[smit]

Using the latest build i`m having masive audio dropouts when i`m sending SPDIF to an external amp.

As it seems there is a problem with the latest Haali spliter and CUDA.
When i enable MPC-HC`s internal splitter in conjunction with CUDA everything is ok.

Hardware
Mobo Gigabyte GA-MA78GM-S2H - http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2758
VGA Gigabyte GV-NX86T512H - http://www.gigabyte.com.tw/Products/VGA/Products_Overview.aspx?ProductID=2604

Software
Vista 32bit
MPC-HC 1.2.908 final and 1.2.989 beta
CoreAVC 1.9
AC3 filter 1.51a
Slysoft Reclock 1.8.3.4


I tried many combinations and different options in my software setup but audio dropouts continued to occur quite frequently..I changed AC3filter to reencode the signal.I disabled Reclock.I did every possible combination i could think.I must add that it is the same for DTS and DD.

Only when i disable Haali or CUDA the sound is ok.

.

[leeperry]

am I the only one getting a slight freeze for a few seconds when I start a movie in CUDA mode ? running XP SP3 w/ the latest CoreAVC/KMPlayer betas.
it works fine in software mode....it feels as if there were some lag/latency to start the CUDA communication :confused:

I'm using Reclock in 24Hz and a winamp2 plugin in ffdshow, so it's like they were all trying to initiate simultaneously...freezing the system until they're all synchronised :o

even HR's jitter starts at +1000ms and quickly comes down to <8ms, so it means that the start was laggy to hell..

PS: a friend of mine also gets terrible jitter in HR when he starts a movie in CUDA mode.

[BetaBoy]

lee... I'm not seeing there here. Your running the new Beta Build?

[leeperry]

yup! there's some latency when the CUDA communication starts, is there a way this could be shortened?

[me7]

I installed the 182.06 drivers on my laptop (thanks to laptopvideo2go) and CUDA in now available in CoreAVC. Playback of low res and bitrate files works rather well but if I feed it some 1080p content the video stutters like hell.
Does someone know if mobile GPUs have 'inferior' VP2 units? My 8400M GS (G86) is supposed to have VP2, but the playback is far from smoth.

[buletti]

BetaBoy could you please give some more details about the requirements that have to be met to use CUDA respectively to get the green icon? The driver and hardware requirements are quite clear but I wonder if there are other requirements like output color spaces or demands regarding the used renderer.
In my usecase I decode H264 to YV12 and use FFDShow's raw video filter to apply heavy post processing via Avisynth prior to the rendering. I'd love to outsource the decoding to the GPU and save the CPU cores for the post processing. But until now the decoding had to be done in software as DxVA was not usable with this filter chain because of the close decoder-renderer coupling. So, I had high hopes that the new CUDA decoding would not have these restrictions anymore. But as I get it, the DxVA limitations do also apply to the CUDA implementation? Is this because the new coreAVC version is not doing any decoding in software on the GPU hardware but is relying on the hardware decoder like DxVA?

[leeperry]

But as I get it, the DxVA limitations do also apply to the CUDA implementation?
you can decode in CUDA and apply Avisynth PP in ffdshow, I do it all the time :p

[buletti]

I checked the trail version and it works with FFDShow and AviSynth :D For some streams I get the green icon, for some other streams I get the blue icon. I compared the streams with MediaInfo and checked profile, reference frame count, encoder options etc. but could not come up with a stream attribute that would determine the decoding path (except for interlaced streams which are software only atm). So, what are the prerequisites for a stream to be decodable via CUDA?

[zoose]

With the latest stable drivers (182.06) under XP SP3 with a GTX 260 I get decoding errors at around the 3 second mark with the following clip.

http://www.mediafire.com/?djlldagrwdg

Works fine with:
CoreAVC software mode
MPC HC both DXVA and software decoders

[neuron2]

Works fine in DGAVCDecNV, so it's not a CUDA decoding problem.

[chros]

VMR9 renderless bug: latest CoreAVC applies more level correction than it requires (darker) ... No problem with EVR Custom ... (using MPC-HC) (all options is Auto )
OS: WinXP

[SixKiller]

For me Cuda isnt working at all. The Option is enabled, and the newest 182.06 Drivers are installed. But the Icon never turns green, it stays blue, no matter what material i feed. HDTV 1080i or 720p. Bluray h.264 or reencoded x264 mkv. Always stays blue ...Any Ideas?

Btw using Vista x64 with 8800 GTX an c2Q @ 3.0 Ghz.

Greetings

Six

[neuron2]

8800 GTX has VP1 and so won't work. See here:

http://en.wikipedia.org/wiki/PureVideo#Table_of_PureVideo_.28HD.29_GPUs

You need VP2 or better.

[Gleb Egorych]

VMR9 renderless bug: latest CoreAVC applies more level correction than it requires (darker) ... No problem with EVR Custom ... (using MPC-HC) (all options is Auto )
OS: WinXP
VMR7 is OK too (WinXP SP3).

Edit: It's strange, I don't have the problem with VMR9 renderless. CoreAVC settings: Input levels AUTO, Output levels FORCED TV, Forceware 182.06 Output levels FORCED PC. Both VMR7 and VMR9, both Cyberlink H.264 and CoreAVC have same picture. Seems like the bug is in CoreAVC Output Levels AUTO.

[yesgrey]

@BetaBoy,
I believe you know that YUV is not the correct designation (it's an analog format), that the digital format correct designation is YCbCr (to be exact, is Y'CbCr, but since we also don't use R'G'B', I think it's ok to drop the ' from the Y).
I think it would be a good idea if you use the correct designation in your decoder dialogs. It would help stop spreading this misinformation...;)

[BetaBoy]

@BetaBoy,
I believe you know that YUV is not the correct designation (it's an analog format), that the digital format correct designation is YCbCr (to be exact, is Y'CbCr, but since we also don't use R'G'B', I think it's ok to drop the ' from the Y).
I think it would be a good idea if you use the correct designation in your decoder dialogs. It would help stop spreading this misinformation...;)
Sure... this was a decision we made early on based on "what ppl know as ..." and YUV is what we decided (I think Haali had the final say on this one). I'll throw it around internally and see what they think.

[me7]

Am I the only one with a VP2 GPU who gets extreme stuttering (2~3 fps)? Here are the filters used by MPC-HC:
http://img26.imageshack.us/img26/4139/filters.th.jpg (http://img26.imageshack.us/my.php?image=filters.jpg) I don't see anything that could cause trouble.
System: Geforce 8400M GS (with desktop drivers, installed with modded nv_disp.inf from laptopvideo2go), T8300 (Penryn 2,4 GHz), 3GB Ram, Vista SP1 32bit

[yesgrey]

this was a decision we made early on based on "what ppl know as ..."
There was a time that "what ppl know as ..." the center of the universe was the Earth.:)
I also always called him YUV, until recently, when I realized that it was wrong. If nobody starts correcting it, people will continue to "know it as...". In ffdshow it was recently corrected (also by my suggestion), and it would be good if Haali also corrects it in his Renderer...;)

[neuron2]

You're being pedantic. Historically you are correct, but time advances and usage evolves. Today, the term YUV is commonly used to describe formats that are encoded using YCbCr.

Anyway, it's pissing up a rope. I tried for a while to stop people from saying "I could care less" instead of the correct "I couldn't care less". Totally futile.

Go with the flow, the meaning is clear in the context used.

[yesgrey]

You're being pedantic.
I have posted my opinion without ofending anyone, just joked a little with the Earth example. If I have offended anyone, I apologize here, I did not intend that.
You could have wrote exactly what you had without this initial phrase, and I would agree with part of it, but you haven't.
So, use whatever you want, but don't start offending people. I'm done with this.

[neuron2]

http://dictionary.reference.com/browse/thin-skinned

[leeperry]

I'm done with this.
easy buddy http://forum-images.hardware.fr/images/perso/julm3.gif

ffdshow is a tool aimed at power users, CoreAVC is a fast h264 decoder....not the same target...a major part of its users prolly got no idea what Y'CbCr actually is :D

like ppl calling 90-20Hz infrabass, infrabass is <20Hz if you wanna respect the true jargon :o

[Sagekilla]

If you wanna get technical, infrasound is frequencies below <20 Hz to respect the "true jargon" ;)




* Sorry for poking fun at you leeperry, I was just trying to show how pointless it is to get caught up in semantics. No offense :)

[leeperry]

If you wanna get technical, infrasound is frequencies below <20 Hz to respect the "true jargon" ;)
http://forum-images.hardware.fr/images/perso/julm3.gif


http://forum-images.hardware.fr/images/perso/justin_bridou.gif

[ADude]

Are there any performance improvements to the software decoder in 1.9.0 or is the hardware acceleration (and other fixes mentioned in the change list) the only difference ?

[leeperry]

ouh...the latest beta works like a charm :cool:

I've got some ski ORF1 german broadcasts in 720p@50 that were giving slight pixelation when seeking, but this is now history...also seeking in KMP is just as fast as in software mode, and I can't see much latency remaining when the movie starts. way to go! :p

:thanks:

[TheShadowRunner]

With CUDA enabled I sometimes have a green screen after switching resolutions "live" (while a movie is playing, needed for ReClock).
Happened at some point in full software mode in previous builds but was finally fixed in 1.8.5.0.
Hopefully, you (CoreCodec) can test this for the next 1.9.x version with CUDA enabled.
Thanks.
Later,

TSR

[tahir]

CUDA is greyed out at settings.

I have GeForce 8600GTS
Windows XP SP3
Driver version 181.22

in C:\windows\system32
nvcuda.dll 6.14.11.8122

what am i doing wrong ?

[BetaBoy]

* You will also need drivers 182.05 or higher from NVIDIA

[me7]

BetaBoy, are mobile GPUs (like my 84000M GS) even supported?

[lucassp]

Yes, your 8400M GS is supported.

http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

You can use GPU-Z to find out which GPU do you have:

http://www.techpowerup.com/downloads/SysInfo/GPU-Z/

[ADude]

Are there any performance improvements to the software decoder in 1.9.0 or is the hardware acceleration (and other fixes mentioned in the change list) the only difference ?

[DJ Bobo]

@ BetaBoy
I see the hardware requirements have been updated on the website to include the supported GPUs, but the main issue remains: the recommended hardware is set way too low! You're still recommending a P4 for 1080p videos! How do you guys test at CoreCodec?! I don't think you can recommend anything below a dual core for this. As said, my Athlon X2 @1.9GHz, which is roughly equivalent to a Pentium D @3.2GHz (I can't emphasize the D enough!), averages 70 to 75%. There is no way a P4 could handle this!

[ranpha]

@ BetaBoy
I see the hardware requirements have been updated on the website to include the supported GPUs, but the main issue remains: the recommended hardware is set way too low! You're still recommending a P4 for 1080p videos! How do you guys test at CoreCodec?! I don't think you can recommend anything below a dual core for this. As said, my Athlon X2 @1.9GHz, which is roughly equivalent to a Pentium D @3.2GHz (I can't emphasize the D enough!), averages 70 to 75%. There is no way a P4 could handle this!

If you have a supported GPU, you can get away with a Celeron 1.6Ghz even for a high-bitrate 1080p video, easily. Maybe the website should explicitly specify that for those that do not have supported GPUs, should have a dual-core or something like that.

[lucassp]

As said, my Athlon X2 @1.9GHz, which is roughly equivalent to a Pentium D @3.2GHz (I can't emphasize the D enough!), averages 70 to 75%. There is no way a P4 could handle this!

Back when I had a Athlon64 2800+ S754, I used to play 1080p content from Apple Trailers with an average of 80% of CPU load. I didn't have any complex videos to test with.

[DJ Bobo]

Here a graph showing the CPU charge when playing the Seven Pounds 1080p trailer (http://showcase7.divx.com/SevenPoundsTrailer[DivX7].mkv) from the DivX site:
http://img408.imageshack.us/img408/6706/cpuusage1080p.gif (http://imageshack.us)
* Durchschnitt = Average

This trailer should be pretty much representative for your typical DVD-9 1080p rip (80MB per minute)
I wouldn't recommend anything below an Athlon X2 3800+ or equivalent.

[adiabatic]

@ BetaBoy
I see the hardware requirements have been updated on the website to include the supported GPUs, but the main issue remains: the recommended hardware is set way too low! You're still recommending a P4 for 1080p videos! How do you guys test at CoreCodec?!

I had no problem playing 1080p content with a P4 2.4 and CoreAVC two years ago. There's every reason for me to think the decoder has gotten better in those two years. There's a lot of variety in bandwidth for 1080p though... I have some high-ref frame x.264 stuff that I know wouldn't play on that P4.

[tetsuox]

I have some high-ref frame x.264 stuff that I know wouldn't play on that P4.

Unless I'm mistaken, High Ref. frames uses more memory, not more CPU.

[~bT~]

I had no problem playing 1080p content with a P4 2.4 and CoreAVC two years ago. There's every reason for me to think the decoder has gotten better in those two years. There's a lot of variety in bandwidth for 1080p though... I have some high-ref frame x.264 stuff that I know wouldn't play on that P4.

1080p with p4 & coreavc (with cuda) should be fine.

i used to play them before on my p4 with coreavc.

[DJ Bobo]

I don't know what kind of trailers you were watching, but I remember having trouble playing 720p stuff on a P4@3GHz!! It would play alright until there is a lot going on on the screen.
Check the Apple 720p trailer in this page (http://www.apple.com/quicktime/guide/hd/bbc-nhk.html) for example (since some people here seem to consider Apple trailers as a reference!). Its bitrate comes close to what you would expect from a DVD-5 720p rip. The scene with a lot of people coming together at the end would choke the aforementioned P4, even when decoded with CoreAVC!
So even the 720p "recommended requirements" are too low. I would recommend here at least a P4@3.2GHz (or Athlon XP 3200+)
But 1080p is definitely out of the league of single-core CPUs!

CUDA is another story. The so called "recommended" requirements were there long before CUDA even existed.
I thought may be it's time for CoreCodec to update those recommendations to fit the reality, may be 2 recommendations: with and without CUDA?

[Shinigami-Sama]

I was playing downscale 1080p on my P4...
I needed to OC up to 3.4ghz to get it to play though, other wise it would drop frames all the time
rather than just every 30seconds or so

[carlo_0000]

and any chance to have dxva with ati cards (hd2400pro) in the next version ?

because i m still waiting for a codec for my mediacenter

cpu is not sse2 so powerdvd did not work with dxva
seperon2200+ soket A

and codec of mpchc do not work correctly with dvb (1080i) 720p/1080p is ok

and software decoder is to slow


I was playing downscale 1080p on my P4...
I needed to OC up to 3.4ghz to get it to play though, other wise it would drop frames all the time
rather than just every 30seconds or so

3.4ghz and stil to slow ?

on my athlon 64 2800+ (oc @ 2560mhz) gf5200 i can play 1080p with 8mbit/s videobitare and coreavc without lag (all programe and tray icon must be closed) cpu 90-96%

[Dark Shikari]

3.4ghz and stil to slow ?

on my athlon 64 2800+ (oc @ 2560mhz) gf5200 i can play 1080p with 8mbit/s videobitare and coreavc without lag (all programe and tray icon must be closed) cpu 90-96%An Athlon 64 is not a Pentium 4.

[Shinigami-Sama]

p4 sucks and that was with lavc
now I use dxva

[Dark Eiri]

Well, I can watch 720p video flawlessly with an AMD Turion TK-36, single core, 2.0 GHz with no lag at all, decoded with CoreAVC. No DXVA here. So I think there's something wrong with a Pentium 4 @ 3 GHz not playing it.

[Dark Shikari]

Well, I can watch 720p video flawlessly with an AMD Turion TK-36, single core, 2.0 GHz with no lag at all, decoded with CoreAVC. No DXVA here. So I think there's something wrong with a Pentium 4 @ 3 GHz not playing it.An Athlon 64 at 2Ghz is significantly faster than a P4 at 3Ghz.

And the above people were talking about a P4 playing 1080p, not 720p. 1080p is 2.25x harder to decode than 720p.

[Dark Eiri]

I was talking about this:

So even the 720p "recommended requirements" are too low. I would recommend here at least a P4@3.2GHz (or Athlon XP 3200+)

[DJ Bobo]

@ Dark Eiri
A Turion 2GHz is roughly equivalent to a 3.4GHz P4! so there is nothing wrong with a 3GHz P4 having problems ;)

@ Shinigami
DXVA doesn't always work, does it? ;)

@ carlo
An Athlon 64 isn't 2800+ anymore if overclocked to 2.5GHz, it is even faster than an Athlon 64 4000+!
Could you tell us your average load with the Seven Pounds trailer please? with a graph if possible. I can't imagine your CPU not maxing out.

[Dark Eiri]

@ Dark Eiri
A Turion 2GHz is roughly equivalent to a 3.4GHz P4! so there is nothing wrong with a 3GHz P4 having problems ;)


That's good to know, I always saw it as a 'big' Celeron. :p
Thanks for the info!

[carlo_0000]

@ Dark Eiri
A Turion 2GHz is roughly equivalent to a 3.4GHz P4! so there is nothing wrong with a 3GHz P4 having problems ;)

@ Shinigami
DXVA doesn't always work, does it? ;)

@ carlo
An Athlon 64 isn't 2800+ anymore if overclocked to 2.5GHz, it is even faster than an Athlon 64 4000+!
Could you tell us your average load with the Seven Pounds trailer please? with a graph if possible. I can't imagine your CPU not maxing out.

dou you have a download link ?

beause i search google , found only video for quicktime, i don't like quicktime and probably do not use coreavc, and i was unable to download the .mov (only 96ko)

[DJ Bobo]

You can find the link in the previous page, where I posted the graph. Just click on "Seven Pounds"

[carlo_0000]

@ original speed 1.8G

not fast enough and some lag

pict: http://ftp1.dommel.be/picture_library/1800mhz.JPG


oc 2.5ghz

didn't hit 100% when playing

pict: http://ftp1.dommel.be/picture_library/2500mhz.JPG


and on my athlon x2 4200+ (olso oc @ 2.5ghz) cpu usage is 20-24%

[BetaBoy]

DJ Bobo, yes we updated the requirements page.... but it is hard to balance the 'recommended' requirements to real life usage. For example the requirements page is based on non paff/mbaff content, ie; typical content for Apple trailers. We can refine it more for sure.... any recommendations? I am willing to have the community, ie; d9 rewrite what we should put there.

[ChronoCross]

DJ Bobo, yes we updated the requirements page.... but it is hard to balance the 'recommend' requirements to real life usage. For example the requirements page is based on non paff/mbaff content, ie; typical content for Apple trailers. We can refine it more for sure.... any recommendations? I am willing to have the community, ie; d9 rewrite what we should put there.

If you let the d9 community write it, it will be a 12 page document chronicaling every feature available in the h264 spec and what's viewable in different resolutions on 30 different processors. Might be a bit of overkill for a more non-power user audience.

[DJ Bobo]

@ carlo
Something's wrong here. You sure you're not using DXVA? 'cause the Seven Pounds Trailer would play in DXVA mode if you don't disable the correpondant option in MPC-HC.
There can't be so much difference between a 1.9GHz X2 (70-75%) and a 2.5GHz X2 (20-25%)

@ BetaBoy
I guess you can do it like most game editors would: minimum and recommended requirements. The minimum would correspond to what you have on the website right now, the recommended to what is common among the scene, may be something close to the DivX Plus HD profile at common bitrates (5 to 6 Mbit/s for 720p content (eq. to a DVD-5 rip) and 9 to 10 Mbit/s for 1080p content (eq. to a DVD-9 rip)).
Sure, you won't make everybody happy, there are always the 5% that won't agree ('cause they're using unusual settings), but at least the requirements would be much more realistic.
If you can't decide on what is "common", I guess you could always post a poll with several encoding options and then go with the majority and base the recommended requirements on that.
Cheers

[_DW_]

DJ Bobo, yes we updated the requirements page.... but it is hard to balance the 'recommend' requirements to real life usage. For example the requirements page is based on non paff/mbaff content, ie; typical content for Apple trailers. We can refine it more for sure.... any recommendations? I am willing to have the community, ie; d9 rewrite what we should put there.

The requirements look fine to me but you might want to add under CPU something to the effect of "or equivalent AMD processor." Someone who is cursing through your site might just assume you don't support AMD processors and move on.

May sound silly but it can happen and adding a few words like that will prevent that.

[lucassp]

you could also add 8800 GTS 512 to the supported CUDA graphic cards.

[BetaBoy]

_DW_, lucassp.... suggestions added to the page.... DJ Bobo... thanx for the input, we will consider it.

CC.... yeah, but that's why I enjoy D9 as much as I do.

[lucassp]

_DW_, lucassp.... suggestions added to the page.... DJ Bobo... thanx for the input, we will consider it.

I did make the 512 bold for a reason :) The 320/640 have the old G80 core which does not have VP2, while the 512 version is based on G92 core and does have the VP2 decoder.

[BetaBoy]

changed

[DJ Bobo]

The requirements look fine to me but you might want to add under CPU something to the effect of "or equivalent AMD processor." Someone who is cursing through your site might just assume you don't support AMD processors and move on.

May sound silly but it can happen and adding a few words like that will prevent that.

What was that? Are you even following the discussion? This is not about "or equivalent", this is about requirements being unrealistic. It won't change anything if they would put "or equivalent AMD processor" because an Athlon 64 2800+ is equivalent to a P4@2.8GHz and both are absolutely not sufficient to play 1080p!

Unbelievable! :mad:

[_DW_]

What was that? Are you even following the discussion? This is not about "or equivalent",

Apparently not. I made a suggestion and it looks like it was taken. There was an open call to make suggestions, I made one. If you don't agree please feel free to make another suggestion. Personal attacks do nothing but lower the value of your character and contribute nothing to the discussion at hand.

I also don't think a AMD 2800+ is "equivalent" to P4@2800 but I think I'm bias....:p

[carlo_0000]

@ carlo
Something's wrong here. You sure you're not using DXVA? 'cause the Seven Pounds Trailer would play in DXVA mode if you don't disable the correpondant option in MPC-HC.
There can't be so much difference between a 1.9GHz X2 (70-75%) and a 2.5GHz X2 (20-25%)

@ BetaBoy
I guess you can do it like most game editors would: minimum and recommended requirements. The minimum would correspond to what you have on the website right now, the recommended to what is common among the scene, may be something close to the DivX Plus HD profile at common bitrates (5 to 6 Mbit/s for 720p content (eq. to a DVD-5 rip) and 9 to 10 Mbit/s for 1080p content (eq. to a DVD-9 rip)).
Sure, you won't make everybody happy, there are always the 5% that won't agree ('cause they're using unusual settings), but at least the requirements would be much more realistic.
If you can't decide on what is "common", I guess you could always post a poll with several encoding options and then go with the majority and base the recommended requirements on that.
Cheers


no and no it s full software, my video card is fx5600 it does not support dxva

and olso it s coreavc codec 1.8 (no dxva)

and you sayed before 64 2800+ oc @ 2.5g = 4000+ that s no possible, 4000+ is faster and had more cache , it s more = to a 3400+ (maybe litle slower)

and on my athlon x2 4200+ there is olso no dxva (geforce 7600gt)



i think it s something wrong with your computer

and when i disable 1 core i taskmanager, i can still play 1080p with 40% cpu usage (80% for the used core)



i olso did some test, on my media center seperon 2200+ soket A readon hd2400pro

i underclock the cpu @ 900mhz, and i was still able to play a bluray with dxva, codec of mpchc (cpu around 75%)
1080p (1080i i can't play it it s corrupt deinterlace probleme)

[DJ Bobo]

@ BetaBoy
Thanks

@ DW
Whatever

@ carlo
That's impossible. No way an AVC Blu-Ray would run on a 900MHz CPU, even when backed up with a Radeon HD. You sure your blu-ray disc is not MPEG-2?
As for your A64 being faster than a 4000+, it's based on the frequency, the first 4000+ was a 2.4GHz CPU.
Anyway, it's like you're telling me that a single A64 @ 2.5GHz is equivalent to my X2 @ 1.9GHz. This can mean one of the 3 things:
1) My laptop is busted => can't be, check the 6th page (http://forum.doom9.org/showthread.php?t=135923&page=6) of the x264 benchmark: my results are better than steelista's Pentium D @ 3GHz.
2) CoreAVC is not well optimized for multi-threading? I guess I'll leave this one to BetaBoy to answer (only 33% boost with a second core?!)
3) Your player is skipping frames to keep things running. That's for you to answer.

[Snowknight26]

That's impossible. No way an AVC Blu-Ray would run on a 900MHz CPU, even when backed up with a Radeon HD.

It's possible. Don't denounce it till you've tried it.

[nm]

That's impossible. No way an AVC Blu-Ray would run on a 900MHz CPU, even when backed up with a Radeon HD. You sure your blu-ray disc is not MPEG-2?
I think that's quite possible since he was apparently playing back a decrypted stream. MPEG-2 vs AVC shouldn't make a difference when using full hardware decoding.

As for software decoding of the 1080p trailer, 1 core of a 2 GHz Core 2 Duo (T7200) seems to be enough with libavcodec, which is in line with carlo's numbers except that he probably meant 40-48 % overall CPU usage with the X2 4200+ instead of 20-24 % (which wouldn't be realistic).

[DJ Bobo]

I'm not gonna argue with you guys about things you can learn from online reviews. You go check and you'll find that what he's claiming is impossible w/ AVC blu-ray discs. MPEG-2 is another story. A 1.8GHz Sempron is what it takes for blu-ray AVC with a Radeon HD3200 (http://www.tomshardware.com/de/AMD-780G-HDTV-Blu-Ray,testberichte-239963-3.html), probably a bit less with an HD2400pro, but definitely not 900MHz.

Back on topic: I just tested the Seven Pounds trailer on a Core 2 Duo @ 2 GHz too (roughly equivalent to Athlon X2 5000+), average was 46%, thanks for confirming that nm. I noticed that the second core was way more loaded than the first one, which may confirm my theory that multi-threading isn't well implemented in CoreAVC.
Guess we'll just have to wait for BetaBoy to comment on that.

[Dark Shikari]

I'm not gonna argue with you guys about things you can learn from online reviews. You go check and you'll find that what he's claiming is impossible w/ AVC blu-ray discs. MPEG-2 is another story. A 1.8GHz Sempron is what it takes for blu-ray AVC with a Radeon HD3200 (http://www.tomshardware.com/de/AMD-780G-HDTV-Blu-Ray,testberichte-239963-3.html), probably a bit less with an HD2400pro, but definitely not 900MHz.

Back on topic: I just tested the Seven Pounds trailer on a Core 2 Duo @ 2 GHz too (roughly equivalent to Athlon X2 5000+), average was 46%, thanks for confirming that nm. I noticed that the second core was way more loaded than the first one, which may confirm my theory that multi-threading isn't well implemented in CoreAVC.
Guess we'll just have to wait for BetaBoy to comment on that.The amount that your cores are loaded has absolutely nothing to do with CoreAVC and everything to do with your operating system's scheduler.

A better measurement of CoreAVC's threading would be how much each thread is loaded.

[ajp_anton]

An E5200 at 1200MHz is just a little bit too slow to decode the WallE Blu-ray with CoreAVC (from hard drive, .m2ts, decrypted).

[carlo_0000]

I'm not gonna argue with you guys about things you can learn from online reviews. You go check and you'll find that what he's claiming is impossible w/ AVC blu-ray discs. MPEG-2 is another story. A 1.8GHz Sempron is what it takes for blu-ray AVC with a Radeon HD3200 (http://www.tomshardware.com/de/AMD-780G-HDTV-Blu-Ray,testberichte-239963-3.html), probably a bit less with an HD2400pro, but definitely not 900MHz.

Back on topic: I just tested the Seven Pounds trailer on a Core 2 Duo @ 2 GHz too (roughly equivalent to Athlon X2 5000+), average was 46%, thanks for confirming that nm. I noticed that the second core was way more loaded than the first one, which may confirm my theory that multi-threading isn't well implemented in CoreAVC.
Guess we'll just have to wait for BetaBoy to comment on that.

ho no ? you don't know what you speeking about

are my print screen al fake maybe ????


here playing beyonce experience m2ts file , it s VC1 video bitrate 42 mbit/s

cpu 900mhz
gpu readon 2400pro

http://ftp1.dommel.be/picture_library/vc1%20beyonce.JPG


here some h264 from Within Temptation Black Symphony 20mbit/s


http://ftp1.dommel.be/picture_library/Within%20Temptation%20Black%20Symphony.JPG

only probleme, it does not deinterlace

[ADude]

Are there any performance improvements to the software decoder in 1.9.0 or is the hardware acceleration (and other fixes mentioned in the change list) the only difference ?

- Licensed CoreAVC Pro user

[BetaBoy]

ADude... read the thread (but it looks like you did). No perf mentions in the changelog.

[BetaBoy]

The amount that your cores are loaded has absolutely nothing to do with CoreAVC and everything to do with your operating system's scheduler.

A better measurement of CoreAVC's threading would be how much each thread is loaded.

Thx DS... you beat me ;-)

[meatwad]

Has anyone else experienced issues with older versions of coreavc using vmr9 or vmr7 after unregistering/uninstalling 1.9? Some streams will no longer work with older versions once 1.9 has been registered/installed. 1.9 is fine, but the seeking issues have become too distracting for me and I wanted to use 1.6 again (still the most compatible version with the player and htpc software I use). Anyway, I've tried unistalling all my codecs, but the issue is still there. 1.6 will work after 1.9 was installed, but it's hit or miss on whether it will display a tv stream if I use vmr9 or vmr7 (which of course means I lose deinterlacing if I use the generic overlay). Is there an easy fix or am I stuck with 1.9 for the time being?

[DJ Bobo]

@ Dark Shikari / BetaBoy
How would I do that? the idea jumped to my mind because somewhere along the changelog of CoreAVC there is something about better multiple core balance, which doesn't seem to work on the Core2 laptop (with XP), but seems to work fine on my X2 laptop (with Vista).

@ carlo
DXVA decoding is off topic, let's keep this for another thread.
But now that I've seen your new screens, I saw that you disabled deblocking. Could you have disabled deblocking in CoreAVC too? That may explain why your A64@2.5GHz is able to compete with my X2.

@ anton
And how much is needed to decode it properly from start to end? Mind you, my X2 should be slightly slower than a pentium dual core e2140 (1.6GHz).

[nm]

DXVA decoding is off topic, let's keep this for another thread.
But now that I've seen your new screens, I saw that you disabled deblocking.
Skip deblocking = "None" means that deblocking is not skipped.
Secondly, those are libavcodec settings and they don't have any effect on DXVA decoding. I don't think that the current ATI and NVIDIA hardware implementations even allow disabling in-loop deblocking by an user-controllable setting.

Remember that he is playing a previously decrypted stream. Playing Blu-ray directly from the disc with PowerDVD is another matter and that would require a somewhat faster CPU because of software AES decryption and other overhead.

[leeperry]

How would I do that? the idea jumped to my mind because somewhere along the changelog of CoreAVC there is something about better multiple core balance, which doesn't seem to work on the Core2 laptop (with XP), but seems to work fine on my X2 laptop (with Vista).
add this to your XP boot.ini, and update to SP3 of course :
/NOEXECUTE=ALWAYSOFF /FASTDETECT /USEPMTIMER /NODEBUG /TIMERES=9766
it will kill your batteries faster on a laptop, but it will also increase the system snappiness.

this is also a good idea, plus running your media player in high priority and all the background stuff in low(process.exe in a batch is your friend) :
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl]
"Win32PrioritySeparation"=dword:00000016

[DJ Bobo]

Skip deblocking = "None" means that deblocking is not skipped
Oh, got things mixed up, thanks for clarifying this (not good though, would mean that I go back to the "not well optimized" theory :devil:)

@ leeperry
Thanks, but the Core2 laptop is not mine, and I don't think my friend would like me "messing up" with the registry and boot files. I thought, it was about some program that can measure that...

[Gleb Egorych]

Betaboy, when the next version is planned to be released? As I understand all major 1.9.0.0 bugs are already fixed.

[BetaBoy]

Gleb Egorych... in general I no longer announce releases unless its 'on deck' and through QA. We are still working on interlaced support atm so the best I can say is that there is no release scheduled for this week.

[IgorC]

An E5200 at 1200MHz is just a little bit too slow to decode the WallE Blu-ray with CoreAVC (from hard drive, .m2ts, decrypted).
Did you downclock your E5200? Because its stock frequency is 2.5 Ghz. I get smooth playback of blu ray 30 Mbit/s on HDD with E2160.

BTW, nice avatar with Shrödinger's equations.

[BetaBoy]

Some clarification for those from DVinfo....
Input Levels
- TV (16-235): (ITU-R BT.601) always assume the stream uses TV levels.
- PC (0-255): (ITU-R BT.709) always assume the stream uses PC levels.
- Auto detect: use the full range flag in the stream to determine Luminance range.
Note: The input levels setting allows the overriding of the stream's colorspace setting and affects the conversion to RGB color space when it is done by the decoder.


TV = ITU-R BT.601
and
PC = ITU-R BT.709

This is now in our KB and will be added to the next update (within the help tab).

[leeperry]

TV = ITU-R BT.601
and
PC = ITU-R BT.709

This is now in our KB and will be added to the next update (within the help tab).
too bad this is false information.
SD = 601 / HD = 709...except FRAPS videos, there's no PC levels videos to begin w/

[squid_80]

too bad this is false information.
SD = 601 / HD = 709...except FRAPS videos, there's no PC levels videos to begin w/
What? You can't determine the colorspace used based just on the resolution.

There is a flag in the H264 stream that specifies if it is full range or not. This setting allows the decoder to ignore that flag.

[leeperry]

What? You can't determine the colorspace used based just on the resolution.

There is a flag in the H264 stream that specifies if it is full range or not. This setting allows the decoder to ignore that flag.
oh sure there's a flag....which is sometimes wrong from what I read?
Yes you can define the YCbPr decoding matrix depending on the resolution.

Rec. ITU-R BT.601-5 => SD(PAL/SECAM/NTSC)
Rec. ITU-R BT.709-4 => HD

a while ago I asked Haali if he could add this in HR, w/ x<1024=601, x>1024=709...I also use the same rules in ffdshow, everything's pretty fine ;)

BTW, I understand Haali is working for your firm....any chance you could let him improve HR a bit? or is this really out of scope? :(

[squid_80]

But there's nothing stopping anyone from encoding in SD using 709 or HD using 601, is there?

[leeperry]

But there's nothing stopping anyone from encoding in SD using 709 or HD using 601, is there?
well, if you encode HD to SD w/o using ColorMatrix() to convert from 709 to 601....sure :o

and if you encode an SD upscale to HD w/o converting from 601 to 709, same problem will occur.....but luckily the chances of encountering these 2 cases is rather thin, and these are badly encoded material anyway...not specs compliant.

DVD=601, HDTV/BD=709 :cool:

[squid_80]

and if you encode an SD upscale to HD w/o converting from 601 to 709, same problem will occur.....but luckily the chances of encountering these 2 cases is rather thin, and these are badly encoded material anyway...not specs compliant.
Not specs compliant? According to what specs, yours? Otherwise show me where it says this in the AVC specifications.

[leeperry]

Not specs compliant? According to what specs, yours? Otherwise show me where it says this in the AVC specifications.
well, it's not AVC specific AFAIK.

there's no such thing as SD commercial AVC, these are mostly encodes from SD sources I think...and SD requires Rec. ITU-R BT.601-5 YCbPr decoding matrix coeffs

and HD is using Rec. ITU-R BT.709-4, whatever in VC1/MPEG2/AVC/DivX...you name it :
http://www.google.com/search?hl=en&safe=off&q=HD+ITU-R+BT.709-4&btnG=Search&lr=

this only matters if users enable the RGB output in CoreAVC, YV12/YUY2 are pass-through...and either ffdshow or the graphic card drivers will (try to) guess whether it's 601/709 depending on the resolution when converting to RGB.

[Audionut]

there's no such thing as SD commercial AVC,

Bold claim. Just because you haven't come across it, doesn't mean it doesn't exist.

and SD requires Rec. ITU-R BT.601-5 YCbPr decoding matrix coeffs

Choose your words more carefully. SD can be any color space the author chooses. HD too.

[leeperry]

Bold claim. Just because you haven't come across it, doesn't mean it doesn't exist.

Choose your words more carefully. SD can be any color space the author chooses. HD too.
well the NTSC/PAL/SECAM specs give BT.601, sorry for that :
http://www.google.com/search?hl=en&safe=off&q=NTSC%2FPAL%2FSECAM+601&lr=

decodes all variations of PAL, SECAM, and NTSC signals into standard ITU-601 compatible component colour values

just like HD is using Rec.709, this is mandatory :o

probably you're mixing YCbPr decoding matrix coeffs and gamut coordinates....HD can indeed use many different types of gamut(Rec 709/SMPTE RP 145/EBU Tech. 3213), and so does SD(SMPTE RP 145/EBU Tech. 3213)

and I always choose my words very carefully, just so you know :p

[Audionut]

well the NTSC/PAL/SECAM specs give BT.601, sorry for that :
http://www.google.com/search?hl=en&safe=off&q=NTSC%2FPAL%2FSECAM+601&lr=

A google page. Come on.

decodes all variations of PAL, SECAM, and NTSC signals into standard ITU-601 compatible component colour values

What a decoder from your google link is capable of has no bearing on the ability for SD to be encoded in any color space.


just like HD is using Rec.709, this is mandatory :o

No it's not.

I'm relying on my mobile phone atm until I get my adsl transferred.

I'll be more than happy to post samples of SD and HD material encoded in varying color spaces when I get adsl back.

[squid_80]

and I always choose my words very carefully, just so you know :p
Not carefully enough. You're talking about SDTV and HDTV as if they mean the same thing as SD and HD.

[carlo_0000]

@dj bobo

no debloking is enable in coreavc


and for mpchc it s enable too, i m not english but for me

skip debloking : none, it s mean that it do not skip deblokin so it s = to enable no ? because it no skip

no ?

[DJ Bobo]

@ carlo
OK, so you're saying that deblocking is enabled in CoreAVC right? (Deblocking: Standard)
That would mean that under similiar circumstances, you're achieving with an A64@2.5GHz what I'm achieving with an X2@1.9GHz.
To remove any doubts, I'd like you -if possible!- to give me the average CPU load using the Throttlewatch program (http://www.softpedia.com/get/Tweak/CPU-Tweak/ThrottleWatch.shtml) (this program doesn't need any installation, just decompress somewhere)
You just start Throttlewatch, start the Seven Pounds trailer, click back on the Throttlewatch window, wait until the trailer reaches 20 seconds, hit F5 to start logging, wait until the trailer reaches 2 minutes and hit F5 again. You should get a journal.txt file in your Throttlewatch directory with an average load specified at the end.
If possible also a screenshot of MPC playing the trailer with statistics enabled to check for dropped frames (preferably a screenshot after the player finished playing)
Merci :)

[leeperry]

I'll be more than happy to post samples of SD and HD material encoded in varying color spaces when I get adsl back.
I'm talking about everyday consumer content Mr NitPicker :D

DVD/VHS rips/DVB/SDTV/HDTV/HDDVD/BD/VCD/SVCD you know...sure you can encode a movie in FCC YCbCr colorspace using some obscure gamut Germany was using during WW2...but then don't count on any consumer PC software to decode it properly me thinks, not w/o some heavy avisynth scripting in ffdshow.
Not carefully enough. You're talking about SDTV and HDTV as if they mean the same thing as SD and HD.
oh well, decode 1080p in 601 if you like, and keep 709 for full range videos only...I'm cool w/ that :cool:

BTW the major lag I had at the beginning of movies(when CUDA was enabled) was apparently due to the "delay compensation" option in Ozone4 that was fighting against it, disabling it fixed the problem altogether.

when I enable it, it says 68ms...in 48Hz :confused:

http://www.image-load.eu/out.php/i148333_delay.jpg

[carlo_0000]

@ carlo
OK, so you're saying that deblocking is enabled in CoreAVC right? (Deblocking: Standard)
That would mean that under similiar circumstances, you're achieving with an A64@2.5GHz what I'm achieving with an X2@1.9GHz.
To remove any doubts, I'd like you -if possible!- to give me the average CPU load using the Throttlewatch program (http://www.softpedia.com/get/Tweak/CPU-Tweak/ThrottleWatch.shtml) (this program doesn't need any installation, just decompress somewhere)
You just start Throttlewatch, start the Seven Pounds trailer, click back on the Throttlewatch window, wait until the trailer reaches 20 seconds, hit F5 to start logging, wait until the trailer reaches 2 minutes and hit F5 again. You should get a journal.txt file in your Throttlewatch directory with an average load specified at the end.
If possible also a screenshot of MPC playing the trailer with statistics enabled to check for dropped frames (preferably a screenshot after the player finished playing)
Merci :)


ok done, it s 38%
some higher whayt i thinked with taskmanager

but it say clock frequency 4570mhz (little bug because it s not possible, it s 2.5g /core)

http://ftp1.dommel.be/picture_library/journal.txt

http://ftp1.dommel.be/picture_library/x2coreavc.JPG

[DJ Bobo]

@ carlo
Sorry I wasn't clear enough, I asked for your numbers with the Athlon 64 @ 2.5GHz, not with the X2. That 1080p works on the X2 is pretty much established.
By the way, your links don't work.

[madshi]

Some clarification for those from DVinfo....

TV = ITU-R BT.601
and
PC = ITU-R BT.709

This is now in our KB and will be added to the next update (within the help tab).
I believe this is flat out wrong. Both BT.601 and BT.709 are usually encoded to video levels.

[G_M_C]

I believe this is flat out wrong. Both BT.601 and BT.709 are usually encoded to video levels.

Aside from the fact that they can both be in either TV or PC levels. So 601 doesnt automatically mean TV levels.

[madshi]

Aside from the fact that they can both be in either TV or PC levels. So 601 doesnt automatically mean TV levels.
Yes, both can be either PC levels or video levels, but both are *usually* video levels.

So it's wrong to tie either of these norms to PC or TV levels.

[G_M_C]

Yes, both can be either PC levels or video levels, but both are *usually* video levels.

So it's wrong to tie either of these norms to PC or TV levels.

Yep that's wrong too. But i was referring to this post: http://forum.doom9.org/showthread.php?p=1257453#post1257453

Where Betaboy linked the TV or PC levels to one colormetry; When you encounter PC levels, it automatically would mean 709 where TV levels automatically means 601.

This is what he wrote;


Input Levels
- TV (16-235): (ITU-R BT.601) always assume the stream uses TV levels.
- PC (0-255): (ITU-R BT.709) always assume the stream uses PC levels.
- Auto detect: use the full range flag in the stream to determine Luminance range.
Note: The input levels setting allows the overriding of the stream's colorspace setting and affects the conversion to RGB color space when it is done by the decoder.


From where he deduced;


TV = ITU-R BT.601
and
PC = ITU-R BT.709


So both assumptions he made were wrong :p :cool:

[BetaBoy]

So based on everyone's input here.... We went back and started to test some of the diffs with 601 vs. 709... and found that it's different to the input levels. The filter 'does' always assume bt.601, even when the stream indicates otherwise. We are going to fix that, and add an option to override it.

[carlo_0000]

@ carlo
Sorry I wasn't clear enough, I asked for your numbers with the Athlon 64 @ 2.5GHz, not with the X2. That 1080p works on the X2 is pretty much established.
By the way, your links don't work.


ok

i see the server is down, so i put this one to an other

http://perso.latribu.com/tribu/mkv/journal.txt

http://perso.latribu.com/tribu/mkv/athlon64coreavc.JPG

[madshi]

So based on everyone's input here.... We went back and started to test some of the diffs with 601 vs. 709... and found that it's different to the input levels. The filter 'does' always assume bt.601, even when the stream indicates otherwise. We are going to fix that, and add an option to override it.
Thanks!

[DJ Bobo]

@ carlo
Thank you very much.
So it did hit the 100% mark a few times and dropped a lot of frames after all.
I knew there was something fishy :devil:

So, I would say, regular 1080p is definitely too much for a single core CPU (unless someone has one of those newer LE-1660 models and can share his results with us)

So BetaBoy, I would say the preliminary results for CoreAVC's recommended hardware requirements to play usual H.264 content would be:
Athlon XP 3200+ or P4 @3.2GHz for 720p
Athlon X2 3800+ or Pentium D @3.2GHz for 1080p
I'll leave the verification and further testing up to you, I guess I've done a great deal already :D

[leeperry]

The filter 'does' always assume bt.601, even when the stream indicates otherwise.
are you sure the stream has a colorimetry flag :confused:
apparently some Samsung projectors(such as the SP-A800B) can auto-detect whether it's 601/709....but is it in the container or sumthing?

while you're fixing RGB conversion problems, maybe you could also implement progressively upsampled chroma.
I believe some ppl complained that your were doing it interlaced(like the ATi drivers).
here's a test pattern :
http://forum.doom9.org/showpost.php?p=1137196&postcount=1868

[HowlerX]

So BetaBoy, I would say the preliminary results for CoreAVC's recommended hardware requirements to play usual H.264 content would be:
Athlon XP 3200+ or P4 @3.2GHz for 720p
Athlon X2 3800+ or Pentium D @3.2GHz for 1080p
I'll leave the verification and further testing up to you, I guess I've done a great deal already :D

The only reason I bought CoreAVC was so I could play 720p content on my P4 2.53GHz. I've been happily using CoreAVC for over 2 years now. This has been one of those best-bang-for-my-buck pieces of software.

CPU usage varies from 40-90% depending on complexity of video.

Now that Flash video sites are starting to feature more and more 720p H.264 content you would think they would improve the efficiency of their decoder. I've tried playing the 720p content on Hulu.com and even on a 2.4GHz Core2Duo the thing plays choppily. It's ridiculous. Maybe they should license the CoreAVC decoder. :rolleyes:

[DJ Bobo]

@ HowlerX
I invite you to test the 720p Apple trailer (http://www.apple.com/quicktime/guide/hd/bbc-nhk.html) I posted earlier (Use QT Lite to be able to download it and play it in any player you want so that CoreAVC can be used).
I don't think your P4 will cope with it, at least not at the end where a lot of people come together, since as said, not even a 3GHz P4 was able to play it flawlessly.
You could post the same results I asked carlo for if you want.

[HowlerX]

@ HowlerX
I invite you to test the 720p Apple trailer (http://www.apple.com/quicktime/guide/hd/bbc-nhk.html) I posted earlier (Use QT Lite to be able to download it and play it in any player you want so that CoreAVC can be used).
I don't think your P4 will cope with it, at least not at the end where a lot of people come together, since as said, not even a 3GHz P4 was able to play it flawlessly.
You could post the same results I asked carlo for if you want.

Played flawlessly. I used MPC configured to use CoreAVC 1.8.5 and Haali Renderer (my preferred renderer). Even the DivX H.264 decoder plays this trailer flawlessly. Again using Haali Renderer (or even regular plain Overlay.)

Now if I change the renderer to VMR7 or VMR9, I definitely see skipped frames all over the place. But I haven't used those renderers in over 3 years, so why bother. My video card is an NVidia 6600GT on an obselete AGP bus.

Also, should note that I don't plan on upgrading to the latest CoreAVC decoder 'cause ver. 1.8.5 hasn't given me problems and I don't have a CUDA-enabled vidcard.

[Shinigami-Sama]

I played back that trailer fine a 3ghz P4 using MPC-HC rev 854 internal decoder...
I guess I should update mpc to see how much faster it is now with updated ffmpegs...

[G_M_C]

So based on everyone's input here.... We went back and started to test some of the diffs with 601 vs. 709... and found that it's different to the input levels. The filter 'does' always assume bt.601, even when the stream indicates otherwise. We are going to fix that, and add an option to override it.

You can make your live easier by using 709 for High definition. Rec709 is the (mandatory ?) standard for HD, so everything >= 720p is always Rec709. And then make TV levels the default for that, and PC levels optional (like the "BtB / WtW" switches on the Blu-ray players)

I would not know how to automate it so that a programm can scan the stream and deduce for itself what is applicable 601 or 709, TV-levels / PC-levels. There are differences between all thhose options, but a programm that "sees" what is apllicable, like a human can do by watching the clip closely and comparing between the options, does not yet exist ...

[madshi]

You can make your live easier by using 709 for High definition. Rec709 is the (mandatory ?) standard for HD, so everything >= 720p is always Rec709. And then make TV levels the default for that, and PC levels optional (like the "BtB / WtW" switches on the Blu-ray players)
Actually the h264 bitstream itself contains information about whether BT.709 or BT.601 is used, IIRC. So there's no need at all to tie the color norm to the resolution. It's true that 709 is usually used for HD content, but that doesn't mean that some reencoding couldn't be using BT.601 for HD content instead. So it's better to do what BetaBoy suggested, namely making use of the h264 color norm information fields. I don't even know if it's necessary to offer a switch to overwrite that, but it won't harm (except making the user interface more complicated).

About TV/PC levels: There's a "full range" flag in the h264 stream which indicates to which levels the stream was encoded. Unfortunately, this flag is set wrong for many European HDTV broadcasts. So it is necessary to offer an overwrite for this.

[DJ Bobo]

@ Howler / Shinigami
Numbers or graphs, and screenshots to check for dropped frames please.
PS: I don't know why but Haali doesn't seem to report dropped frames to MPC even if frames are dropped...

[hellrasinbrasom]

The program I used with my 2nd set of encodes was XVID4PSP
+ DVD Decryptor/Shrink

PLATFORM
------------------------------
OS: Microsoft Windows NT 6.0.6000.0
OEMCodePage: 437
Language: ENU
DecimalSeparator: .
Framework: 2.0.50727.312
Processors: 2
Machine: THEPC
UserName: Big Boss
SystemDrive: C:

XVID4PSP
------------------------------
Version: 5.036
Created: 10/18/2008 11:36:32 AM
TempPath: C:\Temp
AppPath: C:\Program Files\Winnydows\XviD4PSP5

FILES
------------------------------
VTS_01_1.VOB >
VTS_01_2.VOB >
VTS_01_3.VOB >
VTS_01_4.VOB >
VTS_01_5.VOB >
Documents_T01.mp4

TASK
------------------------------
Format: MP4
Duration: 02:18:17:598 (248679)
VideoDecoder: MPEG2Source
Resolution: 720x480 > 1280x720
VCodecPreset: x264 Q21 Ultra
VEncodingMode: Quality
VideoCodec: MPEG2 > x264
VideoBitrate: 3446 > Q21.0
Framerate: 29.970
SourceType: INTERLACED
FieldOrder: UNKNOWN
Deinterlacer: TomsMoComp
AudioDecoder: NicAC3Source
AEncodingPreset: AAC-LC ABR 128k
AudioCodec: AC3 > AAC
AudioBitrate: 448 > 128
Samplerate: 48000
Channels: 6
Normalize: 100%
Accurate: 3%
Gain: 1.846
Delay: 83 > 83

VIDEO ENCODING
------------------------------
Encoding video to: C:\Temp\0003.264
x264 Q21.0 1280x720 29.970fps (248679 frames)
x264 [info]: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=6 psy_rd=1.0:0.0 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-2 threads=2 thread_queue=2 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=1 b_bias=0 direct=1 wpredb=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=crf crf=21.0000 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

AUDIO ENCODING
------------------------------
Encoding audio to: C:\Temp\0003.m4a
AAC 128kbps 6ch 16bit 48000khz

MUXING
------------------------------
Video file: C:\Temp\0003.264
Audio file: C:\Temp\0003.m4a
Muxing to: C:\Users\Big Boss\Documents\Documents_T01.mp4

TIME
------------------------------
Total encoding time: 23 hour 1 min 36 sec
Out file size is: 4985.91 mb

:helpful:

[carlo_0000]

@ carlo
Thank you very much.
So it did hit the 100% mark a few times and dropped a lot of frames after all.
I knew there was something fishy :devil:

So, I would say, regular 1080p is definitely too much for a single core CPU (unless someone has one of those newer LE-1660 models and can share his results with us)

So BetaBoy, I would say the preliminary results for CoreAVC's recommended hardware requirements to play usual H.264 content would be:
Athlon XP 3200+ or P4 @3.2GHz for 720p
Athlon X2 3800+ or Pentium D @3.2GHz for 1080p
I'll leave the verification and further testing up to you, I guess I've done a great deal already :D


i m not agree with you for the 720p recommended requirements
you a litle high athlon 2700+ must play it very good (because cpu frenquecy is close to the 3200+)

the 2400+ is to slow (drop frames in some scene)

i had a 3100+ barton soket A (2.2ghz) it played 720p easy but i can't test it anymore (cpu is dead), it was not able to play 1080p (slower than the athlon 64 2800+)


i olso deagree for the 1080p because there are single core with higer frequency like athlon 64 6000+ 6400+ ? i m sure that thay can play 1080p, no nesesary needed a dual core

[DJ Bobo]

@carlo
i m not agree with you for the 720p recommended requirements
you a litle high athlon 2700+ must play it very good (because cpu frenquecy is close to the 3200+)
Good point. Athlon XP @ 2.2GHz would be better then I guess.
i olso deagree for the 1080p because there are single core with higer frequency like athlon 64 6000+ 6400+ ?
There is no such thing as Athlon 64 6000+. You're probably confusing this with Athlon 64 X2 6000+, which is a dual core CPU.
Anyway, I already said
unless someone has one of those newer LE-1660 models and can share his results with us
The Athlon 64 LE-1660 is a 2.8GHz single core unit.

[carlo_0000]

i did some test today

with sempron 2200 (1.5ghz) soket A

i m surpised because i olso tested a barton mobile 2400+ (1.8ghz) on the same computer and

the sempron plays 2% beter the 720p video's than the barton

i can't understand that (sempron is like a duron no ? it must be slower than a barton)

i olso oc the barton to max 2130mhz but did only 4% beter
and the duron to 1650mhz and did litle beter than the barton 2.1ghz

i found that the barton 2400 is pretty bad

is to slow for 720p 50fps (but x264 rip in 720p 25fps is playable (3-5mbits videobitrate)

[DJ Bobo]

@ carlo
It may have something to do with the chipset and memory performance.

[Ryokurin]

Sometimes a faster frontside bus can win out over cache when it came to Athlon processors.

[lucassp]

i can't understand that (sempron is like a duron no ? it must be slower than a barton)

The Socket A Sempron is based on the TBred B or Thornton (half cache Barton) cores.

[Ice =A=]

I just wanted to mention thath I've been using CoreAVC for quite some time now to watch 720p content on an Atom N270 1,6GHz Netbook!
Of course I can't guarantee that it will work with any material (and most likely it won't), but so far I've NEVER had any problems!

[clsid]

I have an 8 year old 1.33 Ghz processor that can play 720p content. That is nothing special. 1080p is about twice as hard to decode. Also, the encoding settings can have a big impact on decoding performance.

[Sagekilla]

Some encoding settings can have an impact on decoding performance. In fact, only two: Deblock and CABAC. Nothing else makes a significant difference.

[BetaBoy]

Just got the new MacBook Pro here... gonna setup a dual boot tonight and see how well CoreAVC w/CUDA works.

[Betsy25]

Just got the new MacBook Pro here... gonna setup a dual boot tonight and see how well CoreAVC w/CUDA works.

Have fun ! :)

[DJ Bobo]

@ Ice/clsid
Your PCs won't be able to play "normal" 720p videos, not the Apple trailer I posted above, and not the 720p trailers available in the DivX showcase (http://www.divx.com/en/downloads/divx-7-showcase)

@ BetaBoy
Hopefully you didn't receive one of those defective units. It seems like the new MacBook Pro have a lot of problems with the graphics (http://www.computerbase.de/bildstrecke/24736/2/).

[clsid]

Well, you are wrong. My old PC plays them fine. Sure, it will hit 100% CPU with certain files like your BBC sample, but the video is watchable without any annoying stuttering.

[Kurtnoise]

back on topic...I'm wondering if CoreAVC w/ CUDA enabled is able to decode MBAFF contents properly ? Does anybody succeeded ?

I ask this because it seems that CUDA is disabled with such files (tray icon is blue instead of green for me). Any clue ?

I'm using the last release...

[DJ Bobo]

@ clsid
Please provide us with a link to a 720p trailer that would work on your old PC without torturing your CPU. May be you're using the Haali Renderer too and are not aware of it slowing down your video?

[clsid]

The Overlay Mixer is most CPU efficient, so that is what I use.
TerminatorSalvationTrailer[DivX7].mkv plays fine with an average CPU usage of about 85-90%.

[ChronoCross]

back on topic...I'm wondering if CoreAVC w/ CUDA enabled is able to decode MBAFF contents properly ? Does anybody succeeded ?

I ask this because it seems that CUDA is disabled with such files (tray icon is blue instead of green for me). Any clue ?

I'm using the last release...

If I remember correctly interlacing support for CoreAVC CUDA is not currently available.

[BetaBoy]

If I remember correctly interlacing support for CoreAVC CUDA is not currently available.

Correct, We are doing regression testing on CUDA interlaced support atm and we are only down to a handful of files that need to be supported, so we are closer for an internal QA release for a potential 1.9.x.

[DJ Bobo]

@ clsid
I couldn't download the Terminator trailer since download speed was too slow, but I did a test on the Star Trek trailer I downloaded before, while giving MPC only one core, logging from 00:10 to 01:45 average was ~56% and max was ~82% on that core with the overlay mixer. I don't see your 1.33GHz CPU not hitting 100% if mine came over 80%, and I'm ready to bet that it hit 100% too often and lost a lot of frames in the way (even though MPC shows 0, since Overlay Mixer doesn't report anything to MPC)
Please post a graph or numbers showing CPU usage.

[clsid]

It hits 100% just a few times. Point is that the video is watchable without loss of audio sync or stuttering. I don't care about a few skipped frames. The BBC sample is more difficult to decode though.

[DJ Bobo]

It hits 100% just a few times. Point is that the video is watchable without loss of audio sync or stuttering. I don't care about a few skipped frames
I don't believe this is coming from your mouth. You're sure you're THE clsid???
Anyway, 1.33GHz CPUs do NOT play 720p "just fine" as you say, since, obviously, 100% automatically means stuttering and loss of audio sync.
CoreAVC is fast, but it doesn't do miracles.
Case closed.

[Cyber-Mav]

anyone got a sample video of the most difficult content to decode? would love to use it for cpu testing purposes.

[littleD]

You guys simply overestimate needs for decoding 702p material. With deblocking off terminator trailer is playable even by divx decoder with just small two audio desynchronizations. Coreavc is slightly better on old one core machines. So i believe clsid. I changed fsb by speedfan to reach 1.33gh. Only if coreavc team could add sse optimizations...:sly:

[DJ Bobo]

With deblocking off
OK, let's set something straight. The recommended requirements that I posted are with Deblocking ON. Because the requirements posted on the website already imply that deblocking is off! And as you may know, a P4@2.2GHz is roughly equivalent to a Pentium-M@1.5GHz.
So please stop this non-sense. You want to prove me wrong with CPUs that hit 100% with deblocking off? come on guys.
OK, here's the deal: please no further contributions unless you comply with the following:
1) Deblocking in set on "Standard"
2) CPU usage doesn't exceed 95% and you can document that with a graph or numbers
3) No skipped frames (screenshot with statistics if possible).

[clsid]

We seem to be talking about different things here. I totally agree that the minimum requirement for completely smooth playback is higher as what my old PC has. I also agree that P4's are crap. I was just saying that in some cases playback quality/performance is acceptable on an 8 year old PC (with a high-end CPU at that time). Normally I will simply fire up the Core2 for playing such material.

And on a blind test, I'll bet that 9/10 people won't see the difference between for example 22 and 24 fps.

[littleD]

Allright Dj Bobo. Can u point the "real" 720p video (sample) then, and forget that crappy trailers:) Lets use it as reference and stop that nonsense :)

[Inventive Software]

If it's any help, with the "old" CoreAVC in TCPMP, I can play SD (720x576) content on my Celeron 800 MHz. :)

[hajj_3]

u long away from giving us a new version betaboy?

[DJ Bobo]

@ littleD
The Apple trailer I posted above is just fine for testing 720p.

[_DW_]

@ littleD
The Apple trailer I posted above is just fine for testing 720p.

Will this thing play without quicktime? I refuse to put that abomination on my PC.

[Sagekilla]

BetaBoy, I have a question regarding the latest CoreAVC Pro build (1.9.0).

I'm running CoreAVC on my desktop with hardware acceleration disabled, and I'm using the decoder through DirectShowSource in avisynth to decode my Blu-rays. It seems like when I run x264 with the --psy-rd switch, I get a crash in x264 if getting my video through an avs. A GDB trace leads to a segfault in CoreAVCDecoder.ax. Also, if I decode the video to y4m first, then feed to x264 the crashes stop.

Any thoughts on why CoreAVC would crash when I put --psy-rd on my command line for x264, but run perfectly fine without it? For whatever reason, my identical laptop setup can encode fine.

(Note to mods: I'm not sure if I'm violating the rules by posting this here. If I am, let me know and I'll take down my post immediately)

[squid_80]

Are you sure the name of the module that's crashing is CoreAVC.ax?

[Sagekilla]

Sorry, I meant to say CoreAVCDecoder.ax. Here's the link to the GDB traces:
http://forum.doom9.org/showpost.php?p=1260502&postcount=16
http://forum.doom9.org/showpost.php?p=1260504&postcount=18

[squid_80]

CoreAVC won't allow itself to be loaded while running under a debugger. It's not actually the root cause of your problem.

[Sagekilla]

Hm. I'll try decoding with ffmpegsource instead. I've been trying to do it solely through CoreAVC (for speed reasons) though.

[littleD]

@ littleD
The Apple trailer I posted above is just fine for testing 720p.

If so, then it plays fine on sempron 2600 1.8 gh. There were just small slowdowns with red trees and ending city. But its playable with deblocking on. Nice video btw.
==
But im not sure if its representative 720p source as has specific properties. E.g. no CABAC.

[DJ Bobo]

@ DW
Of course. Look further behind how to download and play the Apple trailers without having QuickTime (this is about CoreAVC's performance after all).

There were just small slowdowns with red trees and ending city
That's exactly why this trailer is interesting. It is full 16:9, has 30fps (which makes up for the lack of CABAC) and simulates high-bitrate action scenes at the end pretty well.
Nice video btw
Yes it is :D

[cdv1010]

Hello everybody, I have a Geforce 8400M GS laptop video card. When I turn on CUDA options, I can't play 1080p mkv files(frame rate only <5) although i can play it nearly smooth (about 18~20 fps) without CUDA.
My CPU is core2 duo 1,4Ghz. Have anyone got solution for this situation?

[Cyber-Mav]

Hello everybody, I have a Geforce 8400M GS laptop video card. When I turn on CUDA options, I can't play 1080p mkv files(frame rate only <5) although i can play it nearly smooth (about 18~20 fps) without CUDA.
My CPU is core2 duo 1,4Ghz. Have anyone got solution for this situation?

solution is media player classic home cinema.

[me7]

Hello everybody, I have a Geforce 8400M GS laptop video card. When I turn on CUDA options, I can't play 1080p mkv files(frame rate only <5) although i can play it nearly smooth (about 18~20 fps) without CUDA.
My CPU is core2 duo 1,4Ghz. Have anyone got solution for this situation?

I had the same problem, I solved it by using Overlay Mixer.
Using MPCHC with VMR or EVR caused the same problem.

[BetaBoy]

We are compiling a release for CoreAVC v1.9.5 as we speak that now features CUDA Interlaced support and addresses all of the known issues and even adds new input colorspace options. Also for our OEM/CE customers or potential licensee's we have also added NVIDIA CUDA support to the latest CoreAVC SDK, for more info you can email: licensing AT corecodec DOT com

Once we QA the final release package we will unleash it.... so likely right after the weekend.

[ajp_anton]

Is there an x64 version coming?

[BetaBoy]

In CoreAVC 2.0 yes

[Shakey_Jake33]

For the interested, there's now an official mobile driver that supports CUDA on the CUDA page

http://www.nvidia.com/object/cuda_get.html

[hajj_3]

We are compiling a release for CoreAVC v1.9.5 as we speak that now features CUDA Interlaced support and addresses all of the known issues and even adds new input colorspace options. Also for our OEM/CE customers or potential licensee's we have also added NVIDIA CUDA support to the latest CoreAVC SDK, for more info you can email: licensing AT corecodec DOT com

Once we QA the final release package we will unleash it.... so likely right after the weekend.

Great news, hopefully out any day then:)

[BetaBoy]

ok... QA has passed. Here are the release details.

CoreAVC H.264 Video Codec - Version 1.9.5.0 (20090316)
- Add: NVIDIA CUDA accelerated decoding for interlaced streams (MBAFF and PAFF)
- Add: Input stream colorspace override options
- Fix: CUDA matrix handling and DPB management improvements
- Fix: SEI messages were sometimes discarded
- Fix: Seeking problems with Canon HF100 streams
- Fix: Use faster asynchronous memory transfers between CPU<->GPU for CUDA

Note three things with CUDA:
- CUDA does not support lossless AVC
- There is a 16 ref frames limit that is caused by CUDA relying on direct3d. Technically our implementation supports higher ref's so if NVIDIA fixed that in their driver, those streams would start working.
- The next driver release from NVIDIA will address a CUDA cropping issue (content with a height of 368 and 1088 is automatically clipped to 360 and 1080).

Notifications for the update download will begin to go out soon. Please post some results or any bugs you might have found.

[Dark Shikari]

- There is a 16 ref frames limit that is caused by CUDA relying on direct3d. Technically our implementation supports higher ref's so if NVIDIA fixed that in their driver, those streams would start working.Doesn't the spec already limit you to 16 reference frames? Or are you referring to the case of interlaced, where the spec allows 32 reference fields?

[BetaBoy]

Doesn't the spec already limit you to 16 reference frames? Or are you referring to the case of interlaced, where the spec allows 32 reference fields?

Correct.

[squid_80]

16 ref frame limitation = streams with 16 reference frames aren't supported with CUDA. Streams with <16 should be ok.

[tetsuo55]

16 ref frame limitation = streams with 16 reference frames aren't supported with CUDA. Streams with <16 should be ok.

Wait.

so a stream with 15 ref frames does work and a stream with 16 ref frames does not?

What about bframes, these too have a spec based limit of 16

Does a 16ref frames 16bframes + bpyramids file work?

[squid_80]

Wait.

so a stream with 15 ref frames does work and a stream with 16 ref frames does not?Correct.What about bframes, these too have a spec based limit of 16CUDA has no additional b-frame limitation.Does a 16ref frames 16bframes + bpyramids file work?No, because 16 reference frames aren't supported.
I spoke a bit about the technical reasons in this post (http://forum.doom9.org/showthread.php?p=1192953#post1192953).

[BetaBoy]

tetsuo55... in other words, if CUDA were not tied to DirectX there would be no limitation.

[tetsuo55]

Does DirectX 11 remove this limitation?
What about if you use DMO instead of directshow?

So this file should work: 15 ref frames, 16 bframes+bpyramids (because bframes don't matter for cuda?)
What is the resolution limit? 4096x2304?
What about the bitrate limit, is it 960MBIT/S

Does 15 ref frames still work at that high resolution?

[squid_80]

Does DirectX 11 remove this limitation?Not to my knowledge.What about if you use DMO instead of directshow?That wouldn't make any difference.So this file should work: 15 ref frames, 16 bframes+bpyramids (because bframes don't matter for cuda?)Right.What is the resolution limit? 4096x2304?
What about the bitrate limit, is it 960MBIT/S

Does 15 ref frames still work at that high resolution?
CoreAVC is currently limited to 2048x2048. If there is insufficient available memory on the video card software decoding will be used.

[Cyber-Mav]

how much video memory is required for 2048x2048 resolution decoding?

[tetsuo55]

CoreAVC is currently limited to 2048x2048.

Does that resolution still work with 15 ref frames?

Also what is the bitrate limit?

[CiNcH]

Still wrong field order for 1080i.

[BetaBoy]

Ok.. emails going out now for 1.9.5.

[Inventive Software]

The reliance of CUDA on DirectX is one more reason for them to switch to OpenCL I suppose.

[lucassp]

It would be really nice if OpenCL would offer access to VPx/UVD, but I really doubt that.

[LoRd_MuldeR]

Ok.. emails going out now for 1.9.5.

Got it. Thanks :)

[BetaBoy]

The reliance of CUDA on DirectX is one more reason for them to switch to OpenCL I suppose.
We will support OpenCL in CoreAVC and CorePlayer as well. What's going to be interesting is to see what works best in the long run since NVIDIA plans to support both efforts.

[BetaBoy]

Got it. Thanks :)

Great.... let me know if you run into any issues. But our regression testing has come up clean... so we don't expect many bumps with this release. But if needed we have 1.9.6 and upward to take care of them. However we would like for there to be only one more release prior to going to 2.0.... as the demands for CoreAVC 64bit on windows as well as our release for Linux is getting greater every day.

[Cyber-Mav]

betaboy does your internal testing of coreavc 64bit show any speed difference compared to 32bit?

[halsboss]

<dummy alert>
1. looked at the 1st page and the last couple of pages and coreavc.com and didn't recognise an answer ... does it come with an mp4/mkv splitter sort of like halli , or do I need to obtain one of those too to play MP4s with MPC ?
2. people here seem to use this codec, so I guess it's a recommended reputable one (if so I'll buy it) ?
</dummy alert>

[Shinigami-Sama]

<dummy alert>
1. looked at the 1st page and the last couple of pages and coreavc.com and didn't recognise an answer ... does it come with an mp4/mkv splitter sort of like halli , or do I need to obtain one of those too to play MP4s with MPC ?
2. people here seem to use this codec, so I guess it's a recommended reputable one (if so I'll buy it) ?
</dummy alert>

it comes with haali

its good, I'm waiting on 2.0 myself
grab a trail and see if its worth buying yourself

[lych_necross]

Yeah, no more blocking/corruption when I seek in files!!! :) Is the version of Haali's splitter different from the one posted on haali.net?

[Gleb Egorych]

BetaBoy, is it hardware/driver limitation that mixed progressive/interlaced content is not properly deinterlaced in "hardware deinterlace" mode? I wrote that here (http://forum.doom9.org/showthread.php?p=1249189#post1249189)

[deets]

all works with cuda on interlaced material now, i can watch my ITV HD games via dbviewer and claw back a few CPU % :)

edit: one thing, i would love to know how to get the purevideo deinterlacing via hardware to work with coreavc

[Dark Eiri]

Well, with 1.9.5, again, CoreCodec proves it does an excellent job! Up to this moment, it could play flawlessly, in CUDA, pretty much everything I throw at it! If it's some old encode with 16 ref-frames, it falls back to software mode, so it's really spot on! I was thinking to go ATi HD4870 for my next upgrade... well, guess I'll go GTX 260 now :D

edit: one thing, i would love to know how to get the purevideo deinterlacing via hardware to work with coreavc

Set the output to NV12 and it's sure to work.

[Disabled]

betaboy does your internal testing of coreavc 64bit show any speed difference compared to 32bit?
At least BetaBoy said something like that some time ago (I didn't find the posting though).

2. people here seem to use this codec, so I guess it's a recommended reputable one (if so I'll buy it) ?
I suggest you at least wait until a statement about v2.0 was made, else you would have to pay again in a short time if you want continued support.
You might try DivX7 though, its free and if it plays your videos CoreAVC will give you not much more (unless you need GPU acceleration for encoding or together with subtitle rendering)

[Kurtnoise]

A dummy question: where are located in the registry the CoreAVC settings ?

ok, found it but not in the registry :: User\xxx\AppData\Roaming\CoreAVC.ini


:thanks:

[BetaBoy]

Kurtnoise, yeah we store it in an ini to KISS it and only store whats absolutely needed in the registry to keep it (the registry) as clean as possible.

[deets]

I was thinking to go ATi HD4870 for my next upgrade... well, guess I'll go GTX 260 now :D



Set the output to NV12 and it's sure to work.

ot but i put in an order for a 4870 then quickly cancelled when i saw the 260 had dropped in price, partly due to the hardware advantages with nvidia

edit: and the deinterlacing didnt work, well not as i wished anyway. ffdshow handles the hardware deinterlacing fine and gives me a nice bobbed output but coreavc doesnt seem to do the same

[Dark Eiri]

Hey, BetaBoy, what's the chance of CodeCodec developing a VC-1 or even MPEG-2 codec with CUDA support? That would be awesome!

[Cyber-Mav]

mpeg2 decoding works great using nvidia purevideo decoder from nvidia. as for vc-1 you can decode that already in hardware with purevideo 3 (vpu3) capable gpu from nvidia.


also this 1.9.5 version is working great for me, no more crazy colours or blocking. i use cuda mode permanently now and its fantastic. old opteron 144 @ 1.8ghz with 8600gt = awsome media center machine now. no need to shell out on huge hardware upgrades now just to play hd video.

[Dark Eiri]

as for vc-1 you can decode that already in hardware with purevideo 3 (vpu3) capable gpu from nvidia.

But with no filters or even subtitles outside MPC.

[halsboss]

Very pleased with my purchase of the pro. It plays the immensely moving MattHardingDancing2008_720p.mp4 nicely.
Thanks.

[smit]

When version 1.9 was released i wrote about audio problems with spdif connection.
Using the latest build i`m having masive audio dropouts when i`m sending SPDIF to an external amp.

As it seems there is a problem with the latest Haali spliter and CUDA.
When i enable MPC-HC`s internal splitter in conjunction with CUDA everything is ok.

Hardware
Mobo Gigabyte GA-MA78GM-S2H - http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2758
VGA Gigabyte GV-NX86T512H - http://www.gigabyte.com.tw/Products/VGA/Products_Overview.aspx?ProductID=2604

Software
Vista 32bit
MPC-HC 1.2.908 final and 1.2.989 beta
CoreAVC 1.9
AC3 filter 1.51a
Slysoft Reclock 1.8.3.4


I tried many combinations and different options in my software setup but audio dropouts continued to occur quite frequently..I changed AC3filter to reencode the signal.I disabled Reclock.I did every possible combination i could think.I must add that it is the same for DTS and DD.

Only when i disable Haali or CUDA the sound is ok.

.

With 1.9.5 things are vastly improved and somehow changed.
Occasionally i`m having audio dropouts.Very few now (congrats) but annoying none the less.

The situation is changed from before.Now it has nothing to do with the splitter (Haali or MPC HC) and it is due to cuda solely.
If i disable Cuda i have no dropouts but when i enable it i`m having audio dropouts at random intervals.DD and DTS behave the same.


Keep up the good work!

.

[leeperry]

I'm having terrible jitter in HR w/ the latest official build, the latest beta before that worked a lot smoother...it hiccups every few seconds now, and works fine if I disable CUDA :o

I guess I should update my XP drivers though, but it's such a pain to recreate all the custom resolutions...which vanish after one reboot, so you have to create them twice :rolleyes:

[cyberbeing]

I guess I should update my XP drivers though, but it's such a pain to recreate all the custom resolutions...which vanish after one reboot, so you have to create them twice :rolleyes:
I assume that means you are using driver sweeper or cleaner to do a clean install of your driver.

If you export the CUST_MODE binary value from the registry beforehand, import CUST_MODE back into the registry after you have installed the new driver, and reboot, your custom resolutions will be back without having to input them again.

[leeperry]

I assume that means you are using driver sweeper or cleaner to do a clean install of your driver.

If you export the CUST_MODE binary value from the registry beforehand, import CUST_MODE back into the registry after you have installed the new driver, and reboot, your custom resolutions will be back without having to input them again.
yeah I tried that and I always use DriverCleaner too ;)
but it only worked fot my primary display(CRT), not secondary(pj)...and each time I input them on the pj, they vanish after the first reboot :rolleyes:
so I don't update frenetically anymore, like I did w/ the ATi drivers...I can tell you that :D

anyway, what are the best drivers for CoreAVC 1.95 on XP SP3 w/ a G92? the latest stable 182.08?