PDA

View Full Version : CoreCodec/H.264 Codec "CoreAVC"


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29

LoRd_MuldeR
1st January 2009, 23:25
So the issue is how well the decoder handles these, and CoreAVC doesn't do well with the above video...

CoreAVC handles standard-compliant MV's properly. If the stream contains MV's that exceed the limitations defined in the standard, one can't expect proper decoding.

I think the CoreAVC developers have stated that they are not going to "fix" this, as the problem isn't on their side, but on the encoder's side. The encoder needs to be fixed.

However other H.264 decoders, such as libavcodec, seem to be more robust against such standard violations ...

Atak_Snajpera
2nd January 2009, 00:46
However other H.264 decoders, such as libavcodec, seem to be more robust against such standard violations ...
that's why I like ffdshow :) it can decode resolutions higher than 1080p

BetaBoy
2nd January 2009, 02:02
@LoRd_MuldeR... More robust? We would diff from that opinion. Adding higher non-spec compliant MV's in any decoder comes at the cost of CPU cycles, ie; speed.
@Atak_Snajpera... are resolutions higher then 1080p within the AVC spec?
@laserfan... what are you using to encode these videos? I would like to contact them about their problem.

While it was about 100+ pages back... we have added 'some' out of spec MV support to CoreAVC, but stopped short at the point where it began to effect speed.

LoRd_MuldeR
2nd January 2009, 02:11
@LoRd_MuldeR... More robust? We would diff from that opinion. Adding higher non-spec compliant MV's in any decoder comes at the cost of CPU cycles, ie; speed.

So obviously it's a trad-off. And the CoreAVC team decided to give performance (speed) a higher priority than robustness against (slightly) broken streams.

However if a significant number of original Blu-Ray discs contain out-of-spec MV's, then it may be a good idea to be prepared for that case.

Strictly limiting your decoder to the specs won't help your users as long as the big studios keep on violating these specs. And I don't expect the studios to change their behavior.

After all speed isn't everything. Nasty artifacts may be much more annoying than a reasonable speed drop...

@Atak_Snajpera... are resolutions higher then 1080p within the AVC spec?

The specs for Level 4.0/4.1 of H.264:
* Max. number of macroblocks per seconds: 245760
* Max. picture size in macroblocks: 8192
* Examples: 1920x1080 @ 30.1 fps, 2048x1024 @ 30.0 fps

The specs for Level 4.2 of H.264:
* Max. number of macroblocks per seconds: 522240
* Max. picture size in macroblocks: 8704
* Examples: 1920x1080 @ 64.0 fps, 2048x1080 @ 60.0 fps

The specs for Level 5.0 of H.264:
* Max. number of macroblocks per seconds: 589824
* Max. picture size in macroblocks: 22080
* Examples: 1920x1080 @ 72.3 fps , 2560x1920 @ 30.7 fps

The specs for Level 5.1 of H.264:
* Max. number of macroblocks per seconds: 983040
* Max. picture size in macroblocks: 36864
* Examples: 1920x1080 @ 120.5 fps, 4096x2048 @ 30.0

Source:
http://de.wikipedia.org/wiki/H.264#Level

BetaBoy
2nd January 2009, 02:22
So obviously it's a trad-off. And the CoreAVC team decided to give performance (speed) a higher priority than robustness against (slightly) broken streams.

However if a significant number of original Blu-Ray discs contain out-of-spec MV's, then it may be a good idea to be prepared for that case.

Strictly limiting your decoder to the specs won't help your users as long as the big studios keep on violating the specs. And I don't expect the studios to change their behavior.

After all speed isn't everything. Nasty artifacts may be much more annoying than a speed (minor) speed drop...

I have already been in direct contact with 2 studios that produced the titles mentioned in this thread 6+ months ago and they both stated that they are aware of the problem and are addressing the mastering issue.

Otherwise we beg to disagree to add non-compliance as being robust.

vwpassion
2nd January 2009, 02:24
So obviously it's a trad-off. And the CoreAVC team decided to give performance (speed) a higher priority than robustness against (slightly) broken streams.

However if a significant number of original Blu-Ray discs contain out-of-spec MV's, then it may be a good idea to be prepared for that case.

Strictly limiting your decoder to the specs won't help your users as long as the big studios keep on violating the specs. And I don't expect the studios to change their behavior.

After all speed isn't everything. Nasty artifacts may be much more annoying than a speed (minor) speed drop...

I agree. Nasty artefacts (check screenshots a few posts earlier) are a biggern concern to me than speed. In fact, I'm now preferring ffdshow's video decoder over coreavc due to this.

I've encountered these artefacts on several blurays already, thats whats the biggest concern to me. If it was a one-time thing, I'd be less worried. But with new studios popping up on the bluray market, I can foresee more of these out-of-spec MV's appearing on a number of blurays yet to come.

LoRd_MuldeR
2nd January 2009, 02:38
I have already been in direct contact with 2 studios that produced the titles mentioned in this thread 6+ months ago and they both stated that they are aware of the problem and are addressing the mastering issue.

Well, that is a step to the right direction but won't fix existing discs. But still users that own these discs would like to play them.

Can you bring a disc back to shop because it contains "none-standard-compliant MV's" and get a new "fixed" copy, although the discs will play back properly on almost any Blu-Ray player?

Sorry, I doubt it. The guys at shop won't even understand what the problem is ;)


Otherwise we beg to disagree to add non-compliance as being robust.

Fact is: Blu-Ray discs with out-of-spec MV's exist and it seems they aren't that rare. CoreAVC won't decode these discs properly, no matter whose mistake that is.

The customers will decided whether this is a reason to buy CoreAVC or to go for another decoding solution ...

Sharktooth
2nd January 2009, 02:58
standards are made for a reason. if a studio produces a non standards compliant disc then it's their fault and ppl should avoid buying those products.

LoRd_MuldeR
2nd January 2009, 03:14
standards are made for a reason. if a studio produce a non standards compliant disc then it's their fault and ppl should avoid buying those products.

Ideally yes. But realty often looks different. Companies define their own "de-facto" standards :rolleyes:


If your favorite movie was available on Blu-Ray disc and you really want to have it, but you also knew that the release contains none-standard-compliant MV's, what would you do?

1. Buy it anyway and use another decoder that can handle the problem (e.g. ffdshow).

2. Refuse to buy the disc and miss that movie in your collection, just because of some mastering bug (one that can be worked around quite easily)


I think most people would rather use a different decoder than not being able to watch their favorite Blu-Ray movies.

But after all CoreCodec has to decide what's best for their (potential) customers...

laserfan
2nd January 2009, 03:29
standards are made for a reason. if a studio produce a non standards compliant disc then it's their fault and ppl should avoid buying those products.You can't be serious--someone is going to evaluate & ID non-std discs, and ppl are going to seek-out and find this definitive list (worldwide, for all variants) and make buying decisions accordingly? Never in the real world! :confused:

BetaBoy
2nd January 2009, 05:15
@LoRd_MuldeR...

- A MV work around other then what we have done already as you say is not as easy as you state it to be, and would take a considerable amount of work.

- Dark Shikari himself said about 100+ pages ago that it would take studios 6+ months for his x264 fix for make MV spec compliant to float its way just through the various distros and we consider the current state on non-spec MV's going on a downward trend.

- on resolution... that's a 'me bad' as I misinterpreted the question.

LoRd_MuldeR
2nd January 2009, 05:21
- A MV work around other then what we have done already as you say is not as easy as you state it to be, and would take a considerable amount of work.

What I meant is that there is an easy workaround for the user, if CoreAVC shows artifacts for none-compliant streams:
Download and install ffdshow ;)

So my point was that customers rather go for another decoder than avoiding none-compliant discs, since we must assume they already bought the disc for hard money.


- on resolution... that's a 'me bad' as I misinterpreted the question.

So are there any plans to enable CoreAVC for higher resolutions anytime soon?

From what I know the H.264 specs only limit the resolution through levels. And in level 5.1 you can have 4096x2048 at 30.0 fps.

squid_80
2nd January 2009, 06:23
So are there any plans to enable CoreAVC for higher resolutions anytime soon?
Currently CoreAVC handles up to 2048x2048; besides Crowdrun, does anyone have any proper streams (i.e. that they haven't encoded themselves for testing) that exceed these limits?

Ice =A=
2nd January 2009, 13:12
I also think you should NOT sacrifice speed for non-compliant encodings!
After all, you have to draw a line somwhere.

You could include an option to switch on a less rigid codec interpretation with lower speed somewhere in the options menu, but I think that would not be worth the extra money and work!

clsid
2nd January 2009, 14:14
Isn't the solution simple? Implement the MV related functions twice. The current implementation, and a slower one that works with out-of-spec MVs. Add an option to the GUI called "Support out-of-spec motion vectors" with a tooltip like "Warning: this will reduce decoding performance". During initialization, just set the appropriate function pointer in the code based on the option. Users can then choose between speed and compatibility with non-standard video streams.

Result: All your customers are happy.

Dark Shikari
2nd January 2009, 14:42
I also think you should NOT sacrifice speed for non-compliant encodings!Given the way CoreAVC handles MVs, "fixing" decoding of non-compliant streams would in fact speed up, not slow down, encoding ;)

Guest
2nd January 2009, 16:00
BTW, in addition to ffdshow, the Nvida VP2 decoder plays this stream correctly, as do the DirectShow decoders from several software players that I have installed. Core is out on their own here. I don't believe the claim that it would be difficult to fix it or that speed would suffer dramatically.

blubberbirne
2nd January 2009, 16:10
BTW, in addition to ffdshow, the Nvida VP2 decoder plays this stream correctly,

*hm* ffdshow has DXVA support now?

BetaBoy
2nd January 2009, 16:10
Isn't the solution simple? Implement the MV related functions twice. The current implementation, and a slower one that works with out-of-spec MVs. Add an option to the GUI called "Support out-of-spec motion vectors" with a tooltip like "Warning: this will reduce decoding performance". During initialization, just set the appropriate function pointer in the code based on the option. Users can then choose between speed and compatibility with non-standard video streams.

Result: All your customers are happy.

Correct and we talked about this xx# of pages ago and its something I am throwing around internally here again as we go into 1.9.x and 2.0... this would include a pop-under with a similar warning to what you stated but from the tray icon which would then lead them to an option to change support for for larger MV's.

Guest
2nd January 2009, 16:28
*hm* ffdshow has DXVA support now? No, DGAVCDecNV has VP2 support. :)

blubberbirne
2nd January 2009, 19:44
ah ok, i think i was confused :D

RealNC
4th January 2009, 00:06
I hope you guys will support OpenCL instead of CUDA when NV and ATI drivers introduce support for it so that CoreAVC can make use of both ATI and NV :)

CiNcH
4th January 2009, 16:11
I hope you guys will support OpenCL instead of CUDA
There is nothing similar to the CUDA Video API for accessing the PureVideo engine within OpenCL. OpenCL could just replace the CUDA API which uses the shader ALU's for generic computation.

RealNC
5th January 2009, 00:03
There is nothing similar to the CUDA Video API for accessing the PureVideo engine within OpenCL. OpenCL could just replace the CUDA API which uses the shader ALU's for generic computation.

Yes. Doesn't that mean you can run the decoder in-GPU with OCL? That also means that every video will be playable, regardless of it's encoding settings.

tetsuox
5th January 2009, 00:25
Yes. Doesn't that mean you can run the decoder in-GPU with OCL? That also means that every video will be playable, regardless of it's encoding settings.

The PureVideo engine is virtually the same across all 8xxx+ GPU's with minor difference in clock speed (save the lowest end models which use VP3), which leads to similar decoding performance.

Shader clock speeds however are different, not to mention the number of shaders of the various models, which leads me to assume that decoding performance via OpenCL can vary from 900MHz (lowest end 8xxx series) to 1836MHz (GF9800 GTX+). Number of shaders also range from 16 to 240 from the latest and greatest that nvidia has to offer.

nm
5th January 2009, 11:59
Yes. Doesn't that mean you can run the decoder in-GPU with OCL?
You can, but first you'll need to program such a decoder and that is a huge task. For CUDA, NVIDIA provides access to their hardware decoder which means that most of the hard work has already been done.

CruNcher
5th January 2009, 12:32
You can, but first you'll need to program such a decoder and that is a huge task. For CUDA, NVIDIA provides access to their hardware decoder which means that most of the hard work has already been done.

Why do you want to have Decoders written in CUDA for the supported formats it is more efficient then anything else it is like a SAP :) a CUDA based Decoder wouldn't be that Energy Efficient show me HD Video Decoding @ under 1W in CUDA (the shader part of the GPU) :). It would be interesting for other non supported formats like Dirac or VPx :)
And i know many will say it isn't 1W and yes + idle energy it isn't, though you have to face reality and that is GPUs will be everywhere they already in many systems used for Enhancing the GUI Experience of the OS, though for Video Decoding/Encoding in the future Consumers gonna see a nice move to currently 50k like DSP/FPGA solutions that gonna do the Transcoding/Decoding on the fly for the Consumers alike (for a much lower Price) :). In those regards Nvidia and Ati have 1 big + they are here already it's easier for the PC manufacture to get only 1 Card that does it all then 1 GFX card + DSP and Nvidia and Ati currently provide that (Ati/Amd going 1 step already into future Research trying to bring everything into 1 chip) solution at least for the Decoding part, for sure we gonna see progress on the Encoding/Transcoding part from Nvidia and Ati as well :)


Though the problem is only of temporal Nature for Consumers currently, next Generation of Video nobody needs to care anymore about resolution, decoding complexity, Mobile or Desktop Devices will handle it the same way without much heavier Power consumption for Decoding and so also Transcoding will slowly become just a ugly remembering of the Past Digital century :). Future Generations gonna just lough if you tell them "Hey we had to change the complexity of the Video to be able to use it on our Mobile Devices".

nm
5th January 2009, 13:35
Why do you want to have Decoders written in CUDA
If you are replying to me, I don't. I was arguing the same thing as you, CiNcH and tetsuox: using dedicated hardware decoders for H.264, VC-1 and MPEG-2 decoding is currently much more feasible than developing new decoders from scratch with any general purpose GPU language.

RealNC
5th January 2009, 21:05
Hmm, what about Stream SDK then? (AMD/ATI's equivalent to CUDA). It would be sad to have GPU accelerated CoreAVC only for NVidia :(

TheShadowRunner
5th January 2009, 21:43
Just making sure... adding a filter between decoder and renderer wouldn't break CUDA offload, would it?
(i'm thinking how Vsfilter currently breaks dxva..)
Later,

TSR

CruNcher
6th January 2009, 00:39
It shouldn't break it also it is independent of the Renderer as it uses Nvidias Hardware Decoding Engine directly the same way Donald does it and you should also be able to leverage from most of the bugfixes in the NVCuvid Ecosystem :)

TheShadowRunner
6th January 2009, 01:17
thanks for your confirmation didn't catch the joke about donald though

nm
6th January 2009, 01:35
No joke there, CruNcher was talking about Donald Graft's (aka neuron2) DGAVCDecNV.

Guest
6th January 2009, 01:36
I didn't get the joke either. :)

TheShadowRunner
6th January 2009, 01:55
haha sorry neuron ;)
Good news about VSFilter not breaking anything, CUDA sounds like it's the best of both worlds.

BetaBoy
7th January 2009, 16:30
Ok.. I've been getting some email on this so... now that DivX 7 out I can respond more publicly. We will be releasing some official comparisons of DivX 7 Vs CoreAVC by the end of the week at http://compare.coreavc.com/ (dead link atm) and yes we will also be including ffdshow-mt in the comparison chart and full specs on the test environments and we will show separate NVIDIA CUDA results.

Also if anyone is at CES you can PM me and we can give you some times on where we will be if you want to see some of the various projects we are doing.... We will also be showing CorePlayer Mobile for the iPhone/Touch.

Also NVIDIA has told us that CoreAVC 'CUDA Enabled' Professional Edition will be showcased at the NVIDIA booth, so go swing by there to check it out in action.

clsid
7th January 2009, 19:06
Wouldn't such a comparison be biased? Because I noticed that benchmarks from others show that CoreAVC performs better for some samples, while DivX performs better with other samples. If either one publishes a comparison, then they will obviously pick those samples that make their decoder look better.

Dark Shikari
7th January 2009, 19:09
Wouldn't such a comparison be biased? Because I noticed that benchmarks from others show that CoreAVC performs better for some samples, while DivX performs better with other samples. If either one publishes a comparison, then they will obviously pick those samples that make their decoder look better.Then I can provide a sample: grab one of these (http://mirror05.x264.nl/Dark/?dir=./x264clips).

JohnnyFu
7th January 2009, 20:17
When it comes to reviews on big tech websites, these websites usually compare the most common media files for their readers. Blu-Ray, HD-Streams, Apple Trailer for instance.
Hopefully CoreAVC can perform well on that stuff. Btw, almost every website I read reported about DivX 7 these days. This is something I miss for CoreAVC, there is alot of work for the marketing guys :)

BetaBoy, I just dropped you a PM.

BetaBoy
7th January 2009, 20:20
DS... thx for the samples and we will use them... clsid... yes and no... but we will be as open to the conditions and we will adjust it accordingly based on everyone's feedback like DS has just done. We are not trying to bash anyone at all, we just want to get through the facts (from our perspective of coarse) that others are putting out there so consumers can make the choice that meets their needs.

LoRd_MuldeR
7th January 2009, 20:22
Btw, almost every website I read reported about DivX 7 these days.

Crazy that so many sites report about DivX 7, which basically is the DivX 6.8.5 Codec with a new logo :rolleyes:

(...and a slightly improved, but still useless DivX Converter)

leeperry
7th January 2009, 21:11
Crazy that so many sites report about DivX 7, which basically is the DivX 6.8.5 Codec with a new logo :rolleyes:

(...and a slightly improved, but still useless DivX Converter)
well it includes Remoulade, which is just as fast as CoreAVC.....and freeware.

I've posted benchmarks here :
http://forum.doom9.org/showpost.php?p=1232971&postcount=13

and it has a "low latency" option that seems to help a lot jitter-wise in Haali's Renderer when using crazy AVS scripts in ffdshow :o

LoRd_MuldeR
7th January 2009, 21:20
well it includes Remoulade, which is just as fast as CoreAVC.....and freeware.

That's really the only reason to check out DivX 7. And even that only if you don't own CoreAVC and if you aren't satisfied with ffdshow-MT.

BetaBoy
8th January 2009, 00:31
leeperry.... that's a misleading statement on DivX7, it maybe as you state with some content and with 'your' configuration but for others as reported in this thread and in other threads it is not. That's why we feel the compare site is important, to inform. If they truly did beat us I would be the first one jumping at chance to showcase CoreAVC 2.0 @ the NVIDIA booth while we are here at CES.

Cyber-Mav
8th January 2009, 00:39
betaboy you believe that coreavc 2.0 will be a lot faster on cpu decoding than current 1.8.5 version? how much more speed is there left to gain?

Dark Shikari
8th January 2009, 00:42
betaboy you believe that coreavc 2.0 will be a lot faster on cpu decoding than current 1.8.5 version? how much more speed is there left to gain?A lot. Current CoreAVC doesn't use SSE at all.

tetsuo55
8th January 2009, 00:51
A lot. Current CoreAVC doesn't use SSE at all.

Maybe SSE4.1 will help even more, not sure of its completely interesting for h264 decoding, and AVE should speed things up even more..

Here is an article on SSE4.1 in a video environment
http://www.virtualdub.org/blog/pivot/entry.php?id=199

Cyber-Mav
8th January 2009, 01:00
A lot. Current CoreAVC doesn't use SSE at all.

huh?? i thought it used sse2???

damn any guesstimates on how much % increase in speed can be seen with SSE being used?

Dark Shikari
8th January 2009, 01:03
Maybe SSE4.1 will help even more, not sure of its completely interesting for h264 decoding, and AVE should speed things up even more..

Here is an article on SSE4.1 in a video environment
http://www.virtualdub.org/blog/pivot/entry.php?id=199I have yet to imagine any possible use of SSE4 for decoding, though maybe there might be something creative with pblend or pinsrd.

It will be used for some upcoming x264 optimizations, but those are only encoder-side.huh?? i thought it used sse2???

damn any guesstimates on how much % increase in speed can be seen with SSE being used?A lot. This by the way is the reason why CoreAVC has such a huge advantage on older CPUs--on newer ones, competing encoders making heavy use of SSE close the performance gap, but on older CPUs where SSE isn't available or isn't very fast, CoreAVC has a large advantage.

IgorC
8th January 2009, 03:00
If I remember correctly most of x264's algos obtained 15-30% perfomance gain when gone from MMX to SSE/SSE2/SSE3....
But I'm not sure about CoreAVC as it is a decoder not encoder.

Sagekilla
8th January 2009, 03:16
You also have to realize the decoder isn't doing stuff like RD or any other optimization of file size vs quality ;) In that case, speeding up a function that's commonly used on both encoding and decoding could provide two different results. On encoding, it may only improve your speed 5 - 10%, while on decoding it might speed up by 30%* instead.


* Note: Just used some numbers to give an idea of comparison, don't take this as actual word for % speedup you'll get.

leeperry
8th January 2009, 04:09
leeperry.... that's a misleading statement on DivX7, it maybe as you state with some content and with 'your' configuration but for others as reported in this thread and in other threads it is not. That's why we feel the compare site is important, to inform.
oh ok sure, sorry...didn't mean to troll in your topic :rolleyes:
my results were on an o/c Q6600...they might very well differ on a dualcore/amd/p4 and so on :o
still hoping to see the bugs in CoreAVC CUDA I told you about fixed http://forum.slysoft.com/images/smilies/agreed.gif

laserfan
8th January 2009, 06:04
How can I try CoreAVC Pro as input to x264? It works fine with Media Player Classic, showing on my system that Sonic HD Demuxer is feeding it, but I can't seem to make an Avisynth script that x264 (or e.g. VirtualDub) will work with.

I've tried the simple

DirectShowSource("d:\video.h264")

since CoreAVC is set to Preferred but no dice. I've tried building a graph and opening IT:

First I tried Haali Media Splitter and it says "not a recognized format" (the h264 is demuxed from a BD disc). Using Sonic HD Demuxer lets the graph play with a Video Renderer but it won't open in an .avs.

How can I try CoreAVC as input to x264?

Guest
8th January 2009, 06:10
Start with the working graph. Remove the renderer. Save it. Then open the graph using DirectShowSource("video.grf", audio=false).

laserfan
8th January 2009, 06:36
Thanks but no go here. Seems simple, I dragged the video.264 onto GraphEdit and it makes a nice

video.264 --> Sonic HD Demuxer --> CoreAVC Video Decoder --> VMRinput Video Renderer

graph and this plays out of GE in an ActiveMovie window. I delete the Video Renderer, save the graph and then make a 'try.avs' that's simply:

DirectShowSource("d:\video.grf", audio=false)

but this .avs causes the x264 cmd to yield

avis [error]: unsupported input format (DIB)
x264 [error]: could not open input file 'try.avs'

BTW I do see an instance of CoreAVC's icon in the tray appear when I launch my x264.cmd which lingers there after the cmd is done. Then I mouse over it and it disappears, so SOMETHING got CoreAVC's attention, but it hangs. Any ideas???

rebkell
8th January 2009, 06:54
Try moving the YV12 Output format to the top of the list in Output formats: in the config for CoreAVC.

Guest
8th January 2009, 06:56
Does the AVS open in VirtualDub?

Snowknight26
8th January 2009, 08:24
Try moving the YV12 Output format to the top of the list in Output formats: in the config for CoreAVC.

Or just add ConvertToYV12() to your avs file.

laserfan
8th January 2009, 15:11
Try moving the YV12 Output format to the top of the list in Output formats: in the config for CoreAVC.

Or just add ConvertToYV12() to your avs file.YV12 Output is already on top for CoreAVC.

Does the AVS open in VirtualDub?No, neither VDub nor VDubMod would open it. This morning I've tried instead demuxing to an .mkv instead of .h264 and the resultant .grf is very simple:

video.mkv --> CoreAVC Video Decoder --> VMR Video Renderer

Delete the Renderer and this works! The (simple) DSSource .avs is liked by x264 and Vdub both. But I'd like to know why .mkv works but .h264 doesn't? GraphEdit inserts/wants Sonic HD Demuxer between the source and the CoreAVC for 264 (which doesn't work with .avs/x264/Vdub) but .mkv is so simple Input --> CoreAVC? I don't get it. Both types of files are created by eac3to v2.87.

I did btw spend a bunch of time trying to get my DS to Prefer a different intermediate than Sonic HD Demuxer but nothing other than Cyberlink PDVD would insert there. I thought CoreAVC needed Haali. :confused:

Thanks guys, at least now I know how I can try CoreAVC as input to my x264.cmd--if anyone knows why I seem only to be able to use .mkv tho please advise!? I don't like these mysteries and I've spent hours on this...

Guest
8th January 2009, 15:48
No, neither VDub nor VDubMod would open it. What is the error message?

It works just fine for me.

BetaBoy
8th January 2009, 15:58
I thought CoreAVC needed Haali. :confused:

Not required but recommended (we love Haali's work and he is an asset to CoreCodec and the D9 community).

Sagekilla
8th January 2009, 15:58
@laserfan: If you're using DSS to open a graphedit file, your flow is supposed to be only Source --> Video Decoder. No renderer, that's only when you're displaying the video ;)

laserfan
8th January 2009, 16:10
What is the error message? It works just fine for me.After some long seconds, I get a "DirectShowSource: timeout waiting for graph to start". :(

I tried another .264 file, same problem. neuron2 (or anyone) if you simply drag a .264 file onto GraphEdit, what if anything does your system insert between the Input and the CoreAVC? On mine it insists on Sonic HD Demuxer and when I try to force Haali that doesn't work at all i.e. won't "connect".

Guest
8th January 2009, 16:17
http://neuron2.net/misc/grf.jpg

laserfan
8th January 2009, 16:20
Argh! Looks just like mine. Damn.

Thanks neuron2. Just doesn't work for me, and only CoreAVC exhibits a problem, and only with .264s. The only thing I can think is I'm using newest Avisynth & maybe I should revert to 2.5.7 or something?

madshi
8th January 2009, 17:41
we love Haali's work and he is an asset to [...] the D9 community
He was, when he was still active. There is a really bad bug in his current TS/m2ts splitter version (try playing m2ts with a 5.1 or 7.1 LPCM track) and he didn't care to fix it for 9.5 months now... :(

Guest
8th January 2009, 18:22
Is the source code available?

STaRGaZeR
8th January 2009, 19:36
He was, when he was still active. There is a really bad bug in his current TS/m2ts splitter version (try playing m2ts with a 5.1 or 7.1 LPCM track) and he didn't care to fix it for 9.5 months now... :(

Stereo LPCM won't play either :scared:

Neuron, if you're refering to Haali's splitter, no it's not open source.

laserfan
8th January 2009, 22:17
@laserfan: If you're using DSS to open a graphedit file, your flow is supposed to be only Source --> Video Decoder. No renderer, that's only when you're displaying the videoYep, my graphs look just like the one neuron2 posted, and play fine either out of GE or with MPC, but when I delete the Video Renderer and attempt an open it fails with a timeout.

I've uninstalled Avisynth 2.5.8 and installed 2.5.7 and then reinstalled 2.5.8, rebooting the PC and checking DirectShowSource.dll every time, to no avail. Note .mkvs work but not .h264s. CoreAVC is the only problem I'm having w/this--can anyone imagine what might be wrong? :scared:

Sagekilla
8th January 2009, 23:21
Personally, I've never tried doing a .264 Source --> CoreAVC --> Output to DSS. I've always done m2ts source / mkv source --> CoreAVC --> Output to DSS.

Shouldn't be an issue though, since CoreAVC -should- handle the file the same regardless.

Snowknight26
8th January 2009, 23:59
BetaBoy, any word on the release of a new Haali Media Splitter?

Cyber-Mav
9th January 2009, 00:25
I have yet to imagine any possible use of SSE4 for decoding, though maybe there might be something creative with pblend or pinsrd.

It will be used for some upcoming x264 optimizations, but those are only encoder-side.A lot. This by the way is the reason why CoreAVC has such a huge advantage on older CPUs--on newer ones, competing encoders making heavy use of SSE close the performance gap, but on older CPUs where SSE isn't available or isn't very fast, CoreAVC has a large advantage.

does that mean that performance could get a bit better for older amd athlon xp cpus? (barton core specifically)

Sagekilla
9th January 2009, 02:07
If the CPU supports SSE (and isn't terribly slow at it), then yes. I don't know if the very first CPUs to have SSE (P3 and Athlon I believe?) have the fastest SSE engines though, so it might not net much of a benefit.

Dark Shikari
9th January 2009, 02:28
does that mean that performance could get a bit better for older amd athlon xp cpus? (barton core specifically)Athlon XPs don't even have SSE2.

roozhou
9th January 2009, 09:41
Argh! Looks just like mine. Damn.

Thanks neuron2. Just doesn't work for me, and only CoreAVC exhibits a problem, and only with .264s. The only thing I can think is I'm using newest Avisynth & maybe I should revert to 2.5.7 or something?

Try this. Just specify your input file as paff.264 and you don't need an avisynth script.
http://forum.doom9.org/showthread.php?t=141441

If you can also input .grf files, and remember NOT TO delete video renderer.

popper
9th January 2009, 12:39
Currently CoreAVC handles up to 2048x2048; besides Crowdrun, does anyone have any proper streams (i.e. that they haven't encoded themselves for testing) that exceed these limits?

the only Original higher test sets than 1080P i know of are the big bunny/ED and these grabs from 2004, but i dont know if they are also in encoded streams or just 3840x2160p/50 .sgi pics etc, just one pic is a massive 47.4MB (49.766.912 bytes) so your going to need a fast BB and lots of spare HD space though to make even a small test .TS/MKV

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

perhaps other people know other CC test sets too, perhaps we should have a list made up for people to use!

Mottodj
9th January 2009, 12:57
Hi everyone. I have a question about switching color output formats in CoreAVC. I'm using mpc-hc with VMR9 and CoreAVC ver. 1.7, and while switch output format from YV12 to RGB32 picture changes colors(it looks like change colorimetry from bt601 to bt709). Is that decoder thing or it source problem?(original source(avc1 also) don't produce such issue, but x264 encode of this source produce such noticeble color change.)

squid_80
9th January 2009, 12:59
It's easy enough to make high res. H264 streams yourself, but I'm asking if anyone is having problems playing streams obtained from other (legitimate) sources. Otherwise I think people are making the issue seem bigger than it actually is.

popper
9th January 2009, 13:15
easy to upscale your content yes, but your going to loose details, capturing in these native res is another matter all together...even for the video Pros and their kit here id imagine, so perhaps a super HD list is still a good idea.

if you happened to have access to the "DVB-S2 Enables 140 Mbps Super Hi-Vision By Satellite At IBC 2008" stream then while its not a problem right now it might be one day....

something for the video devs to aspire to at least i guess.

http://www.dvb.org/news_events/dvbscene_magazine/DVB-SCENE27.pdf
page 4 of 16

"One of the highlights of this year’s IBC in Amsterdam is the first broadcast, live by satellite, of Super Hi-Vision (SHV) using DVB-S2, from the RAI Research up-link station in Turin.

SHV, the 4000 line x 8000 pixels/line television system under development by NHK, the Japanese public broadcaster, offers an astonishing user experience, thanks to a picture resolution sixteen times that of what we presently call ‘High Definition’.

There are 60 progressively scanned frames a second, and for audio,...

...
Since the native SHV signal bit rate is a massive 24 Gbit/s, the major part of the challenge has been in developing technical ways of delivering the service to the final user. SHV is in our case compressed using MPEG-4 AVC at a final bit-rate of around 140 Mbit/s and delivered to IBC in Amsterdam from the up-link station of the research headquarters of Italian public
broadcaster RAI in Turin, over Ku-band satellite capacity provided by Eutelsat.

For this first public demonstration of SHV by satellite, it will come as no surprise to discover that DVB-S2 technology has been selected by RAI, which led the development of this ‘father’ of second generation DVB systems in 2003....
"
http://www.dvb.org/news_events/dvbscene_magazine/index.xml

TheShadowRunner
9th January 2009, 15:39
In the latest nVidia drivers 181.20 release notes i see:
Added support for the new NVIDIA CUDA Video Encoder with H.264 optimization
Anyone has a clue what Encoder they're talking about? Any relation to CoreAVC? (the developer, not codec)
Later,

TSR

TheResidentEvil
9th January 2009, 17:48
I dont know what encoder they are talking about specifically however, I found this encoder which does support CUDA and I have never used

http://www.badaboomit.com/?q=node/4

Sharktooth
9th January 2009, 18:09
In the latest nVidia drivers 181.20 release notes i see:

Anyone has a clue what Encoder they're talking about? Any relation to CoreAVC? (the developer, not codec)
Later,

TSR
nope. i guess they're talking about their own encoder...
I dont know what encoder they are talking about specifically however, I found this encoder which does support CUDA and I have never used

http://www.badaboomit.com/?q=node/4
blah... badaboom still sux. on actual computers x264 is faster and produces better quality.
i guess they need some more months to actually produce a good encoder...

deekey777
9th January 2009, 20:09
In the latest nVidia drivers 181.20 release notes i see:

Anyone has a clue what Encoder they're talking about? Any relation to CoreAVC? (the developer, not codec)
Later,

TSR


CyberLink Launches the New PowerDirector 7 Optimized for NVIDIA CUDA Technology (http://www.cyberlink.com/eng/press_room/view_1994.html)
CyberLink PowerDirector 7 designed with NVIDIA CUDA Encoder technology achieves up to 274% performance gain when transcoding H.264 videos. By leveraging the multi-core parallel power of the GPU, PowerDirector 7 provides consumers with an accelerated video editing experience resulting in faster rendering of H.264 HD videos to AVCHD, M2T format and for viewing on iPod® and PSP®. PowerDirector 7 supports CUDA-enabled NVIDIA GeForce® processors with NVIDIA graphics drivers version 181.20 or higher.

Maybe it's Nvidia's answer to ATI's AVT.

popper
9th January 2009, 21:45
Isn't the solution simple? Implement the MV related functions twice. The current implementation, and a slower one that works with out-of-spec MVs. Add an option to the GUI called "Support out-of-spec motion vectors" with a tooltip like "Warning: this will reduce decoding performance". During initialization, just set the appropriate function pointer in the code based on the option. Users can then choose between speed and compatibility with non-standard video streams.

Result: All your customers are happy.

you missed out the most vital option, a BIG fat onscreen warning

"THIS IS AN OUT OF SPEC ENCODING,Please speak to the vendor"

you could also include the out of spec vecture OC to make it easy to report/fix etc....

that way, its clear that theres a problem somewere that people might not be aware of otherwise, and the master houses cant help but see this warning every time they play their wrong encodes in testing, its assumed they will be using CoreAVC in their chain at some time in their inhouse end user simulation tests, and so they get the chance to fix it BEFORE its released publicly...

that would do far more to help eradicate this problem in the future, as they wont want their encodes to be publicly broadcasting these Pro house Encoder errors to all their potential viewers/customers...

laserfan
9th January 2009, 22:13
http://neuron2.net/misc/grf.jpgI tried ArcSoft MPEG Demux instead of Sonic HD Demuxer and it finally works! My Sonic v4.3.0.89 must be broken somehow, and still dunno why Haali Splitter doesn't even like my 264 files, but glad I found that AS MPEG Demux works for h264 (nice name, no wonder I couldn't find it).

Thanks to neuron2 & all who responded. Man that was painful.

Guest
9th January 2009, 22:16
Mine is 4.2.00.0064.

popper
10th January 2009, 03:38
CyberLink Launches the New PowerDirector 7 Optimized for NVIDIA CUDA Technology (http://www.cyberlink.com/eng/press_room/view_1994.html)


Maybe it's Nvidia's answer to ATI's AVT.

AVT ?, perhaps you meant the ATI UVD ASIC Logic ! ,the equ of the NV VP2 Logic but better as its got more options!

it appears theres going to be a potentially long wait (at least months) for open source coders docs to access that UVD Logic if Ever OC, unless OC someone manages to persuade them to put the internal bean counters on ice as regards this UVD , rapidly shift gears, and put open UVD Logic docs and Dev errata support at the top of their list of things to do....

people like BetaBoy might stand a better chance to get access to UVD Logic docs and Dev support sooner though perhaps.. only if he and other Devs here asks them OC....

Bridgman said:""we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "

http://www.phoronix.com/forums/showthread.php?t=14641&page=9
"Quote:
Originally Posted by popper
thats a shame, we are looking at months at the very least then!

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


http://www.phoronix.com/forums/forumdisplay.php?f=43

popper
10th January 2009, 07:01
I hope you guys will support OpenCL instead of CUDA when NV and ATI drivers introduce support for it so that CoreAVC can make use of both ATI and NV :)

by the looks of it i wouldnt go getting any hopes up any time soon, NV VP2 Logic and potentially a lot later ATI UVD ASIC Logic if the review goes through and passes the OK are currently probably the chosen easy 3rd party dev path it seems, i dont know what you might use on Intel Gfx though ! ,do they also have an equivalent video streaming FIFO ASIC onboard? and a matching sub-set API you can easily use! to make it do stuff.


http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=104649&highlight_key=y&keyword1=openCL

it doesnt seem hopeful of any real alpha/beta progress until at least Q2 2009, and even then "The OpenCL spec puts the language at a higher level than CAL but not at as high a level as Brook+. "

the
Topic Title: Project on GPU accelerated applications
Topic Summary: Looking for ATI Stream programs
Created On: 01/04/2009 10:04 PM

posted 6 days ago
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=106226&enterthread=y

only mentions one test app so far, not good....for the official site you would expect to see some early activity and test code in this generic ATI Stream programs subject

shader decoding test code "Generic GPU-Accelerated Video Decoding"
http://www.bitblit.org/gsoc/g3dvl/

says he made a somewhat working code thats super slow but kind of functions for HD, however thats working on NV only not ATI, so your going to have to add that ATI part and improve the speed a LOT, probably re-write it from scratch infact...using CAL and/or Brook+. http://forums.amd.com/devforum/categories.cfm?catid=328

http://www.phoronix.com/forums/showthread.php?p=57896#post57896
to the question of shader decoding , Bridgeman says

"....In terms of hardware required, quick answer is "nobody knows for sure until the code is written".

I doubt that the 40-ALU parts (HD2400, HD34xx, 780) will have enough power since the 3D engine is also being used for render accel (colour space conversion, scaling, deinterlacing etc..).

I have always suggested that anyone wanting to run the open source drivers go with at least a 120-ALU part (2600, 3650 etc..) to have some shader power left over for decode work.

Again, this is all hypothetical right now anyways. I am just trying to give everyone an idea of what the likely scenarios are -- "

that about covered the basic i think, were do we go from here on all platforms with your average ATI X1550,HD3650,HD4xxx card or two!

perhaps BetaBoy could be convinced to play a better Divx7 game ;) and have these produced as a plug in and go HW En/DE code portable device, linked together with a good FPGA for processing LOTS of related datasets and unthought of HW assisted apps today on a cheap USB2 stick, you WOULD have to finally write that PPC (thats a real powerPC remember BB) app to use it ON PPC (PS3 etc) linux etc though....BetaBoy ;)

if not Core, perhaps some readers with access to far easten contacts could have them run something like this up and we could get away from all this messy HD Encoding/Decoding, perhaps x264 could be refactored into a basic FPGA and put on USB2 too? and we could give X264 etc some money too for all the great work already done to bring us this far.

"just a very quick search brings you this mobile/handheld chipset/SOC (OC you could also use it in USB stick and the like , anyone doing that today), not as flexable as FPGA OC and not a PPC SOC but its cheap and flexible, and Ohh look...

"Each chip is a real-time H.264/MPEG4-AVC High Definition (level 4.1) Encoder/Decoder (Codec) that provides the ideal mix of flexibility and power efficiency for consumer electronics
applications....."

"full HD (1920x1080). Qpixel
is also raising the power-performance bar by being the first to offer
full HD H.264 encoding at less than 275 mW of power,"

http://www.reuters.com/article/pressRelease/idUS10020+02-Jun-2008+BW20080602
Industry's Lowest-Power Full HD H.264 Codecs With the Broadest Feature Set Unveiled...
Sun Jun 1, 2008 8:00pm EDT"

"

http://www.videsignline.com/products/212501012;jsessionid=BAZHTTSN1ARPSQSNDLPCKH0CJUNN2JVN

true its a large chip but its billed as "... are claimed to offer the industry's largest density, highest performance, highest system bandwidth, and lowest power among high-end FPGA solutions. "

you could even activate its gigaE ports and use it on your LAN and make an HD encoder multicast tunneled end to end mesh for multi PIP TS feeding out of them ;) got to think bigger and turnkey USB3 to make real long term money OC...

popper
10th January 2009, 10:32
I have yet to imagine any possible use of SSE4 for decoding, though maybe there might be something creative with pblend or pinsrd.

It will be used for some upcoming x264 optimizations, but those are only encoder-side.A lot. This by the way is the reason why CoreAVC has such a huge advantage on older CPUs--on newer ones, competing encoders making heavy use of SSE close the performance gap, but on older CPUs where SSE isn't available or isn't very fast, CoreAVC has a large advantage.

just go and ask Luca Barbato, markos (freevec) http://www.freevec.org/ and the other Altivec boys, they have been bit shifting 128-bit Altivec SIMD vector code for a long time, and will probably give you some idea's for all sorts of interesting things to try and match Altivec now that SSE4.1 has finally almost got there. after all these years ;)

Dark Shikari
10th January 2009, 15:09
just go and ask Luca Barbato, markos (freevec) http://www.freevec.org/ and the other Altivec boys, they have been bit shifting 128-bit Altivec SIMD vector code for a long time, and will probably give you some idea's for all sorts of interesting things to try and match Altivec now that SSE4.1 has finally almost got there. after all these years ;)Altivec has been behind SSE for years--it still doesn't have pmovmskb ;)

(Or for that matter, any way to emulate it at all)

Cyber-Mav
13th January 2009, 05:04
Athlon XPs don't even have SSE2.

true but they do have SSE1, would that be of any benefit? or is sse2 needed as a minimum for speed increase?

BetaBoy
13th January 2009, 05:12
All... just getting back from CES tonight. I want to thank the CES staff from NVIDIA for demo'ing CoreAVC Professional Edition w/CUDA support. We have received a lot of feedback and comments but it was nice to see someone at CES mention that the other CUDA enabled product demo's shown had to show a video of the CUDA statistics (before / after) in use, while CoreAVC was 'live' and you could seen the difference in realtime!

Now that the show is over and we have had some more feedback. We have a new punchlist of small changes and are going to schedule a release of v1.9 by the end of the month.

Dark Shikari
13th January 2009, 05:37
true but they do have SSE1, would that be of any benefit? or is sse2 needed as a minimum for speed increase?Only integer operations are useful for video decoding, so SSE1 isn't useful.

leeperry
13th January 2009, 15:20
Now that the show is over and we have had some more feedback. We have a new punchlist of small changes and are going to schedule a release of v1.9 by the end of the month.
any chance to see the 2 CUDA bugs I told you about fixed ?
the pulp fiction sample that's missing colors, and the seeking problem in KMPlayer that doesn't wait for keyframes and sends garbled video instead..
they still both occur even w/ the 185.20 beta drivers. :thanks:

BetaBoy
13th January 2009, 17:30
lee... sure.... but atm we are waiting to hear back from NVIDIA on a library distribution question and how to best handle it so we don't conflict with their efforts.

leeperry
13th January 2009, 20:12
awesome http://forum.slysoft.com/images/smilies/cool2.gif

and do you still have plans to release CoreWMV? I could personally use some fast WMV3/VC1 decoder.

in case you got some beta version ready, I'm willing to try it and give feedback too :D

madshi
14th January 2009, 10:17
and do you still have plans to release CoreWMV? I could personally use some fast WMV3/VC1 decoder.
Me, too. BTW, BetaBoy, you talked earlier about CoreAAC. All I can find is a rather old version for download. Will there be a new CoreAAC release, too? And will it be free or cost something? If you really do create CoreWMV and CoreAAC, maybe you want to consider a "CoreCodec" package for purchase which would combine all codecs you currently offer and will offer in the future?

tommy_vercetti
15th January 2009, 02:38
Me, too. BTW, BetaBoy, you talked earlier about CoreAAC. All I can find is a rather old version for download. Will there be a new CoreAAC release, too? And will it be free or cost something? If you really do create CoreWMV and CoreAAC, maybe you want to consider a "CoreCodec" package for purchase which would combine all codecs you currently offer and will offer in the future?

That would be great !

frank
16th January 2009, 14:28
laserfan wrote:
I've uninstalled Avisynth 2.5.8 and installed 2.5.7 and then reinstalled 2.5.8, rebooting the PC and checking DirectShowSource.dll every time, to no avail. Note .mkvs work but not .h264s. CoreAVC is the only problem I'm having w/this--can anyone imagine what might be wrong? Nothing wrong.
I never could stream .h264 from DirectShowSource. And MPC HC can't play it too. That's the reason why I encode to mkv.
I use XPpro, HaaliSplitter and ffdshow. No Sonic or other filters.

Daiz
16th January 2009, 21:42
I've just always used DSS2("source.mkv") when I want to input H.264 video using CoreAVC as the decoder.

BetaBoy
18th January 2009, 19:23
A small heads up.... work is almost done on the 64 bit version of Haali's splitter so we are talking about releasing CoreAVC Pro 64 either in 1.9 or with 2.0. Also this will mean we will be releasing CoreAVC Pro 64 with CUDA support as well since CUDA supports 64bits. Although the QA is gonna be tight with that, we'll see... but an FYI for all none-the-less.

On CoreWMV.... technically supports VC-1 as well as all WMV based video (we wrote it from scratch). But we stopped working on it more to work on CUDA w/CoreAVC. I'll spring it on the guys here to see if we can pickup on it.

TheShadowRunner
18th January 2009, 19:52
BetaBoy, any ETA for the next release of the 32bits version of CoreAVC with CUDA?
Later,

TSR

BetaBoy
18th January 2009, 22:22
TheShadowRunner, see:
atm we are waiting to hear back from NVIDIA on a library distribution question and how to best handle it so we don't conflict with their efforts.

DeathWolf
30th January 2009, 06:16
Is there any chance that coreavc could get an option to actually pass on the AR info?
Unless haali's splitter is used, anamorphic does not work well otherwise.
Currently with
(mpc internal matroska splitter)->coreavc->ffdshow->haali's renderer => does not work
haali's splitter->coreavc->ffdshow->haali's renderer => works fine
(and mpc's internal splitter does pass dwPictAspectRatioX: 853,dwPictAspectRatioY: 480, however after coreavc it's back to 720x480)
Using ffdshow instead of coreavc works fine too.(since ffdshow does pass on the anamorphic flags)

Pulstar
30th January 2009, 18:49
Well since this is a long thread and this question has already been answered (probably), why do CoreAVC+single core CPU+VMR9+MPC HC+MKV produce choppy framerates for SD and HD resolutions? Whereas if I export the same video streams into MP4 for instance using the same config video playback is smooth and CPU is far from maxed. Is it MKV overhead? Buggy Gabest splitter? Will installing Haali splitter resolve this?

STaRGaZeR
30th January 2009, 20:11
Now that the show is over and we have had some more feedback. We have a new punchlist of small changes and are going to schedule a release of v1.9 by the end of the month.

We're at the end of the month now :cool:

BetaBoy
31st January 2009, 21:36
STaRGaZeR... as I already stated we are working directly with NVIDIA at this time on unifying our 1.9 release with their CUDA release efforts and releases. Look for an announcement shortly on this.

DeathWolf
1st February 2009, 02:04
Note: the force vmr ar options does not apply with haali's or does not do anything.(just thought it might apply)

EDIT:

haali actually explained me that the issue is that some streams have both container ar and stream ar, and that his splitter actually overrides the stream ar if there's a container ar.
Would there be any possibility to actually have an option in coreavc to ignore the stream ar?

BetaBoy
10th February 2009, 03:02
We are about to release CoreAVC v1.9 Professional Edition w/NVIDIA CUDA support. But before we do I wanted inform you of a few things;
- On or after Tuesday 2/10 you will need to download the latest NVIDIA drivers.
- QA has found an interlaced bug related to CUDA playback, so this initial release will fall back to software for any interlaced content.
- This release will feature the new 32/64bit Haali Media Splitter and is a precursor to CoreAVC 64 that will be released with v2.0.
- v1.9.x will be EOL for CoreAVC Standard Edition as we migrate towards CoreAVC Enterprise Edition and our v2.0 code base.

More details and the changelog to follow but we wanted to give everyone the heads up to the pending release.

Cyber-Mav
10th February 2009, 03:10
Tuesday 2/10 ? thats quite far away, unless thats the american date format since in uk 2/10 would mean 2nd of october??

also a question about cuda support, will it be limited to windows vista only? will it also work on windows xp?

BetaBoy
10th February 2009, 03:16
For non-us residents... that is February 10th (thought that was obvious). Its supports XP or Vista (any flavor)... 32bit atm and 64bit when we release v2.0.

Cyber-Mav
10th February 2009, 03:24
thanks for clearing that up. would version 2.0 be a free upgrade for me like 1.8.0 to 1.8.5 was? or will i have to pay an upgrade fee?

thanks

woot february 10th?? in the uk that happend just over 2 hours ago!!

BetaBoy
10th February 2009, 03:37
2.0 upgrade talks? I've mentioned in this thread a few pages back. Lets get past GPU with CUDA for v1.9.x.

STaRGaZeR
10th February 2009, 04:44
We are about to release CoreAVC v1.9 Professional Edition w/NVIDIA CUDA support.
- This release will feature the new 32/64bit Haali Media Splitter and is a precursor to CoreAVC 64 that will be released with v2.0.

That sounds tasty :cool:

cyberbeing
10th February 2009, 06:31
- On or after Tuesday 2/10 you will need to download the latest NVIDIA drivers.

By this do you mean NVIDIA will be releasing a new driver which will be needed for CoreAVC CUDA compatibility (i.e. a driver newer then 181.20/181.22)?

dead_screem
10th February 2009, 07:02
- v1.9.x will be EOL for CoreAVC Standard Edition as we migrate towards CoreAVC Enterprise Edition and our v2.0 code base.Cool. Will Profesional go EOL as well anytime soon? IMO there will be too many editions. Professional and Enterprise decoder 2.0 32 and 64 bit versions, plus multiple editions of the encoder whenever that gets released. Things seem like they might get out of hand.

I'd think having just 32 and 64 bit versions of "Core AVC Decoder" but multiple editions of the encoder would make more sense. I mean really, what good is a decoder if it cant decode everything?

G_M_C
10th February 2009, 09:03
Enterprise edition; So that would also mean broader colorspaces/planes and higher profiles (4:4:4 / High10 or extended profile and such ?). If so, it might be a signal to the encoer-developers to make the switch too (avisynth seems to make steps into areas, adding some color-planes).

BetaBoy
10th February 2009, 14:42
Just spoke to Haali.... we are gonna hold off on the 64bit splitter till 2.0 for now, but will still include the newest version.

clsid
10th February 2009, 14:47
Any particular reason for that? I assume his 64bit splitter is still buggy or unfinished?

BetaBoy
10th February 2009, 14:57
No bugs.... Haali would like to add more explorer integration options.

clsid
10th February 2009, 15:06
I see. That is good news, because the current shell extension doesn't work very well on Vista/Seven.

lexor
10th February 2009, 15:09
I see. That is good news, because the current shell extension doesn't work very well on Vista/Seven.

The latest version (the one from January) doesn't even register for me under 7, the previous version does.

BetaBoy
10th February 2009, 16:01
The latest version (the one from January) doesn't even register for me under 7, the previous version does.

I have the older beta of 7 and it installed fine... loading the new version of 7 now.

Snowknight26
10th February 2009, 16:28
Would be nice if you could coo Haali into posting more here or at least have some acknowledgement/status of unfixed bugs.

lexor
10th February 2009, 16:49
I have the older beta of 7 and it installed fine... loading the new version of 7 now.

I think I have the old version (build 7000, the official beta build that's on MSDN right now). The splitter installs fine, but it does not load and MPC doesn't even see it in the list of external filters.

There are no errors or other visible problems during install.

STaRGaZeR
10th February 2009, 19:04
You can also tell him about the splitter not recognizing LPCM tracks present in .m2ts Blu-ray files.

Snowknight26
10th February 2009, 19:14
You can also tell him about the splitter not recognizing LPCM tracks present in .m2ts Blu-ray files.

You mean TrueHD? It recognizes LPCM tracks, just doesn't split them well.

clsid
10th February 2009, 19:17
In case haali needs sample m2ts files, a couple have recently been posted in the ffdshow and MPC-HC topics.

BetaBoy
10th February 2009, 19:52
ok... just finished QA here is the final changelog:
CoreAVC H.264 Video Codec - Version 1.9.0.0 (20090210)
- Add: NVIDIA CUDA accelerated video decoding (Thanks NVIDIA!!!)
- Add: NVIDIA CUDA detection to installer
- Add: Tray icon showing NVIDIA CUDA state (green=in use, blue=not in use)
- Add: Tray icon mouse over shows 32bit/64bit states
- Add: Initial installer changes for 32/64bit
- Add: Updated Haali Media Splitter
- Fix: Focus bug related to MCE
- Fix: Focus prevention when the tray icon is off
- Fix: Improve seeking on frames with one IDR frame
- Fix: Various small bugs

Haali Media Splitter (20090111)
- Add: The shortcut for gdsmux is created in the start menu
- Fix: Broken Matroska files with looped SeekHeads could cause a hang in Matroska Parser, the number of SeekHeads is now limited to 10
- Fix: Removed the workaround to find tags written by Matroska Shell Extension, this caused excessive file scanning when opening files created by recent MKVToolnix
- Fix: File linking is now enabled by default

Next is the release... but on the splitter issues... I'll speak to Haali about creating a project on CoreForge.org to use the bug tracker.

blubberbirne
10th February 2009, 20:01
hm, great job :D

still waiting for the email with the update link :devil:

laserfan
10th February 2009, 20:06
hm, great job :D

still waiting for the email with the update link :devil:Ya I don't get the "peek-a-boo" approach to software release myself. :confused:

STaRGaZeR
10th February 2009, 20:47
You mean TrueHD? It recognizes LPCM tracks, just doesn't split them well.

Nope, I mean LPCM. The tracks are not recognized. Screenshot for a Blu-ray .m2ts with Haali's and MPC's splitter (left and right respectively):

http://thumbnails8.imagebam.com/2631/11b14726308074.gif (http://www.imagebam.com/image/11b14726308074)

You can see how for Haali's splitter there is only 1 output pin, and it's for video (H.264). You can also see the Audio tab from MPC's splitter. Sample on demand.

TrueHD is another issue. Any news about TrueHD support in Matroska BTW?

BetaBoy
10th February 2009, 21:48
ok... 1.9.0 published and emails are going out now.... make sure to install the latest NVIDIA Beta Drivers 182.05 and note my previous mention of the software fallback atm for interlaced content.

Otherwise... Post some results!!!!

blubberbirne
10th February 2009, 22:06
ok, i need go update my drivers :D

coreavc 1.9 installed now

Thunderbolt8
10th February 2009, 22:12
can anyone tell if the colour issue of the haali splitter (puts out slightly too much red) is already adressed here? (see http://forum.doom9.org/showpost.php?p=1235880&postcount=884)

Rectal Prolapse
10th February 2009, 22:39
ok... 1.9.0 published and emails are going out now.... make sure to install the latest NVIDIA Beta Drivers 182.05 and note my previous mention of the software fallback atm for interlaced content.

Otherwise... Post some results!!!!

When I try to download the 182.05 drivers (after selecting Beta in the dropdown list, doing a search, then selecting 182.05) I get this error on NVIDIA's official site:

The page you tried was not found. You may have used an outdated link or may have typed the address (URL) incorrectly. You might find what you’re looking for in one of these areas:

doesn't work right now --> http://www.nvidia.com/object/winxp_182.05_beta.html

It won't work without 182.05 right? Is that what you meant?

EDIT: Hah! It works on my other PC from remote.

Rectal Prolapse
10th February 2009, 22:46
Direct link to 182.05 Windows XP, 32 bit: (US server):

http://us.download.nvidia.com/Windows/182.05/182.05_geforce_winxp_32bit_english_beta.exe

Cyber-Mav
10th February 2009, 22:52
gonna take some time, im gonna be testing this to see what sort of encodes break hardware acceleration.

Cyber-Mav
11th February 2009, 00:18
so far i can confirm cuda acceleration works on xp with a 9600gso and dual core opteron cpu (2.65ghz), in cpu mode average cpu usage is around 54% in cuda mode its varying between 4% to 15% cpu usage.

so far on videos that have unrestricted/non dxva compliance seem to work but do what my wdtv player does, which is cause artifacts such has large blocking/pixellation. thats to be expected though i guess.

back to more testing.....

Cyber-Mav
11th February 2009, 00:30
noticed 1 more thing, idle system ram consumption is 347mb, as soon as i run a hd video ram usage spikes to 820mb for around 10 seconds then drops down to 445mb and remains at that level for the duration of the video. just an observation so far....

DeepBeepMeep
11th February 2009, 01:58
With CUDA, my CPU usage is down from 60% to 20%. However, with some movies I have lots of blocking which doesn't appear on the CPU only version.

It seems as well there are some compatibility problems with Haali Renderer since one time CUDA became disabled and the other time I got a blue screen of death.

Anyway, thanks for the CUDA support, now it is much easier to use CoreaVC with software filters

BetaBoy
11th February 2009, 02:42
Keep the feedback coming guys... especially the CPU usage differences (with CPU/GPU details).

FYI... I just updated the first post in this thread with the changes to the CoreAVC configuration panel as well as the 'Editions' descriptor reflecting the CUDA addition.

Snowknight26
11th February 2009, 04:40
Are there any requirements for using CUDA similar to DXVA or is it something along the lines of 'as long as CoreAVC can software decode it, it will work with CUDA?'

Rectal Prolapse
11th February 2009, 05:58
Massive blocking artifacts in CUDA mode with an NVIDIA 8800GT, using either 181.22 or 182.05 drivers. Title I used was Ghost in the Shell: Solid State Society blu-ray. Also, auto-detect of levels seems to be broken (in CUDA or software mode) - it does levels expansion when it shouldn't. I have to manually set input and output to 16-235 range. Cyberlink AVC decoder works perfectly with this.

One step forward, three steps back. :)

EDIT: Same problems with Max Payne Blu-ray.

CPU is a Core 2 Duo E6400 clocked to 3 GHz. Windows XP SP3, with all updates.

jj666
11th February 2009, 08:48
Did a quick check on my latest Blu-ray remuxes:

Assault on Precinct 13:
http://thumbnails16.imagebam.com/2636/6075a826359160.gif (http://www.imagebam.com/image/6075a826359160)

http://thumbnails13.imagebam.com/2636/d483e326359161.gif (http://www.imagebam.com/image/d483e326359161)

(decoded correctly in software mode)
http://thumbnails12.imagebam.com/2636/3c2f9c26359166.gif (http://www.imagebam.com/image/3c2f9c26359166)

Ghost Town:
http://thumbnails15.imagebam.com/2636/79543726359167.gif (http://www.imagebam.com/image/79543726359167)

http://thumbnails10.imagebam.com/2636/ea80ad26359168.gif (http://www.imagebam.com/image/ea80ad26359168)

Sting! Bring On The Night:
http://thumbnails4.imagebam.com/2636/e6b62726359162.gif (http://www.imagebam.com/image/e6b62726359162)

http://thumbnails16.imagebam.com/2636/45214026359163.gif (http://www.imagebam.com/image/45214026359163)

http://thumbnails8.imagebam.com/2636/7309f726359165.gif (http://www.imagebam.com/image/7309f726359165)

All of the above worked fine (playback etc) in DGAVCIndexNV using CUDA also.

Raging Bull - worked fine.
Super Troopers - worked fine.
The Last Emperor - worked fine.
The Man Who Fell To Earth - worked fine.

If samples needed, please let me know.

Cheers,

-jj-

BetaBoy
11th February 2009, 14:17
Thx for the reports guys... keep them coming... (this is why we wanted all of 1.9.x for CUDA before we went 2.0).



All of the above worked fine (playback etc) in DGAVCIndexNV using CUDA also.

-jj-
Good that means its not CUDA and something we can fix.

Gleb Egorych
11th February 2009, 15:03
BetaBoy, did you do some tests to compare Intel quads vs AMD Phenom (Phenom II) in terms of decoding speed? And do AMD X3 processors have any advantage on X2 processors?

Guest
11th February 2009, 15:16
Good that means its not CUDA and something we can fix. That's unfortunately not necessarily the case. I use the latest nvcuvid.dll from my contact at Nvidia. The version I have has several fixes beyond what is in the released driver.

BetaBoy
11th February 2009, 15:19
That's unfortunately not necessarily the case. I use the latest nvcuvid.dll from my contact at Nvidia. The version I have has several fixes beyond what is in the released driver.

Ahh... that could be the case then. We are taking the stand to not include the CUDA DLL in our installer but instead opting to use the one that is public. We will see if this is the right approach as time progresses and continue to work with NVIDIA on it.

BetaBoy
11th February 2009, 15:28
BetaBoy, did you do some tests to compare Intel quads vs AMD Phenom (Phenom II) in terms of decoding speed? And do AMD X3 processors have any advantage on X2 processors?

What I have found out so far based on the feedback is that since every system configuration is different it yields varied results. We are getting some report of a massive drop of 60% CPU usage down to 1%-7%. But I think the average so far is about a 50-60% reduction (more like 75% for me with a dual core 3.2ghz 9400GPU laptop). It will be interesting to see the interlaced figures when the bug is fixed.

Also, we are talking about setting up a DB for reporting. We'll see on that as we already scrapped our 'compare' website plans against other decoders as we did not want to come off biased.

Cyber-Mav
11th February 2009, 15:48
right single core tests on an opteron 146 @2ghz stock speed with nvidia 8600gt, transformers 1080p rip made using unrestricted 2 pass insane settings in megui, cpu decoding in high action scenes flatlines at 100% cpu usage, using cuda cpu usage averages 16% in those same high action scenes that flat line at 100% on cpu only decoding mode.

as for image quality as jj666 posted above some rips seems to have blocking/artifacting on them, shockingly the transformers rip i made played fine and thats using the unrestricted profile.

will do some more tests, gonna do some underclocking on the single core opteron and see how low i can go on clock speed for videos to still run perfectly.

madshi
11th February 2009, 15:52
Ahh... that could be the case then. We are taking the stand to not include the CUDA DLL in our installer but instead opting to use the one that is public. We will see if this is the right approach as time progresses and continue to work with NVIDIA on it.
I agree that distributing the CUDA DLL with CoreAVC doesn't make much sense, since the danger would be high that the CUDA DLL you distribute would be outdated rather soon.

But maybe you could make the latest CUDA DLL available as a separate optional download? Updating this download whenever a new CUDA version is available should be easy for you (no need for any installers or release notes or such stuff, just the DLL).

Gleb Egorych
11th February 2009, 15:57
What I have found out so far based on the feedback is that since every system configuration is different it yields varied results. We are getting some report of a massive drop of 60% CPU usage down to 1%-7%. But I think the average so far is about a 50-60% reduction (more like 75% for me with a dual core 3.2ghz 9400GPU laptop).
You apparently talk about CUDA acceleration but I asked about pure software decoding, about comparing different CPUs.
For example, timecodec results for Intel Qxxx0, AMD X4, X3 and so on.

DJ Bobo
11th February 2009, 16:35
Since we're talking about CPU usage here, shouldn't the hardware requirements list on the CoreAVC homepage get updated? Recommending a P4@2.8GHz for 1080p videos can be a little bit misleading, can't it? I mean, I'm getting a little over 70% average CPU usage on an Athlon X2 QL-60 (1.9GHz) which should be roughly equivalent to a Pentium D @ 3.2GHz, and you recommend a P4?!
I mean not everybody can use this CUDA thing, I have a Radeon for instance.

Rectal Prolapse
11th February 2009, 17:04
The artifacts jj666 saw look identical to what I saw with Max Payne and Ghost in the Shell: Stand Alone Complex: Solid State Society (whew, long name!), so if you fix those other titles I'm sure it'll work with these. :)

BetaBoy
11th February 2009, 18:12
Since we're talking about CPU usage here, shouldn't the hardware requirements list on the CoreAVC homepage get updated? Recommending a P4@2.8GHz for 1080p videos can be a little bit misleading, can't it? I mean, I'm getting a little over 70% average CPU usage on an Athlon X2 QL-60 (1.9GHz) which should be roughly equivalent to a Pentium D @ 3.2GHz, and you recommend a P4?!
I mean not everybody can use this CUDA thing, I have a Radeon for instance.
We are holding off in such changes till we release the Press Release with NVIDIA. Then we will update the frontpage and the requirements page. However we have updated both the changelog and the Configuration Guide to reflect the 1.9 release.

squid_80
11th February 2009, 18:24
That's unfortunately not necessarily the case. I use the latest nvcuvid.dll from my contact at Nvidia. The version I have has several fixes beyond what is in the released driver.
Your quickstart html tells people to copy nvcuvid.dll into the windows/system32 directory, so it's going to clobber the one installed with the driver anyway (or alternatively be clobbered if the user installs a new driver).

hajj_3
11th February 2009, 19:01
would it not be best to include the .dll in 1.9.0.0 and update it by 1 build each time and bundle the new .dll in and call it 1.9.0.1 have the changelog say "updated cuda .dll file". would save loads of people from having to mess around.

STaRGaZeR
11th February 2009, 19:13
Field order when using hardware deinterlacing is still wrong.

Guest
11th February 2009, 20:31
Your quickstart html tells people to copy nvcuvid.dll into the windows/system32 directory, so it's going to clobber the one installed with the driver anyway (or alternatively be clobbered if the user installs a new driver). Most CoreAVC users are not DG tool users, so my point stands. Or maybe I missed yours?

My point was that nvcuvid.dll is evolving faster than the driver releases, and it would benefit users to distribute the latest version, as I do for my tools.

Guest
11th February 2009, 20:32
Field order when using hardware deinterlacing is still wrong. The VMR framework forces a one-field delay when the deinterlacer is enabled.

leeperry
11th February 2009, 20:49
thanks for the final 1.9!

but my pulp fiction sample still suffers from banding(doesn't occur in software decode, only CUDA), and seeking still makes terrible artefacts in KMPlayer(only in CUDA mode) :(

that's w/ the 181.20 drivers on XP SP3, I'll try to update..

BetaBoy
11th February 2009, 21:20
My point was that nvcuvid.dll is evolving faster than the driver releases, and it would benefit users to distribute the latest version, as I do for my tools.
Short term that maybe the case... but I think in a few weeks that it will be diff. But maybe there is a compromise. I'll ping the guys.

squid_80
11th February 2009, 21:21
Most CoreAVC users are not DG tool users, so my point stands. Or maybe I missed yours?

My point was that nvcuvid.dll is evolving faster than the driver releases, and it would benefit users to distribute the latest version, as I do for my tools.
My point was if a user says "It doesn't work with CoreAVC, but it works with DGAVCIndexNV" then they obviously do have both installed and have probably copied your nvcuvid.dll to the system directory. But then again if they've installed the driver afterwards it might have switched the dll to an older version. I think it would be better if DGAVCIndexNV didn't rely on nvcuvid.dll being in system32; the program location is stored in the .dga file so why can't DGAVCDecodeNV load nvcuvid.dll from there?

I see 2 strong reasons for not distributing nvcuvid.dll with CoreAVC:
- It's now part of the official driver package from nvidia and it's bad practice for applications to overwrite driver files with unofficial versions (unofficial = no version information attached to the .dll)
- It's a lot easier to trace bugs if you know exactly what configuration the user has. It's easier to ask them what driver version is installed than ask them to find the timestamp/hash of a .dll and hope you've got a matching version somewhere.

leeperry: Does the pulp fiction sample look exactly the same as before?

leeperry
11th February 2009, 21:29
leeperry: Does the pulp fiction sample look exactly the same as before?
a bit better, but still quite a lot of banding.
and seeking in KMPlayer looks a bit better too, less artefacts but they're still there.
none of this happens in software mode :o

madshi
11th February 2009, 21:52
@BetaBoy,

I'm a bit confused about what kind of CUDA acceleration you're actually using. It seems to me that there are two different possibilities:

(1) Either you could let the NVidia dedicated video decoding circuit decode the h264 stream.

(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 and not the video decoding circuit of the graphics card).

Could you please clarify which solution you're using? To be honest, I don't really like the idea of using (1), because if there's a bug in the video decoding circuit, all hope is lost. Basically by using (1) you'd give up all control over quality. It's possible that there are some shortcuts in the video decoding circuit, so we can't be 100% sure if we get perfect quality or not. I don't see such risks when using approach (2), so I was hoping you'd use that.

Finally, if you (ever) switch from CUDA to OpenCL, probably you'd be forced to choose approach (2), right?

lexor
11th February 2009, 21:54
Hey Betaboy, you said previously that CUDA has no inherent limitations like DXVA, but the guys in MPC-HC thread are reporting that they get the exact same compatibility level with 1.9 as they do with build in DXVA decoder.

What's the score here?

Rectal Prolapse
11th February 2009, 22:08
Well, according to the DGAVCIndexNV documentation, DGAVCIndexNV requires an NVIDIA card that has the VP2 or better video unit in it. So I suspect that a lot of the work is still being done by the built-in video decoder that is also used by DXVA. I would hazard a guess that CoreAVC does the same thing.

Now the thing is - the Cyberlink (powerdvd) h264 decoder is DXVA and works fine in h/w mode decoding everything I've thrown at it, and use the same amount of CPU. Weird huh?

netchris
11th February 2009, 22:54
Well, according to the DGAVCIndexNV documentation, DGAVCIndexNV requires an NVIDIA card that has the VP2 or better video unit in it. So I suspect that a lot of the work is still being done by the built-in video decoder that is also used by DXVA. I would hazard a guess that CoreAVC does the same thing.

Sigh, if that is true, this cuda implimentation will not work with my 8800 gts 640MB (first generation 8800) either (as mpc hc doesnt too). I had high hopes coreavc 1.9 would work with my gpu. No luck it seems..

STaRGaZeR
12th February 2009, 00:28
The VMR framework forces a one-field delay when the deinterlacer is enabled.

I can't see why that would affect CoreAVC passing BFF flags with TFF content to the renderer. This is in software mode BTW and has been the same since forever. It has been discussed in this thread a few pages back.

BetaBoy
12th February 2009, 00:33
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.

lexor... I'll check with the guys.

Dark Eiri
12th February 2009, 01:09
Just tried the 1.9 trial with CUDA acceleration enabled and I must say it didn't decode properly any of my 720p videos with 10 ref-frames. They get really blocky and green frames all over, then the video stops, but when I try to seek, it plays for a few seconds and stops again. Just tested a 720p with 16 ref-frames and it decodes flawlessly, so it's kinda weird... Blocking when seeking is also present here, but it goes away in a second. Most videos play flawlessly! Again, great job, CoreCodec!

Also, I would like to know why "SD" videos aren't CUDA enabled? I think it would really help some Intel Atom systems with the new nVidia Ion chipsets (GeForce 9400, PV2 \ CUDA capable).

EDIT: Oh, yeah... I'm using 182.05 drivers for Vista 32-bit.
EDIT2: It seems some SD videos are working. Example: Youtube "HQ" MP4 videos are working with CUDA, some of my DVD backups are falling to software decoding.

DeepBeepMeep
12th February 2009, 01:20
Well I have tried to replace my nvcuvid.dll with the version that can be obtained in the installation package of DGAVCIndexNV and I still have some ugly blockiness and banding on half my movie samples.

It is important to stress that I don't have the blockiness with either Cyberlink DXVA decoder or CoreAVC CPU decoder.

Well hopefully this can be fixed easily.

On a side note is it possible to use CUDA as well to accelerate VC1 decoding and obtain better performances than with Nvidia DXVA (which are not great)?

_DW_
12th February 2009, 01:59
I have a question not related to CoreAVC decoding abilities. I've been test driving the trial version for the last few days. What I want to know if I buy it now what will it get me in the future? You've been talking about 2.0 for a while now. If I buy 1.9.x now can I automatically upgrade to 2.0?

BetaBoy
12th February 2009, 02:29
As I've said in earlier posts.... although I'm mentioning 2.0 more then several time (especially for 64bit) we are not even close to a release as we want to spend time in 'v1.9.x land' for a while exploring, adding, fixing, changing GPU. So we have no idea how long the 1.9.x release cycle will be and or how many releases are yet to come. But any current user purchaser will get a 'unique' discount upgrade link when 2.0 is out and any user purchasing it within xx days since the last release will get the upgrade for free (with xx being to be determined later). Of coarse this is subject to change... but this is the plan atm.

Cyber-Mav
12th February 2009, 02:35
would have been a lot clearer and simpler if you just said that "version 2.0 will require purchase since upgrade from 1.x will not be free."

_DW_
12th February 2009, 03:16
would have been a lot clearer and simpler if you just said that "version 2.0 will require purchase since upgrade from 1.x will not be free."

That was exactly what I was fishing around for. The change from the 1.x to the 2.x will cost. Since 1.9 is 15 bucks I'm not really going to worry about it. I've removed the trial version and I'm going to use fddshow for a few more days till the bugs to 1.9.x are worked out.

STaRGaZeR
12th February 2009, 04:02
So no 64-bit Haali's splitter for several months then. :(

Inspector.Gadget
12th February 2009, 04:58
I have an 8600M GT and I've just updated to the 182.05 drivers. Immediately after that (but after rebooting), I installed CoreAVC Professional 1.9.0.0. When I go to the configuration page for CoreAVC, the "Prefer CUDA Acceleration" option is grayed out. This remains the case even after deleting "CoreAVC.ini" in my Appdata\Roaming folder. The 8600M GT supports VP2, according to Nvidia. Is there something else I need to do to enable CUDA acceleration or have I made a mistake somewhere?

ilkertezcan
12th February 2009, 05:09
CoreAVC settings file (coreavc.ini) saved to %userprofile%. (\Documents Settings\...\Application Data). I want save to another folder. How am I make this?
Or...
I want only registry entries(no INI file): (HKEY_LOCAL_MACHINE\SOFTWARE\CoreCodec\CoreAVC Trial\ ...)
I created "brightness" dword value. But don't working(automatically created coreavc.ini).

BetaBoy
12th February 2009, 05:49
CoreAVC settings file (coreavc.ini) saved to %userprofile%. (\Documents Settings\...\Application Data). I want save to another folder. How am I make this?
Or...
I want only registry entries(no INI file): (HKEY_LOCAL_MACHINE\SOFTWARE\CoreCodec\CoreAVC Trial\ ...)
I created "brightness" dword value. But don't working(automatically created coreavc.ini).

The ini file is the only way and cannot be moved to another location. I'll see about adding an registry option.

edison
12th February 2009, 06:04
The hardware de-interlacing does not work when playing interlaced h264 video and RGB32 output, my card is GeForce 9600GT.

BetaBoy
12th February 2009, 06:18
edison... you did see the note that interlaced content is not supported with this initial CUDA release, correct?

cyberbeing
12th February 2009, 06:45
So no 64-bit Haali's splitter for several months then. :(
If you're feeling impatient or want to possibly speed up the process, you could use Haali's experimental 64-bit build (http://www.mediafire.com/?qznjzmmnvz0) in the meantime, and help by reporting any bugs found to Haali in the Alternative Matroska Splitter (http://forum.doom9.org/showthread.php?t=80762) thread.

BetaBoy
12th February 2009, 07:18
cyberbeing... did Haali sign off on you distributing that? I know he wants to do more before ppl start commenting on fixing 64 related issues.

cyberbeing
12th February 2009, 08:20
cyberbeing... did Haali sign off on you distributing that? I know he wants to do more before ppl start commenting on fixing 64 related issues.

Haali has been posting builds in the Alternative Matroska Splitter thread (http://forum.doom9.org/showpost.php?p=1240156&postcount=893). You can get it directly from his website if you want: http://haali.net/mkv/mkx.y.8.exe.

If he would like, I'll delete it from Mediafire. I just hosted it there since I find his site slow at times.

As for feedback, he never said not to leave feedback when he posted the build here on doom9, so I just assumed he wanted it. *shrug*

Upon your request, if you don't want CoreAVC users installing this build, and since this is the CoreAVC thread, I would be happy to delete my posts linking to it.

squid_80
12th February 2009, 09:15
The hardware de-interlacing does not work when playing interlaced h264 video and RGB32 output, my card is GeForce 9600GT.

Hardware deinterlacing normally only works with NV12 or YUY2 output. It's a common video card limitation.

squid_80
12th February 2009, 09:18
I have an 8600M GT and I've just updated to the 182.05 drivers. Immediately after that (but after rebooting), I installed CoreAVC Professional 1.9.0.0. When I go to the configuration page for CoreAVC, the "Prefer CUDA Acceleration" option is grayed out. This remains the case even after deleting "CoreAVC.ini" in my Appdata\Roaming folder. The 8600M GT supports VP2, according to Nvidia. Is there something else I need to do to enable CUDA acceleration or have I made a mistake somewhere?
If the option is grayed out it means the driver did not install properly, there are required files missing.

squid_80
12th February 2009, 09:36
I can't see why that would affect CoreAVC passing BFF flags with TFF content to the renderer. This is in software mode BTW and has been the same since forever. It has been discussed in this thread a few pages back.
Because that's not what is happening; CoreAVC is passing the correct flags and VMR9 interprets them wrongly. If it was passing the wrong flags why do VMR7 and Haali's renderer always show the fields in the correct order?
VMR9 is broken. It even changes field order randomly when you seek.

madshi
12th February 2009, 09:37
madshi... more of the #2 approach. That has been the basis for all our goals with GPU...
I'm glad to hear that! :)

Do you happen know where your GPU accelerated code is being executed on the graphics card? Is it the shader hardware or the dedicated video decoding circuit?

Thank you!

edison
12th February 2009, 10:19
edison... you did see the note that interlaced content is not supported with this initial CUDA release, correct?

HW De-interlacing does work when using YV12 output, but can not work with RGB32 output.

ACrowley
12th February 2009, 10:51
Mh... i dont have a Nvidia Card but a ATI HD4870

Something is strange with 1.9.0.0. BBC-HD 1080i MBAFF Files are stuttering/shaking with Hardware deinterlacing. It works fine with 1.8.5.0

Inspector.Gadget
12th February 2009, 14:05
If the option is grayed out it means the driver did not install properly, there are required files missing.

Thanks. I used the 185.20 drivers from LaptopVideo2go (which didn't require a modded INF) because the Nvidia site didn't list any beta drivers newer than the 179.x series for the 8600M GT. Is there something else I need to do other than just running "setup.exe" and doing the usual installation wizard procedure? If it matters, I have nvcuda.dll in my Windows\System32 folder.

samepaul
12th February 2009, 14:21
2 BetaBoy
Damned. Didn't think that I will be the one with complains "it doesn't work", but unfortunately :(
So, here is the movie (downloaded as 1080p example compatible with DXVA)
General
Complete name : E:\Movies\~test\bbc-blue_m1080p.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 234 MiB
Duration : 3mn 22s
Overall bit rate : 9 689 Kbps
Movie name : BBC Motion Gallery
Encoded date : UTC 2007-05-04 18:32:15
Tagged date : UTC 2007-05-04 18:32:26
Copyright : ©2007 BBC Motion Gallery
Comment : All Rights Reserved

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.1
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 3mn 22s
Bit rate mode : Variable
Bit rate : 9 563 Kbps
Width : 1 920 pixels
Height : 1 072 pixels
Display aspect ratio : 16/9
Frame rate mode : Variable
Frame rate : 30.000 fps
Minimum frame rate : 16.216 fps
Maximum frame rate : 300.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.155
Stream size : 230 MiB (99%)

Audio
...


NVIDIA Beta Driver 182.05 downloaded and installed (RivaTunner confirms that version is indeed 182.05). Board 8800GTS 320Mb
Option "Prefer CUDA acceleration" is available and selected, but tray icon does not turn green during playback. Also CPU usage is same as it was before codec upgrade - ~50%.
Tried under XP and under Win7 - same result on both systems.
What's wrong with me? :)

At least multithreading works :)

STaRGaZeR
12th February 2009, 14:29
Because that's not what is happening; CoreAVC is passing the correct flags and VMR9 interprets them wrongly. If it was passing the wrong flags why do VMR7 and Haali's renderer always show the fields in the correct order?
VMR9 is broken. It even changes field order randomly when you seek.

That would be right if I were using VMR9, but it happens with EVR and EVR Custom. When playing TFF content it's clear that the renderer (or another filter located after CoreAVC like ffdshow) is receiving BFF flags. When you force TFF then all is right. Again this has nothing to do with VMR. Already discussed and confirmed with tests a few pages back.

CoreAVC outputting NV12 with TFF Blu-ray content muxed into Matroska and using Haali's splitter:

VMR7 windowed/renderless --> no hardware deinterlacing (not CoreAVC's fault)
VMR9 windowed/renderless --> black screen
Haali renderer --> it does not accept NV12, falls back to Video Renderer, no hardware deinterlacing
EVR --> hardware deinterlacing with wrong field order
EVR Custom --> hardware deinterlacing with wrong field order

nm
12th February 2009, 14:30
NVIDIA Beta Driver 182.05 downloaded and installed (RivaTunner confirms that version is indeed 182.05). Board 8800GTS 320Mb
[...]
What's wrong with me? :)
Your GPU does not have VP2 (http://en.wikipedia.org/wiki/PureVideo#Table_of_PureVideo_.28HD.29_GPUs), so NVCUVID (and CoreAVC) can't use it.

Carpo
12th February 2009, 14:35
im guessing this has been asked before but is there an x64 version in the offering soon? or is that a 2.x/3.x release ;)

samepaul
12th February 2009, 14:55
Your GPU does not have VP2 (http://en.wikipedia.org/wiki/PureVideo#Table_of_PureVideo_.28HD.29_GPUs), so NVCUVID (and CoreAVC) can't use it.

I definitely know that 8800GTS has limited DXVA support, but CUDA is different stuff, not related to DxVA and according to NVIDIA (http://www.nvidia.com/object/cuda_learn_products.html) is supported on my board.
So I believe the problem is elsewhere...

nm
12th February 2009, 15:09
I definitely know that 8800GTS has limited DXVA support, but CUDA is different stuff, not related to DxVA and according to NVIDIA (http://www.nvidia.com/object/cuda_learn_products.html) is supported on my board.
So I believe the problem is elsewhere...
No, CoreAVC uses nvcuvid.dll, which requires VP2 or VP3 video decoding hardware. It does not use the stream processors of the GPU to decode video.

samepaul
12th February 2009, 15:34
No, CoreAVC uses nvcuvid.dll, which requires VP2 or VP3 video decoding hardware. It does not use the stream processors of the GPU to decode video.

What for CUDA needs video decoding hardware? CUDA is a way to perform general purpose calculations on GPU. How it is related to VP? Tesla processors has no VP at all, since they are CUDA-dediacted, but according to you they can't run CUDA code? I think you're wrong (unless you can provide link proving that you're right).

BetaBoy can you comment on this?

lucassp
12th February 2009, 15:47
nVidia offered VP2/VP3 access through their CUDA API so you can skip some of the DXVA limitations.

The Tesla cards have the same GPU's as desktop cards with some functionality disabled through software.

squid_80
12th February 2009, 16:19
That would be right if I were using VMR9, but it happens with EVR and EVR Custom. When playing TFF content it's clear that the renderer (or another filter located after CoreAVC like ffdshow) is receiving BFF flags. When you force TFF then all is right. Again this has nothing to do with VMR. Already discussed and confirmed with tests a few pages back.
EVR contains most of the same bugs as VMR9.

I'd like to know how you're examining the flags. Are you aware they can change at any time during playback, even be set differently for each frame? CoreAVC specifies the stream as BFF while connections are being made but passes the correct field order downstream as soon as it starts decoding.

Inspector.Gadget
12th February 2009, 16:26
Using CoreAVC with the version of nvcuvid.dll included in the newest DGAVCIndexNV generates a brief period of image corruption on a 720p video that doesn't occur when CUDA acceleration is disabled. This does not appear on seeking, but only on initially opening the video and beginning playback and depending on the file appears as a flash of pure bright green for a few frames or blocking/distortion problems lasting several seconds. I'm using an 8600M GT with Windows Vista Home Premium 32-bit. The details of the file in question are below; I'm using Haali's Matroska Splitter with MPC-HC as a frontend, ffdshow as an audio decoder, and the VMR9 renderless renderer. Edit: This problem also appears with Haali's renderer, so it seems to be renderer-independent.

General
Complete name : C:\File.mkv
Format : Matroska
File size : 4.38 GiB
Duration : 1h 42mn
Overall bit rate : 6 091 Kbps
Encoded date : UTC 2009-02-08 09:55:59
Writing application : mkvmerge v2.4.1 ('Use Me') built on Dec 5 2008 18:30:05
Writing library : libebml v0.7.7 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 42mn
Bit rate : 4 304 Kbps
Nominal bit rate : 4 607 Kbps
Width : 1 280 pixels
Height : 544 pixels
Display aspect ratio : 2.35
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.258
Writing library : x264 core 66 r1099 c0be810
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / 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=12 / 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=2pass /
bitrate=4607 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 1h 42mn
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Resolution : 24 bits
Language : English

Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : English

Is there another version of nvcuvid I should try? I've hunted through the installation files for the latest appropriate driver and not found one. :thanks:

TheShadowRunner
12th February 2009, 16:29
Here CUDA works, Geforce 8500 / XP / 182.05, however shows artifacts not present with software decoding.
CPU use is greatly reduce though, going from 60% to around 15% when CUDA is enabled.
The artifacts:
http://videoff7.free.fr/cuda.jpg
http://videoff7.free.fr/soft.jpg
Later,

TSR

deekey777
12th February 2009, 16:34
I definitely know that 8800GTS has limited DXVA support, but CUDA is different stuff, not related to DxVA and according to NVIDIA (http://www.nvidia.com/object/cuda_learn_products.html) is supported on my board.
So I believe the problem is elsewhere...

http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_ImageVideoCUDA_web.pdf
Go to the page 29/30.

squid_80
12th February 2009, 16:36
List of supported cards as listed in the CoreAVC Installer:
NVIDIA GeForce GTX 260/280, 9800, 9600, 9500, 8800 GT, 8700, 8600, 8500, 8400, Tesla S1070/C1060, Quadro FX 3700, Quadro FX 3600M, Quadro FX 1700/FX 570/ NVS 320M/FX 1600M/FX 570M/FX 370/NVS 290/NVS 140M/NVS 135M/FX 360M/NVS 130M and higher.
Unfortunately the 8800 Ultra, GTX and GTS miss out.

BetaBoy
12th February 2009, 16:52
squid... I added that list to the first post in this thread, the CC forum thread, and the KB on the support center.

samepaul
12th February 2009, 16:55
http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_ImageVideoCUDA_web.pdf
Go to the page 29/30.

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
12th February 2009, 17:05
TheShadowRunner the artifacts/blockiness is known thx for the feedback.

I also want to that everyone for the amazing amount of details and results so far... it definitely is helping track down the issues.

nm
12th February 2009, 17:12
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?
Yep, that's all.

STaRGaZeR
12th February 2009, 17:59
EVR contains most of the same bugs as VMR9.

I'd like to know how you're examining the flags. Are you aware they can change at any time during playback, even be set differently for each frame? CoreAVC specifies the stream as BFF while connections are being made but passes the correct field order downstream as soon as it starts decoding.

http://forum.doom9.org/showthread.php?t=104277&page=205

Since you were there you know what I'm talking about. ffdshow fixed that problem with all renderers, it works perfectly now with all H.264 sources. The flags can be examined with ffdshow's internal deinterlacers. They're not affected by any renderer, and clearly shows that CoreAVC flags TFF content as BFF. You can output YV12 from CoreAVC and put ffdshow as a postprocessing filter handling the deinterlacing process. If any deinterlacer is set to Auto, it'll behave the same as the "faulty" renderers, which indicates it's not the renderer's fault. If this is not CoreAVC sending the wrong flags downstream I don't know what it is. Force TFF and everything is OK. Use Auto (it'll use the field order that is passed to the deinterlacer, in this case CoreAVC's field order) or Force BFF and you'll get the typical back and forth motion. This is with samples that have all their frames or interlaced macroblocks (if it's MBAFF) flagged as TFF. On a side note PAFF samples with TFF flags in all their interlaced frames behave the same.

Jay Bee
12th February 2009, 19:48
VMR9 is broken. It even changes field order randomly when you seek.

Not true since XP SP3.

vucloutr
12th February 2009, 20:03
List of supported cards as listed in the CoreAVC Installer:

Unfortunately the 8800 Ultra, GTX and GTS miss out.

Funny thing is that the 8800 GTS 512 is also supported (G92 chip).
People usually refer to these models as 8800 GTS with 512MB or 1024MB RAM.
I guess one can blame Nvidia for their confusing naming scheme.

ACrowley
12th February 2009, 22:24
Mh... i dont have a Nvidia Card but a ATI HD4870

Something is strange with 1.9.0.0. BBC-HD 1080i MBAFF Files are stuttering/shaking with Hardware deinterlacing. It works fine with 1.8.5.0

Ah...the Stuttering is caused by Haali Splitter + CoreAVC
Works perfect with Gabest/MPC Mpeg Splitter and also Haali+ MPC Videodecoder (DXVA+HW Deinterlacing active)

Im not sure if it was working with older Haali Version.

Cyber-Mav
13th February 2009, 01:27
initial tests show that there is no decoding speed difference between a 8600gt and a 8800gt i have. both yield in similar levels of cpu usage, but thats to be expected since both of the cards use the same VP2 processor.

back to testing...

Mixer73
13th February 2009, 01:45
TheShadowRunner the artifacts/blockiness is known thx for the feedback.

So BB is this just a factor of hardware decoding of the streams or is it something that can improve?

BetaBoy
13th February 2009, 12:21
Mixer73.... its something we are working on fixing in our CoreAVC CUDA support and not a problem with CUDA... well at least that's what it looks like atm. So far since the release we have fixed the reported 'threading issue' and the 'blockiness after seeking' bugs.

Dark Eiri
13th February 2009, 12:25
BetaBoy, could you have a look into that issue with 10 ref-frames videos? They were encoded with the old HQ-slowest profile on MeGUI. Curiously, videos encoded with the HQ-Insane profile, 16 ref-frames, are perfectly decoded. And also, videos encoded with old revisions of x264 fall back to software decoding.

Kurtnoise
13th February 2009, 14:20
Hey,

I'm looking for some benchmarks between CoreAVC Cuda enabled vs MPC Dec DXVA. Could be great to have some comparisons...

BetaBoy
13th February 2009, 17:17
Hey,

I'm looking for some benchmarks between CoreAVC Cuda enabled vs MPC Dec DXVA. Could be great to have some comparisons...

I agree ;-)

ranpha
13th February 2009, 18:46
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 22s
Bit rate : 9613 Kbps
Nominal bit rate : 10000 Kbps
Width : 1920 pixels
Height : 1088 pixels
Display aspect ratio : 16/9
Frame rate : 59.940 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.080
Writing library : x264 - core 56 svn-667C



CoreAVC CUDA
User: 25s, kernel: 2s, total: 27s, real: 66s, fps: 177.3, dfps: 73.9
User: 24s, kernel: 2s, total: 27s, real: 64s, fps: 181.5, dfps: 76.5
User: 24s, kernel: 2s, total: 27s, real: 66s, fps: 178.4, dfps: 74.5

CoreAVC 1.9 software mode
User: 14s, kernel: 0s, total: 14s, real: 41s, fps: 342.2, dfps: 118.7
User: 13s, kernel: 0s, total: 13s, real: 41s, fps: 355.3, dfps: 119.6
User: 15s, kernel: 0s, total: 15s, real: 41s, fps: 319.8, dfps: 119.2

MPC-HC 908 DXVA
User: 220s, kernel: 0s, total: 220s, real: 221s, fps: 22.4, dfps: 22.4
User: 215s, kernel: 0s, total: 216s, real: 216s, fps: 22.9, dfps: 22.8
User: 215s, kernel: 0s, total: 215s, real: 216s, fps: 22.9, dfps: 22.8

MPC-HC 908 software mode
User: 28s, kernel: 2s, total: 30s, real: 205s, fps: 160.3, dfps: 24.1
User: 27s, kernel: 3s, total: 30s, real: 208s, fps: 160.1, dfps: 23.7
User: 26s, kernel: 3s, total: 29s, real: 206s, fps: 166.4, dfps: 24.0


Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 31s
Nominal bit rate : 1200 Kbps
Width : 1280 pixels
Height : 720 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.054
Writing library : x264 - core 59 r859M ce13bb6


CoreAVC CUDA
User: 5s, kernel: 1s, total: 6s, real: 16s, fps: 315.5, dfps: 135.2
User: 5s, kernel: 1s, total: 6s, real: 16s, fps: 338.2, dfps: 130.9
User: 6s, kernel: 1s, total: 7s, real: 16s, fps: 295.0, dfps: 133.2

CoreAVC 1.9 software mode
User: 3s, kernel: 0s, total: 3s, real: 6s, fps: 698.1, dfps: 346.5
User: 3s, kernel: 0s, total: 3s, real: 6s, fps: 638.1, dfps: 358.0
User: 3s, kernel: 0s, total: 3s, real: 6s, fps: 715.9, dfps: 351.7

MPC-HC 908 DXVA
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 72.3, dfps: 71.6
User: 28s, kernel: 0s, total: 28s, real: 28s, fps: 78.4, dfps: 78.1
User: 28s, kernel: 0s, total: 28s, real: 28s, fps: 77.4, dfps: 76.9

MPC-HC 908 software mode
User: 5s, kernel: 0s, total: 6s, real: 32s, fps: 357.0, dfps: 67.2
User: 5s, kernel: 0s, total: 5s, real: 33s, fps: 385.3, dfps: 66.1
User: 5s, kernel: 0s, total: 5s, real: 32s, fps: 378.1, dfps: 68.0


Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 6
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 40s
Nominal bit rate : 1041 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 1.850
Frame rate : 29.970 fps
Standard : NTSC
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.101
Writing library : x264 - core 56 svn-667C


CoreAVC CUDA
User: 63s, kernel: 16s, total: 79s, real: 133s, fps: 534.2, dfps: 319.3
User: 62s, kernel: 16s, total: 79s, real: 132s, fps: 537.9, dfps: 322.2
User: 57s, kernel: 14s, total: 72s, real: 130s, fps: 585.5, dfps: 325.5

CoreAVC 1.9 software mode
User: 21s, kernel: 0s, total: 21s, real: 52s, fps: 1968.2, dfps: 807.5
User: 20s, kernel: 0s, total: 20s, real: 52s, fps: 2047.9, dfps: 810.7
User: 21s, kernel: 0s, total: 21s, real: 51s, fps: 1947.2, dfps: 822.1

MPC-HC 908 DXVA
User: 174s, kernel: 0s, total: 175s, real: 176s, fps: 242.7, dfps: 241.5
User: 175s, kernel: 0s, total: 176s, real: 176s, fps: 241.9, dfps: 241.4
User: 173s, kernel: 0s, total: 174s, real: 174s, fps: 244.8, dfps: 244.2

MPC-HC 908 software mode
User: 53s, kernel: 3s, total: 57s, real: 253s, fps: 743.2, dfps: 168.1
User: 55s, kernel: 3s, total: 59s, real: 258s, fps: 718.4, dfps: 165.1
User: 54s, kernel: 3s, total: 57s, real: 242s, fps: 735.2, dfps: 175.9

nVidia 9800GT with 182.05 beta drivers under Windows 7 beta.
CPU is Phenom X4 9500 2.2Ghz and RAM is 4GB DDR2 667.

All numbers show that the CUDA decoder is faster. Now if only the decoder can play those files without artifacts that isn't seen in CoreAVC software mode or MPC-HC in DXVA and software mode, that would have been better.

MPC-HC software mode seems to be slower than DXVA mode because it only uses 1 core (even if I set it to 4 in its property page), unlike CoreAVC that can use all 4 cores.

Kurtnoise
13th February 2009, 18:55
could you add also values for CoreAVC w/o Cuda & MPC Dec w/o DXVA ?

:thanks:

Gleb Egorych
13th February 2009, 21:02
Some bug with interlaced content support. I tried BBC Galapagos Blu-ray, MediaInfo says it's MBAFF. The main video is progressive while titles in the end are interlaced.

Cyberlink H.264 decoder with DXVA enabled and "auto-select" deinterlacer plays the video at 50fps and bobs video (with bob artifacts).
CoreAVC 1.8.5 and 1.9.0 with "hardware" deinterlacer play it at 50fps, but discard "the second field" of the titles. Looks like them weave the main video and double the first field of the titles.

With bob deinterlacer CoreAVC plays both fields, the result seems to be indentical to Cyberlink DXVA. But bob deinterlacer affects picture quality (line-doubling).

ajp_anton
13th February 2009, 21:52
MPC-HC software mode seems to be slower than DXVA mode because it only uses 1 core (even if I set it to 4 in its property page), unlike CoreAVC that can use all 4 cores.At least when looking at the number of threads in task manager, it goes up when raising the number of threads in MPC-HC (all the way up to 6). Plus with two threads it can play things that it can't with one.

lexor
13th February 2009, 22:10
Am I reading that wrong, or is CoreAVC software faster than CUDA in those tables ranpha posted? We are supposed to look at dfps, right?

ajp_anton
13th February 2009, 23:41
Am I reading that wrong, or is CoreAVC software faster than CUDA in those tables ranpha posted? We are supposed to look at dfps, right?Yes, with a quad core, and with 100% CPU usage instead of 10%.

Malow
14th February 2009, 03:19
"prefer cuda acceleration" is greyed on my pc.

i have a Asus M3N-HT deluxe, chipset nforce 780a, nvidia 8xxx compilant onboard video.

all other softwares detect and use hardware decoding perfectly.

BetaBoy
14th February 2009, 03:37
If its greyed out then either its not a compliant NVIDIA CUDA card (not all 8xxx cards are compliant.. for example the 8800GTX is not compliant) or you have not installed the 182.05 beta drivers. When in doubt look at the supported CUDA card list:

NVIDIA GeForce GTX 260/280/290/295, 9800, 9600, 9500, 8800 GT, 8700, 8600, 8500, 8400, Tesla S1070/C1060, Quadro FX 3700, Quadro FX 3600M, Quadro FX 1700/FX 570/ NVS 320M/FX 1600M/FX 570M/FX 370/NVS 290/NVS 140M/NVS 135M/FX 360M/NVS 130M and higher.

ajp_anton
14th February 2009, 04:41
When in doubt look at the supported CUDA card list:8800GTS 512 (and 1024 if those exist?) MB is still missing.

Malow
14th February 2009, 06:28
If its greyed out then either its not a compliant NVIDIA CUDA...
i reeeealy belive it is, cause it have a 8400GS core, all others hardware-based decoders can do gpu decoding (cpu usage 1%) and it even works with hardware encoding softwares for CUDA GPUs, like BadaBOOM Media Converter.

i know, some 8xxx does not are cuda-enabled, (and also does not have full purevideo-HD capabilities) but mine has.

H.264 Decode Acceleration
H.264 Decode Acceleration with IDCT and CAVLC/CABAC
VC-1/WMV Decode Acceleration
VC-1/WMV Decode Acceleration with IDCT
MPEG-2 Decode Acceleration
High-Quality Scaling
MPEG-2 Spatial-Temporal De-Interlacing
MPEG-2 Inverse Telecine

question: how coreavc detect compatible GPUs?

imk
14th February 2009, 06:35
Will there ever be support for the G80 8800 series cards?

squid_80
14th February 2009, 06:44
i reeeealy belive it is, cause it have a 8400GS core, all others hardware-based decoders can do gpu decoding (cpu usage 1%) and it even works with hardware encoding softwares for CUDA GPUs, like BadaBOOM Media Converter.Have you installed the 182.05 driver?

Malow
14th February 2009, 08:45
ahhhhh, was the driver.... i was using 185.20, as it is "higher" than 182.05, i was thinking it was ok. but 185.20 is in fact older than 182.05...

now back to the decoder, with cuda enabled i got 15~20% of cpu usage on 720p clip (athlon x2 5200+). its normal?

chros
14th February 2009, 09:32
You don't need the beta driver, you can use the latest WHQL: v181.22 ... At least, it works for me ...
(System: GF 9600GT, WinXP SP3)

squid_80
14th February 2009, 10:20
You don't need the beta driver, you can use the latest WHQL: v181.22 ... At least, it works for me ...
(System: GF 9600GT, WinXP SP3)
The 181.22 driver by itself does not contain all the needed components. Perhaps you've installed one of the DG***IndexNV programs.

leeperry
14th February 2009, 10:44
If its greyed out then either its not a compliant NVIDIA CUDA card (not all 8xxx cards are compliant.. for example the 8800GTX is not compliant) or you have not installed the 182.05 beta drivers. When in doubt look at the supported CUDA card list:
you can add the 9600GSO/8800GS...as I have one of these ;)

hajj_3
14th February 2009, 11:41
are those of you who are saying your card isnt supported copying the .dll to /windows/system32 ? as the box will be greyed out until you do so. I now have the option enabled after doing that. I've got an Nvidia 9400GT. You can add that card to the supported list as in all of the Geforce 9 Series have CUDA support: http://www.nvidia.com/object/product_geforce_9400gt_us.html

Sharc
14th February 2009, 12:26
Works here with 9600GS / 182.05.
However, few green frames when starting playback and ugly blocks for about 1 second when seeking or changing audio track.

squid_80
14th February 2009, 12:33
are those of you who are saying your card isnt supported copying the .dll to /windows/system32 ?
This is not the recommended procedure, it is preferred to install the 182.05 driver or higher instead. This takes care of installing nvcuvid.dll (and ensures it is an up-to-date build) and also avoids confusion between system32/syswow64 on 64-bit systems.

hajj_3
14th February 2009, 13:05
true but the 182.05 drivers are beta, i like alot of other nvidia users get 4bit colour and 800x600 res when upgrading nvidia drivers so have to revert to previous drivers so i try not to update nvidia drivers too often and certainly not to betas. Wish nvidia fixed their updating drivers problem but that may never happen.

vucloutr
14th February 2009, 13:59
I made this list of graphics devices that should be supported from "nv_disp.inf" of the 182.05 beta driver.

supported graphics cards (G84, G86, G92, G94, G96, G98 Core):
GeForce 8300 GS, 8400, 8400 SE, 8400 GS, 8500 GT, 8600 GS, 8600 GT, 8600 GTS, 8800 GS, 8800 GT, 8800 GTS 512
GeForce 9300 SE, 9300 GE, 9300 GS, 9300M GS, 9400 GT, 9500 GS, 9500 GT, 9600 GS, 9600 GSO, 9600 GSO 512, 9600 GT, 9800 GT, 9800 GTX, 9800 GTX+, 9800 GX2
GeForce GTX 260, GeForce GTX 280, GeForce GTX 285, GeForce GTX 295
Quadro NVS 290, NVS 420, NVS 450,
Quadro CX
Quadro FX 370, FX 370 LP, FX 570
Quadro FX 1700, FX 3700, FX 4700 X2, FX 4800, FX 5800
Quadro VX 200
Quadroplex 2200 S4
Tesla C1060

supported integrated chipsets:
GeForce 8200, 8300
GeForce 9200, 9300, 9400
Quadro FX 470


definitely _not_ supported (G80 Core):
GeForce 8800 GTX, 8800 GTS, 8800 Ultra
Quadro FX 5600, FX 4600
Tesla C870

BetaBoy
14th February 2009, 14:56
8800GTS 512 (and 1024 if those exist?) MB is still missing.

ajp_anton... thx for the report. When we get confirmation that it works and there are not different generations of the cards then we will add it/them.

hajj_3
14th February 2009, 15:48
betaboy, can we expect a 1.9.1 version with all the bugs reported fixed next week?

Cyber-Mav
14th February 2009, 15:55
8800gts 512 is a 128 stream processor version of the 8800gt and both cards use the G92 core, afterall the 8800gts 512 is a 9800gtx.

Malow
14th February 2009, 16:26
I made this list of graphics devices that should be supported from "nv_disp.inf" of the 182.05 beta driver.
a few onboard video chipset should work too (like mine)

nForce 780a SLI
nForce 750a SLI

nForce 790i SLI
nForce 780i SLI
nForce 750i SLI

how about this list?
http://www.nvidia.com/object/cuda_learn_products.html

You don't need the beta driver, you can use the latest WHQL: v181.22 ... At least, it works for me ...
(System: GF 9600GT, WinXP SP3)
didn't work for me :(

nm
14th February 2009, 16:32
how about this list?
http://www.nvidia.com/object/cuda_learn_products.html
That includes G80 cards that don't have VP2.

Malow
14th February 2009, 16:44
8800gts 512 is a 128 stream processor version of the 8800gt and both cards use the G92 core, afterall the 8800gts 512 is a 9800gtx.
there is something different with GeForce 8800 GTX and GeForce 8800 GTS...

http://i39.tinypic.com/hurog4.png

That includes G80 cards that don't have VP2.
well, i guess we are looking for a specific capability of cuda GPUs... being cuda is not enough :)

~bT~
14th February 2009, 17:54
http://en.wikipedia.org/wiki/CUDA#Supported_GPUs

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

88keyz
14th February 2009, 18:15
Here is another sample of the the video blocking present on the CUDA accelerated CoreAVC vs. the DXVA accelerated MPCDecoder which does not show the blocking effect.

CoreAVC 1.9 with CUDA enabled
http://img17.imageshack.us/img17/8783/coreavcv19withcudaxi4.th.png (http://img17.imageshack.us/img17/8783/coreavcv19withcudaxi4.png)

MPCDecoder with DXVA enabled
http://img294.imageshack.us/img294/7/mpcdecoderwithdxvaom4.th.png (http://img294.imageshack.us/img294/7/mpcdecoderwithdxvaom4.png)

Looks like MPCDecoder with DXVA is still the way to go for hardware accelerated H.264 video files.

Malow
14th February 2009, 20:16
http://en.wikipedia.org/wiki/CUDA#Supported_GPUs

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

my onboard video shoud be G98/VP3 i guess, cuz it can play 1080p VC1 in MPC-HC/DXVA using ... 0.00% cpu... im happy with my onboard video ; :)