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

STaRGaZeR

22nd September 2008, 20:51

its not that simple to "just use the shaders" for the video processing. you need to interface with the streamprocessors/shaders on the graphics cards. Shader programming language is more complex to deal with compared to CUDA which uses the standard C language to communicate with the shaders and makes them do what the programmer wants to achieve.

What I mean is that, in both cases using the CUDA language to communicate with the shaders, it seems more logical to me writing the entire application in a way that it only uses the shaders and not a combination of the shaders and the PureVideo processor. Why? Using dedicated chips that do fixed functions have the avantage of being much faster than a general purpose processor. But the disavantage of not having any flexibility. I don't know the specs of the PV chip, but let's imagine it only supports AVC acceleration up to level 4.1 . What about if you want to add level 5.1 support? You can't if you use that dedicated PV unit. You'd have to use the shaders, that have no limitations, for that one. And doing this since the beginning is better IMO.

ati do have a method/api for interfacing with the shaders on thier graphics cards, i believe its called CTM and like OpenCL, its no where near as far developed and supported as CUDA is though.

one thing to remember, CUDA support is provided for free by Nvidia, even ATi are allowed to have their cards support CUDA with no royalty payments or catches. It has also been shown that 3rd party modified drivers bring working CUDA support to ATi graphics cards, so it is possible for ATi to adopt CUDA, but if they do or dont, well its up to them.
One thing to take into account is that CUDA is very large in its user base, many specialist companies are using it for thier specific applications, e.g the hospital in my city uses a CUDA accelerated system for tomographic scans (some sort of 3D x-rays).

You're right, the huge advantage of CUDA is that every one with a NV 8800 card already has a CUDA processor. That 3rd party software has never been proven to exist, so if it's not released it does not exist. Of course ATI cards can do CUDA, but they just don't want to support it officialy, and I understand them. Is a pain for a company to use the competitors technology (even being free) and become a puppet somehow. Do you have experience with both OpenCL and CUDA?

Sagekilla

22nd September 2008, 22:26

Correct me if I'm wrong here, but also if you used CUDA based decoding, overclocking the video card would make decoding faster. Or am I wrong on that?

Cyber-Mav

22nd September 2008, 22:36

Correct me if I'm wrong here, but also if you used CUDA based decoding, overclocking the video card would make decoding faster. Or am I wrong on that?

yes overclocking the video card can make things faster, but you need to understand that stress testing becomes more vital since an unstable overclock in games may just cause some artifacts to be displayed on screen or some dodgey textures to show up, but when using an app that wants precise calculation results a dodgey overclock can cause a whole lot of issues.

STaRGaZeR: i havent worked with OpenCL just have some CUDA and HLSL experience with a very very tiny bit of Cg experience.

Inventive Software

23rd September 2008, 12:14

What I mean is that, in both cases using the CUDA language to communicate with the shaders, it seems more logical to me writing the entire application in a way that it only uses the shaders and not a combination of the shaders and the PureVideo processor. Why? Using dedicated chips that do fixed functions have the avantage of being much faster than a general purpose processor. But the disavantage of not having any flexibility. I don't know the specs of the PV chip, but let's imagine it only supports AVC acceleration up to level 4.1 . What about if you want to add level 5.1 support? You can't if you use that dedicated PV unit. You'd have to use the shaders, that have no limitations, for that one. And doing this since the beginning is better IMO.

The problem with that is that I'm almost certain ATI and NVIDIA use different methods to call the shaders, thus you can't do one solution fits all at the moment. NVIDIA's CUDA allows access to the VP2 decoder (which is not in G80 GPUs), ATI did have a solution but this seems to have slowly died. This is why OpenCL is around and being ratified.

You're right, the huge advantage of CUDA is that every one with a NV 8800 card already has a CUDA processor. That 3rd party software has never been proven to exist, so if it's not released it does not exist. Of course ATI cards can do CUDA, but they just don't want to support it officialy, and I understand them. Is a pain for a company to use the competitors technology (even being free) and become a puppet somehow. Do you have experience with both OpenCL and CUDA?

DGAVCIndexNV/DecodeNV are both work-in-progress programs that are proven to use the NVIDIA GPU effectively. See the thread in this sub-forum for more information.

STaRGaZeR

23rd September 2008, 12:50

DGAVCIndexNV/DecodeNV are both work-in-progress programs that are proven to use the NVIDIA GPU effectively. See the thread in this sub-forum for more information.

3rd party software to enable CUDA on ATi cards, not 3rd party CUDA applications in general. To be more specific, the 'hack' shown was a few screenshots of 3DMark Vantage showing huge increases in the CPU score with an ATi card due to PhysX support through CUDA.

BetaBoy

24th September 2008, 18:40

CoreAVC v1.8.5 is in final QA now. If all goes we will release it tomorrow.

TheShadowRunner

24th September 2008, 19:00

Please BetaBoy, test to make sure that switching resolution while a video is playing doesn't produce artefacts. (happens after 1.6.5, up to 1.8)
See you,

TSR

BetaBoy

24th September 2008, 19:24

From the v1.8.5 changelog....
- Fix: Improved dynamic reconnection

TheShadowRunner

24th September 2008, 19:57

Sounds good to me ;)
Thanks,

TSR

CruNcher

24th September 2008, 21:07

BetaBoy very interesting read is the conversation between Donald Graft and a Nvidia Developer seems from his standpoint many Software Decoders/Encoders and he talks about a lot aren't fully Compliant yet with the H.264 Specification compared to Nvidias Hardware, what would you say to this statement.

It seems that the problem is the same for all 3, and I strongly suspect these are not compliant (The decode HW is very very strict on compliance, though there might be some fudging we can do in the driver).

The Cuvideosource will fail to detect mpeg4-hosed.264 as a valid elementary stream because of invalid nal_ref_idc (0) being specified for the PPS (I can modify that, but that's not a problem for actual decoding).

Looking at sample.264, it appears to be B-pyramid with 3-bframes, using B-frames as reference, and only one reference frame in the reference picture list.

I don't seem to see a problem except for the fact that it is truncated at a non-IDR point, so some of the reference frames will not be available for the first few B-frames that are then used as reference. It also seems a bit unusual to have multiple consecutive B-frames sharing the same frame_num value, even though these have nal_ref_idc!=0 (this can cause unpredictable results in the sorting of the reference picture list if they are used as a reference by a P-frame) -> I don't think this is compliant, but I'll have to double check.

Many encoders & decoders out there (including CoreAVC, libavcodec, MPC-HC, Cyberlink and x264) do not fully implement the H.264 specification, especially when it comes to DPB management and reference picture list reordering.

I guess with MPC-HC/Cyberlink he meant the Software parts

24th September 2008, 22:05

Dark Shikari

24th September 2008, 22:31

Um, looks like he's just saying that most software decoders aren't as strict on H.264 spec compliancy as hardware implementations. This means that software decoders may be able to decode some broken streams that the hardware decoder fails on. A strict software decoder would be useful for testing encoders, but otherwise it doesn't really matter.Moreso, "spec compliancy" says absolutely nothing about ability to decode broken streams; it only defines what a non-broken stream is.

BetaBoy

25th September 2008, 02:05

mlaviolette

25th September 2008, 16:51

Additionally if anyone is aware of and has a sample of any non-compliant h.264 stream that we don't support let me know (aside from 4:2:2 or 4:4:4 profiles).I'm glad you asked! CoreAVC has some problems with Hauppauge-generated h.264 streams if you use the No IDR encoder default when creating the file. The file plays fine if you start from the beginning, but if you reposition (using the slider in Windows Media Player, for example), then playback is jerky as CoreAVC skips frames. Stopping and starting at the beginning corrects this but makes repositioning impossible.

If I use GraphEdit to load the Hauppauge encoder filter and choose one of the IDR options to create a new file, then I can reposition just fine. Unfortunately Hauppauge does not make these options easily available, and are only accessible via GraphEdit on a "development" tab of the filter.

The ArcSoft player handles No IDR just fine.

I opened a ticket with CoreAVC support but they just blew me off.

BetaBoy

25th September 2008, 17:31

The support center is not really the right place for more technical stuff as they answer more generic support issues and then they forward any technical issues our way (but they are becoming more technical every day and making it easier for the rest of the staff and our customers). For an expedited and direct 'technical' response is best handled to contact me directly at: betaboy AT corecodec DOT com and I'll review any potential issues/files with the devel staff.

mlaviolette please send a sample and we'll take a look at it. But if you look back a few pages the issue you talk about has been discussed and we are working on a fix.

Cyber-Mav

25th September 2008, 17:52

CoreAVC v1.8.5 is in final QA now. If all goes we will release it tomorrow.

is this the release you were mentioning that will be the last of the 1.x versions and the following releases after this one will be 2.0 based?

Dark Shikari

25th September 2008, 18:04

I can confirm the latest CoreAVC 1.8.5 demo supports Predictive Lossless.

Great job!

Sharktooth

25th September 2008, 18:40

on the website it's still 1.8.0

BetaBoy

25th September 2008, 18:45

I can confirm the latest CoreAVC 1.8.5 demo supports Predictive Lossless.

Great job!

Thx DS... we are trying to knock out the last of these features and issues before the v1.9.0 CUDA release as we know that CUDA will have its own issues we need to work through and that's why we wanted to focus on it and do it in v1.9.x and not post v2.0.

Also, the IDR problem is really the last big bug... but wouldn't you know that `md just pointed to a 59fps file that plays slower (we think that's CORE related and not filter).

Malow

25th September 2008, 19:56

hamz... gamma adjustment in the decoding options besides B/C/S is planned? :p

me7

25th September 2008, 22:54

Thx DS... we are trying to knock out the last of these features and issues before the v1.9.0 CUDA release...

Can you talk about the "when" yet? Next three months, half year, full year???

BetaBoy

26th September 2008, 04:27

When its ready.

lilhobo

26th September 2008, 05:38

how do we know which codec is used by what application?

Dark Shikari

26th September 2008, 05:46

More good news; I modified x264 to support lossless i8x8 blocks in Predictive profile and CoreAVC 1.8.5 beta supports those correctly too. I'm not 100% sure whether the standard implies that i8x8 predictive is supposed to use 8x8-filtered pixels or actual edge pixels; apparently CoreAVC and I agreed on the latter.

BetaBoy

26th September 2008, 06:42

BUG: coreavc.marvel.bug.png (http://x264.nl/coreavc.marvel.bug.png)
Sample: marvel.m2ts (http://x264.nl/marvel.m2ts)

Extra info:
[00:32] (CruNcher): jarod
[00:32] (CruNcher): i saw alot of these problems with CoreAVC and X264 streams
[00:32] (jarod): but this is not x264
[00:33] (CruNcher): oh

So look into it please!
People encoding bluray movies are still using CoreAVC instead of DGAVCDEC because CoreAVC is faster.

ok.... we looked at the sample some more.... and found that it has out of range motion vectors. Even more then what we added support for (for the older x264 builds). So no fix is planned for this as its out of spec. BTW... what was used to create this?

Snowknight26

26th September 2008, 07:17

I'm very much inclined to say that thats from the Iron Man Blu-ray, so most likely not x264.

Dark Shikari

27th September 2008, 02:19

BetaBoy

27th September 2008, 15:06

DS thx.... I'll pass it on but I think its also related to that current 'seek' bug as well. I'll let you know.

Dark Shikari

27th September 2008, 20:12

DS thx.... I'll pass it on but I think its also related to that current 'seek' bug as well. I'll let you know.It is? I was thinking what you were doing is something on the order of re-initting the decoder each time it switched between modes, the lazy way of dealing with function pointer overloading for replacing the various functions with what is necessary. This isn't a bad method, since its unlikely anyone is going to be that sadistic with the streams they generate... :p

CruNcher

27th September 2008, 20:39

ok.... we looked at the sample some more.... and found that it has out of range motion vectors. Even more then what we added support for (for the older x264 builds). So no fix is planned for this as its out of spec. BTW... what was used to create this?

BetaBoy but if that really is the case then it would mean

Nvidia (Hardware)
Mainconcept/Elecard/DivX
ffh264
Arcsoft
Cyberlink
Intervideo

All of them would do it wrong or better they all would try to make these wrong mastered BDs watchable, somehow it sounds crazy (unless for example these would have been mastered with Elecard/Mainconcept Solutions (Sonic Cinevision for example) and they never found this Bug and their SDK is also bugged (as many other Decoder are being based on it) and the others work around this spec non compliant streams (Nvidia) to prevent such viewing problems for their customers (and never ever came on the idea to contact the Studios about it) all of this would also apply if it's actually user damaged streams and error correction sets in in those Decoders fixing this small problems.

Not sure if all of them are so incompetent to see or realize that they doing it wrong (not for me to rate that), but i guess for the CoreAVC user it's better then to prevent such problematic renderings for already released BD's so this would mean accepting the Spec noncompliance and work around it (if it really is such and no other things play into this) :(
So in other words CoreCodec is standing currently against their Customer experience and all other Vendors and says "These BD's are mastered wrong we don't make this error all the others "accept" it so you have to accept that with CoreAVC you will have these problems with this kind of wrong Mastered BD's" not sure if that is doing the CoreAVC users any good here that try to experience such BD's with your Product currently.
At least then CoreCodec should take the next step and get in contact with the Studios (that BD's have been found wrongly mastered Spec non compliant,but first should really check such a BD themselves, maybe all these samples got damaged somehow at these frames and error correction sets in for the other Decoders @ that time) and tell them they master it wrong so that this can be prevented in future BD releases, the way it is currently it only hurts CoreCodec and their customers.

Of course i only say that because CoreCodec seems really 100% sure that this is actually a spec non compliant mastering behavior (or a damaged stream) (on the side of some Studios or users) and couldn't find any bug in the way they apply the Spec (Decoder does it 100% correct no bug found). Though I'm not sure why the other Decoder have no problems here but i realized that CoreAVC has no way of error correction (which would seem to be capable of fixing such bad 1 or 2 frame series) even not a very simple one as ffh264, maybe that plays into this problem and preventing it visually for the other Decoders.

BetaBoy

27th September 2008, 21:49

CruNcher.... we've all been through the Motion Vector issue before in this thread right? and nothing has changed. The AVC spec and reference is available for all to review... Dark Shikari had corrected the Motion Vector compliance in x264 post rev663. However, we totally understand the reasoning on why we should support it in CoreAVC.... but no matter what those reasons are, the bottom line is that it is _NOT_ spec compliant (I'm a broken record), period. Why follow the AVC Specifications? They are created for a reason and in this case it's very valid because a larger MV range comes at the cost CPU/GPU cycles, its as simple as that.

As I've already discussed with Jarod.... but yes I am going through the motions to reach out to each of the mastering houses for videos that are brought to our attention. However at the same time we will also address how we are going to deal with this in CoreAVC 2.0.

Thx everyone for the great feedback!

CruNcher

27th September 2008, 21:54

So these Motion Vector in compliant streams couldn't be actually bad streams caused in copy actions from or to the BD/HDD mastering media, that get fixed for the other Decoders because of error correction ? (You know i don't trust consumer HDD's these days in terms of reliability especially not with such extreme user behavior as BD backup with extreme I/O scenarios that result out of this)

molitar

28th September 2008, 18:37

BetaBoy

28th September 2008, 18:51

BTW Dark Shikari... congrats on: http://mailman.videolan.org/pipermail/x264-devel/2008-September/004993.html

BetaBoy

28th September 2008, 19:29

molitar Pls interject something of value and stop the DXVA ranting. I've been through this with you before and I'm not gonna do it again.

28th September 2008, 19:53

Ok I wish to know why is it so hard just to add DXVA support in CoreAVC? After all it already works in Mediaplayer Classic Home Cinema but the only issue is if the format is even off by a little bit the file won't play :(
Having DXVA support in CoreAVC wouldn't change that at all compared to MPC HC. In DXVA, it's mostly the video driver and hardware that determine what can be decoded, not the filter that routes the video stream to the driver.

ATI is the KING when it comes to using video card for media use because unlike Nvidia who removed secondary full screen display which is very crucial to a good media system they completely removed it so now I have myself an ATI Radeon HD 3870 video card and not going back to Nvida CRAP!
Well, the latest driver version from NVIDIA now supports L5.1 H.264 decoding. Maybe ATI will follow at some point (if their hardware is up to it).

Every indication seems that this is still not being worked on as yet! Instead your going to spend your time working on something called CUDA for NVIDIA and not DXVA support for our GPU's! I'm getting so sick of hearing promises of GPU support comming soon!
If you want to use your ATI GPU for >L4.1 H.264 decoding with the current drivers, you need a custom GPU decoder implemented on the stream processors, not DXVA support.

CruNcher

28th September 2008, 20:10

Ok I wish to know why is it so hard just to add DXVA support in CoreAVC? After all it already works in Mediaplayer Classic Home Cinema but the only issue is if the format is even off by a little bit the file won't play :( ATI is the KING when it comes to using video card for media use because unlike Nvidia who removed secondary full screen display which is very crucial to a good media system they completely removed it so now I have myself an ATI Radeon HD 3870 video card and not going back to Nvida CRAP! I use my video card for gaming and watching video's on my HDTV and Nvidia can't do this properly anymore. But the one feature that I am wanting in CoreAVC still has not been implemented! GPU Support! If it wasn't that the DXVA will not work through ffdshow I wouldn't even bother using CoreAVC yet CoreAVC still does not support GPU the ONE and ONLY feature I have been wanting!

Every indication seems that this is still not being worked on as yet! Instead your going to spend your time working on something called CUDA for NVIDIA and not DXVA support for our GPU's! I'm getting so sick of hearing promises of GPU support comming soon!

Indeed it is strange that Nvidia removed it first on Vista now on XP (especially as it was flawless working for both), but the Problem here wasn't Nvidia Microsoft Demand it because of DRM protection reasons (see Vista Specs) someone could now get the idea that Nvidias Hardware design is weak in terms of useing this to circumvent DRM (and no Driver protection is possible or takes time to implement so the only solution was removing it for the time completely), i guess there will be some interesting things coming up in those regards soon when people begin to analyze this ATI yet seems to better protect it or is missing something so Microsoft isn't such harsh with them as they are currently with Nvidia ;)

https://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_adp.php?p_faqid=2011&p_created=1169076830

Dark Shikari

28th September 2008, 20:37

BTW Dark Shikari... congrats on: http://mailman.videolan.org/pipermail/x264-devel/2008-September/004993.htmlIndeed, now we'll see how long it takes everyone else to support it :p

BetaBoy

2nd October 2008, 13:54

Interesting, if I swap repeatedly between lossy and predictive lossless mode in the same frame, it almost cuts in half CoreAVC's performance :eek:

105fps lossless
115fps lossy (QP5)
56fps mix (QP8 / lossless mix)

(In other news, I'm not going to actually implement this swapping in x264 right now... :p )

Dark Shikari... we looked at this more and looks like I was wrong about it being a bug and that lossy and predictive lossless switching _is_ slow atm in CoreAVC and that we will add it to the todo for 2.0.

BTW... do you have a sample(s) we can test?

Dark Shikari

2nd October 2008, 16:38

Dark Shikari... we looked at this more and looks like I was wrong about it being a bug and that lossy and predictive lossless switching _is_ slow atm in CoreAVC and that we will add it to the todo for 2.0.

BTW... do you have a sample(s) we can test?Yeah, I figured it wasn't a bug; my guess was that you were re-inittiing the decoder on a switch between lossy and lossless to change function pointers or something like that. Which is a completely reasonable approach given that odds are nobody will do such a crazy thing. Of course, saying that is just asking for someone to do it for the purpose of making CoreAVC look slow ;)

I'll post a sample in a bit.

qyqgpower

3rd October 2008, 12:51

@BetaBoy
CoreAVC 1.8 seems to always pass BFF flag to Enhanced Video Renderer and VMR9 (with Haali Renderer, everything is OK) even if the source is actually TFF, causing the pictrues to jump back and forth.
This issue can only be observed when the deinterlacer in EVR and VMR9 is activated.

And a little question, Will CoreAVC support those amazing quality deinterlacers in DXVA?

3rd October 2008, 13:44

CoreAVC 1.8 seems to always pass BFF flag to Enhanced Video Renderer and VMR9 (with Haali Renderer, everything is OK) even if the source is actually TFF, causing the pictrues to jump back and forth.
This issue can only be observed when the deinterlacer in EVR and VMR9 is activated.
Are these x264-encoded sources or something else? With x264, you need to use the nal-hrd+interlaced patch and correct parameters to insert field order SEI to the stream: http://forum.doom9.org/showthread.php?t=137432

And a little question, Will CoreAVC support those amazing quality deinterlacers in DXVA?
The same hardware deinterlacing, noise reduction etc. post-processing filters are in use with normal DirectShow video rendering too. Just set CoreAVC to use "Hardware deinterlacing", like you probably already have.

STaRGaZeR

3rd October 2008, 13:50

Just to confirm, NV12 output will be available in 1.8.x or in 1.9?

Just set CoreAVC to use "Hardware deinterlacing", like you probably already have.

With ATI cards, you also need NV12, else it won't work.

squid_80

3rd October 2008, 13:56

CoreAVC looks at the stream to determine if it's TFF or BFF and passes the appropriate flags to whatever renderer is connected; it's up to the renderer to interpret them correctly. VMR7 is almost always correct, Haali's is correct, VMR9 is a complete gamble based on your OS/video drivers (EVR I don't know about). Even when VMR9 does get it right seeking to a new position can make it flip the order (likewise when it gets the field order wrong seeking can sometimes correct it).

qyqgpower

3rd October 2008, 14:24

@nm
The test clips are encoded by x264 and of course I set the --nal-hrd and interlaced parameters correctly, as they plays totally fine with all other decoders(mainconcept, cyberlink, ffdshow etc.) and renderers.
BFF video encoded same way (just change --tff to --bff) works fine with CoreAVC and all renderers.

@squid_80
If VMR9 is a complete gamble at field order, why other decoders could work with it (and EVR) correctly.

squid_80

3rd October 2008, 15:12

I see the same symptoms when using VMR9 with hardware deinterlacing no matter which codec I use.

BetaBoy

3rd October 2008, 15:40

Just to confirm, NV12 output will be available in 1.8.x or in 1.9?

Its already in 1.8.5... but this IDR/Seek bug is what's on task now and is holding up the release.

STaRGaZeR

3rd October 2008, 15:52

Nice, looking forward to it :)

Cyber-Mav

7th October 2008, 03:34

would future version of coreavc using cuda be more tolerant of decoding h264 encoded video and does not follow the dxva specifications closely than current dxva implementations do, such as cyberlink etc?

seems like anything out of the norm breaks dxva acceleration very easily.

how is coreavc's gpu decoding assist going to be implemented? is it using cuda to access the video decode hardware? or will it be using cuda to communicate directly with the stream processors and have them do the general purpose processing that is required for the decoding? im guessing the latter method would eliminate a lot of the issues with encoded content variances that break hardware acceleration quite easily.

BetaBoy

7th October 2008, 06:58

Define tolerent as I thing if we handle it it should parse just fine..... Also CUDA only has one option atm... that's on or off.... We have not optimized it in this first phase for 1.9.x. but take a look at some numbers;
benchmarks on a 1440x1080 mbaff clip:
4 cores: coreavc = 136.6fps, cuda 69.1fps
2 cores: coreavc =79.5fps, cuda 69.2fps
1 core: coreavc 40fps, cuda 58fps

As you can see CoreAVC scales with the number of cpus, while CUDA is limited by the gfx card. But note that we are not showing it above but the offload from the CPU to the GPU in general makes this more then worth the effort.

STaRGaZeR

7th October 2008, 11:41

What GPU was used in that comparison?

Disabled

7th October 2008, 12:23

And please tell us, if youre using the VP2 decoder engine, or if G80 GPUs (or every gpu supporting Cuda) is supported.

madshi

7th October 2008, 12:25

Dark Shikari

7th October 2008, 12:53

Dark Shikari... we looked at this more and looks like I was wrong about it being a bug and that lossy and predictive lossless switching _is_ slow atm in CoreAVC and that we will add it to the todo for 2.0.

BTW... do you have a sample(s) we can test?From the Incredibly Obnoxious Conformance Vectors department, I've created a test clip (http://www.mediafire.com/?l5zn5yijg5e). I cannot guarantee it is absolutely correct; in fact, my current ffmpeg patch for predictive lossless fails to correctly decode it (I suspect the issue might be clipping or similar)! CoreAVC appears to work correctly, however.

This has the following:

1. Deblocking
2. CABAC
3. B-frames (pyramidal, with weights)
4. All macroblock types, including 8x8dct and PCM.
5. Random distribution of QPs, with 50% lossless and 50% ranging from 1 to 31.

Have fun :cool:

Cyber-Mav

7th October 2008, 15:39

Define tolerent as I thing if we handle it it should parse just fine..... Also CUDA only has one option atm... that's on or off.... We have not optimized it in this first phase for 1.9.x. but take a look at some numbers;

As you can see CoreAVC scales with the number of cpus, while CUDA is limited by the gfx card. But note that we are not showing it above but the offload from the CPU to the GPU in general makes this more then worth the effort.

ahh for tolerance i ment that videos encoded using high number of b-frames or other options like referencing frames greater than 6 or 7 which tends to usually break dxva acceleration in other hardware based decoders.

is coreavc's implementation of cuda based around the purevideo vpu? or is it going in the direction of utilising the stream processors for custom data processing?

im under the assumption that its the latter since if coreavc were to use the vpu then cuda would not be the best method since it would mean more work in implementing a seperate method for gfx cards that dont support cuda.

but if using cuda for general purpose processing then i can see a lot more control being gained in the decoding stages. either way it shows that hardware acceleration is beneficial....... hold on a second.. (lol im typing as im thinking.)

you mentioned that speed will vary depending on the graphics card. a lot of the newer nvidia cards have the same purevideo engine 2 or so in them, so even a 8400gs would give the same decode acceleration as a 9800gtx.. but if you say speed will depend on the graphics card then it seems like you will be using the latter approach i mentioned above, which is to have the stream processors on a graphics card do the general purpose processing that you require them to do. hence a card with more stream processors will perform better.

Cyber-Mav

7th October 2008, 15:44

@BetaBoy, those are interesting numbers. I'm wondering: Are you planning to offer a way to combine both CPU + GPU power for decoding? Wouldn't that result in 136.6 + 69.1 = ca. 200 fps? Also: Will image quality be 100% identical with CUDA compared to the software based CoreAVC? Thanks!

from my work with cuda there is always some cpu usage going on when doing gpu off-loading. so im going to assume that coreavc on its own could use e.g 70% cpu but with cuda the cpu could use something like 40% and the rest offloaded to the gfx card.
im just guessing here and those percentages are not real, just some made up examples, betaboy will be able to answer that question with more accuracey and detail.

me7

7th October 2008, 18:29

Do mobile nVidia cards support PureVideo (paricular the 8400M GS)?

BetaBoy

7th October 2008, 19:08

From the Incredibly Obnoxious Conformance Vectors department, I've created a test clip (http://www.mediafire.com/?l5zn5yijg5e). I cannot guarantee it is absolutely correct; in fact, my current ffmpeg patch for predictive lossless fails to correctly decode it (I suspect the issue might be clipping or similar)! CoreAVC appears to work correctly, however.

This has the following:

1. Deblocking
2. CABAC
3. B-frames (pyramidal, with weights)
4. All macroblock types, including 8x8dct and PCM.
5. Random distribution of QPs, with 50% lossless and 50% ranging from 1 to 31.

Have fun :cool:

Yummy, a challenge... ;-)

Cyber-Mav

7th October 2008, 19:09

Do mobile nVidia cards support PureVideo (paricular the 8400M GS)?

yes it does.

BetaBoy

7th October 2008, 19:17

What GPU was used in that comparison?

Intel Core 2 Quad Q6600 2.4GHz running a 9600gt with VP2.

Cyber-Mav

8th October 2008, 02:47

im guessing gpu acceleration would be more beneficial to those who use slower single core cpus?

BetaBoy

8th October 2008, 02:53

Well we are far from done.... this is first round work. There are some long term (lower level) CUDA goals for us we are planning for both CoreAVC as well as support in CorePlayer. Lets get this VP2 release out the door first..... but no matter what CUDA does as advertised and offloads CPU cycles, allowing for more CPU intensive AVC features and aggressive bitrates.

lucassp

8th October 2008, 07:13

So, in the end, it's still VP2 support brought to CoreAVC.

BetaBoy

8th October 2008, 07:25

So, in the end, it's still VP2 support brought to CoreAVC.

What? Please elaborate.

Disabled

8th October 2008, 10:29

What he meant was youre only using the VP2 decoder, so only g90+ based GPUs are supported.

lucassp

8th October 2008, 10:30

Well, you said CoreAVC is going to use CUDA but not VP2 because its limitations. And I thought you're going to write a CUDA based decoder for doing things faster. Please correct me if I understood you wrong. And please give us more details on it :)

PS: I'm not a native English speaker and maybe sometimes I understand things worng :)

CiNcH

8th October 2008, 11:56

You got it right. They use the CUDA Video API to access PV2 and not the shaders to offload some complex computation. Still CUDA is far less restrictive than DXVA given the possibility to read back the decoded frames into main memory, but restricted concerning AVC/H.264 levels and profiles of course...

Inventive Software

8th October 2008, 13:22

CUDA supports (or will with a coming driver update) L5.1. Check the DGAVCDecodeNV thread.

ashlar42

8th October 2008, 14:33

@BetaBoy, those are interesting numbers. I'm wondering: Are you planning to offer a way to combine both CPU + GPU power for decoding? Wouldn't that result in 136.6 + 69.1 = ca. 200 fps? Also: Will image quality be 100% identical with CUDA compared to the software based CoreAVC? Thanks!I'm interested too in answers to these questions. Is CoreAVC gonna combine CPU+GPU or you'll have to choose which one to use. I hope for the former, as it would free up resources to do heavy post processing.

BlackSun

8th October 2008, 21:48

We're looking into a way to combine both, but that is doubtful. So possibly you would have to choose. The CPU still handle some operations such as parsing, blitting (color conversion/deinterlacing).

lucassp

9th October 2008, 06:09

The CPU still handle some operations such as parsing, blitting (color conversion/deinterlacing).

Maybe you could do the color conversion on CUDA, and you could also enable the VP2 deinterlacer as an alternative to the VMR Deinterlacer.

squid_80

9th October 2008, 11:12

Using the CPU to do the color-conversion/deinterlacing is better as it can be done while the gpu is decoding more frames. Also VP2 deinterlacer = VMR9 deinterlacer (exact same thing).

CUDA still has limitations on the number of possible reference frames, similar to DXVA... The technical limit is 15 references, due to 15 (ref frames) + 1 (output frame) = 16 which is the maximum number of surfaces allocatable under DirectX. In reality this limit may be lower due to out-of-order frames waiting to be displayed. AFAIK this is not a limitation of the hardware but of DirectX, which CUDA is unfortunately still tied to at the moment.

laserfan

10th October 2008, 21:35

How to I make PowerDVD Ultra from Cyberlink use the CoreAVC codec for h264, instead of its own CL264Dec.ax??? I've checked "Preferred decoder" in CoreAVC config, which didn't work. Next I un-registered CL's codec, and PDVD still doesn't pick-up on the CoreAVC decoder, in fact it won't play video at all.

Is there a way to make PDVD use CoreAVC?

Jay Bee

11th October 2008, 00:13

Is there a way to make PDVD use CoreAVC?

No...

laserfan

11th October 2008, 14:57

Is there a PC-based BD player that WILL work with CoreAVC? I mean, one which recognizes the disc structure and from which I can see & play the menus and extras etc.

I know it works with MPC, and CorePlayer looks like it will play individual files, but how to play a disc "as programmed"?

shon3i

11th October 2008, 15:24

laserfan

11th October 2008, 16:50

@laserfan, why you need that? Using CoreAVC for BD decoder i think is not good idea, right now because Cyberlink and Arcosft have DXVA(for both ATI and Nvidia, and all streams (MPEG2, AVC, VC-1), and in software mode are fast too, not fast as CoreAVC but fast enough for any Dual Core :)
For my setup I have found that NOT ONLY is CoreAVC faster, but it is also (oddly) much BETTER for playback from a quality POV. I get blockiness & posterization with Cyberlink and ffdshow decoders, and perfection w/CoreAVC (using Media Player Classic).

Would like to achieve same good results with a full-featured disc playback program.

Yes I need to upgrade my P4/AGP videocard platform, but given current economics I can't rationalize it (yet). I can however easily rationalize the <$20 bucks for CoreAVC.

Quark.Fusion

11th October 2008, 21:48

This stream is correctly decodes with ffdshow, but CoreAVC produces some garbage on screen — is that decoder bug or error in stream?

http://www.savefile.com/files/1833602
http://www.fileqube.com/shared/vIRND131162

rahzel

13th October 2008, 06:16

Can someone help me with some settings?
First of all, I have a HTPC connected via HDMI to my LCD TV and i have an ATI 780G HD3200 IGP. MPC HC is my player of choice and i have MPC set so that it uses its internal DXVA filter for DXVA compliant videos, and CoreAVC (using 1.8.0.0) for everything else. I'm using Overlay Mixer Renderer as i see tearing using VMR9 or haali.

1) Should i uncheck all Output formats except for YUY2, or should i leave them all checked?

2) Should I set deinterlacing to Hardware deinterlacing?

3) Is there any negative effects for deblocking, like softening the image, or is this best left on, and if so, which is the best setting? Standard?

4) To play it safe, should i set Output levels to TV (16-235)? I found that previous to the driver i'm using, it output to the incorrect levels at Auto, but it seems ok with the latest video drivers.

TIA.

Jay Bee

13th October 2008, 21:10

2) If you watch interlaced content then HW deint should produce the highest quality. It isn't as good as when using Cyberlink though. I'm hoping that the upcoming adition of NV12 colorspace may change this.

3) Deblocking is only performed if the encoder intended it to be used. Disabling it in this case saves some CPU time but causes ugly artifacts.

BetaBoy

17th October 2008, 13:52

We are about to push the publish button.... here is the v1.8.5 Changelog for CoreAVC Professional and Standard Editions.

CoreAVC H.264 Video Codec - Version 1.8.5.0 (20081017)
- Add: NV12 output
- Add: Option to disable/enable system tray icon
- Add: Filter is registered with preferred priority
- Fix: Proper seeking for streams with one IDR frame
- Fix: Decoder priority adjustable by limited user accounts
- Fix: Fix weighted prediction with MBAFF
- Fix: Options dialog wrong size with large fonts
- Fix: Fixed output format priority saving
- Fix: Improved dynamic reconnection
- Fix: Explicitly reject streams with unsupported resolutions
- Fix: Tray Icon stability
- Fix: Fix Force VMR AR correction function
- Fix: Help tab text highlight bug

Cyber-Mav

17th October 2008, 15:29

whats the benefit of NV12 output compared to the other output methods?

LigH

17th October 2008, 15:39

Some Nvidia graphic cards prefer this FourCC for planar YUV 4:2:0 output (the usual chroma subsampling type used in MPEG 1/2/4 Main profiles), and may not support the FourCC "YV12" correctly instead.

BlackSun

17th October 2008, 17:52

We are releasing the 1.8.5 !

CoreAVC H.264 Video Codec - Version 1.8.5.0 (20081017)
- Add: NV12 output
- Add: Option to disable/enable system tray icon
- Add: Filter is registered with preferred priority
- Fix: Proper seeking for streams with one IDR frame
- Fix: Decoder priority adjustable by limited user accounts
- Fix: Fix weighted prediction with MBAFF
- Fix: Options dialog wrong size with large fonts
- Fix: Fixed output format priority saving
- Fix: Improved dynamic reconnection
- Fix: Explicitly reject streams with unsupported resolutions
- Fix: Tray Icon stability
- Fix: Fix Force VMR AR correction function
- Fix: Help tab text highlight bug

megalith6

17th October 2008, 21:01

hi

warning - newbie - warning :))

notice the deblocker - does this mean i can pass some of my blocky mpegs through CoreCodec and clean them up please ~ i have not seen deblock filters mentioned in other decoder softwares?

thanks

Ric

clsid

17th October 2008, 21:07

CoreAVC only decodes H.264 video.

If you want to deblock your videos, use ffdshow.

bmnot

17th October 2008, 21:09

CUDA support not included this time?

dead_screem

17th October 2008, 21:29

A bug in 1.8.5, Thumbnails no longer extract for avi files... They still extract fine when haali is used for mkv and mp4 for instance. I havn't tried using haali for avi to see if that would fix it, but i'm not doing that anyway.

hajj_3

17th October 2008, 23:37

this fixes my delay when playing 720p .mkv files with x264 video and ac3 audio, used to take 8 secs or so on my fast pc for some .mkv files. HOWEVER, it doesnt fix the delay for .mkv files with aac audio that i create from my mpeg2 soccer broadcasts that i record and archive in x264 + aac. Hope that can be fixed in next version.

My brother's old laptop now uses 10% less cpu when playing 720p tv shows now compared to previous version.

keep up the good work guys!

qyqgpower

18th October 2008, 04:12

The NV12 output of 1.8.5 still presents wrong field order in decoding TFF MBAFF/PAFF when connected to Enhanced Video Renderer and VMR9.
sample clips:
http://www.mediafire.com/file/zwm5nndnmig/MBAFF-TFF.mkv (may have seeking issue since it is cut from my encode, but it's enough to reproduce the field order issue)
http://www.mediafire.com/file/nnjdjmxddkm/PAFF-TFF-Sample.mp4

More strangely, while ffdshow-rev2099_20080903_clsid_sse_icl10 produces correct field order, like CyberLink H.264/AVC Decoder.
ffdshow-rev2202_20081010_clsid_sse_icl10 and ffdshow-rev2210_20081012_clsid produces inverted field order, just like the behavior of CoreAVC.

squid_80

18th October 2008, 04:24

@squid_80
If VMR9 is a complete gamble at field order, why other decoders could work with it (and EVR) correctly.(Emphasis added by me to make my own point stand out.)
More strangely, while ffdshow-rev2099_20080903_clsid_sse_icl10 produces correct field order, like CyberLink H.264/AVC Decoder.
ffdshow-rev2202_20081010_clsid_sse_icl10 and ffdshow-rev2210_20081012_clsid produces inverted field order, just like the behavior of CoreAVC.:rolleyes:
Why is this a CoreAVC problem when other codecs randomly show the same issue? Wouldn't that indicate the renderer is at fault?

qyqgpower

18th October 2008, 05:02

Not RANDOMLY indeed, because
CyberLink H.264/AVC Decoder(PDVD8)
Mainconcept AVC/H.264 Video Decoder
ArcSoft Video Decoder
ffdshow-rev2099_20080903_clsid_sse_icl10

always do the correct communication between renderer and decoder.

Recent ffdshow build can only be considered as degradation.

Jay Bee

18th October 2008, 10:08

2) If you watch interlaced content then HW deint should produce the highest quality. It isn't as good as when using Cyberlink though. I'm hoping that the upcoming adition of NV12 colorspace may change this.

Nice. The new NV12 output did indeed fix some HW deinterlacing quality problems. Screens attached. Have a look at the sawteeth on the white lines.

YUY2:
http://img186.imageshack.us/img186/8255/yuy2km8.jpg

NV12:
http://img186.imageshack.us/img186/1352/nv12hk1.jpg

One problem that still hasn't gone away though are small stutters while watching true interlaced content (football) live with DVBViewer. Is there any way I can help troubleshoot/debug this?

VMR9 is a complete gamble at field order

It's not random, it worked fine in CoreAVC 1.5. The random thing your'e talking about is a seperate issue that has been fixed by this Microsoft hotfix: http://support.microsoft.com/kb/919071

CiNcH

18th October 2008, 11:17

Think I am slowly running out of mail addresses for the trials +g+

Tried 1.8.5 and am still experiencing high jitter and sync-offset with 1080i and hardware deinterlacing, now also with NV12 (and vector-adaptive deinterlacing). All other deinterlacing methods do not suffer from that problem.

BetaBoy

18th October 2008, 17:10

Based on the early feedback (thx everyone) we are probably going to do a 1.8.6 release after the weekend.... stay tuned.

STaRGaZeR

18th October 2008, 19:20

It seems that when using NV12 and hardware deinterlacing (ATI) the field order is reversed. It's exactly the same thing you see when you use MPC's internal DXVA decoder with interlaced content, but obviously this is not a DXVA problem. Can anybody confirm if this is wrong field order or if it's something else?

Also, when NV12 is selected as the only output colorspace, Single field or Bob deinterlacing don't work.

All this is playing interlaced Blu-ray content muxed into Matroska and splitted with Haali. ffdshow doesn't have this problem, maybe because when NV12 output is selected it uses "NV21,VU" instead.

BTW thanks for the "Use tray icon" button ;)

BetaBoy

18th October 2008, 23:08

CUDA support not included this time?

CUDA is for our 1.9.x releases that then leads to 2.0. It also allows us to work with the NVIDIA engineers now to address some of the issues that we are finding (like Donald here @ D9) before we go public with a release.

squid_80

19th October 2008, 01:42

It seems that when using NV12 and hardware deinterlacing (ATI) the field order is reversed. It's exactly the same thing you see when you use MPC's internal DXVA decoder with interlaced content, but obviously this is not a DXVA problem. Can anybody confirm if this is wrong field order or if it's something else?Does it still happen with VMR7 or Haali's renderer? If not, it's probably the same old VMR9 issue as above.
Also, when NV12 is selected as the only output colorspace, Single field or Bob deinterlacing don't work.The internal deinterlacing methods don't support target formats that use vertical subsampling (NV12, YV12 and I420). The same goes for hardware deinterlacing on most graphics cards, except that most cards now days do support NV12.

STaRGaZeR

19th October 2008, 03:00

Does it still happen with VMR7 or Haali's renderer? If not, it's probably the same old VMR9 issue as above.

Interesting. Results with NV12+hardware deinterlacing, Aero enabled:

System Default, Old Renderer, VMR7 (windowed), VMR7 (Renderless) and Haali's Renderer result in no deinterlacing whatsoever.

VMR9 (windowed), VMR9 (Renderless), EVR and EVR Custom have the field order reversed.

Overlay Mixer N/A.

Let me say again that ffdshow have no problems with any of them except System Default, Old Renderer and VMR7 (windowed), resulting in no deinterlacing.

Results with NV12+hardware deinterlacing, Aero disabled:

System Default, Old Renderer, Overlay Mixer, VMR7 (windowed), VMR7 (Renderless) and Haali's Renderer work perfect.

VMR9 (windowed), VMR9 (Renderless), EVR and EVR Custom have the field order reversed.

And here ffdshow have no problems with any of them except Old Renderer and VMR7 (renderless) resulting in no deinterlacing.

The internal deinterlacing methods don't support target formats that use vertical subsampling (NV12, YV12 and I420). The same goes for hardware deinterlacing on most graphics cards, except that most cards now days do support NV12.

I've tested every colorspace and with EVR/EVR Custom the only one that will do something to deinterlace, apply any of the ATI's postprocessing options (Edge-enhancement and such) or allow DXVA is NV12. Also, NV12 is so far the only format that use vertical subsampling supported by EVR/EVR Custom. Can't talk about NV here.

dead_screem

19th October 2008, 04:13

A small feature request for the next version, before you rewrote the properties dialog/direct show stuff the properties dialog would show which Input 4cc and which output colorspace is active. Can this be readded?

qyqgpower

19th October 2008, 05:09

Let me say again that ffdshow have no problems with any of them except System Default, Old Renderer and VMR7 (windowed), resulting in no deinterlacing.
The topic is kinda OT, but I'll still post here.
The previous build of ffdshow (080903) works perfectly with NV12 output and interlaced flag, giving nice HW deinterlace in EVR & VMR9.
But recent, even latest build(081017) would always give wrong field order to renderer. Not only EVR & VMR9, even haali renderer(which CoreAVC could correctly work with) couldn't render the decoded interlaced frame from ffdshow (081017) correctly.

If I replace the libavcodec.dll from 080903 with 081017, the field order issue will occur. Something must be faultily modified in recent libavcodec.dll

STaRGaZeR

19th October 2008, 13:24

I'm using albain's lastest betas for the new audio codecs, and it's version of libav gives either deinterlacing or no deinterlacing, but always the good field order. But that's out of the question here. The fact is that both CoreAVC and ffdshow are doing something wrong with hardware deinterlacing, some renderers are at fault but not all of them and there are problems even with those that don't have issues by themselves. That's why we are here reporting bugs, to make CoreAVC a better codec and a justified purchase. Let's hope the CoreAVC guys will look at our reports.

clsid

19th October 2008, 13:26

STaRGaZeR

19th October 2008, 14:05

The code present in albain's betas has no problems assuming field order with all my files, don't know about your builds. qyqgpower, you can test the same build I'm using (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2224_20081017_dbt_new_audio_codecs.exe?modtime=1224232861&big_mirror=0) and see if for you the order is fine too. Also, what criteria is ffdshow using for assuming one or another, and why has been changed?

However, if MediaInfo for example can determine what field order is used, ffdshow should be able too?

qyqgpower

19th October 2008, 14:29

Thank you for the info, clsid. As you said "It simply assumes an order", I've tested more MBAFF files with different build of ffdshow, CoreAVC 1.8.5 and Cyberlink. Renderer is EVR.
for TFF:
080903 ffdshow=TFF
081017 ffdshow=BFF < incorrect
CoreAVC=BFF < incorrect (with Haali Renderer=TFF)
Cyberlink=TFF

for BFF:
080903 ffdshow=TFF < incorrect
081017 ffdshow=BFF
CoreAVC=BFF
Cyberlink=BFF

for faultily mastered BFF(SHOULD BE output as BFF and jump back and forth)
080903 ffdshow=TFF < incorrect
081017 ffdshow=BFF
CoreAVC=BFF
Cyberlink=BFF

So the result is:
080903 ffdshow always assumes TFF.
recent ffdshow always assumes BFF.
CoreAVC always assumes BFF when connecting to EVR, but giving correct order to Haali Renderer.
Cyberlink could correctly detect the field order.

So, the detection of field order in MBAFF may be actually possible.
BFF is mostly common for PAL, and TFF for NTSC, but BFF could also be used in NTSC.
Both field order is commonly used around the world, so the best option is "Auto Detection". If it can't be done now, a possible work around would be an option to select output field order.

qyqgpower

19th October 2008, 14:38

STaRGaZeR

19th October 2008, 14:58

MediaInfo can't tell the actually field order for MBAFF H264.

Indeed, my bad. I was looking at some non MBAFF TFF NTSC files.

clsid

19th October 2008, 16:06

If you kindly ask Haruhiko, maybe he is willing to implement an option to configure which field order should be assumed.

hubblec4

19th October 2008, 16:29

hi

@ BetaBoy

Is there a development at the CoreAAC decoder (CoreAAC.ax)

I miss the 7.1channel decode for playback.

hubble

BetaBoy

19th October 2008, 17:34

OT... but ok.... We have had our CoreAAC decoder (directshow filter) done for well over a year now, but we have slowly been adding more profiles SBR, PS, etc. to the core. We have a bit more of coding to do on it and then QA before we sign off on it as a stand alone product like CoreAVC.

Quark.Fusion

19th October 2008, 19:52

LoRd_MuldeR

23rd October 2008, 02:44

Is it intentional that the CoreAVC Decoder v1.8.5 setup installed a pretty old version of Haali Renderer on my system? :confused:

(I was confused because the "Show OSD" and "Luma Range" options were missing all of a sudden ^^)

[EDIT]

A quick hash compare showed that the HaaliMkx.exe included in the CoreAVC installer equals version 2007-01-31 of Haali Media Splitter.

lych_necross

23rd October 2008, 07:21

Nothing is faulty in ffdshow. It has no way of knowing what field order is correct. It simply assumes an order. The current code assumes different order as before. This order is incorrect for your files, but will be correct for other files. From what I have been told the field order may differ per country.

If you can provide some information about what field order is most common that I can perhaps adjust ffdshow's behavior.

Can't you just use AssumeTFF() or AssumeBFF() in the Avisynth portion of ffdshow to correct field order problems? If not, why not include an option that forces either top or bottom field first in ffdshow?

BetaBoy

23rd October 2008, 12:45

KornX

23rd October 2008, 21:45

fleon

24th October 2008, 19:04

Hi I have xp x64 and coreavc 1.8.5 and I'm using media player classic home cinema x64 and eventhought I have configured coreavc to be the preferred decoder and to display the tray icon that doesnt happen inestead the ffdshow x64 tray icon appear eventhought the h264 decoding in ffdshow x64 is disabled, i tried re registering coreavc but nothing..

LoRd_MuldeR

24th October 2008, 19:21

MPC-x64 will work with x64 filters only! But I don't think there's a x64 version of CoreAVC yet. Also there is no reason to use MPC-x64, because MPC-x86 will run on 64-Bit Windows just fine.
Usually you'll even get better performance with the x86 version, because the x64 filters available presently are far less optimized than the x86 ones...

fleon

24th October 2008, 20:27

I didnt knew that, so I will use ffdshow x86, mpc hc x86 inestead and keep using coreavc thanks

LoRd_MuldeR

24th October 2008, 21:23

I didnt knew that, so I will use ffdshow x86, mpc hc x86 inestead and keep using coreavc thanks

On 64-Bit Windows you can run x86 and x64 processes at same time. However x86 and x64 code can not be mixed in the same process!
That means: A x86 executable cannot load any x64 DLL's and also a x64 executable cannot load any x86 DLL's.

In theory x64 code should run faster than x86 code, because it has got more and wider registers available.
But in practice optimized assembler code, as used by all applications that are developed for high performance, is only available for x86, not for x64.
That's why x86 code often runs faster than x64 code. At least that's the situation for Windows at the time being.

If I remember correctly, x64 support was announced to be added to CoreAVC at a later time...

clsid

24th October 2008, 21:45

LoRd_MuldeR

24th October 2008, 22:16

Well, libavcodec in ffdshow x64 is now also compiled with GCC, so it has all the optimizations that the x86 version has. In the past, before MinGW64 was around, we used MSVC for compiling 64bit libavcodec, and that resulted in bad performance. So performance is not much of an argument anymore, but stability is. The 64-bit builds of ffdshow are not as stable as the x86 builds.

Does your libavcodec compiled by MinGW64 include any of the optimized assembler code?

As far as I know you must disable all "hand optimized" assembler code on x64 Windows, unless you want to modify it specifically for x64 Windows.
That's because x64 Windows has some obscurities that x64 Linux doesn't have (keyword: "calling convention").
And it's also the reason why x264 can be built for 64-Bit Linux, but not for 64-Bit Windows (except you disable all the nice assembler optimizations).

clsid

24th October 2008, 22:26

Yes, all the assembly stuff is included.

LoRd_MuldeR

24th October 2008, 22:28

Yes, all the assembly stuff is included.

Wow :D

Then there is hope to get x264 fully working on MinGW64 one day? ;)

Dark Shikari

24th October 2008, 23:51

Most of lavc's assembly is using GCC inline syntax, not yasm/nasm, and so doesn't have the same calling convention issues.

LoRd_MuldeR

24th October 2008, 23:56

Most of lavc's assembly is using GCC inline syntax, not yasm/nasm, and so doesn't have the same calling convention issues.

I see. Why decided the x264 developers to use yasm/nasm instead of GCC inline syntax?
MSVC compatibility isn't really an argument, because most of the Assembler must be disabled for MSVC anyway...

squid_80

25th October 2008, 03:36

I see. Why decided the x264 developers to use yasm/nasm instead of GCC inline syntax?Probably because it's only compatible with GCC...
MSVC compatibility isn't really an argument, because most of the Assembler must be disabled for MSVC anyway...
Not sure why you think x264 can't be built with asm by MSVC (there was the stack alignment thing but that's not an issue if you know what you're doing).

LoRd_MuldeR

25th October 2008, 03:54

Not sure why you think x264 can't be built with asm by MSVC (there was the stack alignment thing but that's not an issue if you know what you're doing).

Well, there definitely is a problem with MSVC and stack alignment that makes various ASM functions in x264 crash. I think it's the SSE functions that are affected.
Currently x264 has a workaround for MSVC and will disable all the problematic ASM code when built by MSVC. But the build will be significant slower than a GCC build.
So in fact you are bound to GCC, if you want to have a build that has all the nice ASM speed-optimizations. And who doesn't ???

That in mind, using the GCC inline syntax would not be a big drawback. You'd need to disable all ASM code for MSV, instead of a significant part of it. So?
But there would be a big benefit: Thanks to MinGW64 you would be able to get a fully working x64 build of x264 for Windows with all ASM enabled and a huge speed-up.
If I remember correctly, it was stated that a x64 Linux build of x264 runs ~20% faster than a x86 Windows build at the moment.

I guess the biggest problem would be to convert all ASM code from nasm/yasm syntax to GCC inline syntax. Far too much work, if possible at all...

Guest

25th October 2008, 04:15

if possible at all... It's statements like that that show you have an agenda and are not a seeker after truth.

Dark Shikari

25th October 2008, 04:29

Probably because it's only compatible with GCC...No, because GCC Inline syntax is unbelievably awful to code in, especially for very complex functions, due to its ugly syntax and weak macro capabilities.

squid_80

25th October 2008, 05:02

Well, there definitely is a problem with MSVC and stack alignment that makes various ASM functions in x264 crash. I think it's the SSE functions that are affected.
Currently x264 has a workaround for MSVC and will disable all the problematic ASM code when built by MSVC. But the build will be significant slower than a GCC build.
So in fact you are bound to GCC, if you want to have a build that has all the nice ASM speed-optimizations. And who doesn't ???Like I said, it's fixable if you know what you're doing (i.e. how function calls work at a low level). If you're someone who just chucks code into compilers without understanding it, yeah you're stuck with GCC. :P

That in mind, using the GCC inline syntax would not be a big drawback. You'd need to disable all ASM code for MSV, instead of a significant part of it. So?
But there would be a big benefit: Thanks to MinGW64 you would be able to get a fully working x64 build of x264 for Windows with all ASM enabled and a huge speed-up.
If I remember correctly, it was stated that a x64 Linux build of x264 runs ~20% faster than a x86 Windows build at the moment.So you propose rewriting all the asm to (ugly and general PITA to work with, thank you) gcc inline syntax, just to get win64 working? It would be far easier to fix the existing asm to work with win64 (which does use a 16-byte aligned stack btw).
MS b0rked the ABI for win64 from the start, then decided it wasn't bad enough and b0rked it some more after XP64 RC1*. x264-64 for windows will never see the same speed increases over x264-32 as the linux version.

(* - Ever have trouble finding a win64 device driver? Imagine you write drivers for a living; MS comes and says we've got a new OS coming, here's the specs if you want to make a new driver for it. So you write a new driver using their specs, then BAM! Right before the OS is released, the specs change and your new driver is now broken. Would you rewrite it again, or just say screw MS and their new OS and bin the whole thing?)

Quark.Fusion

25th October 2008, 06:00

IMHO 64-bit is future, so earlier or later you will face the need to make x64-compatible build. The choice is to wait when "OS" will be released or do it during its development. And of course the last worsest choice is to be lazy and not doing it at this time.

dukey

27th October 2008, 01:53

I've got a problem with coreavc
It basically won't play some h264 videos (with mkv container) unless i load it, stop the video in direct show and play it again. Then it will start playing.

I am using my own renderer, currently it only supports the RGB24 colour space.

I am running my graph like this

CoInitialize(NULL);

if(FAILED(CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER,IID_IGraphBuilder, (void **)&iGraphBuilder))) {
printf("creating filter graph failed\n");
return E_FAIL;
}

oglRenderer = new OpenglRenderer(NULL, &hr);
oglRenderer->setupOpengl(hwnd,hglrc,hdc);

if (FAILED(hr) || !oglRenderer) {
delete oglRenderer;
printf("Could not create texture renderer object! hr=0x%x", hr);
return E_FAIL;
}

// Get a pointer to the IBaseFilter on the TextureRenderer, add it to graph
iRenderer = oglRenderer;

if (FAILED(hr = iGraphBuilder->AddFilter(iRenderer, L"OpenglRenderer"))) {
printf("Could not add renderer filter to graph! hr=0x%x", hr);
return hr;
}

iGraphBuilder->RenderFile(fileName,NULL);

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaControl, (void**)&iMediaControl))) {
printf("could not get iMediaControl interface\n");
return hr;
}

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaSeeking, (void **)&iMediaSeeking))) {
printf("could not get mediaseeking interface\n");
return hr;
}

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaPosition, (void **)&iMediaPosition))) {
printf("could not get iMediaPosition interface\n");
return hr;
}

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaEventEx, (void **)&iMediaEvent))) {
printf("could not get iMediaEvent interface\n");
return hr;
}

iMediaEvent->SetNotifyWindow((OAHWND)hwnd, WM_USER, 0);
iMediaEvent->SetNotifyFlags(0); // turn on notifications

Then i run it like this
iMediaControl->Run();

Only with *some* videos, and CoreAVC it appears to do nothing. No sound plays, no video, nothing gets sent to the renderer. I check the state of the graph and it claims the graph is running. With FFDshow and libavc it works perfectly. Maybe there is a bug somewhere? I am using the latest version of Haali's media splitter.

dukey

27th October 2008, 14:56

This problem is definitely to do with CoreAVC and not my program. I set the output type in coreavc to RGB24

now
http://img338.imageshack.us/img338/1545/heroesdshowxx0.jpg

When i try to run it.
http://img368.imageshack.us/img368/2597/errorlm5.png

Strangely, after this error has come up and I try to run the graph again, it works. When I use a different h264 decoder, it works ! no problems ie ffdshow.

squid_80

27th October 2008, 17:37

What's the format type of CoreAVC's output pin before and after the error message?

dukey

27th October 2008, 17:51

I think CoreAVC's 24bit output must be broken, it doesn't seem to want to output rgb24 at all, only RGB32
when i force the output type as RGB32 it works like a champ
maybe i'll try and make my renderer support that as a work around

me7

27th October 2008, 19:01

A small noob question: Do the output formats provide different performances? If yes, which one is the fastest?

LoRd_MuldeR

27th October 2008, 19:09

A small noob question: Do the output formats provide different performances? If yes, which one is the fastest?

YV12 should be the fastest, because that's the "native" format. Hence using YV12 output will prevent any color-space conversion.

Of course the YV12 to RGB conversion needs to be done at a later time then, e.g. in the renderer...

me7

27th October 2008, 19:21

YV12 should be the fastest, because that's the "native" format. Hence using YV12 output will prevent any color-space conversion.

Of course the YV12 to RGB conversion needs to be done at a later time then, e.g. in the renderer...

Is one of these two methods known to be faster?
MPC offers three renderers with subtitle compatibility (VMR7 (renderless), VMR9 (renderless) and EVR Custom preset), is one of them "better/faster" than the others?

I'm currently trying to turn my HDMI equipped laptop into a mobile HD-machine and want to squeeze every last bit of performance out of it ;)

LoRd_MuldeR

27th October 2008, 19:26

This depends on how the renderer is implemented. In the worst case the renderer will do it in software, in the best case the renderer will use the GPU to do it.
Also if you feed YV12 into the VMR7/VMR9/EVR renderers you often get wrong levels. However there is a shader available in MPC to fix the "levels" problem...

clsid

27th October 2008, 19:42

You don't need a renderer with subtitle compatibility. If you use VSFilter for subtitles, you can use any renderer you want. Overlay Mixer has the lowest CPU usage and also does not suffer from luminance levels issues.

me7

27th October 2008, 20:15

All right, I'll try YV12 with Overlay Mixer. Thanks to both of you.

squid_80

28th October 2008, 03:53

I think CoreAVC's 24bit output must be broken, it doesn't seem to want to output rgb24 at all, only RGB32If the connecting filter won't accept RGB24, obviously CoreAVC won't output it. But it should offer it, which is why I asked what the output format is before and after you see the error message. Also check with the pin disconnected, it should offer 4 types of RGB24 (VideoInfoHeader/VideoInfoHeader2 and Bottom-Up/Top-Down).
There really shouldn't be any need to force a particular colorspace at all, if your renderer only supports RGB24 then that is what it should request from CoreAVC. If it is accepting whatever formats are offered to it then it's broken.

dukey

28th October 2008, 13:26

I cant even get the RGB output types to work in graph edit with vrm7/9 without errors, so I don't think it's going to work in my program (without errors).

So just gonna have to stick to use ffdshow and libavcodec for now.

dukey

28th October 2008, 18:10

I found out what was causing my problem
in the mkv splitter force 25fps was set, causing random behaviour downstream, problems solved now :)

fleon

28th October 2008, 21:29

Overlay Mixer has the lowest CPU usage and also does not suffer from luminance levels issues.

I was reading that this discussion and since I have been using VMR9 and your argument is valid, I changed it to overlay mixer but then I noticed that the video was too dark, and I thought that it must be because of my monitor I'm using a Samsung Syncmaster 732n plus I tried to calibrate the colors and everything but I'm still not sure about it, how can I get the true colors?

dukey

28th October 2008, 21:43

tell the decoder to output RGB24 or RGB32
the thing with VRM7/9 is when they are given YUV or however its packed
they will use the scale 0-255, instead of 16-239 or whatever it is. So all blacks, instead of being black will end up brighter.

fleon

28th October 2008, 22:17

According to avisynth by using info() my video is YUV12 because of what clsid said i want to keep using overlay mixer, but as I said the problem is that my monitor(Samsung Syncmaster 732n plus) doesnt seems to be well calibrated so keeping all that how can I calibrate my monitor to show the true colors

clsid

28th October 2008, 22:35

Why do you think your monitor is the cause? Your graphics driver settings are more likely the cause. Those often have settings that mess with colors.

fleon

28th October 2008, 22:44

Why do you think your monitor is the cause? Your graphics driver settings are more likely the cause. Those often have settings that mess with colors.

You are right that is also a posibility, but I dont think I can discard the monitor thing, since I changed some settings like constrast and brightness maybe it was just the graphic driver but now maybe is also the monitor, for what is worth I have an ati x1650 pro with the 8.10 drivers x64, I have windows xp x64

LeMoi

28th October 2008, 23:24

When switching from a segment to another in a multi-segment mkv file, x264 video disappears (using latest Haali Media Splitter)

ckjnigel

19th November 2008, 19:05

The coreAVC decoder works beautifully on the MSI Wind.
It took me hours to find settings to turn off ffdshow for h/x264. Media Player Classic HC, kmPlayer and XoomPlayer 6 all work nicely (though I favor KM...).
Since I see clsid in this thread, I wonder which ffdshow builds are recommended for the MSI Wind netbook (presumably, that would also be what's best on Asus EEE).

BetaBoy

5th December 2008, 22:27

@betaboy...

would it be possible to raise the max resolution to a far higher level?

like quadHD?

and what is the max framerate?

My testclip won't run (but with other codecs)
50fps 3840x2160

KornX

When QuadHD becomes more mainstream we will have a specific decoder function for it. ATM it will require some devel work for us to support it without it otherwise affecting cpu cycles.

kemuri-_9

6th December 2008, 00:25

When QuadHD becomes more mainstream we will have a specific decoder function for it. ATM it will require some devel work for us to support it without it otherwise affecting cpu cycles.

i'm guessing the same could be said of Ultra HD/Super Hi-vision?
which is looking to be a future standard, though we might be using h.265 by then... :rolleyes:

STaRGaZeR

6th December 2008, 00:30

Based on the early feedback (thx everyone) we are probably going to do a 1.8.6 release after the weekend.... stay tuned.

Any news?

Jay Bee

6th December 2008, 05:36

Any news?

Do yourself a favour and end the waiting game by getting yourself a modern graphics card for use with Cyberlink dxva. That's what I did, and now I have no field order issues, no DVBViewer stuttering issues and on top of that, due to the much lower CPU usage, all the fans in my PC stay quieter (and my power bill stays lower).

CoreAVC is a great solution for systems with older GPUs, but for bugfree TV and Media playback, dxva is the way to go.

EDIT: I see you already have a 4870. So I guess there's no reason for you to wait.

BetaBoy

6th December 2008, 07:28

Jay Bee.... is that really necessary in this thread? Pls take that OT discussion elsewhere... that's something you've been warned about over and over again in this thread, but you insist to keep on doing.

DXVA is _NOT_ the way to go (imho) and DXVA is just your opinion as only 'one' means of GPU access for windows users.... Also, we opted to go right to 1.9 atm with CUDA and there will be no 1.86 release.

CruNcher

6th December 2008, 14:43

lexor

6th December 2008, 14:51

Speaking of Haali, whatever happened to the 64bit splitter that was just about to be released when 1.8 hit?

Jay Bee

6th December 2008, 15:23

Jay Bee.... is that really necessary in this thread? Pls take that OT discussion elsewhere... that's something you've been warned about over and over again in this thread, but you insist to keep on doing.

Plz don't make up things. I was never for dxva before I recently got a GPU that supported it properly. I never said anything about dxva before my last post. And I have never been warned about anything in this thread. If you had gotten the field order problems and DVBV problems dealt with sooner I probably still wouldn't see a need for dxva.

STaRGaZeR

6th December 2008, 15:46

Do yourself a favour and end the waiting game by getting yourself a modern graphics card for use with Cyberlink dxva. That's what I did, and now I have no field order issues, no DVBViewer stuttering issues and on top of that, due to the much lower CPU usage, all the fans in my PC stay quieter.

CoreAVC is a great solution for systems with older GPUs, but for bugfree TV and Media playback, dxva is the way to go.

EDIT: I see you already have a 4870. So I guess there's no reason for you to wait.

I know, but I'm sick of the restrictions DXVA has. Nice for DVB streams and the like, also in PCs with slow processors, but it is a mess for all the other things. Software decoding works virtually always, DXVA not. My only complaint about CoreAVC now is the field order bug, and I was hoping for a "quick release", but knowing CoreAVC's release speed it was a "no" since the beginning. Seriously, I think fixing this kind of simple bugs for everyone is more important than releasing new features that could be used only by those with NV cards and probably will be plaged with bugs, but I guess the developers think different. Bad for me.

DigitalDeviant

6th December 2008, 15:59

Seriously, I think fixing this kind of simple bugs for everyone is more important than releasing new features that could be used only by those with NV cards and probably will be plaged with bugs, but I guess the developers think different. Bad for me.

Seconded. As an Ati user I could care less since their 'universal' solution isn't going to include me. The funny thing is it seems by their own initial benchmarks only single core processors will see any benefit from the CUDA decoding. Now how many people are going to have a CUDA capable GPU and only a single core?

If you have the money to spend I'd recommend a quadcore and ffdshow-mt. At least when you post about bugs to the ffdshow developers they try to respond and fix the problem in a timely manner.

STaRGaZeR

6th December 2008, 16:21

Seconded. As an Ati user I could care less since their 'universal' solution isn't going to include me. The funny thing is it seems by their own initial benchmarks only single core processors will see any benefit from the CUDA decoding. Now how many people are going to have a CUDA capable GPU and only a single core.

Yes, that's the other thing. I don't understand the fixation of the CoreAVC team with CUDA. Well I do have some guesses actually, but that doesn't belong here.

If you have the money to spend I'd recommend a quadcore and ffdshow-mt. At least when you post about bugs to the ffdshow developers they try to respond and fix the problem in a timely manner.

CoreAVC and quick releases don't belong to the same sentence :D

ffdshow-MT still has some bugs, making it unusable for now (for me at least). In some time it will be completed and ready for the masses :)

BetaBoy

6th December 2008, 17:07

But why going CUDA ? shouldn't that be more overhead (see all the GPU transcoding) then going via Nvidias Direct Decoder Core API ncuvid.dll (same that Donald Graft uses) also that way i think you would be surface independent so it should in theory also work on Haalis Renderer in the end and you would also leverage from all the debuging done by the other ISVs and the Doom9 Community :)

NVIDIA's CUDA is the first technology we feel is a step in the 'right direction' from GPU/SOC companies and a more universal approach for access.

As far as overhead... from what we have seen... CUDA development is very immature... in fact the 'low level' coding that is possible is not even being used because the tools are not even in place for it. So these leaves a lot of room for improvement as it matures.

As far as debugging... we have a plan for CoreAVC 2.0 that we have touched on here and discussed internally as well with a few developers over the past few months and at this point we are convinced its the way to go for 2.0.

Also on the 64 bit splitter... I've already stated that that would not be till CoreAVC 64.

Cyber-Mav

7th December 2008, 00:02

i agree with betaboy on this subject, CUDA is the right direction to take since the gains will continue to come as the platform matures. Nvidia do seem to want to support CUDA with everything they have, and there is hardly much support out there for things such as CTM since ATi dont even seem to want to support it themselves.

CruNcher

7th December 2008, 00:24

Though in those regards ehh neither CTM nor CUDA are really preferable but OpenCL to have 1 common base for ISVs :) but anyway im talking about how to render the frames and i guess Nvidia does it on purpose on a unique logic Part inside the GPU (the 400 MHz powered VP2 Logic, especially the CABAC Decoding) and not via CUDA as this i think would draw a lot more Energy. Nevertheless im optimistic that Picard and the other Low Level CoreAVC Developer know what they do, so i let myself be surprised by them :)

rebkell

7th December 2008, 00:28

Any progress on working with DGAVCDec, the non-NV version?

Guest

7th December 2008, 00:50

Any progress on working with DGAVCDec, the non-NV version? I assume you are asking CoreAVC about making an API available for DGAVCDec (and other third party apps) to use. I'm curious too. Last I heard was something about maybe after version 2.0. I don't think it's a high priority for them.

LoRd_MuldeR

7th December 2008, 00:54

Wouldn't it be possible to access CoreAVC through the "normal" DShow API from DGAVCIndex? Too ugly? Too inefficient?

Guest

7th December 2008, 01:06

Not frame accurate.

BetaBoy

7th December 2008, 01:32

I assume you are asking CoreAVC about making an API available for DGAVCDec (and other third party apps) to use. I'm curious too. Last I heard was something about maybe after version 2.0. I don't think it's a high priority for them.

It is a part of 2.0 and it _is_ a priority for sure. But I cannot comment on specifics yet as we are still working on the details.

squid_80

7th December 2008, 05:07

But why going CUDA ? shouldn't that be more overhead (see all the GPU transcoding) then going via Nvidias Direct Decoder Core API ncuvid.dll
nvcuvid.dll is a component of CUDA. The proper name is Nvidia CUDA Video Decoder API.
The funny thing is it seems by their own initial benchmarks only single core processors will see any benefit from the CUDA decoding.Depends what you consider the benefits to be. Max decoding speed is much higher with CPU decoding but GPU decoding requires much less CPU which is better for transcoding. People also claim reduced power consumption for GPU decoding but I've never seen any facts to back that up.

Cyber-Mav

7th December 2008, 15:58

i hope once the hardware decoding and 64bit support are all added into coreavc that its price doesnt increase. betaboy will pricing remain as it currently is?

BetaBoy

26th December 2008, 22:33

We are kicking out some betas starting this week for the CUDA enabled version of CoreAVC Professional Edition. We are looking for testers that can report real-world statistics as we will included in some PR set for release at CES. Send an email with your VP2 or VP3 enabled device listing, OS, Media Player your using, to: info AT corecodec DOT com

As far as performance.... I think NVIDIA users will be pleased. [omited perf #s till I get more feedback] But we are also still working on 2 bugs atm and once they are resolved we will then figure out the release schedule.

While I don't want to get OT and mods can split this off if they wish... I would like to add a side note to the upcoming DivX 7.

While I usually don't comment on what ppl say from a competition perspective... it is no stretch to say that DivX will in fact continue to compare itself to CoreAVC for decoding and x264 for encoding. While we welcome the challenge (as i'm sure DS and the other x264 devs do) I would like to ask a question... Is DivX 7 really relevant anymore? Given that x264 has a massive head start on h.264 encoding side... and it seems that DivX has just done a mashup of the Main Concept/DivX Encoder/Decoder from their betas and latest Alpha release.

But the biggest thing I would to point out that DivX 7 is NOT DivX at all.... given the spirit of which when I first joined the ProjectMayo/DivX team in 2000 it is now far from what those days were (and why I started CoreCodec), and that DivX 7 it seems is nothing more then a far fetched reach to re-invent itself again and keep the stock afloat.

Now lets see if DivX does the right thing and starts to promote Matroska, considering in their DivX 7 'intro' poster there is not one mention of it ;-(

toytown

26th December 2008, 22:57

I would like to ask a question... Is DivX 7 really relevant anymore?

I could say exactly the same thing about CoreAVC. I purchased it back in 2006 for the FIFA world cup, with the promise of gpu acceleration coming soon. Anyways i continued to use it up until a year ago, where GPU/CPU power has increased to the part , where now i have no use for it whatsoever, as i can either use DXVA for my encodes or rely on libavcodec to play them in software mode.

CruNcher

26th December 2008, 23:19

@Toytown
Though the Energy usage is different, but ok not everyone cares about that sad but true, if you have a GPU inside not leveraging it is stupid, especialy for all the Decoding and Post Processing stuff which costs almost 0 additional (additional because you have to calculate the idle energy usage also, though in systems where a GPU is already inside that makes no point anymore) energy 1W (+ Audio CPU) @ most compared to almost 30W + (idle energy GPU 30-40W) that a DualCore alone is consuming :)

Atak_Snajpera

26th December 2008, 23:20

libavcodec to play them in software mode
FFDshow MT (Mpeg-2 and h.264) is really FAST despite 'experimental' label. Divx AVC decoder is even faster.

BetaBoy

27th December 2008, 01:00

@Toytown
Then seeing how you posted in the NVIDIA Encoding thread you would not say the same thing about x264 as well?

@Atak.... you have any performance numbers in this regards?

leeperry

27th December 2008, 11:35

you have any performance numbers in this regards?
I do :D

http://forum.doom9.org/showpost.php?p=1226130&postcount=5786

I'd love to try these CUDA enabled betas if any possible, I will come back with lotsa benchmarks on my G92/3.3Ghz Q6600 combo...I promise :p

CruNcher

27th December 2008, 11:52

leeperry

27th December 2008, 11:56

Your test is invalid for a Decoding comparison leeperry you compare in a Enviroment where already most cpu cycles are used by the Post Processing so it's normal that it can't get faster and the results are so close
well yeah, the idea was to benchmark generic/ICL10/MT ffdshow performance differences(if any)

yet, ffdshow-MT is very close to CoreAVC, and so is Remoulade(for which I'm also a betatester)

I was eagerly hoping for CUDA decoding in CoreAVC, so I could use even more avisynth post-processing in ffdshow....and this day has come it seems :D

if I get chosen as betatester, I will disable all postprocessing in my benchmarks of course.

Ice =A=

27th December 2008, 13:46

My humble opinion on DivX7:
If DivX just promotes the "old" x264 codec and the "old" matroska container (as they said they will) and if they manage to get that standard to stand allone players all over the world (as they did with MPEG4 asp), that would be great!!!
Of course if they should start to "reinvent" mpeg4 avc that would be daft...

And concerning CoreAVC:
Till it's proven otherwise CoreAVC still is the fastest AVC-decoder using only the cpu.
And since it can run most 720p content on those popular Atom-Netbooks CoreAVC was never as important as today!

LeMoi

27th December 2008, 16:16

When switching from a segment to another in a multi-segment file, video disappears... (works fine with FFDShow)

toytown

27th December 2008, 17:45

@Toytown
Then seeing how you posted in the NVIDIA Encoding thread you would not say the same thing about x264 as well?

No because the encoding is no where near IMO the same levels of quality.

If of course i could use a GPU accelerated encoder to give me exactly the same quality/same bitrate as x264 but 2-10times faster, then yes for me x264 would be irrelevant, as i would no longer use it.....of course this assuming that x264 wouldn't offload work to the GPU in future.

For decoding the performance doesnt matter as much (at least for me), if the competitors products can show the same files without any frame drops, why would i purchase coreAVC instead of using the free product?

BetaBoy

27th December 2008, 18:19

why would i purchase CoreAVC instead of using the free product?That's a great point in that for your needs it may not be required, but for others as noted with it maybe just what they need.

As far as GPU encoding.... there are already a few in the works for CUDA and (1) I know of that's out now (but I did not test it yet). So trends to hardware will surely offset and enhance software products... but will never replace it (at least in the short term).

LoRd_MuldeR

27th December 2008, 18:23

why would i purchase coreAVC instead of using the free product?

Because CoreAVC works nicely with DVBViewer, which currently is my only option to watch HDTV :D

I can't get ffdshow to work with DVBViewer for HD channels (H.264) for some reason. It just gives "black screen", no error message or anything...

leeperry

27th December 2008, 20:44

thanks for allowing me as a beta tester, goddamn this thing is fast! :eek:

basically 4 times faster than ffdshow-MT on HD content from my initial tests, will run more benchmarks tomorrow :)

tal.aloni

27th December 2008, 21:30

BetaBoy,
let's say you're using Windows XP and got two GPUs connected, the primary supports Nvidia PureVideoHD, the secondary does not.
would it be possible to use the CUDA engine with CoreAVC while playing video on the secondary monitor?
(I would like to test it if you're not sure, as I happen to have such setup)

Tal

LoRd_MuldeR

27th December 2008, 21:54

basically 4 times faster than ffdshow-MT on HD content from my initial tests, will run more benchmarks tomorrow :)

My tests showed that it's faster than ffdshow-MT indeed. But not that much!

E:\HD\premiere-paff.ts

[ffdshow, rev2527, Pre-Beta 6, 2008-12-19, 4 threads]
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 317.1, dfps: 87.7
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 353.8, dfps: 87.3
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 321.1, dfps: 87.0

[ffdshow-MT, rev2525, 2008-12-20, 4 threads]
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 457.6, dfps: 130.2
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 446.9, dfps: 130.0
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 404.3, dfps: 129.3

[CoreAVC Decoder, v1.8.5]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 1032.6, dfps: 160.2
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 899.0, dfps: 159.2
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 1091.7, dfps: 158.9

That's a speed-up of 22,5 % compared to ffdshow-MT ;)

leeperry

27th December 2008, 22:02

That's a speed-up of 22,5 % compared to ffdshow-MT

fastandfurious-tlr1_h720p.mov

latest ffdshow MT :
User: 41s, kernel: 0s, total: 42s, real: 60s, fps: 73.4, dfps: 51.1

CoreAVC CUDA :
User: 10s, kernel: 0s, total: 11s, real: 17s, fps: 271.5, dfps: 177.6

that's with a 3.3Ghz Q6600 & a 96 shaders G92 on XP SP3

but I'm getting blockiness on seeks, and sometimes on movies too, hell I even got a nv4_disp infinite loop...I use the 180.48 drivers.

I will update to 180.100

LoRd_MuldeR

27th December 2008, 23:22

fastandfurious-tlr1_h720p.mov

latest ffdshow MT :
User: 41s, kernel: 0s, total: 42s, real: 60s, fps: 73.4, dfps: 51.1

CoreAVC CUDA :
User: 10s, kernel: 0s, total: 11s, real: 17s, fps: 271.5, dfps: 177.6

Since when does CoreAVC have GPU support ???

The official site still says:

GPU support (to be added**)

** GPU scheduled to be added at a later date

ChronoCross

27th December 2008, 23:27

@LoRd_MuldeR

Since when does CoreAVC have GPU support ???

The official site still says:

thanks for allowing me as a beta tester, goddamn this thing is fast! :eek:

basically 4 times faster than ffdshow-MT on HD content from my initial tests, will run more benchmarks tomorrow :)

He's a Cuda Beta tester for coreavc

LoRd_MuldeR

27th December 2008, 23:32

He's a Cuda Beta tester for coreavc

I see. But in that case it's not surprising that the GPU-enabled decoder (CoreAVC GPU) is faster than the pure software decoder (ffdshow-MT).

ChronoCross

27th December 2008, 23:39

I see. But in that case it's not surprising that the GPU-enabled decoder (CoreAVC GPU) is faster than the pure software decoder (ffdshow-MT).

Agreed. I suppose the only thing we can take out of this is that CoreAVC is now both the best CPU and GPU decoder solution for H264.

nurbs

27th December 2008, 23:43

There's the best thing again. I think the decoder in mpc-hc is better because it works on my ATI card.

LoRd_MuldeR

27th December 2008, 23:51

Agreed. I suppose the only thing we can take out of this is that CoreAVC is now both the best CPU and GPU decoder solution for H264.

The best? Maybe it's the fastest - given that you have a Nvidia card. But faster doesn't necessarily mean better!

Aas long as ffdshow-MT allows smooth "real time" playback, it is as good as any faster decoder for almost any purpose...

leeperry

27th December 2008, 23:52

There's the best thing again. I think the decoder in mpc-hc is better because it works on my ATI card.
except that it doesn't allow ffdshow postprocessing, and neither does it support >L4.1 encodes I think ? never bothered w/ DXVA myself, where's the fun in that :D

nurbs

28th December 2008, 00:05

leeperry

28th December 2008, 00:09

it's completely useless for anyone who doesn't have a nvidia card.
who's to blame ? ATi is catching up on the HW side, but their drivers support still lags behind IMVHO.

indeed if you don't care for ffdshow/avisynth PP & don't have >L4.1 encodes....MPC HC DXVA ftw :)

lexor

28th December 2008, 00:13

Hey guys, does anyone have both CoreAVC and Asus Eee PC? I know there are 3 versions of that pc now, can the fastest of them do x264: Unrestricted 2 Pass Insane from MeGUI at 720p and ~5mbps? I'm thinking it's a big fat "no", but I so want it to be "yes".

ChronoCross

28th December 2008, 00:14

All my encodes are level 3.1 and I don't do ffdshow postprocessing. If I wanted to do any of that I'd just use ffdshow-mt for decoding. Don't get me wrong, it's fine if it works for you. My problem was with CronoChross calling it the best GPU decoder while it's completely useless for anyone who doesn't have a nvidia card.

We've already established that DXVA is a pile of garbage that is being abandoned by both ATI and Nvida in favor of their own proprietary systems. Right now CoreAVC's CUDA implementation matters to 31% of graphics card holders so that's a pretty significantly higher market share than AMD/ATI's 20%

MPC-HC's limitations make it hard to compare the two in terms of performance but if it works for you on the content your watching then great!

lexor

28th December 2008, 00:20

We've already established that DXVA is a pile of garbage that is being abandoned by both ATI and Nvida in favor of their own proprietary systems.
Notice that you are the only one who's still concerned/talking about DXVA in this thread for a while now.

Right now CoreAVC's CUDA implementation matters to 31% of graphics card holders so that's a pretty significantly higher market share than AMD/ATI's 20%
The hell it is. 20% of multi-million user market, is not insignificant. And where are these % coming from?

ChronoCross

28th December 2008, 00:25

Notice that you are the only one who's still concerned/talking about DXVA in this thread for a while now.

You apparently decided to reply without reading. Or your just ignorant to the fact that MPC-HC uses DXVA for video acceleration.

The hell it is. 20% of multi-million user market, is not insignificant.

Sure it is. Especially when ATI has made no progress in the multimedia market to speak of recently. Their more of a gaming platform rather than a multipurpose company.

As soon as they release something not related to DXVA that can be used properly by companies for video acceleration of 1080 material then they will become more signifigant

lexor

28th December 2008, 00:29

You apparently decided to reply without reading. Or your just ignorant to the fact that MPC-HC uses DXVA for video acceleration.
No, you have misinterpreted posts by others. Just because MPC uses DXVA, doesn't mean that that is the profile people are using/aiming for.

Do not put words in my mouth again.

Sure it is. Especially when ATI has made no progress in the multimedia market to speak of recently. Their more of a gaming platform rather than a multipurpose company.
Aha, and now tell me how that makes CoreAVC's GPU acceleration superior for ATI users, therefore making it a "best" GPU decoder?

ChronoCross

28th December 2008, 00:35

No, you have misinterpreted posts by others. Just because MPC uses DXVA, doesn't mean that that is the profile people are using/aiming for.

Do not put words in my mouth again.

I didn't misinterpret anything. 3.1 guy decided to speak up about how great his 1337 MPC can decode his 3.1 streams. CoreAVC on the other hand is using something that can decode just about any profile. that is my comparison. Not entirely sure why you decided to jump in on the conversation by telling me I'm the only one talking about DXVA.

Aha, and now tell me how that makes CoreAVC's GPU acceleration superior for ATI users, therefore making it a superior GPU decoder?

That wasn't what I said either. I could care less that it doesn't support crippled ATI hardware. Like I said once ATI decides to actually give a toot about multimedia then maybe CoreAVC can add support for it.

Dark Shikari

28th December 2008, 00:36

I could care less that it doesn't support crippled ATI hardware. Like I said once ATI decides to actually give a toot about multimediahttp://i39.tinypic.com/23r34n4.jpg

ChronoCross

28th December 2008, 00:38

it'd be a troll if I used nvidia hardware. Alas I'm stuck with my crippleware ATI graphics card.

lexor

28th December 2008, 00:38

I didn't misinterpret anything. 3.1 guy decided to speak up about how great his 1337 MPC can decode his 3.1 streams. CoreAVC on the other hand is using something that can decode just about any profile. that is my comparison. Not entirely sure why you decided to jump in on the conversation by telling me I'm the only one talking about DXVA.
What does it matter what makes MPC tick? It works, and not just for DXVA profile (3.1 is not 4.0 or 4.1)

That wasn't what I said either. I could care less that it doesn't support crippled ATI hardware. Like I said once ATI decides to pull their heads out of their anus' and actually give a toot about multimedia then maybe CoreAVC can add support for it.
You could care less? So you do care, now? OK. It was you who said CoreAVC was the "best" GPU decoder. How is it the best if it doesn't work for 20% of the users... and where did you get that 20% from?

ChronoCross

28th December 2008, 00:43

What does it matter what makes MPC tick? It works, and not just for DXVA profile (3.1 is not 4.0 or 4.1)

You could care less? So you do care, now? OK. It was you who said CoreAVC was the "best" GPU decoder. How is it the best if it doesn't work for 20% of the users... and where did you get that 20% from?

http://www.jonpeddie.com/about/press/2008/q2-2008-gpu-shipments.php

Q2 08 market analysis.

vucloutr

28th December 2008, 00:57

except that it doesn't allow ffdshow postprocessing, and neither does it support >L4.1 encodes I think ? never bothered w/ DXVA myself, where's the fun in that :D

mpc-hc does support up to L5.1 for Nvidia cards since rev 857 (http://www.xvidvideo.ru/content/view/358/2/).
and it is actually working pretty good, only few encode won't work correctly.

nurbs

28th December 2008, 00:58

Cool, I started a flamewar.
I didn't mean my comment in any way as an ATI vs. nVidia thing. The reason I have an ATI card is that a friend of mine gave it to me when he bought a new PC about a year ago. He didn't have any use for an AGP card anymore. Before that I had a geforce3. My point was that there is a reason for why there is no best on this forum, namely that what works well for one person might be completely useless to another. I mean CUDA is nice and if I had an nVidia card i'd buy the software neuron2 makes that uses it, but going by your numbers at least 69% of the cards out there don't support it so it's not a good GPU decoder for owners of these cards at all. Then there is the fact that older cards and a lot of mobile GPUs don't support any kind of hardware acceleration and not everyone needs it to play their content anyway, I certainly don't.

leeperry

28th December 2008, 01:27

guys, as soon as ATi learns better you can count on CoreCodec to see what can be done I'm sure. ATi fails at drivers support, live with it or buy an nvidia.

bond

28th December 2008, 14:26

guys, please keep everything nice and cosy!

IgorC

28th December 2008, 20:47

And concerning CoreAVC:[/U]
Till it's proven otherwise CoreAVC still is the fastest AVC-decoder using only the cpu.
And since it can run most 720p content on those popular Atom-Netbooks CoreAVC was never as important as today!
Well, last beta of Divx H.264 is on par. http://forum.doom9.org/showthread.php?p=1225025#post1225025
Probably the final release of Divx decoder will be still faster
Maybe that's why corecodec are hurry with their GPU acceleration.

BetaBoy

28th December 2008, 23:28

Well, last beta of Divx H.264 is on par. http://forum.doom9.org/showthread.php?p=1225025#post1225025
Probably the final release of Divx decoder will be still faster
Maybe that's why corecodec are hurry with their GPU acceleration.
Not at all.... If you read the changelog ( see: http://www.coreavc.com/index.php?option=com_content&task=view&id=27&Itemid=1 ) all we have done is work on adding features and bug fixes. CORE CPU and algorithm optimizations have not been touched at all since our first release almost 3 years ago. I have also stated several times in this thread that those changes are happening now as we go into 2.0 and that CUDA support is a precursor to 2.0 and fulfills our promise to add GPU support.

I would also note that without saying names we are also working with many other hardware manufacturers on GPU support not only for CoreAVC but also for the CorePlayer Platform and will be making an announcements both at CES and 3GSM in this regards.

Sharktooth

29th December 2008, 05:18

amd/ati, s3... maybe intel (maybe some unreleased product...)?

madshi

29th December 2008, 11:16

@BetaBoy, two GPU acceleration questions:

(1) Is your GPU accelerated decoding mathematically 100% identical to pure software decoding? Or can there be slight variations? Will the decoding mathematically differ between different GPUs (NVidia/ATI)?

(2) I'm sometimes experiencing bluescreens after seeking (or when playing corrupted sources) when decoding h264 movies with DXVA acceleration (ATI 3850). Do you think that your hardware acceleration could eventually suffer from similar problems?

Thanks!

BetaBoy

29th December 2008, 15:53

@ madshi...
1 - yes its correct. But as the NVIDIA engineers have noted that 'we' could actually create our own tools and algorithms to take even more advantage of the GPU then what they have provided. We will see about that as the big momentum atm for GPU seems to be swinging towards OpenCL for mass adoption which we are fine with as we want to see hardware acceleration of OpenGL ES.

2 - I have yet to read any internal issues that experience any blue screens like that with CoreAVC CUDA, but we have built in software fallback if it encounters any issues during playback (like your corrupted source).

madshi

29th December 2008, 17:10

Thanx!

Dark Eiri

30th December 2008, 05:02

So CUDA can decode H264 L5.1, right? I wonder why they limited the DXVA decoders to 4.1.

lexor

30th December 2008, 05:31

So CUDA can decode H264 L5.1, right? I wonder why they limited the DXVA decoders to 4.1.
The same reason sports channels broadcast in 1080@60i (at best) instead of 60p or more. They rushed it to market and proper/powerful enough hardware wasn't available. Now they are stuck with having to provide backwards compatibility.

Anywho, betaboy, I guess it got lost in the mini flame war we just had here, but do you have any asus eee box pc benchmarks (or anything on atom front)? How far can atom be pushed without cuda (which it can't use in asus rig)?

BetaBoy

30th December 2008, 07:41

IIRC it was said a while back here that there was no AVC profile limitation to what CUDA can support other then maybe current programming limitations on NVIDIA's side (and there are none that I have been told about). I'll ask internally to confirm this and let you know.

BetaBoy

30th December 2008, 07:56

The same reason sports channels broadcast in 1080@60i (at best) instead of 60p or more. They rushed it to market and proper/powerful enough hardware wasn't available. Now they are stuck with having to provide backwards compatibility.

Anywho, betaboy, I guess it got lost in the mini flame war we just had here, but do you have any asus eee box pc benchmarks (or anything on atom front)? How far can atom be pushed without cuda (which it can't use in asus rig)?

We are going to be doing benchmarks later this week on the Eee's we have here with CorePlayer with CoreAVC/CoreAAC (we just added HE-AAC support) as we are making installers for it.

Also we have a few different versions for Linux:
- CorePlayer Pro w/QT UI x11
- CorePlayer Pro w/GTK UI
- CorePlayer Pro w/GTK UI and DirectFB
- CorePlayer Pro w/CoreUI and DirectFB

Now CoreUI and DirectFB is far from ready so I don't expect it to be benchmark capable. But it will be interesting to see what is fastest, but my bet is for CorePlayer Pro w/QT UI x11.

Now with that being said.... the above is not CUDA enabled yet and we have just begun talking about adding native CUDA to CP for both Windows and Linux.

A side note.... If anyone wants to see/play with either CoreAVC CUDA or CorePlayer on Linux and try to benchmark/test it for themselves we are going to be at CES next week and are planning a get together with some of the ex-DivX, x264 and FFMPEG devs. Send me an email: betaboy AT corecodec DOT com for more info.

BetaBoy

30th December 2008, 08:12

@ lexor.... I should have also said.... I'll post some CorePlayer Benchmark results but PM me with some content you want me to test against it. But pls try and match the dar/par of the Eee and don't get too crazy with the bitrate ;-)... oh also.... maybe one with and without MBAFF.

CruNcher

30th December 2008, 10:48

Betaplayer ;) ?

MatMaul

30th December 2008, 12:07

So CUDA can decode H264 L5.1, right? I wonder why they limited the DXVA decoders to 4.1.
it has been said several times, recent nvidia drivers support dxva decoding of L5.1 streams.

EDIT :
IIRC it was said a while back here that there was no AVC profile limitation to what CUDA can support other then maybe current programming limitations on NVIDIA's side (and there are none that I have been told about). I'll ask internally to confirm this and let you know.
does lossless profiles (old one and predictive one) are supported too ?

CruNcher

30th December 2008, 12:56

@MatMaul
If Nvidias Logic is Programmable it should be doable (though only by Nvidia, i guess they have to update the Driver for that) but even if it is i doubt they gonna invest the time to include Lossless support :)

BetaBoy

30th December 2008, 15:35

Dark Eiri

30th December 2008, 17:49

So you can pretty much say there's no limitations, since 15 ref frames is absurdly insane :D

Thanks for the info!

BetaBoy

30th December 2008, 18:18

Well I should also said Lossless is not supported but I guess you already knew that.

madshi

30th December 2008, 18:56

@BetaBoy, when you post benchmark results, it would be interesting to see one set of numbers for a reasonable HTPC setup. E.g. one of those new NVidia mainboards for Intel Core with HDMI audio support. I'll probably buy one of those sooner or later. It would help knowing how much advantage CUDA brings with the relatively slow onboard graphics of such an HTPC mainboard. Would help me decide whether to go for dual core or quad core. Thanks...

(And before somebody says that I can use DXVA with such an NVidia mainboard: No thanks. I want to use the Haali Renderer and ffdshow's high quality YUV -> RGB conversion...)

Cyber-Mav

31st December 2008, 01:48

ok.... I bounced it internally... while the CUDA documentation states there is a 4.1 level limitation this is not correct or has not been updated and there are no known limitations based on our coding/working/testing with CoreAVC+CUDA. The only limitation we can think of is that there is a 15 ref frame limit for Windows.

thats amazing, CUDA has level 5.1 capability unofficially? DXVA hardware acceleration seems to break easily but by what your saying 15 reference frames being do-able means that coreavc CUDA's playback using hardware acceleration will be pretty much bulletproof compared to the gpu assistance provided by competing products.

LoRd_MuldeR

31st December 2008, 01:57

thats amazing, CUDA has level 5.1 capability unofficially?

Well, CUDA is just an API for developers to take advantage of the GPU. So there should be no inherent level limitation in CUDA.

However it depends on the individual decoder implementation which levels are supported and which are not.

Just because a decoder makes use of CUDA doesn't mean that it can't do certain things in software - things that are hard/impossible to do entirely in hardware.

The developers decide which parts of the decoding process they move over to the GPU and which parts are better done on the CPU ...

mlaviolette

31st December 2008, 03:46

@BetaBoy, I just upgraded my CoreAVC Pro from 1.8.0 to 1.8.5, and now it appears that CoreAVC is not being invoked. Applications relying on this codec (like Windows Media Player) cannot process the video portion of the H.264 .ts files, only the audio. I tried de-registering and re-registering (from the START->Programs->CodeCodec->CoreAVCPro), but no luck. Applications having their own codec (like ArcSoft, MPCHC) work fine, but I need to get CoreAVC working again. Did I miss something simple? Thanks.

LoRd_MuldeR

31st December 2008, 04:08

mlaviolette

31st December 2008, 14:33

Instead of a player that tries to hide as much information as possible from the user and that doesn't offer any useful options, why not use a player that allows you to specify the decoder filter you want to use? ;)

http://mpc-hc.sourceforge.net/

Anyway, you may want to check the "Preferred decoder" option in CoreAVC, if you did not do so yet...I had checked that option.

Along with Windows Media Player not working, H264TS Cutter also fails when it cannot decode the video. That is more important to me than WMP not working. I must be missing a simple step.

LoRd_MuldeR

31st December 2008, 14:42

I had checked that option.

Along with Windows Media Player not working, H264TS Cutter also fails when it cannot decode the video. That is more important to me than WMP not working. I must be missing a simple step.

If you run GraphStudio (or GraphEdit), can you load the CoreAVC filter and connect it manually to your source ???

Note that along with CoreAVC you also need suitable splitters for your source!

BTW: Last time I updated CoreAVC, it installed a pretty old version of Haali Media Splitter, it replaced my "new" version that was installed. So try updating your Haali Media Splitter ;)

http://haali.cs.msu.ru/mkv/

mlaviolette

31st December 2008, 15:40

BTW: Last time I updated CoreAVC, it installed a pretty old version of Haali Media Splitter, it replaced my "new" version that was installed. So try updating your Haali Media Splitter ;)

http://haali.cs.msu.ru/mkv/That was it!!! I installed the latest Haali and everything now works. Thank you so much!

LoRd_MuldeR

31st December 2008, 15:44

That was it!!! I installed the latest Haali and everything now works. Thank you so much!

Maybe they'll decide to ship the next release of CoreAVC with latest Haali Media Splitter ;)

madshi

31st December 2008, 16:10

Maybe they'll decide to ship the next release of CoreAVC with latest Haali Media Splitter ;)
Probably not, because if they did they'd be flooded with bug reports about broken LPCM playback of m2ts files... :(

BetaBoy

31st December 2008, 16:34

BTW: Last time I updated CoreAVC, it installed a pretty old version of Haali Media Splitter, it replaced my "new" version that was installed. So try updating your Haali Media Splitter ;)

http://haali.cs.msu.ru/mkv/

v1.8.5 has the latest splitter.... the initial release however on the first day did have an old splitter but only was live for a few hours and we did a silent update.

LoRd_MuldeR

31st December 2008, 17:50

v1.8.5 has the latest splitter.... the initial release however on the first day did have an old splitter but only was live for a few hours and we did a silent update.

I see :D

vwpassion

1st January 2009, 21:07

From time to time I stumble over blurays, which when I decode with coreavc, produce glitches on a few frames. Decoding the same frames with another decoder works just fine, so its definitely coreavc related. Is this a known issue with coreavc? Sorry if this has been discussed before, but wasnt able to find a proper answer to this issue.

LoRd_MuldeR

1st January 2009, 21:08

vwpassion

1st January 2009, 21:43

You'd need to provide a short sample that can be used to reproduce the problem, I guess...

http://www.mediafire.com/download.php?qotxytgxdd2

Take a look at frames 24-27.

LoRd_MuldeR

1st January 2009, 21:59

http://www.mediafire.com/download.php?qotxytgxdd2

Take a look at frames 24-27.

Yup, I see. There are some artifacts on these frames when using CoreAVC. The same frames are fine with DGAVCIndex/AVCSource.

http://img73.imageshack.us/img73/9339/coreavcglitchescoreavcdy2.th.png (http://img73.imageshack.us/img73/9339/coreavcglitchescoreavcdy2.png) http://img73.imageshack.us/img73/4753/coreavcglitchesavcsourckm0.th.png (http://img73.imageshack.us/img73/4753/coreavcglitchesavcsourckm0.png)

Dark Shikari

1st January 2009, 22:16

I'm going to guess it's another case of the Blu-ray discs violating the spec for MVs again.

laserfan

1st January 2009, 23:08

I'm going to guess it's another case of the Blu-ray discs violating the spec for MVs again.I have seen similar artifacts, but they appear at random i.e. will vary from one encoding attempt to the next, and in fact seem NOT to have anything to do with image complexity i.e. they'll appear in "quiet" scenes quite unexpectedly.

When it's happened I've tried another decoder but will still get the glitches, in a different place, maybe 5-10 total over 200,000 frames (VERY hard to find).

I have worked hard to *rule-out* CPU/Memory issues which clearly could cause problems--is there anything else besides decoder issues (the CoreAVC issue mentioned here) that can cause such pixelations? For example, over-loading my P4 from a threads/threading/decode/encode POV?

Dark Shikari

1st January 2009, 23:11

I have seen similar artifacts, but they appear at random i.e. will vary from one encoding attempt to the next, and in fact seem NOT to have anything to do with image complexity i.e. they'll appear in "quiet" scenes quite unexpectedly.Blu-ray encoders are notorious for producing random, all-over-the-place MVs even in quiet scenes.

laserfan

1st January 2009, 23:21

Blu-ray encoders are notorious for producing random, all-over-the-place MVs even in quiet scenes.So the issue is how well the decoder handles these, and CoreAVC doesn't do well with the above video... Dark do you have a preference for a "MV-tolerant" VC-1 decoder, Microsoft's or ffdshow/libavcodec or I suppose Cyberlink or Arcsoft or...?

Re: 264 I'd been using Cyberlink for playback/viewing and on my system it looked awful, but CoreAVC looks much, much better (and is faster) but frameserving for encoding is a different animal entirely?

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

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

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.

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".

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

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

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

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

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

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

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

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

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...

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.

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

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 :(

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 ; :)

BetaBoy

14th February 2009, 22:35

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

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

chros

14th February 2009, 22:58

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

leeperry

14th February 2009, 23:47

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

way to go :cool:

Inventive Software

15th February 2009, 13:30

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

15th February 2009, 14:08

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

leeperry

15th February 2009, 14:36

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

BetaBoy

15th February 2009, 16:36

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

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

Disabled

16th February 2009, 02:34

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

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

BetaBoy

16th February 2009, 03:33

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

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

dansus

16th February 2009, 19:41

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

way to go :cool:

Where? how?

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

lexor

16th February 2009, 20:11

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

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

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

hajj_3

16th February 2009, 20:39

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

Cyber-Mav

16th February 2009, 21:44

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

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

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

STaRGaZeR

16th February 2009, 22:02

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

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

lexor

16th February 2009, 22:52

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

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

Disabled

17th February 2009, 00:47

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

DeepBeepMeep

17th February 2009, 01:08

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

Are you implying you don't need VP2?

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

STaRGaZeR

17th February 2009, 01:44

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

Are you implying you don't need VP2?

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

Sulik

17th February 2009, 07:08

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

CiNcH

17th February 2009, 13:10

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

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

Guest

17th February 2009, 14:12

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

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

jj666

17th February 2009, 14:12

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

Obvious.

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

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

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

Cheers,

-jj-

STaRGaZeR

17th February 2009, 15:51

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

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

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

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

BetaBoy

17th February 2009, 16:47

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

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

BetaBoy

17th February 2009, 16:55

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

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

TheShadowRunner

17th February 2009, 17:05

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

TSR

CiNcH

17th February 2009, 18:10

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

squid_80

17th February 2009, 18:51

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

Disabled

17th February 2009, 19:29

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

BetaBoy

17th February 2009, 19:38

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

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

jj666

17th February 2009, 21:25

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

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

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

Cheers,

-jj-

Cyber-Mav

17th February 2009, 23:09

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

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

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

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

Rectal Prolapse

17th February 2009, 23:42

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

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

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

me7

18th February 2009, 00:04

STaRGaZeR

18th February 2009, 00:11

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

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

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

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

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

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

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

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

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

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

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

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

squid_80

18th February 2009, 03:09

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

Sulik

18th February 2009, 03:19

ranpha

18th February 2009, 09:59

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

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

MatMaul

18th February 2009, 10:21

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

paulvdb

18th February 2009, 10:53

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

TheShadowRunner

18th February 2009, 13:10

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

me7

18th February 2009, 13:28

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

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

Cyber-Mav

18th February 2009, 14:17

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

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

paulvdb

18th February 2009, 19:21

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

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

me7

18th February 2009, 20:24

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

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

@BetaBoy: are mobile drivers maybe unsupported?

18th February 2009, 20:39

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

STaRGaZeR

18th February 2009, 21:00

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

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

squid_80

18th February 2009, 22:18

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

me7

19th February 2009, 12:39

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

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

STaRGaZeR

19th February 2009, 12:43

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

I stand corrected with exceptions:

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

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

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

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

Cyber-Mav

19th February 2009, 14:09

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

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

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

STaRGaZeR

19th February 2009, 14:41

Yep, the memory leak is impressive.

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

Cyber-Mav

19th February 2009, 15:39

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

smit

19th February 2009, 16:38

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

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

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

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

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

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

.

leeperry

20th February 2009, 01:04

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

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

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

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

BetaBoy

21st February 2009, 15:36

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

leeperry

21st February 2009, 16:42

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

me7

21st February 2009, 17:38

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

buletti

21st February 2009, 20:56

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

leeperry

21st February 2009, 21:24

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

buletti

21st February 2009, 23:52

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

zoose

22nd February 2009, 03:16

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

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

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

Guest

22nd February 2009, 04:08

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

chros

22nd February 2009, 21:22

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

SixKiller

22nd February 2009, 21:36

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

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

Greetings

Six

Guest

23rd February 2009, 01:43

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

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

You need VP2 or better.

Gleb Egorych

23rd February 2009, 07:51

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

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

yesgrey

23rd February 2009, 10:27

BetaBoy

23rd February 2009, 14:21

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

me7

23rd February 2009, 14:58

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

yesgrey

23rd February 2009, 15:26

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

Guest

23rd February 2009, 15:32

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

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

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

yesgrey

23rd February 2009, 16:03

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

Guest

23rd February 2009, 16:49

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

leeperry

23rd February 2009, 17:04

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

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

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

Sagekilla

24th February 2009, 17:51

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

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

leeperry

24th February 2009, 20:14

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

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

ADude

25th February 2009, 04:46

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

leeperry

25th February 2009, 19:44

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

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

:thanks:

TheShadowRunner

25th February 2009, 20:08

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

TSR

tahir

26th February 2009, 08:36

CUDA is greyed out at settings.

I have GeForce 8600GTS
Windows XP SP3
Driver version 181.22

in C:\windows\system32
nvcuda.dll 6.14.11.8122

what am i doing wrong ?

BetaBoy

26th February 2009, 09:06

* You will also need drivers 182.05 or higher from NVIDIA

me7

26th February 2009, 13:23

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

lucassp

26th February 2009, 14:07

Yes, your 8400M GS is supported.

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

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

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

ADude

27th February 2009, 04:03

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

DJ Bobo

27th February 2009, 09:59

ranpha

27th February 2009, 10:57

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

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

lucassp

27th February 2009, 11:52

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

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

DJ Bobo

27th February 2009, 11:56

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

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

adiabatic

28th February 2009, 08:40

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

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

tetsuox

28th February 2009, 11:02

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

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

~bT~

28th February 2009, 14:49

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

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

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

DJ Bobo

28th February 2009, 17:33

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

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

Shinigami-Sama

28th February 2009, 22:10

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

carlo_0000

1st March 2009, 02:11

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

because i m still waiting for a codec for my mediacenter

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

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

and software decoder is to slow

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

3.4ghz and stil to slow ?

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

Dark Shikari

1st March 2009, 02:22

3.4ghz and stil to slow ?

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

Shinigami-Sama

1st March 2009, 03:48

p4 sucks and that was with lavc
now I use dxva

Dark Eiri

1st March 2009, 07:59

Dark Shikari

1st March 2009, 08:04

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

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

Dark Eiri

1st March 2009, 10:06

I was talking about this:

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

DJ Bobo

1st March 2009, 19:32

Dark Eiri

1st March 2009, 19:38

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

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

carlo_0000

1st March 2009, 23:52

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

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

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

dou you have a download link ?

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

DJ Bobo

2nd March 2009, 00:15

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

carlo_0000

2nd March 2009, 01:49

@ original speed 1.8G

not fast enough and some lag

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

oc 2.5ghz

didn't hit 100% when playing

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

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

BetaBoy

2nd March 2009, 03:37

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

ChronoCross

2nd March 2009, 07:34

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

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

DJ Bobo

2nd March 2009, 10:12

_DW_

2nd March 2009, 15:32

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

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

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

lucassp

2nd March 2009, 15:45

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

BetaBoy

2nd March 2009, 16:30

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

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

lucassp

2nd March 2009, 16:49

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

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

BetaBoy

2nd March 2009, 17:23

changed

DJ Bobo

2nd March 2009, 17:30

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

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

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

Unbelievable! :mad:

_DW_

2nd March 2009, 20:21

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

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

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

carlo_0000

2nd March 2009, 20:45

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

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

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

and olso it s coreavc codec 1.8 (no dxva)

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

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

i think it s something wrong with your computer

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

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

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

DJ Bobo

2nd March 2009, 22:01

@ BetaBoy
Thanks

@ DW
Whatever

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

Snowknight26

2nd March 2009, 23:22

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

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

2nd March 2009, 23:42

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

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

DJ Bobo

3rd March 2009, 01:18

Dark Shikari

3rd March 2009, 01:22

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

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

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

ajp_anton

3rd March 2009, 01:35

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

carlo_0000

3rd March 2009, 02:35

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

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

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

are my print screen al fake maybe ????

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

cpu 900mhz
gpu readon 2400pro

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

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

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

only probleme, it does not deinterlace

ADude

3rd March 2009, 03:04

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

- Licensed CoreAVC Pro user

BetaBoy

3rd March 2009, 03:12

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

BetaBoy

3rd March 2009, 03:14

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

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

Thx DS... you beat me ;-)

meatwad

3rd March 2009, 11:14

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

DJ Bobo

3rd March 2009, 12:03

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

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

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

3rd March 2009, 12:16

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

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

leeperry

3rd March 2009, 12:29

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

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

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

DJ Bobo

3rd March 2009, 12:38

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

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

Gleb Egorych

3rd March 2009, 21:59

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

BetaBoy

4th March 2009, 01:11

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

IgorC

4th March 2009, 02:34

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

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

BetaBoy

4th March 2009, 07:48

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

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

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

leeperry

4th March 2009, 10:09

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

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

squid_80

4th March 2009, 10:43

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

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

leeperry

4th March 2009, 10:47

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

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

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

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

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

squid_80

4th March 2009, 11:28

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

leeperry

4th March 2009, 11:44

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

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

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

squid_80

4th March 2009, 11:56

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

leeperry

4th March 2009, 12:04

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

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

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

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

Audionut

4th March 2009, 12:33

there's no such thing as SD commercial AVC,

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

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

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

leeperry

4th March 2009, 12:48

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

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

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

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

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

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

Audionut

4th March 2009, 13:03

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

A google page. Come on.

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

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

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

No it's not.

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

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

squid_80

4th March 2009, 13:27

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

carlo_0000

4th March 2009, 18:16

@dj bobo

no debloking is enable in coreavc

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

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

no ?

DJ Bobo

4th March 2009, 18:45

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

leeperry

5th March 2009, 00:23

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

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

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

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

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

carlo_0000

5th March 2009, 17:19

DJ Bobo

5th March 2009, 17:39

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

madshi

5th March 2009, 17:46

Some clarification for those from DVinfo....

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

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

G_M_C

5th March 2009, 18:02

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

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

madshi

5th March 2009, 18:13

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

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

G_M_C

5th March 2009, 18:20

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

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

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

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

This is what he wrote;

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

From where he deduced;

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

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

BetaBoy

5th March 2009, 21:33

carlo_0000

5th March 2009, 22:00

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

ok

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

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

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

madshi

5th March 2009, 22:04

DJ Bobo

5th March 2009, 23:08

leeperry

6th March 2009, 00:51

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

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

HowlerX

6th March 2009, 01:00

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

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

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

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

DJ Bobo

6th March 2009, 01:22

HowlerX

6th March 2009, 02:28

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

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

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

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

Shinigami-Sama

6th March 2009, 03:40

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

G_M_C

6th March 2009, 10:00

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

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

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

madshi

6th March 2009, 11:11

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

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

DJ Bobo

6th March 2009, 15:43

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

hellrasinbrasom

6th March 2009, 15:56

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

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

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

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

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

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

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

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

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

:helpful:

carlo_0000

6th March 2009, 17:36

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

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

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

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

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

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

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

DJ Bobo

6th March 2009, 20:38

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

carlo_0000

8th March 2009, 02:02

i did some test today

with sempron 2200 (1.5ghz) soket A

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

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

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

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

i found that the barton 2400 is pretty bad

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

DJ Bobo

8th March 2009, 12:35

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

Ryokurin

8th March 2009, 13:07

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

lucassp

8th March 2009, 13:10

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

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

Ice =A=

9th March 2009, 14:50

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

clsid

9th March 2009, 15:15

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

Sagekilla

9th March 2009, 15:26

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

BetaBoy

9th March 2009, 17:40

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

Betsy25

9th March 2009, 19:54

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

Have fun ! :)

DJ Bobo

9th March 2009, 20:10

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

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

clsid

9th March 2009, 23:08

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

Kurtnoise

10th March 2009, 08:19

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

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

I'm using the last release...

DJ Bobo

10th March 2009, 12:54

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

clsid

10th March 2009, 15:08

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

ChronoCross

10th March 2009, 19:39

BetaBoy

10th March 2009, 20:06

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

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

DJ Bobo

10th March 2009, 22:11

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

clsid

10th March 2009, 22:28

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

DJ Bobo

10th March 2009, 23:27

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

Cyber-Mav

11th March 2009, 02:50

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

littleD

11th March 2009, 09:29

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

DJ Bobo

11th March 2009, 13:04

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

clsid

11th March 2009, 13:35

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

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

littleD

11th March 2009, 15:32

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

Inventive Software

11th March 2009, 17:11

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

hajj_3

11th March 2009, 17:39

u long away from giving us a new version betaboy?

DJ Bobo

11th March 2009, 19:24

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

_DW_

12th March 2009, 02:29

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

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

Sagekilla

12th March 2009, 03:12

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

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

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

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

squid_80

12th March 2009, 03:25

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

Sagekilla

12th March 2009, 03:28

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

squid_80

12th March 2009, 04:08

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

Sagekilla

12th March 2009, 04:10

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

littleD

12th March 2009, 08:44

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

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

DJ Bobo

12th March 2009, 14:53

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

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

cdv1010

14th March 2009, 09:04

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

Cyber-Mav

14th March 2009, 13:57

me7

14th March 2009, 15:41

BetaBoy

14th March 2009, 19:55

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

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

ajp_anton

14th March 2009, 20:27

Is there an x64 version coming?

BetaBoy

15th March 2009, 15:52

In CoreAVC 2.0 yes

Shakey_Jake33

16th March 2009, 16:04

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

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

hajj_3

17th March 2009, 02:32

BetaBoy

17th March 2009, 10:34

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

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

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

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

Dark Shikari

17th March 2009, 13:42

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

BetaBoy

17th March 2009, 13:58

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

Correct.

squid_80

17th March 2009, 14:24

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

tetsuo55

17th March 2009, 14:30

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

Wait.

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

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

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

squid_80

17th March 2009, 14:55

Wait.

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

BetaBoy

17th March 2009, 15:06

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

tetsuo55

17th March 2009, 15:13

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

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

Does 15 ref frames still work at that high resolution?

squid_80

17th March 2009, 15:40

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

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

Cyber-Mav

17th March 2009, 15:46

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

tetsuo55

17th March 2009, 16:12

CoreAVC is currently limited to 2048x2048.

Does that resolution still work with 15 ref frames?

Also what is the bitrate limit?

CiNcH

17th March 2009, 17:51

Still wrong field order for 1080i.

BetaBoy

17th March 2009, 17:58

Ok.. emails going out now for 1.9.5.

Inventive Software

17th March 2009, 19:09

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

lucassp

17th March 2009, 19:53

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

LoRd_MuldeR

17th March 2009, 20:30

Ok.. emails going out now for 1.9.5.

Got it. Thanks :)

BetaBoy

17th March 2009, 23:05

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

BetaBoy

17th March 2009, 23:10

Got it. Thanks :)

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

Cyber-Mav

18th March 2009, 00:31

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

halsboss

18th March 2009, 06:21

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

Shinigami-Sama

18th March 2009, 07:06

lych_necross

18th March 2009, 07:38

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

Gleb Egorych

18th March 2009, 07:43

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

deets

18th March 2009, 10:08

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

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

Dark Eiri

18th March 2009, 16:15

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

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

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

Disabled

18th March 2009, 16:17

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

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

Kurtnoise

18th March 2009, 17:50

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

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

:thanks:

BetaBoy

18th March 2009, 18:07

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

deets

18th March 2009, 19:14

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

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

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

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

Dark Eiri

18th March 2009, 23:51

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

Cyber-Mav

19th March 2009, 00:11

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

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

Dark Eiri

19th March 2009, 01:55

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

But with no filters or even subtitles outside MPC.

halsboss

19th March 2009, 12:50

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

smit

20th March 2009, 12:24

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

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

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

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

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

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

.

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

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

Keep up the good work!

.

leeperry

20th March 2009, 13:39

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

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

cyberbeing

20th March 2009, 21:37

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

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

leeperry

20th March 2009, 22:28

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

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

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

ADude

21st March 2009, 00:54

Is there any reason to update to 1.9.5 if one is not using CUDA ?

Cyber-Mav

21st March 2009, 01:50

Is there any reason to update to 1.9.5 if one is not using CUDA ?

just update anyways. always best to be on latest version :)

BetaBoy

21st March 2009, 04:25

ADude... that's not a question to ask, but something only you can judge. Read the changelog to determine this: http://www.coreavc.com/index.php?option=com_content&task=view&id=27&Itemid=1

But as a best practice we suggest to do as Cyber-Mav has suggested.

Sagekilla

21st March 2009, 19:29

BetaBoy, did you benchmark the improvement from using Async transfers at all? If so, how much of a boost did you get from it?

buletti

21st March 2009, 20:42

I just got aware of a special behavior that I wanted to report. In a previous post (http://forum.doom9.org/showthread.php?p=1252911#post1252911)of this thread I tested the brand new version 1.9 and had some issues to understand when CUDA decoding was used. Only about 1 out of 4 files was decoded with CUDA. Back then I was not able to figure out why CUDA worked only for certain files.
Well, today I re-tested the new version 1.9.5 and hoped there were some changes that allowed me to decode more files with CUDA. Bummer! I just got the same result as with 1.9.0: Some files go green but most do not.
Then, because of a totally unrelated issue, I switched the renderer in MPC-HC from VMR9 renderless to EVR and now the icon is green for every single file! Did I overlook the EVR requirement for CUDA decoding or is this a bug? Am I the only one experiencing this issue with VMR9?

I'm running:
- Windows XP SP3
- .NET 3 (for EVR)
- GeForce 6800 GTS
- Forceware 182.06

TheShadowRunner

21st March 2009, 22:06

I have an issue with 1.9.5.0 (CUDA enabled) and VMR9 on XP: when ReClock changes the display frequency at the start of movie playback, the screen sometimes becomes totally green.
It doesn't happen in full soft mode or with other decoders such as Cyberlink h264 decoder (on soft or DXVA mode).
The movie is also decoded properly with CUDA enabled if ReClock doesn't switch resolutions.
This issue with CoreAVC happened in the past for full software (artefacts appearing after resolution switch during playback) but was correted in 1.8.5.0 I believe.
Is it possible to add the same correction for CUDA?
Thanks,

TSR

leeperry

22nd March 2009, 00:09

just wanted to confirm that I've updated to 182.08 on XP w/ my G92, and jitter in HR is perfect now! http://forum-images.hardware.fr/images/perso/prosterne.gif

smit

22nd March 2009, 00:19

squid_80

22nd March 2009, 07:02

Then, because of a totally unrelated issue, I switched the renderer in MPC-HC from VMR9 renderless to EVR and now the icon is green for every single file! Did I overlook the EVR requirement for CUDA decoding or is this a bug? Am I the only one experiencing this issue with VMR9?

I'm running:
- Windows XP SP3
- .NET 3 (for EVR)
- GeForce 6800 GTS
- Forceware 182.06
EVR is definitely not required. I'm guessing your card is probably a 8600GTS and only has 256MB ram; using VMR9 renderless is consuming more vram than EVR and not leaving enough for CUDA.

buletti

22nd March 2009, 10:38

You are right squid_80. It's a fanless 8600 GTS with 256MB GDDR3 (6800 was a typo).

nightrhyme

23rd March 2009, 23:56

HowlerX

24th March 2009, 01:33

Have one question for you guys since my old system: 3ghz p4e (with HT), 1gb dual channel pc3200, ATI 9800pro wasn't quite up to 1080p decoding. Would a asus p5b, C2D e6600 (2.4ghz), 2 x 1gb DDR2-800, ati x1950 be enough ?

More than enough. And you won't even need CoreAVC to decode it. With that CPU, ffdshow or DivX 7 H.264 decoders are enough.

Disabled

24th March 2009, 01:38

More than enough. And you won't even need CoreAVC to decode it. With that CPU, ffdshow or DivX 7 H.264 decoders are enough.
DivX7 will definately be enough, ffdshow might struggle with demanding sources. At least my e6400 doesn't handle 1080p with ffdshow regularly, so I don't think e6600 will do it all the time. *edit* at least not without ffdshow-mt

nightrhyme

24th March 2009, 02:36

My main machine with e6850 kills any 1080p encoded. It will even do 2 (nearly 3) at the same time with ffdshow 2 threads. Is e6600 really that much slower ?

BetaBoy

24th March 2009, 03:03

Been directed to this thread after my thread on the same subject:
http://forum.doom9.org/showthread.php?t=145855

Have one question for you guys since my old system: 3ghz p4e (with HT), 1gb dual channel pc3200, ATI 9800pro wasn't quite up to 1080p decoding. Would a asus p5b, C2D e6600 (2.4ghz), 2 x 1gb DDR2-800, ati x1950 be enough ?
OMG... with those specs 1080p should play fine (close but fine).... but then again.... if you have fully tested it then the e6600 should be fine.

Disabled

24th March 2009, 09:39

My main machine with e6850 kills any 1080p encoded. It will even do 2 (nearly 3) at the same time with ffdshow 2 threads. Is e6600 really that much slower ?
e6850 is about 25% faster than a e6600, so I believe it is able to decode 1080p with ffdshow (and ffdshow being single threaded, decoding 2 streams also). And I said 1080p gives me a hard time with ffdshow on my e6400, thats 33% slower than the e6850.
Of course every of those processors is able to do 1080p without problems with coreavc or DivX7.

TheShadowRunner

24th March 2009, 09:45

BetaBoy, have you been able to reproduce the issue from this post?
http://forum.doom9.org/showpost.php?p=1264271&postcount=4756
Is a fix possible?

nightrhyme

24th March 2009, 14:36

OMG... with those specs 1080p should play fine (close but fine).... but then again.... if you have fully tested it then the e6600 should be fine.

Haven't actually testet yet. Just wanted an assesment before I buy.

e6850 is about 25% faster than a e6600, so I believe it is able to decode 1080p with ffdshow (and ffdshow being single threaded, decoding 2 streams also). And I said 1080p gives me a hard time with ffdshow on my e6400, thats 33% slower than the e6850.
Of course every of those processors is able to do 1080p without problems with coreavc or DivX7.

Perhaps I could overclock the e6600 close to 3ghz

Since this thread is about Coreavc I wanted to test it.
I didn't find it much faster than FFDshow mt.
ffdshow mt used about 19 - 32 % cpu on a particular scene while core avc used about 22 - 35%

Gleb Egorych

25th March 2009, 19:42

BetaBoy, you wrote:
The next driver release from NVIDIA will address a CUDA cropping issue (content with a height of 368 and 1088 is automatically clipped to 360 and 1080).
Does 182.46 beta have the fix?

vucloutr

25th March 2009, 20:01

Does 182.46 beta have the fix?
nope, its still there. using the 182.46 beta driver the green colored line from 1080p (1088 pixel) material is still being displayed, see attachment.

squid_80

26th March 2009, 02:15

Just to clarify: The bug that Betaboy mentioned affects streams encoded with a height of 368 or 1088 pixels when CUDA decoding is used; the bottom 8 lines are shown as duplicates of the lines above (affects all software that uses the GPU for decoding). For 1088 streams this normally doesn't matter since the intended height is 1080 and those lines won't be shown if cropping parameters are present in the stream. If they're not present you can use the "Crop 1088 to 1080" option to force only 1080 lines to be shown.

vucloutr

26th March 2009, 14:44

whoops, i noticed you're right. without "Crop 1088 to 1080" the green bar gets even bigger, seems CoreAVCw/CUDA can't decode my video properly.

squid_80

26th March 2009, 14:49

Your attachment still hasn't been approved so I can't really see, but it sounds like I might need a sample to check it out - PM me if you want to keep it private or need upload space.

vucloutr

27th March 2009, 00:23

here's a sample: http://www.file-upload.net/download-1551960/sample.mkv.html

squid_80

27th March 2009, 00:43

I can't seem to reproduce it, does it only happen with a particular player/renderer?

vucloutr

27th March 2009, 01:36

happens with VMR7 renderless and Haali Video Renderer using Media Player Classic Homecinema.
all other renderer (e.g EVR, VMR9, ..) don't have that problem.

btw: OS is Win Server 2008 x64

Gleb Egorych

27th March 2009, 19:04

vucloutr, with your sample I do have the issue, both in MPC-HC and ZP and with EVR. Vista x64 SP1, 8800GT, FW 182.46.

BetaBoy

27th March 2009, 19:10

I've said this a few times and its in the readme.... We do not officially support Vista 64bit.

leeperry

27th March 2009, 19:45

any chance for a CUDA VC1/WMV3 decoder anytime soon?

BetaBoy

27th March 2009, 19:48

ATM we are concentrating on adding Directshow and then CUDA support into the future release of CorePlayer 2.0. We have talked about CoreWMV and CUDA but nothing is on the roadmap atm as we would get CoreAVC 2.0 out first.

leeperry

27th March 2009, 20:50

if you could get Haali to polish his video renderer, this would be a god's send ^^

like synchronizing to the graphic card's VBL so it never misses the VSYNC flip time when you run a perfect refresh rate w/ Reclock(23.976/24fps@24/48Hz, 25@25/50Hz, 29.97@29.97/59.94/60Hz).....but well I'm daydreaming, I guess HR's jitter is here to stay :(

this is the problem, and HR is unable to control it :
http://software.intel.com/en-us/articles/video-frame-display-synchronization

BetaBoy

1st April 2009, 16:03

On the requests for Haali splitter changes..... he is aware of them.

nightrhyme

1st April 2009, 16:27

Any ATI specific acceleration planed ?

leeperry

1st April 2009, 16:43

On the requests for Haali splitter changes..... he is aware of them.
well jitter is perfect w/ Reclock for 25/29.97 MKV, bad for 23.976 AC3 MKV and terrible for 23.976 DTS MKV...I know he's aware of it but considering that you're gonna polish CorePlayer and that Reclock is a mandatory app for smooth PC playback, maybe there's a chance you could let him fix the "glitch" :scared:

for what it's worth, the Reclock thread has reached 300000 hits....so proper support would be more than welcome : http://forum.slysoft.com/forumdisplay.php?f=85

AVmaniac

1st April 2009, 23:01

Any ATI specific acceleration planed ?

Yes .. it would really be nice to see some non nvidia bound decoding support although i'm owning a gf8800gts based card. What is about OpenCL? Are there any possibilities?

TheShadowRunner

1st April 2009, 23:11

As I already reported [ http://forum.doom9.org/showpost.php?p=1264271&postcount=4756 ], CUDA definitely doesn't like resolution switch during playback. Makes it pretty much useless with ReClock's "change resolution according to media" feature.
After rez switch the screen is just totally green.
Software mode doesn't have this issue.
How to reproduce: Start movie playback with CUDA enabled. Then just switch resolution (like from 1920x1080@60hz to 1920x1080@50hz, for exemple)
Any input on this is very welcome, BetaBoy.
Later,

TSR

lucassp

2nd April 2009, 08:22

BetaBoy

6th April 2009, 21:34

LoRd_MuldeR

8th April 2009, 01:43

Here is a sample, captured from DVD-S, that plays 100% fine in software mode, but stutters horribly with CUDA enabled:
http://www.mediafire.com/file/zmzenddzcnj/Sample_CUDA.7z

squid_80

8th April 2009, 07:36

Got it, thanks... looks like a frame reordering bug somewhere, not caused by CUDA mode but exposed by it.

CruNcher

8th April 2009, 09:31

Lord Mulder i guess the stuttering comes from wrong synchronization i watched this Scenario a lot of times with streaming files you can either chose between getting unsync and there for no jitter and being sync :) happens a lot of times with Adobe flash Player and for example on youtube after the seek in HD.

Mixer73

10th April 2009, 04:06

Betaboy: In the installer for CoreAVC 1.9.5 you seem to install Haali Media Splitter with silent option so the user cannot make changes to the installation.

Haali has a long-standing bug with the Explorer integration which stops you from deleting files you just played.

Unfortunately it also seems that Haali does not uninstall the Explorer extension when you uninstall the splitter so I'll have to hack this myself.

I'd like to suggest you not install Haali silently for this reason.

Kurtnoise

10th April 2009, 07:07

Betaboy: In the installer for CoreAVC 1.9.5 you seem to install Haali Media Splitter with silent option so the user cannot make changes to the installation.

I don't think so...

http://uppix.net/3/8/6/01fa26ce9502a8c5635afbee7e2ee.png (http://uppix.net/3/8/6/01fa26ce9502a8c5635afbee7e2ee.html)

leeperry

10th April 2009, 10:48

Haali has a long-standing bug with the Explorer integration which stops you from deleting files you just played.
don't install Haali's shell extension and you'll be good to go

Mixer73

10th April 2009, 12:58

don't install Haali's shell extension and you'll be good to go

I understand this, but I just installed 1.9.5 and was not presented with the options screen for Haali, and I uninstalled the bundled version, and installed the latest build of Haali with the Explorer option disabled, and the problem remains with being unable to delete the files. Removing Haali altogether and using Gabest's splitter works fine. I suspect the Haali extension isn't correctly uninstalled, and when the file is replaced the registry entry remains.

BetaBoy

10th April 2009, 13:48

I don't think so...

http://uppix.net/3/8/6/01fa26ce9502a8c5635afbee7e2ee.png (http://uppix.net/3/8/6/01fa26ce9502a8c5635afbee7e2ee.html)

I think he was was referring to the /S option.... but not really as that pop-up is suppressed with the silent install switch.

leeperry

10th April 2009, 23:45

you know BetaBoy, I believe Haali works for your firm. Many people would be willing to pay to see fixes in HMS/HR...this package is vital for PC video playback, and whatever the renderer or the splitter are full of unresolved bugs :(

last time we had a few emails, Haali told me that he had no free time anymore to work on this package...so maybe going commercial(bundled w/ CorePlayer 2.0?) would help your company letting him invest more time in it? just an idea, I believe in Santa Claus I know :D

yesgrey

11th April 2009, 14:56

BetaBoy,
Can you take a look to this (http://forum.doom9.org/showthread.php?t=146228) new video renderer?
With my GF 8600GT 256MB I have to disable cuda in coreavc to be able to use it.
When I enable cuda I have major stutters and severe audio drops, it seems like if madVR and coreavc are "fighting" for the GPU...
I don't know if it's just lack of GPU power to handle both or if it's some kind of incompatibility between both... when I disable cuda, it plays fine.

leeperry

11th April 2009, 21:27

With my GF 8600GT 256MB I have to disable cuda in coreavc to be able to use it.
works fine on XP SP3(latest nvidia/DX9 updates) w/ a 384MB 9600GSO(rebadged 8800GS, 96SP G92)

yesgrey

12th April 2009, 00:13

So it's not any incompatibility between them... Great!:)
Thanks.

buletti

12th April 2009, 07:41

yesgrey3: I have a 8600 GTS with 256 MB and had to switch my renderer in order to use CUDA because of a lack in VRAM. EVR seems to require less VRAM than VMR9 (full stroy here (http://forum.doom9.org/showthread.php?p=1264251#post1264251)).
As madVR is also working on the GPU I guess that 256 MB is just not enough to run CoreAVC and madVR.

yesgrey

12th April 2009, 11:02

As madVR is also working on the GPU I guess that 256 MB is just not enough to run CoreAVC and madVR.
Yes, it should be that. I've seen reports of people with lower GPU and higher memory that worked fine.
It's time for a new graphics card...;)

me7

12th April 2009, 16:15

yesgrey

12th April 2009, 17:32

I also have a 256 MB Video Card and I have found Overlay Mixer to work best for me.
But Overlay Mixer is not such a high quality one... I prefer disabling cuda.;)

smit

12th April 2009, 20:16

Concerning the audio problem that i reported at post #4747 http://forum.doom9.org/showpost.php?p=1263746&postcount=4747
It was motherboard related and it`s fixed.

Today i checked at gigabyte`s site and there was an updated bios posted.

The changelog states:
1. Improve Phenom II CPU compatibility
2. Improve Audio compatibility

I`m curious thaw what do they mean by audio compatibility.

As it seems i spoke too soon.Audio drop outs continue to occur when i`m using cuda acceleration.
I`ve tried many combination in order to be certain that it is solely related to cuda.I Updated my drivers,i disabled reclock,i disabled ac3 filter,i disabled HAALI e.t.c.

The only solution to stop the audio drop outs is to disable cuda.
As i previously wrote,this only happens with SPDIF connection.

.

aba101280

14th April 2009, 00:09

Hi,

at first I have to thank you for the great new 1.9.5 release which support interlaced streams with cuda. I use a 9400 GT with the latest drivers (not Beta). The picture quality is really fine and cuda works with interlaced TV streams on my XP SP3 System.

Unfortunatelly it sometimes just closes the software player when siwitching through HD Channels. For example the channel switch form the HD Channel Premiere HD to Astra HD causes massive problems. The Cyberlink Decoder works without a problem here. With progressive files there is no problem

Is this a know issue?

Thanks and Regards,

Alex

smit

15th April 2009, 16:48

Finaly i`ve fixed it.I went and bought a soundcard and no more audio dropouts.

Cyber-Mav

18th April 2009, 01:05

which sound card did you buy?

Gleb Egorych

18th April 2009, 07:36

I wonder is it possible to do hardware deinterlacing using CUDA? Not because it is heavy task but it may help avoid some limitaions.

18th April 2009, 11:23

I wonder is it possible to do hardware deinterlacing using CUDA? Not because it is heavy task but it may help avoid some limitaions.
Yes, NVCUVID provides access to NVIDIA's deinterlacing implementations directly so there's no need to code your own algorithms. Good deinterlacing is also quite a heavy task: x86 implementations usually require more CPU time than H.264 decoding.

Gleb Egorych

18th April 2009, 14:46

Yes, NVCUVID provides access to NVIDIA's deinterlacing implementations directly so there's no need to code your own algorithms.
Hope CoreCodec team will implement it in a next version.

deets

18th April 2009, 17:51

Hope CoreCodec team will implement it in a next version.

me too. I would love to use hardware deinterlacing as so much of my viewing is 1080i HD.

i cant even get coreavc to use hardware in non cuda mode

BetaBoy

18th April 2009, 18:13

Well the next version _is_ 2.0.... will that be added for it? Likely not in the first 2.0 release as we have other priorities atm for optimizations and 64 bit. But lets see how the next few weeks goes.

deets

19th April 2009, 13:52

have i asked this before? so i cant get coreavc to use hardware bobbing like i can via ffdshow using output NV21. any tips? would like to just use the one setup for 1080i and 720p etc :)

LoRd_MuldeR

19th April 2009, 13:56

BetaBoy, any comment on this one?

Here is a sample, captured from DVD-S, that plays 100% fine in software mode, but stutters horribly with CUDA enabled:
http://www.mediafire.com/file/zmzenddzcnj/Sample_CUDA.7z

smit

24th April 2009, 16:46

which sound card did you buy?

Sorry for the late responce but i was out of town.

I bought this one
http://www.speed-link.com/?p=2&cat=16&pid=16659&paus=1

And i`ve installed this driver
http://code.google.com/p/cmediadrivers/

Works perfectly.

Cyber-Mav

27th April 2009, 01:27

i cant even get coreavc to use hardware in non cuda mode

:rolleyes:

oh man i dont even know how to reply to that

deets

27th April 2009, 13:22

:rolleyes:

oh man i dont even know how to reply to that

hardware de interlacing? when i select hardware for my in the options i get an awful picture. ive managed to get harware de interlacing sorted in ffdshow and mpc-hc using the internal dxva decoder and would love the same otption for coreavc.

halsboss

27th April 2009, 14:08

i cant even get coreavc to use hardware in non cuda mode :D CUDA is the programming means by which you access the video card hardware. No CUDa = no hardware access. Think how funny your statement was.

STaRGaZeR

27th April 2009, 14:13

No CUDa = no hardware access. Think how funny your statement was.

Now that's funny ;)

27th April 2009, 14:16

:D CUDA is the programming means by which you access the video card hardware. No CUDa = no hardware access. Think how funny your statement was.
deets was talking about hardware deinterlacing, which can be requested through DirectShow. Whether deinterlacing is actually done depends also on the renderer and driver.

halsboss

28th April 2009, 02:45

glad you enjoyed it :) loosely talking, of course, per dgavcdec type GPU access context. should have read the posts.

Roscoe62

5th May 2009, 06:32

I don't mean to interrupt the flow of things here, but I need some help.

I've been using CoreAVC for quite a while now, and have been very impressed by it's ease of use. Currently I'm using CoreAVC Professional 1.9.5. Most of the stuff I play back are my blu-ray disks I've remuxed to mkv. I just got my wife a K D Lang blu-ray (Live in London) and the source is interlaced - I don't think I've got anything else interlaced! The picture was REALLY jittery and showed combing all over the place.

I thought it might be the settings within CoreAVC needed adjusting but there doesn't seem to be much there. I currently have DeInterlacing set to Hardware (I'm using a Geforce 8200 motherboard chipset) and for most things this is fine. However, when experimenting with this blu-ray I found that changing the setting to Bob fixed the problem instantly.

My question is this : Can I assume that leaving the Interlacing method set to Bob won't affect playback of my other (non-interlaced) blu-ray backups? (are most blu-rays 1080P?)Or is there a way to make CoreAVC automatically select the correct method? This is in a HTPC rig so manually going in to change the setting isn't really an acceptable option.

Any help is appreciated. :)

squid_80

5th May 2009, 06:38

CoreAVC only applies deinterlacing to interlaced sources, so leaving it set to Bob won't affect playback of 1080P streams.

Shakey_Jake33

5th May 2009, 06:59

CiNcH

5th May 2009, 09:04

Also, depending on how fussy you are about deinterlacing quality, you might find superior deinterlacing quality if you bring ffdshow into the filter chain (by enabling 'raw video' in ffdshow) and deinterlacing using YADIF. It still decodes using CoreAVC, but you benefit in deinterlacing quality by using YADIF.
The best deinterlacing (quality and performance wise) would still be NV12 and hardware deinterlacing checked within CoreAVC, at least if you have an up-to-date graphics card.

I would have bought CoreAVC long time ago if it worked correctly with the 1080i DVB channels I receive, but I am still waiting for that to happen. For some reason there is still a "huge" jitter and sync-offset at the renderer and there is always micro-stuttering when watching (also played back TS recordings with the Haali Media Splitter in line). And if you take a look at edges in the video you can see that it is not smooth (but those stairs at edges can't be spotted easily at 1080 lines). My opinion still is that the field order is not correct with interlaced content. I reported that several times but nobody wants to analyze it with me.

Roscoe62

5th May 2009, 09:12

Thanks very much for the info!! :)

CiNcH

5th May 2009, 16:01

1080i deinterlacing

CoreAVC 1.9.5 NV12 + hardware deinterlacing:
http://members.inode.at/762450/coreavc/coreavc_nv12_hwdeint_logo.jpg

CyberLink NV12 + hardware deinterlacing (DXVA):
http://members.inode.at/762450/coreavc/cyberlink_nv12_hwdeint_logo.jpg

GPU: ATi Radeon HD3650

pankov

5th May 2009, 18:26

CiNcH,
which version of the CyberLink decoder do you use? (from which PowerDVD Version?)
Also what do you think about the image quality (deblocking, noise, image artifacts and color rendering not jitter and fluid motion) of CyberLink vs. CoreAVC? I've read many saying that the recent versions of CoreAVC do produce better image (if one doesn't suffer from stuttering and skips, of course).

CiNcH

5th May 2009, 22:04

H.264 decoders should produce bit-identical output, so the only variable you have is post processing. Since both, CyberLink and CoreAVC, use NV12 and hardware deinterlacing, quality should be pretty similar, but as you can see from the above screenshots, this isn't the case. I still have the impression that fields are swapped with CoreAVC.

I am using the H.264 decoder that came with my TerraTec Cinergy DT USB XS Diversity Stick, which is a pretty recent PowerDVD8 decoder. But quality should not defer too much between PowerDVD version since everything is handled within the GPU anyway.

My opinion is that when it comes to interlaced content you should forget about CoreAVC. I can't use YADIF for 1080i. Think I would get around 5 fps on my C2D CPU.

TheShadowRunner

5th May 2009, 22:10

I really wish Core addressed the CUDA / live resolution switching issue, but it seems the next planned version is 2.0, god knows when :/

Again, the issue occurs when switching resolutions (exemple 1280x720@60hz to 1280x720@24, etc..) WHILE CUDA is being used to decode a movie. After switching rez, the screen will be either completely green or blinking green.
This does NOT occur with CoreAVC in software mode or even with Cyberlink w/ DXVA enabled!

Any input on this would be most welcome as CUDA cannot currently be used along with ReClock's resolution-switch script for the reason described above.
Later,

TSR

BetaBoy

6th May 2009, 10:54

TheShadowRunner..... we are aware of your request to release/renew the outputs and have it on the todo. CiNcH.... same for you... we are not ignoring your report by any means.

Also... it is now planned that we will release one more 1.9.x version, likely 1.9.6 to address some of the bugs as well as integrate a new Haali splitter.

tomos

6th May 2009, 12:54

i have a prob whenever i use haalis splitter as opposed to the inbuilt one in MPC.

if my mkv has a few audio tracks, the inbuilt one shows all 3 as an option under audio, but haalis shows the 1st only

i know this is a core thread, but if he's dealing with you guys .......

BetaBoy

6th May 2009, 14:59

For Haali's Splitter we are talking about adding a public wiki and a bug tracker for it over at CoreForge.org.

BetaBoy

6th May 2009, 15:01

Also wanted to note that in testing the latest WMP within the Windows 7 RC... it looks like they have now enabled DXVA for AVC in Media Foundation (unless I missed it in earlier testing).

A little OT... but does anyone feel like we do that this is getting worse? and that the Apple precedence in the industry for the closed eco-system's on the iPod, iPhone/Touch, which is now being followed up with MS doing the same (but in software)? Yes, it's 'potentially closed' since Windows 7/WMP are just RC atm and not final, but still.

However, at the same time there seems to be hope as MS is now in regular contact with us (thx MS) in regards to the splitter (see the Matroska Mailing List), we are just unsure of the direction MF/WMP will take even if we add outside splitter support as they are suggesting (too OT for this thread, read the ML).

mariner

6th May 2009, 15:25

CiNcH

6th May 2009, 17:18

Further info on the interlaced problem... before the trial expires again, I wanted to try it with nVIDIA as well. Same issue here with NV12 and hardware deinterlacing and also with CUDA enabled. BOB does not suffer from this problem. The logo is clean like with CyberLink then.

squid_80

6th May 2009, 17:20

Have you tried it with Haali's renderer?

CiNcH

6th May 2009, 17:25

Will I get 50fps hardware deinterlacing with Haali? Don't think that Haali will activate that based on the flags being set by CoreAVC!?

squid_80

6th May 2009, 17:31

I wouldn't have suggested it if I hadn't tried it.

CiNcH

6th May 2009, 17:36

But you do not get a connection on NV12. And GPU's only apply the most sophisticated deinterlacing with that color-space (http://www.perry.es/wp-content/uploads/2009/04/dxvachecker_processor.png).

But you are right about Haali.. with YUY2 and the hardware deinterlacing being used then, the static Astra logo also looks smooth.

So does VMR have to be configured differently?

TheShadowRunner

6th May 2009, 20:30

BetaBoy, thanks a lot for your answer.
That's precisely what I wished to hear from Core ;)

Gleb Egorych

6th May 2009, 20:41

But you are right about Haali.. with YUY2 and the hardware deinterlacing being used then, the static Astra logo also looks smooth.
On my 8800GT YUY2 output gives bad quality on red-to-black gradients. They look blocky. No blocks with YV12, NV12 and with Cyberlink DXVA.

CiNcH

9th May 2009, 15:51

After some more tests, I have come to the conclusion that VMR9 is not well supported. I have a lot of frame drops and quality issues with interlaced content. Haali Renderer is fine though but of course far from being a standard renderer. Hope VMR support will get improved. I will keep an eye on CoreAVC, just like I have done for years already, and will join in as soon as it can fulfil my decent needs..

the_corona

23rd May 2009, 08:20

Is there any info available on CoreAVC 2.0?

What I know so far:
- Will be first version with x64 builds (eventually or right away?)
- Will (eventually or right away?) go openCL instead of Cuda for H/W accel
- Will have speed optimizations in software mode
- Will require a new license

I am mostly interested in 2 and 3, but mostly in 3 as my current HTPC is just barely able to play 1080p but I do get alot of dropped frames. Any "peek" at how substantial these improvements will be (5% 10%)? Just a ballmark figure will do.

Also on the other points, are they true as statet?

Keiyakusha

23rd May 2009, 14:11

I heared that there will be mixed GPU+CPU decoding mode or something like that.

Cyber-Mav

24th May 2009, 16:27

speed optimisations are most likley focused on the intel atom cpu lineup.

BetaBoy

25th May 2009, 17:02

the_corona... if you read through the last 20 pages or so I answer all of your questions.

mariner

26th May 2009, 06:10

1920x1080@60P CUDA problem with GeForce 8200/9400 motherboard

Greetings Everyone.

Having problem with CUDA decoding 1920x1080@60P video on GeForce 8200/9400 IGP : Frame rate stays at around 45-50fps instead of 60. Is this a CUDA or GPU limitation? Tested on EVR/Vista.

Many thanks and best regards.

Sample:
http://www.sanyo-dsc.com/products/lineup/dmx_hd2000/img/sample/movie_sample_hd2000_03.zip

Greetings. Did anyone get to try the 1920x1080@60P sample?

The 9400 IGP has 64bit bus and bandwidth of 25.6GB/s according to GPU-Z. What would be the minimum hardware requirement for CUDA to handle this?

Many thanks and best regards.

squid_80

26th May 2009, 06:17

Depending on the bitrate, 1080p@60 can be too much for the hardware decoder on the graphics card to handle. It's not a bus limitation.

mariner

26th May 2009, 07:54

Thanks for the reply, squid.

The bit rate is 24mbps.

What other hardware limitation should one look at? Number of shaders/stream processors perhaps?

FYI, DXVA has no problem handling this.

squid_80

26th May 2009, 08:15

With your particular sample I get 48fps with CoreAVC and 52fps with MPC's DXVA decoder so it's still slower than realtime. You're probably better off using software decoding, it should be able to handle it as long as you have a dual core CPU.

26th May 2009, 09:29

What other hardware limitation should one look at? Number of shaders/stream processors perhaps?

FYI, DXVA has no problem handling this.
Then CoreAVC CUDA might also work on your hardware. Remember that both use the same hardware decoder, only the software layer is different.

mariner

26th May 2009, 11:36

BetaBoy

27th May 2009, 15:04

clsid

27th May 2009, 17:36

Another idea for the Windows 7 issue:
Let Haali's splitter (optionally) deny connection with the MS decoder. Then in theory the DirectShow framework should fall back to using the next available compatible filter (CoreAVC, ffdshow, etc). Of course this will only work with Matroska files and not the stuff that MS handles natively.

BetaBoy

27th May 2009, 17:41

Yeah we had talked about that.... but it negates the purpose of why the splitter/renderer was created as a universal solution (not just MKV) in the first place. We'll see as we are at least now talking with MS about it.

the_corona

28th May 2009, 08:28

The only things in question for 2.0 atm are:
- Initial 64bit version as Haali's splitter needs more work (the filter is ready though)
- Windows 7 splitter/filter support... don't want to got OT in this thread with this FUD as we'd like to see whats possible in MF w/o hacking the registry/perms.

Hi,

Ok, thank you for you're response. But I don't understand (sorry, english is not my mother language), by in question, do you mean

1) these things are the only things that are new in 2.0 or
2) these are the only things we are not yet sure we can get done for 2.0, which would imply that my other statements for 2.0 are true.

Again, sorry if I'm drilling you, but I'm anxiatly awaiting the new release.

PS: why was my previous post deleted, took me along time to find all those quotes and I figured they might be useful to others as a collection?

Shakey_Jake33

28th May 2009, 11:08

^It implies the latter, that those features might not be ready for release.

t3nk3n

28th May 2009, 21:12

Are there plans to support OpenCL or STREAM for full hardware acceleration HD media decoding?

BetaBoy

28th May 2009, 22:44

OpenCL is the first thing after 2.0 is released.

deekey777

28th May 2009, 23:22

OpenCL is the first thing after 2.0 is released.

You can get access to VP over OpenCL?

desta

29th May 2009, 00:57

OpenCL is the first thing after 2.0 is released.
I'm a little ignorant on this sort of thing, but would that mean possible future hardware acceleration support for ATI cards?

LoRd_MuldeR

29th May 2009, 01:06

If CoreAVC is going to use OpenCL, then any OpenCL-capable hardware will be supported. That will include NVIDIA, ATI and others - once they release OpenCL compatible drivers.

For ATI you will need the latest GPU generation though! For NVIDA probably anything that supports CUDA now will support OpenCL in the future. They have a beta of their OpenCL SDK out already.

(Note that OpenCL can even run on the CPU, in case there's no specialized OpenCL hardware available on the machine)

desta

29th May 2009, 01:12

Thanks for the info. :)

CiNcH

29th May 2009, 08:10

LoRd_MuldeR

29th May 2009, 17:59

But OpenCL does not mean that the video decoder engines (e.g. PureVideo or UVD) are being used. Instead some video decoding algorithms are out-sourced onto the GPU's shaders which is much more complex to implement then accessing the CUDA Video API's. Good thing is that Core already has the decoding algorithms, but porting them means a lot of work too.

OpenCL is very similar to CUDA.

The hardest task is to think of tasks and algorithms that are worth running on the GPU and that are highly parallelizable (so they use the GPU efficiently).

If they have that part already for CUDA, implementing their algorithms on a different but similar API shouldn't be too hard...

CiNcH

29th May 2009, 18:21

If they have that part already for CUDA, implementing their algorithms on a different but similar API shouldn't be too hard...
Did I miss that they already have it for CUDA?
Are both, CUDA and OpenCL, based on C syntax?

29th May 2009, 19:02

Did I miss that they already have it for CUDA?
Nope, haven't heard of such work. So far they have simply been using NVCUVID like you said.

Are both, CUDA and OpenCL, based on C syntax?
Yes, and OpenCL is quite similar to CUDA.

Rumbah

29th May 2009, 19:46

If CoreAVC is going to use OpenCL, then any OpenCL-capable hardware will be supported.

I doubt that because as far as I know OpenCL supports extensions like OpenGL. And based on my own experience OpenGL does not run on every OpenGL capable graphics card as everything modern uses an extension that's different for every vendor.

LoRd_MuldeR

30th May 2009, 14:03

I doubt that because as far as I know OpenCL supports extensions like OpenGL. And based on my own experience OpenGL does not run on every OpenGL capable graphics card as everything modern uses an extension that's different for every vendor.

On the other hand it doesn't make much sense to make the step from CUDA to OpenCL, but then rely on NVIDIA-specific extensions.

I assume that if they go the OpenCL route, then they will support ATI (latest generation) and NVDIA (CUDA-capable generations) at least.

For others, we'll see...

BetaBoy

30th May 2009, 15:28

On the other hand it doesn't make much sense to make the step from CUDA to OpenCL, but then rely on NVIDIA-specific extensions.

I assume that if they go the OpenCL route, then they will support ATI (latest generation) and NVDIA (CUDA-capable generations) at least.

For others, we'll see...

That's correct for both our directshow decoders as well as the CorePlayer Platform.

Cyber-Mav

31st May 2009, 01:20

will ati cards be able to support level 5.1 avc streams using opencl like nvidia cards currently do with cuda?

the_corona

31st May 2009, 04:59

Hmmm, interesting about openCL once you think about it.

Do all OpenCL certified devices such as GPU (but not nessesarily) need to provide the same Video Decoding (H264) API? I would think not, since OpenCL (AFAIK) is much more general than that.

So to me this would mean that the decoding engine would need to be coded by CoreAVC itself, as opposed to just using an OpenCL API to get acess to the special hardware in the device (as is done right now through CUDA for NV cards).

Is that correct? If so it's a massive undertaking IMHO :-)

LoRd_MuldeR

31st May 2009, 11:30

Do all OpenCL certified devices such as GPU (but not nessesarily) need to provide the same Video Decoding (H264) API?

As far as I know, OpenCL does not provide any video decoding API. It provides an API (C extension) to run your own algorithms on the device.

I would think not, since OpenCL (AFAIK) is much more general than that.

Correct.

So to me this would mean that the decoding engine would need to be coded by CoreAVC itself, as opposed to just using an OpenCL API to get acess to the special hardware in the device (as is done right now through CUDA for NV cards).

That is correct, unless you want to rely on vendor-specific OpenCL extensions. But then it would make no sense to move from CUDA to OpenCL.

But maybe there will be video libraries available for OpenCL, that developers can license instead of re-inventing the wheel...

Shakey_Jake33

31st May 2009, 18:46

Just a quick n00b question, I have CoreAVC doing the decoding, and ffdshow as raw video filter to perform deinterlace, resize and conversion to RGB32. With this in mind, should I configure CoreAVC to only output RGB32 also? Or leave the conversion to ffdshow?

I ask because there is a noticable difference in colour levels when setting CoreAVC to output as RGB32 only, and I don't actually know which is correct.

squid_80

1st June 2009, 02:13

I ask because there is a noticable difference in colour levels when setting CoreAVC to output as RGB32 only, and I don't actually know which is correct.

The method that looks better to you is correct.

leeperry

1st June 2009, 21:06

I can't really tell whether it's Asus or CoreAVC's fault, but enabling CUDA in CoreAVC w/ an Asus Essence STX soundcard on XP SP3 gives an almost instant BSOD "IRQL NOT LESS OR EQUAL".
w/o CUDA everything's cool....I'm using the latest build of CoreAVC/nvidia drivers. I've also notified Asus.

Inspector.Gadget

1st June 2009, 22:02

leeperry, are you using NVIDIA 1.85.85 drivers?

leeperry

2nd June 2009, 00:08

yup, and before I put the STX in my box CoreAVC CUDA had always worked just fine(my previous soundcard was USB). same exact problem occured w/ 182.08

clsid

17th June 2009, 17:40

CoreAVC causes Windows Explorer to crash during thumbnail generation of .mkv and .mp4 files. I have been able to reproduce it on XPSP3, VistaSP2 and Win7. I have seen several other people that have the same problem.

Here is a reg tweak to enable thumbnails in case you need it:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.mkv\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}]
@="{c5a40261-cd64-4ccf-84cb-c394da41d590}"

[HKEY_CLASSES_ROOT\.mp4\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}]
@="{c5a40261-cd64-4ccf-84cb-c394da41d590}"

(I am not using Haali shell extension)

BetaBoy

19th June 2009, 04:27

clsid..... noted for the next release. Thanx for the follow-up!

clsid

19th June 2009, 15:31

I have also seen reports of people who have crashes when using Haali's shell extension instead the Microsoft one. The reg keys I posted are for the MS one. So you should test both situations.

Can you give an ETA when the next release will be available? Is Haali making any progress with a new version of his splitter?

BetaBoy

25th June 2009, 16:17

A few updates for everyone:

- Based on customer feedback and us going into 2.0, we have EOL'd CoreAVC Standard Edition. Current users will get the upgrade in 1.9.x to Pro as a part of their original purchase of Standard Edition when we release the next version.
- We have decided to combine the Enterprise features into Pro for 2.0 with the one Enterprise feature 4:2:2 being added for the initial 2.0 release and 4:4:4 to be added in a later 2.x release.
- We will now also combine 32bit and 64bit versions into the CoreAVC Pro installer. Its tbd if we will do this with the initial 2.0 release as Windows 7 coming sooner then we had anticipated has effect our plans for the 64bit splitter work.

Cyber-Mav

26th June 2009, 00:42

will 64bit coreavc allow h264 video playback in vista windows media center?

popper

26th June 2009, 01:32

BetaBoy

26th June 2009, 02:26

popper... PM me with FUD like this and let's keep this thread flame free.

Dark Shikari

26th June 2009, 02:31

AND OC your Core AVC ENCODER will be out before V2 (or was it before v1.9, we forget as its been a while) as you stated way back when in the thread :devil:

first rule about Core AVC Encoder is Dont Talk About Core AVC Encoder....:eek: :devil:Actually, I'll be nice--I'll leak the CoreAVC encoder for you.

Get it here! (http://tinyurl.com/qlw39)

popper

26th June 2009, 04:10

popper... PM me with FUD like this and let's keep this thread flame free.

now Dan, be Nice, theres a good fella, FUD indeed. :search:

10th March 2006, 13:13
#13 http://forum.doom9.org/showthread.php?p=797481#post797481
"The product release schedule for CoreAVC (atm) is:

March 15th CoreAVC Standard and Professional Editions
April 15th CoreAVC Enterprise
May GPU Additions

After that our CoreAVC Encoder will be released.... I will not comment on more specific features of the CoreAVC encoder atm.
__________________
Dan "BetaBoy" Marlin
Ubiquitous Developer Tools and Multimedia Technologies."

OC cant be sure about what might have been redacted without some more indepth searching of caches but no matter.

as i said "first rule about Core AVC Encoder is Dont Talk About Core AVC Encoder...." seems to be correct ;)

popper

26th June 2009, 04:17

Actually, I'll be nice--I'll leak the CoreAVC encoder for you.

Get it here! (http://tinyurl.com/qlw39)

:)

actually as per my concept idea's from way back, id still like to see the x264Core Encoder :devil:
developed to a point were it could fit inside a USB2 stick , sat on an FPGA (so as to be able to be reprogramed and updated for any firmware/codec errors found later, or a fixed cheap unfixable ASIC if you must to get it out the door OC),with perhaps an ethernet + sundry SOC capable of H@L4.1 Encode/Decode in and out of the ethernet and USB bus etc as a stand alone bit of HW and Open cross platform API OC.

BetaBoy

26th June 2009, 11:45

Thx again for resurrecting OT talks on something I stated sometime ago we had plans to hold off on. x264 is the way to go, end of story.

CiNcH

27th June 2009, 09:41

Hi again,

just wanted to inform you that I have the same bad quality with ffdshow + NV12 + VMR9 + Hardware Deinterlacing. And it is not due to field order because within ffdshow it is possible to swap fields.

I am attaching a 1080i sample:

http://bleedingme.dyndns.org/06-27_10-31-33_ASTRAHD+_.ts (~80 MByte)

Please have a look at it and check smoothness with VMR9 (dropped frames within renderer properties) and picture quality (especially at the Astra-Logo on the top left corner).

Maybe NV12 Color-Space-Conversion is buggy. As I said, same with ATi and nVIDIA..

sarastro

29th June 2009, 16:55

will 64bit coreavc allow h264 video playback in vista windows media center?

I don't see why not. Admittedly Microsoft has made it a little hard to select your preferred codec. But CLSID fixed that with a small program, for more information on that:
https://forum.doom9.org/showthread.php?t=146910

I run windows 7 x64 so I can't use coreavc anymore. So my media center uses ffdshow for now, using the dxva decoder from mpc-hc is also a no go thanks to the luminance level problem.

[Drifting slightly off topic] If someone form microsoft is following this thread. Why don't you add this tool/ this functionality to windows. I think CLSID has already shown that the program doesn't have to be difficult. And being able to select your favourite decoders should be standard functionality on a OS.
[/Drifting slightly off topic]

dead_screem

3rd July 2009, 09:29

A few updates for everyone:

- Based on customer feedback and us going into 2.0, we have EOL'd CoreAVC Standard Edition. Current users will get the upgrade in 1.9.x to Pro as a part of their original purchase of Standard Edition when we release the next version.
Does this mean that Standard is EOL effective immediately, and current Standard users get a free upgrade to Pro in 1.9.x?

- We have decided to combine the Enterprise features into Pro for 2.0 with the one Enterprise feature 4:2:2 being added for the initial 2.0 release and 4:4:4 to be added in a later 2.x release.
So Pro and enterprise will be combined for 2.0. Awesome, I was hoping for this. What will 2.0 be named? will it stay as "CoreAVC Professional Edition" or will it be a more generic "CoreAVC Video Decoder"? to reflect that there are no more seperate "editions"?

benwaggoner

3rd July 2009, 19:36

[Drifting slightly off topic] If someone form microsoft is following this thread. Why don't you add this tool/ this functionality to windows. I think CLSID has already shown that the program doesn't have to be difficult. And being able to select your favourite decoders should be standard functionality on a OS.
[/Drifting slightly off topic]
In general, any time you put in any kind of control, 20% of users who find it will set it to something wrong :).

This is why there's PowerToys and such, so that only users who know what they're doing enough to find the tool try to use it.

Plus, anything in Windows is supported as a Windows component, so we have to balance the utility for the advanced user versus complexity for the broader market.

halsboss

4th July 2009, 07:28

Should market a windows-for-the-masses vs a windows-complex-for-people-willing-to-take-the-risk-and-not-call-support.

3ngel

4th July 2009, 13:02

I just want to add that CoreAVC permits me to view smooth 720p on EEPC Atom N270.

So thanks :)

saint-francis

4th July 2009, 15:43

I just want to add that CoreAVC permits me to view smooth 720p on EEPC Atom N270.

So thanks :)

Is that with CUDA or CPU? Can you give some more details about the file/s you are playing? Including Audio streams and player. This is very interesting.

Thanks

clsid

4th July 2009, 18:17

With the Cyberlink PowerDVD filter you can smoothly decode 1080p on netbooks with an Atom CPU and Intel GMA500 chipset.

BetaBoy

4th July 2009, 18:56

... and I can play 480p fine with CoreAVC on my 600mhz P3. lol..... ok... nuff of that guys ;-)

benwaggoner

4th July 2009, 23:41

Should market a windows-for-the-masses vs a windows-complex-for-people-willing-to-take-the-risk-and-not-call-support.
Yes, there are plenty of features like that. They have a unified GUI called regedit :).

This seems to me like a fine place for a 3rd party to provider their own tweaking tool.

Snowknight26

5th July 2009, 00:48

Or better yet, a thorough list of all, if not most, registry entries, valid values, and what they do, published by Microsoft. Everyone would benefit that way.

clsid

5th July 2009, 12:35

Yes, there are plenty of features like that. They have a unified GUI called regedit :).

This seems to me like a fine place for a 3rd party to provider their own tweaking tool.
Question is, will it be possible to configure the preferred DirectShow/DMO/MF filters in the Registry in Windows 7 RTM?

Your statement also contradicts other statements by MS engineers. Isn't the reason why the registry keys are protected because MS doesn't want tweak tools to change those settings?

Now some people are resorting to renaming MF files, which imo is a very bad way to 'tweak' playback.

lych_necross

6th July 2009, 06:57

Forgive my ignorance, but isn't it still possible to set CoreAVC as a preferred filter within MPC running on Win7?

benwaggoner

6th July 2009, 07:42

Question is, will it be possible to configure the preferred DirectShow/DMO/MF filters in the Registry in Windows 7 RTM?
The official mechanism is for a 3rd party app to generate their own filter graph.

I think some people may have found a way to do it in the registry as well, but I'm not sure if that's officially supported as well.

Your statement also contradicts other statements by MS engineers. Isn't the reason why the registry keys are protected because MS doesn't want tweak tools to change those settings?
If an actual engineer who actually works on Windows told you something different than what I have, believe them :). I'm just a compression nerd working on Silverlight, and we don't use the low-level systems like that.

Now some people are resorting to renaming MF files, which imo is a very bad way to 'tweak' playback.
That does sound fragile.

halsboss

6th July 2009, 11:36

OK, thanks, hope the registry tweak becomes well known and "supported" then ... it'd be good if MS let us readily do what we wanted to do with our own PC :) Xp still rules :D And now I've got ubuntu dual booting to start to learn it...

alajaly2009

9th July 2009, 05:59

I am first time working with JSVM, anyone could help on how to run and implementing some testing results. I have downloded the last version, I just need how to do some tests.
with best regards,
alajaly

DanielSun

11th July 2009, 10:47

What is the limitation of CoreAVC CUDA decode?
As far as I known, the only limitation is no more than 16 reference frames.
Are there any other limitations like resolution or bitrate or profile?
Can CUDA decode unrestricted profile streams with unlimit resolution as long as the ref<16?

Can anyone clear this up for me?

Cyber-Mav

12th July 2009, 01:27

cuda supports level 5.1 thats for sure.

popper

12th July 2009, 10:00

cuda supports level 5.1 thats for sure.

but OC YOU really need to understand that just because you can use UPTO ref=15 and UPTO level 5.1 does'nt mean you should, on everything, that really niggles me when upto ref=3 and upto level4.1 are perfectly suited to most HD playback today.

Cyber-Mav

13th July 2009, 12:54

i use level 5.0 and 9 reference frames for all my hd stuff. only drawback is that the 2 ati cards i have wont provide acceleration on video greater than level 4.1. but that problem wont be around for long when i replace those ati cards with nvidia ones.

Sharktooth

13th July 2009, 14:52

do you REALIZE 9 refs are useless? do you realize level 5.0 and 5.1 are overkill even for HD stuff (blu-rays are L4.1).
do you realize 3 refs and 3 b-frames are the new x264 defaults? ...

buzzqw

13th July 2009, 15:06

do you realize that everyone can use the parameters wanted ?

it's a free world, afaik, even if parameters are obviusly overkill

BHH

STaRGaZeR

1st August 2009, 02:27

Betaboy, do you have any info about Haali's splitter new features (if any)? Like support for playing True-HD audio from Matroska.

BetaBoy

1st August 2009, 04:54

Revgen

1st August 2009, 05:47

Also STaRGaZeR when you say True-HD, what do 'you' mean?

http://img338.imageshack.us/img338/4249/truehd.th.jpg (http://img338.imageshack.us/i/truehd.jpg/)

Octo-puss

1st August 2009, 08:43

clsid

1st August 2009, 12:25

Haali and I have talked about the next release after Win7 goes RTM and yes we know its out but not in our hands yet officially. He is also thinking about removing the thumbnails support as its the biggest cause for issues we have. Also STaRGaZeR when you say True-HD, what do 'you' mean?
When are you getting it? August 6th?

Tip: you can install and use Windows 7 for 30 days without the need to activate it. (120 days with re-arm tricks)
Tip 2: it has native support for installing to a virtual harddrive (VHD), so no need to use a dedicated partition for installing 7.

STaRGaZeR

1st August 2009, 13:50

Haali and I have talked about the next release after Win7 goes RTM and yes we know its out but not in our hands yet officially. He is also thinking about removing the thumbnails support as its the biggest cause for issues we have. Also STaRGaZeR when you say True-HD, what do 'you' mean?

This :)

http://img338.imageshack.us/img338/4249/truehd.th.jpg (http://img338.imageshack.us/i/truehd.jpg/)

mkvmerge added support for True-HD tracks but the splitters have to be actualized too. Gabest splitter already supports it, the change to the code was minimal, but with Haali's True-HD tracks are not even listed.

BetaBoy

1st August 2009, 15:59

http://img338.imageshack.us/img338/4249/truehd.th.jpg (http://img338.imageshack.us/i/truehd.jpg/)
Revgen... sure, but I wanted him to clarify that was what he was referring too.

STaRGaZeR

1st August 2009, 18:22

Revgen... sure, but I wanted him to clarify that was what he was referring too.

So what about the initial question?

halsboss

4th August 2009, 10:42

A family member downloaded a .m4v episode from iTunes on a PC which is a bit old/slow. She asked to put it onto DVD to watch on the TV instead. Sure, I said, we paid for it. Used iTunes to export it to a data DVD and then tried to open it on a faster computer with MPC and WMP before running avisynth over it, but haali gives up with "MP4: no supported tracks found." Any ideas ?

STaRGaZeR

5th August 2009, 16:09

So what about the initial question?

... :rolleyes:

BetaBoy

5th August 2009, 16:49

I have asked Haali to comment on it.

BetaBoy

7th August 2009, 15:37

Ok... spoke to Haali... he is looking into True HD.

buzzqw

7th August 2009, 16:54

STaRGaZeR

7th August 2009, 18:26

Ok... spoke to Haali... he is looking into True HD.

Thanks ;) Next time at least say something, you give the wrong impression.

BetaBoy

7th August 2009, 18:39

Well... I thought Haali was gonna jump into this thread... but he is busy these days.

thewebchat

7th August 2009, 19:00

sorry for the dumb question

i have a 9400mGPU motherboard ( Gigabyte GA-E7AUM-DS2H ), with integrated Nvidia 9400m graphic
afaik the integrated graphic card has 16 stream processors

the question: if i watch dvxa ready mkv/h264 with MPC-HC , the CPU just sit idle because the GPU is doing hw decoding

if i install coreavc, what benefit i will have when watching these kind of files ?

thanks!

BHH

The CUDA interface to PureVideo (note: CoreAVC CUDA does not by itself decode anything. Same with neuron2's "CUDA decoders.") will let you retrieve the decoded frames and then run arbitrary filters on them (e.g. ffdshow post-processing, DirectVobSub). The software decoder in CoreAVC is actually faster than PureVideo on higher-end CPUs, so if you need a video dumped to uncompressed YUV, CoreAVC may also be useful there.

Revgen

9th August 2009, 13:39

I really don't understand why people are so crazy over Dolby TrueHD support. Both FLAC and DolbyHD or MLP are lossless formats. The FLAC file encoded by EAC3to from my Batman Begins HD-DVD is actually smaller than the Dolby TrueHD track. The only real advantage to having Dolby TrueHD is that there is meta information implanted in the stream that instructs Dolby TrueHD decoders on how to downmix using the dynamic range settings provided by the DVD producer.

Shakey_Jake33

9th August 2009, 13:55

I suppose people want to play their own encoded content without having to reencode the audio track to FLAC. It adds to the feature set at any rate.

DigitalDeviant

9th August 2009, 14:08

kieranrk

9th August 2009, 14:17

I use CoreAVC for AVC encoded Blu-ray discs. I certainly shouldn't need to rip my discs or reencode anything so I can have proper audio playback.

What's wrong with mpc-hc's internal ts splitter in this instance?

Audionut

9th August 2009, 14:17

@Revgen,

I agree to a certain extent. But how many home theatre receivers support flac!!

honai

9th August 2009, 14:58

Well, you can't pass-thru True HD streams in any non-PowerDVD/non-ArcSoft/non-WinDVD player, either, so having True HD in Matroska is only useful in a sense that you can decode it during playback to ... PCM! Which is the same you'd to with FLAC.

So why not store it as FLAC in the first place?

pankov

9th August 2009, 15:10

Guys,
there is a very simple answer to the question "why we need proper support in Haali's splitter":
Not everyone (if not most users) don't user mpc-hc and that means that we have to resort to Haali to do the splitting of BD disk stored to HDD and played as simple .m2ts files.
Yes, I know there is no (excluding Xonar) hardware to stream through the DD TrueHD track but it could be decoded to PCM and played this way WITHOUT the need to reencode the audio.

clsid

9th August 2009, 15:51

Will the following issue also be addressed in next version of Haali Media Splitter?

http://lists.matroska.org/pipermail/matroska-devel/2009-August/003533.html

Jeff Flowerday

9th August 2009, 16:01

@Revgen,

I agree to a certain extent. But how many home theatre receivers support flac!!

Flac isn't sent to the receiver it's decoded to LPCM. The beauty of it is that it's not down converted at all by madshi's madflac deocder. If using WASAPI mode, you get bit perfect audio.

There is only one other way to get bit perfect audio from BR/HDDVDs on a HTPC and it requires a particular piece of hardware and software.

Nick [D]vB

9th August 2009, 16:06

Isn't FFdshow tryout + Reclock WASAPI/kernel-mode still "bit perfect" TrueHD?

(HTPC with any 1/2 decent soundcard's analogue outputs)

BetaBoy

10th August 2009, 03:15

Will the following issue also be addressed in next version of Haali Media Splitter?

http://lists.matroska.org/pipermail/matroska-devel/2009-August/003533.html

Its related to an old build of k-lite from what I'm hearing but have not confirmed.... but the reg change that colleen from Microsoft suggested will be done.

paulvdb

10th August 2009, 09:01

BBC HD just started using new encoders for their HD broadcasts that are causing problems with CoreAVC. Playing a recorded transportstream from the start works fine but as soon as I jump forward or backward in the stream I get blocks. This does not happen with DivX as the decoder. I can provide a sample if you need that to fix the problem.

Jeff Flowerday

10th August 2009, 14:46

vB;1312885']Isn't FFdshow tryout + Reclock WASAPI/kernel-mode still "bit perfect" TrueHD?

(HTPC with any 1/2 decent soundcard's analogue outputs)

Sorry, I was talking digital to the amp. Of course analog would be another solution. A little more cluttered with cables but another solution for sure.

BetaBoy

10th August 2009, 15:43

Nick [D]vB

10th August 2009, 16:47

I didn’t realise the BBC had switched to new encoders, maybe that explains why the bit-rate has dropped through the floor (<10Mbps!) I remember when the HD trial first started they were using 20Mbps+ Seems like only yesterday I was begging (http://forum.doom9.org/showthread.php?p=827264#post827264) Betaboy to get MBAFF support working before the 2006 world cup finished lol

Here is a sample: http://www.megaupload.com/?d=JXP3C6ML

I also included a sample from ITVHD, they have just started tests for simulticasting an upscaled version of ITV1 but I can’t get it decoding smoothly with any H.264 decoders, maybe there is a problem with their upscaler / encoder ??? They are using some weird H.222 TS encapsulation system but the demuxed HD streams normally play ok with everything.

PS – Betaboy you probably won’t remember this but you gave me a CoreAVC pro licence for helping to test the beta, for some reason it has reverted back to a stranded licence, can you take a look at that for me when you get a sec??? 8 )

Tack

10th August 2009, 16:49

Well, you can't pass-thru True HD streams in any non-PowerDVD/non-ArcSoft/non-WinDVD player, either
Yet. It's just a matter of time before other players like MPlayer support TrueHD passthrough.

OTOH, you need HDMI to passthrough TrueHD, and if you have that, you can also do 7.1 channel PCM. And since flac gives you better compression than TrueHD (at least in my experience), you might as well mux that into your mkvs.

bob0r

10th August 2009, 17:35

A sample of the stream would be great... thx.

Reading IRC would be nice also.
But here goes:
08-08_01-29-47_BBC_HD_(AC3,eng)_Michael_McIntyres_Comedy_Roadshow.ts (http://x264.nl/h.264.samples/force.php?file=./aug.2009/08-08_01-29-47_BBC_HD_(AC3,eng)_Michael_McIntyres_Comedy_Roadshow.ts)

paulvdb

10th August 2009, 18:03

A sample of the stream would be great... thx.
I see that some other people already provided BBC HD samples so I guess you won't need one from me.

Nick [D]vB

10th August 2009, 18:12

I've got the upscaled ITVHD stream working ok now, must have been a problem with DVBViewer after all.

Have you had a look at it yet Paul? They are still showing upscaled ITV1, lets hope it stays that way...

It's not bad but 4HD's upscaled stream looks much better (fewer jaggies etc)

but I think that's in 1920x1080, and I get it through Virgin cable so it's still in MPEG2!

Shark007

16th August 2009, 18:39

clsid

16th August 2009, 20:17

It is a crash in HMS due to a bug in HMS.

You should know that trolling is against the forum rules.

hajj_3

30th August 2009, 10:22

hope a 64bit version of CoreAVC comes soon as MPC-HC 64bit version was just released:)

ajp_anton

30th August 2009, 13:24

hope a 64bit version of CoreAVC comes soon as MPC-HC 64bit version was just released:)Really? I thought I'd been using the 64-bit MPC-HC for almost 14 months...

BetaBoy

30th August 2009, 14:13

CoreAVC 2.0 will be out in the fall and yes 64 bit is included. Guys try and keep it OT.

Snowknight26

30th August 2009, 19:24

Will that include a new version of Haali's splitter?

popper

30th August 2009, 20:33

Will the following issue also be addressed in next version of Haali Media Splitter?

http://lists.matroska.org/pipermail/matroska-devel/2009-August/003533.html

the Most supriseing thing to me after looking at that linked ML is that given Haali Media Splitter is supposed to be used a lot , theres Very few postings on that mailing list, implying theres very little progress or new additions taking place in the codebase and thats a shame.

its also interesting that Colleen Williams (Smart Marketing & Events) MS says
"our end goal is to have a positive end user experience with Windows "

but they cant be bothered to actually put an mkv container ability in their MS xbox360, or even follow the DNLA spec with the "send to" DNLA stuff thats supposed to be in the MS windows 7 but not in the latest 360's firmware.

so nothing like a positive Experience with that MS to MS 360 product combination,
but you can get a reasonable "positive Experience" with an MS to Sony Bravia KDL-46W5500E DNLA HDTV and several others, And to a Sony PS3, how crazy is that, its not 'Smart Marketing' or a good turn of 'Events' thats for sure.

perhaps somone on that list or in contact with her can pass the mkv and 360 firmware DNLA requests on, and get something sorted, then CoreAVC used with PMS might be far more effective with direct DNLA streaming mkv playback on the 360 as a DNLA device one day instead of the very limiting mp4 options people need to use there today.

STaRGaZeR

30th August 2009, 21:22

the Most supriseing thing to me after looking at that linked ML is that given Haali Media Splitter is supposed to be used a lot , theres Very few postings on that mailing list, implying theres very little progress or new additions taking place in the codebase and thats a shame.

That's what you have when the source code of great tools is not available: Haali's splitter and madshi's programs come to my mind. When the author fails we're doomed. madshi is busy with RL affairs and we don't really know the situation with Haali, but should be similar. A shame indeed. If the author is not going to work on it and a lot of people are "dependant" of his work, the best option is to open-source it so at least someone could continue with the project. I guess you can't comment on this BetaBoy?

BetaBoy

30th August 2009, 21:59

popper

31st August 2009, 00:45

vB;1313212']I've got the upscaled ITVHD stream working ok now, must have been a problem with DVBViewer after all.

Have you had a look at it yet Paul? They are still showing upscaled ITV1, lets hope it stays that way...

It's not bad but 4HD's upscaled stream looks much better (fewer jaggies etc)

but I think that's in 1920x1080, and I get it through Virgin cable so it's still in MPEG2!

hi Nick , not seen you for ages, and i cant even remember were those BBC DVB-T MBAFF and tools to use/edit threads took place now.

virgins headend Mpeg2 re-encode of the HD feed always was pritty bad (VM spokesperson: "We Use Mpeg2 Because we can." LOL, because you dont actually have an AVC/H.264 capable STB installed in peoples cable homes through bad long term planning more like),
but im wondering now with the large drop in bitrate reported here weather thats going to be problems with the below DVB-T2 coming online or more likely it dropped because of it.

regarding the change over of the BBC Encoders i cant see anything on the BBC blogs pages about it currently!.

but there is a potential mass of users about to get the DVB-T2 HD feeds soon.

i wonder if this Encoder change is anything to do with the Massive BBC winterhill NW area broadcast coverage towers coming on line soon for the start of the DVB-T2 HD transmissions role out as mentioned by Graham Plumb, the Head of Distribution Technology, BBC Operations Group.

"17:00 UK time, Wednesday, 24 June 2009
[The Editor: In our recent open post we had several questions about the roll-out of Freeview HD. This is the first post on the blog from Graham Plumb, Head of Distribution Technology, BBC Operations Group.]

The plan is still to launch Freeview HD on December 2nd at the Winter Hill transmitter serving Manchester and Liverpool. The plan has always been to roll Freeview HD out around the country following switchover and Winter Hill was selected as the first achievable transmitter. There will need to be a retrospective upgrade of regions that have already switched.

The originally mentioned date of November came from the fact that Winter Hill starts to switch over in November. But it was quickly realised that the BBC's second Multiplex (Mux B) that is being converted for Freeview HD actually switches over on 2nd December at Winter Hill.

The March 2010 date in the Ofcom document is simply the last backstop date by when Winter Hill has to be on air to comply with our licence conditions. They've built in a contingency (as already happens in switchover licences).

The BBC has been working on plans to deliver early upgrades to some stations (serving high populations) that are late in the switchover programme and would otherwise have to wait long for Freeview HD.
..."

its seems like betaBoy and core might have some more mass of interest in decoding this when the Freeview DVB-T2 HD on December 2nd 2009 at the Winter Hill transmitter serving Manchester and Liverpool and pritty much the whole NW as the second most powerful transmitter in the UK comes online for mainstream DVB-T2 HD transmission Finally.

im assuming there may be a few problems to, that need sorting out sooner rather than later, but at least DVB-T2 HD is finally getting out, will coreAVC and the 3rd party DVB-T Transport stream and MBAFF editing apps be ready...

kieranrk

31st August 2009, 00:48

In fact we'll be using DVB-T2, and it's pretty unlikely that PC equipment will be available for a while after channel launch.

popper

31st August 2009, 02:38

thanks for the reminder kieranrk, im usually good at remembering that, but its been a while since i revisited DVB-*2 and i forgot...

halsboss

31st August 2009, 09:56

CoreAVC 2.0 will be out in the fall
Um, whats "the fall" ?

popper

31st August 2009, 10:04

Um, whats "the fall" ?

its not when your walking down the road, then suddenly slip and fall on that winter ice, but rather the Autumn when the trees leaves turn brown and drop to the ground, and football starts to get interesting again , or the 3rd finantial quarter if you prefer, he's refering to :devil:

J_Darnley

31st August 2009, 10:04

Autumn. It is what Americans call the season between summer and winter.

Mixer73

31st August 2009, 10:36

Autumn. It is what Americans call the season between summer and winter.

Would be good if people could use Q1/Q2 or something like that, as the rest of the world has no idea about the US seasons.

popper

31st August 2009, 10:50

OC this "fall" starts tomorrow, as the first day of Autumn, looks out the window, yep , the trees leaves are starting to turn brown...

http://www.woodlands-junior.kent.sch.uk/customs/questions/weather/seasons.htm
http://www.woodlands-junior.kent.sch.uk/customs/year/leaves.jpg

halsboss

31st August 2009, 12:48

its not when your walking down the road, then suddenly slip and fall on that winter ice, but rather the Autumn when the trees leaves turn brown and drop to the ground, and football starts to get interesting again , or the 3rd finantial quarter if you prefer, he's refering to :devil:

Nice pic.

We only fall down when the kangaroos bounding at full pelt knock us over, or an opposition footy player tackes us. Ice is what you get from fridges and put in an eski to keep the beer cold.

Still no the wiser when your autumn is. Hang on, other side of the world and someone said tomorrow so I suppose its 1st September which is our 1st day of spring.

Re Q1 Q2 etc, it depends on your definition too, some go by calendar year and some by tax year. Our tax year is 1st July-30 June; I think our xmas is the same as yours.

STaRGaZeR

31st August 2009, 13:02

Haali and I have talked about open sourcing the filter several times, although not in the past year or so. I'll ping him on it so maybe we can do what we do for Matroska under a dual license (LGPL/BSD) as that seems to make the most sense. But there is some pretty cool code in their that Haali might not want to let go off (easily).... I'll give it a shot and ask him again.

Cool ;)

If he's going to work on it, fix bugs, etc. open-sourcing it is unnecessary. But you know better than us how the situation has been in the past years...

clsid

31st August 2009, 14:19

Is there a preliminary changelog (or roadmap) for CoreAVC 2.0 and HMS x.x? That would give us a nice idea of what improvements we can expect sometime between now and December 21st.

lych_necross

1st September 2009, 07:11

What happened to this thread? Lately, most of the posts seem to be OT. Lets stay on track people. :readrule:

BetaBoy

17th September 2009, 15:00

We are continuing to work on CoreAVC 2.0... in fact I could post a long changelog, but will hold off for now as we are still doing more. The latest of which is the recent changes to the new CUDA SDK. Our goal remains the same, to get it out around the time that Windows 7 is released.

buzzqw

17th September 2009, 15:10

i like to have bought a license :)

BHH

Skandy

17th September 2009, 15:42

i like to have bought a license :)

BHH

Yeah! Me too :)

Hope the upgrade will be free for thos who have bought a 1.9.5 license..

Cyber-Mav

17th September 2009, 17:44

i wonder if coreavc 2.0 will be as fast as or faster than divx h264 decoder.

BetaBoy

17th September 2009, 18:44

i wonder if coreavc 2.0 will be as fast as or faster than divx h264 decoder.

Let's define 'fast' as CoreAVC 1.9.5 is still faster then the DivX decoder on most CPU's. However in every test we have done with 2.0 here, there is no doubt it 'is' faster on all CPU's. But, I'll leave that for you all to tell us when we release it.

buzzqw

17th September 2009, 18:57

@BetaBoy

any comment about

Yeah! Me too :)

Hope the upgrade will be free for thos who have bought a 1.9.5 license..

?

BHH

BetaBoy

17th September 2009, 22:19

@BetaBoy

any comment about

?

BHH

I commented a few pages back.

Snowknight26

18th September 2009, 05:25

BetaBoy, would you be so sweet as to coax Haali into helping me debug a really pesky issue (http://forum.doom9.org/showthread.php?p=1321778#post1321778)? Started happening on my desktop too so that's pretty much put my encoding to a halt. Can't test CoreAVC anymore. D:

ranpha

20th September 2009, 13:48

A couple of questions:-

The upcoming CoreAVC 2.0 decoder, will it be supported under Windows XP?

Can potential buyers be able to pre-order it? Kinda like Windows 7 is? Maybe those who have pre-ordered can have access to a CTP build or something? :)

honai

23rd September 2009, 23:35

BetaBoy

24th September 2009, 00:43

How did this turn out to be? Really an issue with Haali Splitter? And if yes, will this be fixed in time for the next release?

http://lists.matroska.org/pipermail/matroska-devel/2009-August/003533.html

This was reported in this thread a while ago... and the bug is unrelated to the splitter. Read the report closely.

Merkie

26th September 2009, 01:41

I'm having issues with CoreAVC (I think) & Windows 7. It works fine, even with CUDA enabled, but after an hour sometimes the framerate drops to about 10fps, it's like watching a slideshow. Things like pausing/unpausing and closing some Windows often help to retrieve smooth playback. I can't give any more details because it's hard to reproduce the problem. However, it's still annoying as hell because everytime I have to get up and walk to my computer to fix the framerate. CPU usage is practically zero when this issue occurs.

So I have two questions:
1. Is this issue known to any of you? Is it even CoreAVC/CUDA related?
2. If not, what should I do when the issue re-occurs? What kind of information should I gather that would be useful to you?

Software used: MPC 6.4.9.1 + AC3Filter + CoreAVC 1.9.5 (CUDA enabeld) + Haali MKV splitter (and Haali renderer enabled).

DeathWolf

26th September 2009, 01:53

That issue looks like your gpu is overheating/switching to a lower energy consumption mode.
Have you checked the temperature curve?

Merkie

26th September 2009, 02:33

I just noticed I had CUDA disabled (probably did that earlier in an attempt to resolve the issue), so I doubt the GPU is overheating. Also, CPU temperature is the same as always.

pankov

27th September 2009, 18:36

HI
I've been using CoreAVC since it's first version and was pretty pleased with it's performance and quality. Recently I noticed that I have problems with the Hardware Deinterlacing when used with VMR9 or EVR. I thought the problem was either with my hardware or windows installation since it was more than 3 years old XP Professional. Recently I did reinstall my XP (SP3) with all updates and most recent drivers and DirectX and .NET 3.5 and sadly the problem is still there.
With EVR I don't get any deinteralacing ... which I suppose is normal since I use it in WinXP ... can somebody confirm/deny this?
With VMR9 it seams like there is problem with the field order - I don't see any jaggies but there is no fluid motion but total jerkiness.
With Overlay Mixer or Halli everything is butter smooth.
On this PC I use Gigabyte P35 mobo + Intel Quad Q9400 + ATI 4670.
To isolate the hardware as the source of the problem I build a totally different PC with NVidia GF9400 chipset and I decided to put Windows 7 on it.
The problem is still there and sadly in Win7 Overlay Mixer doesn't work (which I think I read somewhere that is normal) so I'm very frustrated now.

What can I do to get smooth playback of interlaced H264 content (50Hz 1080i - EurosportHD / BBC HD)?
What do you guys/gals use?

If needed I can provide samples but I doubt the files are the problem.