CoreCodec/H.264 Codec "CoreAVC"

[ranpha]

BetaBoy says a lot of things that aren't true. Like there will be releases in a few weeks, or "it's in QC now". I don't believe a word that guy says on any forums.

So does that mean the v2.5 will not be free? Do you have any proof of that?

[Octo-puss]

Do you have any proof that this project still exists? :D

[ranpha]

Do you have any proof that this project still exists? :D

If you refers to v2.5, actually yes of course :)

[madshi]

Giving out reliable release dates is a major problem for any developer. Just because BetaBoy's release date estimations have proven to be wrong doesn't mean anything. I've given out release estimates and totally was not able to keep them often enough myself. That's just how it is with software development sometimes.

It was rather clear to me right from the start that 2.5 would be a free update. Otherwise they would have opted to name it 3.0. BetaBoy's forum post confirms it. So it's pretty much a sealed deal. Anybody who still thinks 2.5 will cost money for 2.0 users is seriously paranoid, IMHO.

[yesgrey]

Yes. With a discount, though.
I have to retract myself.

I said this based on the link for shopping it that came with the e-mail they sent me (the one posted by madshi). Now I've realized that the link was for buying the v2.0.0 with a discount due to CES2001, and not for buying the v2.5.

I am very sorry for the confusion.

[ChronoCross]

So does that mean the v2.5 will not be free? Do you have any proof of that?

You don't have any actual proof that it will be free or will even be released at all.

If you refers to v2.5, actually yes of course :)

You don't have any actual proof it exists aside from a PR release. There are a lot of products from 2011 CES that will never see the light of day. Supposedly 2.1 and 2.2 were ready for release but they disappeared as well. There is nothing to say that they won't just re-number it again to 3.0 due to "new and exciting features"

Giving out reliable release dates is a major problem for any developer. Just because BetaBoy's release date estimations have proven to be wrong doesn't mean anything. I've given out release estimates and totally was not able to keep them often enough myself. That's just how it is with software development sometimes.

It was rather clear to me right from the start that 2.5 would be a free update. Otherwise they would have opted to name it 3.0. BetaBoy's forum post confirms it. So it's pretty much a sealed deal. Anybody who still thinks 2.5 will cost money for 2.0 users is seriously paranoid, IMHO.

Not really. It's not particularly hard to determine a development schedule. Besides okay lets say there are delays.....this product isn't large enough or complex enough to justify the amount of time that has passed since "it's in QC now".

[madshi]

Well, ChronoCross, I think you're paranoid. And I think most others agree right now that 2.5 is going to be free a free upgrade for 2.0 customers.

How about a bet: If the upgrade to 2.5 costs money, I'll pay the upgrade for you. If not, you will pay the next payable upgrade (probably 3.0) for me. Agreed?

[ajp_anton]

Well, ChronoCross, I think you're paranoid. And I think most others agree right now that 2.5 is going to be free a free upgrade for 2.0 customers.

How about a bet: If the upgrade to 2.5 costs money, I'll pay the upgrade for you. If not, you will pay the next payable upgrade (probably 3.0) for me. Agreed?You should clarify that you mean the actual 2.5 release and not what was going to be 2.5 but was renamed to 3.0.

[madshi]

Did I miss something? Was 2.5 renamed to 3.0?

[ChronoCross]

Well, ChronoCross, I think you're paranoid. And I think most others agree right now that 2.5 is going to be free a free upgrade for 2.0 customers.

How about a bet: If the upgrade to 2.5 costs money, I'll pay the upgrade for you. If not, you will pay the next payable upgrade (probably 3.0) for me. Agreed?

No. I've stated previously I will never buy any CoreCodec product ever again; that includes other people's licenses.

You should clarify that you mean the actual 2.5 release and not what was going to be 2.5 but was renamed to 3.0.

Correct. I guess I could say overall the next released version of CoreAVC will probably cost money or it will never be released because it will get stuck in QC or redesign

Did I miss something? Was 2.5 renamed to 3.0?

Not yet but soon.

[madshi]

ChronoCross, I'm wondering what you're doing in this thread, if you'll "never buy any CoreCodec product ever again", anyway? What is your motivation of posting here? Just trying to spread fear and doubt?

[ajp_anton]

Did I miss something? Was 2.5 renamed to 3.0?No, but from reading other people's posts here it doesn't seem that unlikely that it will.

[ChronoCross]

ChronoCross, I'm wondering what you're doing in this thread, if you'll "never buy any CoreCodec product ever again", anyway? What is your motivation of posting here? Just trying to spread fear and doubt?

To keep people informed about how they treat their customer base. I've been around them since the early alpha's and have a followed this thread and posted as such with my opinion varying over time.

Lets just say I started out as an optimist just like some of you are now but time has frayed that into being realistic about both their product and their promises.

[madshi]

To keep people informed about how they treat their customer base. I've been around them since the early alpha's and have a followed this thread and posted as such with my opinion varying over time.

Lets just say I started out as an optimist just like some of you are now but time has frayed that into being realistic about both their product and their promises.
Okay, how about a deal: If they rename 2.5 to 3.0 and ask for money, then I'll join your pessimistic view. If they do release 2.5 without asking for money, you stop posting in this thread. Sounds fair? :)

[ChronoCross]

Okay, how about a deal: If they rename 2.5 to 3.0 and ask for money, then I'll join your pessimistic view. If they do release 2.5 without asking for money, you stop posting in this thread. Sounds fair? :)

No :thanks:

[Mixer73]

No :thanks:

Translation: I'd rather keep whining.

Didn't your mother tell you if you haven't got anything nice to say, say nothing?

Should be a forum rule, IMO. You're not adding anything here, it seems in fact you have no reason at all to post in the thread.

[madshi]

IMHO ChronoCross' posts are nothing but FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt) and should be ignored.

[G_M_C]

I to like to see an update to CC. But to be honest, these days CC isn't really needed anymore. Modern CPU's have power enough, the time that CC was needed because of its efficiency is past us. And since that was the biggest argument for people to get CC, i think CC has to go rethink their strategy.

Another argument was that CC was more tolerant to streams with non-standard parameters, and thus decoded more streams then another decoder. These days more end more decodes appear, that can also decode such streams. But i still have a stream that causes blocking on most decoders, and CC decodes it fine. So thats my reason to hope to see an update sometime.

All in all; H264 decoding can be done fine, there are plenty decoder that do the job good to very good. Many of them open source or free. I see no reason to whine like Chronocross.

I get his idea that any party should give customer service, but i refuse to accept his point of view that the customer service should last forever, or should target all-and-every wish any customer makes.

When you dont like the service the shop gives you when you buy a TV, or a BD-player, you go somewhere else (next time). The same goes for this; Plenty of alternatives, so go for the alternative, and be done with it.

[Disabled]

I was a became a "whiner" very early in this thread, and I can tell you, I seriously had to argue against ChronoCross.
Its good to see he finally realized how Core treats their customer.
With 1.x they didn't deliver the promised product for about 3 years, or IMO they never delivered, because 1.x still isn't a h264 high profile decoder which they advertised.
I still hope ChronoCross keeps informing Cores customers about their practices until the next batch of users is pissed at them and he can retire like I did.
I really liked CoreCodec until after they released 1.0 but I didn't see anything impressive since.

[ney2x]

I think Betaboy will reason out the released of Windows 7 Service Pack 1. Maybe he will tell us to wait more because CoreAVC 2.5 is not compatible with Windows 7 Service Pack 1. QC again, and again and again and again. Just my two cents!

[ChronoCross]

Translation: I'd rather keep whining.

Didn't your mother tell you if you haven't got anything nice to say, say nothing?

Should be a forum rule, IMO. You're not adding anything here, it seems in fact you have no reason at all to post in the thread.

My contributions to this thread are to warn possible customers to CoreCodec's tactic's. I have every right to post my opinions here, just like you have every right to post a rebuttal.

Besides having a rule that is entirely subjective to each person would mean no one can post ever because there might be one person who thinks your post are irrelevant regardless of whether they are or not.

IMHO ChronoCross' posts are nothing but FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt) and should be ignored.

lol. You mean your NSHO.

I was a became a "whiner" very early in this thread, and I can tell you, I seriously had to argue against ChronoCross.
Its good to see he finally realized how Core treats their customer.
With 1.x they didn't deliver the promised product for about 3 years, or IMO they never delivered, because 1.x still isn't a h264 high profile decoder which they advertised.
I still hope ChronoCross keeps informing Cores customers about their practices until the next batch of users is pissed at them and he can retire like I did.
I really liked CoreCodec until after they released 1.0 but I didn't see anything impressive since.

Agreed. They are very good at pretending that they are accomplishing a lot but it always ends in disappointment for their customers.

I used to a be a huge supporter but then they basically just took a dump on me after I had defended them on this forum for years. Seriously if any of you new people to this thread go back and read the entire thread you will see what we are talking about.

[Audionut]

They are very good at pretending that they are accomplishing a lot but it always ends in disappointment for their customers.

http://forum.doom9.org/showthread.php?p=1433805#post1433805


I think the posts saying anything from core is going to be released is more OT than ChronoCross posts.

[Forfront]

My contributions to this thread are to warn possible customers to CoreCodec's tactic's.
http://forum.doom9.org/showthread.php?p=1433805#post1433805

I think the posts saying anything from core is going to be released is more OT than ChronoCross posts.

U guys are right:eek:, I spoke up for the customers on coreAVC forum and got BANNED:(!!!

Is there no other group codec developers that have the vision to use GPGPU i.e. CUDA, AMD app &/or dxva2 for decoding with post-processing. Are they really the only ones, how could this have happened:confused:!?!?

[ChronoCross]

U guys are right:eek:, I spoke up for the customers on coreAVC forum and got BANNED:(!!!

Is there no other group codec developers that have the vision to use GPGPU i.e. CUDA, AMD app &/or dxva2 for decoding with post-processing. Are they really the only ones, how could this have happened:confused:!?!?

Lol what did you say? I see the thread but it seems Betaboy deleted whatever you posted.

[Forfront]

Lol what did you say?


BetaBoy lets be “real” here, how long to do u guys think u can just keep stringing ur customers along before someone starts asking hard questions & demanding answers?!?! Seriously I’ve been waiting for Radeon support for around three Years now ಠ_ಠ!!! I would have been content if u would simple said “u know what Forfront we don’t know when it’s going to be finished”

The above statement got me banned! I guess I better PM murdomac’ and explain what happened.

Does BetaBoy have the power to band me here too:(??

[ChronoCross]

The above statement got me banned! I guess I better PM murdomac’ and explain what happened.

Does BetaBoy have the power to band me here too:(??

Luckily he has no mod abilities here.

But yeah what you posted is pretty much the complaint of tons of their clients. Promises, promises, promises and then nothing. Asking for a release date will either get a non answer or an answer that ends up falling through.

I wouldn't worry too much about being banned on their "community" though. Just speak with your wallet and don't buy into their bullshit anymore.

[Forfront]

Luckily he has no mod abilities here.Haha’ that good to know!;)

The sad thing is that as of 2011 coreAVC still has no direct competition in terms of GPGPU that allows for post-processing/filter through ffdshow. From henceforth I will began trying to garnish support from other engineers to start moving in this direction, I would gladly pay for an alternative!.......

It’s time for Change!!!

[Sharktooth]

what are you talking about? ffdshow tryouts has GPU decoding and post-processing/filtering. VLC and MPC-HC (and its directshow decoders) too... on both nvidia and ati cards. some other brands are supported too.

[nm]

what are you talking about? ffdshow tryouts has GPU decoding and post-processing/filtering. VLC and MPC-HC (and its directshow decoders) too... on both nvidia and ati cards. some other brands are supported too.

He's talking about software filtering. IIRC, that was possible with ffdshow's DXVA2 implementation at some point of development, but wasn't it disabled because of problems with transferring the decoded video to main memory fast enough?

[hajj_3]

i joked months ago that when he said it would be out in a few weeks that it would probably be out by christmas, christmas went a long time ago now. It seems that DiAVC development has pretty much stopped as i think neuron and the creator are selling software to netflix or something. Wonder if a new version will be out in 2011.

[Sharktooth]

@nm: probably yes. but MPC-HC has filtering (denoising, deinterlacing, sharpening, chroma upsampling... etc.) thru shaders.

[Forfront]

He's talking about software filtering. IIRC, that was possible with ffdshow's DXVA2 implementation at some point of development, but wasn't it disabled because of problems with transferring the decoded video to main memory fast enough?Correct:)... but I’m particularly speaking of CUDA & AMD APP which will allow for faster copying to the main memory.
what are you talking about?Perhaps Professor Owens can explain this better than I: http://www.youtube.com/watch?v=LW2Q7fwz8hA

CoreAVC has already made this possible v2.0 with CUDA, it’s about using the GPU for video decoding which completely free's up CPU for post-processing i.e. ffdshow AviSynth - raw video - all supported. This gives the user nearly infinite possibilities in terms of what they can do with the raw video stream.
It seems that DiAVC development has pretty much stopped as i think neuron and the creator are selling software to netflix or something
Yes... if they are still developing DiAVC it would be a good prospect for the future;)...

[Sharktooth]

as i said, ffdshow and MPC-HC have GPU decoding. it doesnt work thru CUDA but DXVA. the result is the same.

[Virtual_ManPL]

Also DxVA is "better" because it's not limited to use only definite GPU memory.
In my case it can use all 256MB in DxVA mode and only 239MB in CUDA or OpenCL mode.
Some HD files with high ReFrames and bitrate can't be played properly in CUDA probably because of lacked memory.

[madshi]

I doubt it's a memory size problem. The problem is more likely that CUDA decodes to GPU RAM, but CoreAVC needs the frames to be in system RAM, so basically every decoded frame has to be copied from GPU RAM to system RAM, then later the video renderer will do the reverse (system RAM -> GPU RAM). With DXVA the frames are decoded to GPU RAM and stay there, which is better for performance, but it means you can't access/process the video data via CPU.

[Forfront]

as i said, ffdshow and MPC-HC have GPU decoding. it doesnt work thru CUDA but DXVA. the result is the same. ok then please explain to me how to use DXVA for decoding and ffdshow for flitering in unison??:)

[Virtual_ManPL]

I doubt it's a memory size problem

I strongly believe that it is a memory size problem, but I could be wrong.
Based on my tests when I use Firefox 4 with HW Acc, which also uses GPU memory, playing some HD files which I can play before is impossible. because memory is nearly all eaten by both player and Fx (based on NVIDIA Inspector 1.9.4.4)


ok then please explain to me how to use DXVA for decoding and ffdshow for flitering in unison??:)

Why would you use ffdshow ?
You can use Shaders in DxVA mode. Works the same.

[nm]

Why would you use ffdshow ?
You can use Shaders in DxVA mode. Works the same.

Not all software filters have equivalent shader implementations. And the output can only be used for playback purposes.

[Sharktooth]

common filters needed by the majority of users can be done in shaders. for example MPC-HC comes with denoising, deinterlacing, sharpening, PC<->TV colo-range conversion, bt.601 -> bt.709 conversion and others. plus there is a thread in the software player forums with new filters not yet included in MPC-HC.

[Forfront]

common filters needed by the majority of users.

Haha’ that child's play!!! u are way off target my friend, completely apple and oranges;).

[Sharktooth]

i dont care if this is coreavc thread. i've just given my opinion and as i said, there are other free decoders and apps that are able to use GPUs for decoding and filtering.
yes, it's only for playback but you didnt specify the context.

[Virtual_ManPL]

Exactly,
sharpen and color filters is all you should need for video in HD...

If it's not in HD, you can simply use software decoding with external postprocessing from ffdshow etc.

[Forfront]

i dont care if this is coreavc thread.Wow:eek: u must be angery to say that, if u don’t care, then I don’t care;) i've just given my opinionThe method I described on p.302 has nothing to do with MPC-HC specifically, it would work with any player that support external filteringand as i said, there are other free decoders and apps that are able to use GPUs for decoding and filtering.Name one decoder that supports openCL??yes, it's only for playback but you didnt specify the context.The context, it would take week for me to explain it to u:p. So let just say the purpose is hardware decoding of HD content (why? to take the load off the CPU) & software filtering with AviSynth (scriping for stream manipulation). I already stated this on the other page, I don’t see whats so hard to understand.

[Sharktooth]

i give up...

[STaRGaZeR]

i give up...

Thank god.

[Sharktooth]

those are the stupid posts that make me NOT WANT to give up. ok, mister "i know it all", now, explain what's the difference in using MPC-HC dxva, ffdshow dxva or coreavc for playback. filtering comes with the player with shaders...
from my point of view, free alternatives are much better than coreavc... since they're free and the result is the same.

[Astrophizz]

Forfront was just trolling :P
Wow:eek: u must be angery to say that, if u don’t care, then I don’t care;)
Translates to: "u mad?" at which point it's best to just ignore anything he says.

[Forfront]

@Sharktooth seriously Astrophizz is right, its time just drop all of this! Obviously u don’t use coreAVC 2.0 with CUDA so there noway u could understand my comments.
__________________________________

Just to get things back OT.
Considering that it’s now Feb. and there’s still no news from the guys over at coreAVC about a release, I wonder if it’s because they weren’t able to get the decoded frames copied back into the main memory fast enough through DXVA API. If that's correct, then I think they may skip the v2.5 release, and focus there attention on openCL for ATI users. That would be a major enhancement, v3.0 worthy:D...

[STaRGaZeR]

me NOT WANT to give up

I knew it was too good to be true :(

[Sharktooth]

@Forefront: as if USING means understanding... coreavc is using the decoder on the videocard. it just does it thru cuda that is slower than directly using it thru DXVA. so, what is your point? it's not a full h.264 decoder implemented in CUDA. it's not even possible... again, what's your point?
if you're trying to be a troll, then you made it.

[LigH]

Confusing CUDA with PureVideo again?

[Sharktooth]

LigH? coreavc uses CUDA to access purevideo decoding...
you can do that on ati cards with opencl... UVD is now exposed.

[LigH]

I mean: There is a difference between "using a hardware decoder" and "running a CUDA program as decoder".

PureVideo is a hardware decoder. No complex CUDA program is executed to decode the video stream "macroblock by macroblock".

[Mixer73]

from my point of view, free alternatives are much better than coreavc... since they're free and the result is the same.

Sharktooth, with all due respect I disagree. CoreAVC is an elegant product that is much easier to install and use than the free options.

With Windows 7 however I don't see the need for it at all but for me CoreAVC is a worthy component of a XP or Vista media playback box.

CoreAVC doesn't have to use CUDA, its still a very efficient software decoder. With CUDA though I do not see the performance hit you are claiming.

Personally I don't think FFDShow compares, FFDShow can be very capable but its also often quite broken, and is immeasurably more difficult to set up properly.

[Sharktooth]

that's partially true. you need a decent player and also coreavc comes with no filtering.
mpc-hc is as easy as coreavc to install. it doesnt need external decoders and has filters.
another option is VLC, still single easy installation and it has DXVA support too but no filtering (using DXVA).

[Forfront]

@Sharktooth: Here it is the “proof”;) a complete guide with Big pictures & Bold print, anyone can understand it!:D

http://imouto.my/watching-h264-videos-using-compute-unified-device-architecture-cuda/

Now read over my past statements and u will see everything make sense! Anyway I hop someone finds this helpful.:)

[Sharktooth]

CUDA is not MAGIC. there is NO decoders made using CUDA. CUDA is just a compiler for programming shader processors on nvidia videocards and coreavc is using it to access PureVideo hardware for decoding. the same happens with DXVA and OpenCL.
Most of the limitations in the article you posted are just HARDWARE LIMITATIONS (that can be fooled by software in some cases, as it happens in MPC-HC for example...) and they apply to coreavc or any other CUDA based, DXVA or OpenCL software coz THE DECODER IS A PIECE OF SILICON ON THE GPU and without that CoreAVC wont be able to decode ANYTHING except using the CPU. The decoder is not written in CUDA... can you understand that? if not, go trolling away...

[LigH]

That's what I intended to say... :o

It doesn't matter much which "decoder" software runs on which operating system using which specific API, if the real business is done by an integrated circuit.

[nm]

But there are many practical issues that can make a particular API more suitable even in playback-only scenarios. For instance, MadVR still doesn't work with DXVA.

[Sharktooth]

well, everything has his pro and cons, but still the "average user" doesnt use MadVR. on the other side, coreavc was plagued with bugs and customers had to wait for months to be fixed.
the good thing with free alternatives is usually there are more than one and usually bugs are fixed faster. also they're free...

@ligh: nevermind, i didnt understand we were saying the same thing :)

[weasel_]

why whoud we care about average user...
for example averege user still watch sd ...

[Mixer73]

that's partially true. you need a decent player and also coreavc comes with no filtering.
mpc-hc is as easy as coreavc to install. it doesnt need external decoders and has filters.
another option is VLC, still single easy installation and it has DXVA support too but no filtering (using DXVA).

Sorry, I was a big fan of MPC-HC for a number of years but the latest 'improvements' have rendered it unable to play without stutter on my system, and VLC is actually a joke. Its performance is shitful and on the last build I tried it couldn't even play MP4 files.

I'm using PotPlayer on my desktop rig now.

Regardless, I'm using Windows Media Centre in my loungeroom, and for this specifically I said that CoreAVC is well worth the $15 price.

[Forfront]

why whoud we care about average user...
for example averege user still watch sd ...
Couldn't have said it better my self;)...
I'm using PotPlayer on my desktop rig now.I also believe Daum potplayer is better than mpc-hc, certainly for average users, perhaps even the advanced!:D

[Sharktooth]

ok, so the advanced user, like me, for example, doesnt need coreavc at all coz my CPU is enough and im also not forced to buy an nvidia card... im not limited by the decoder on the videocard, so i can play UHD streams or even 10bit encoded avc streams without a problem. the advanced user doenst want to wait for months for bugs to be fixed in a stupid decoder... expecially if he paid for it. the advanced user does not confuse CUDA with the holy grail and gets informed before spreading bull$hit.
so, you're not and advanced user nor an average user. you're just a cuda fanboy spreading bull$hit and not even conscious that the applications that could be run on GPUs are very, very, very limited.

[davidsama]

You could try using Splash player which uses purevideo for gpu acceleration

[weasel_]

Sharktooth relex, just dont use coreavc...
Let other to use it if they want ... For nvida users, it have some advantage that others free decoders haven`t

You saying you are advance users and others are fanboy... hahaahha
Hardware decoding have some advatage vs softwere...of course it have some limitation ...
Just depend on consumer needs.

[Sharktooth]

@weasel_: sure, everyone uses what they want, but dont come here advertising CoreAVC as there is "no direct competition" and telling false stuff believing in a youtube video without further investigating on the real stuff...
im not saying that others are fanboys... im saying ONE person is a fanboy (not directed to you).

[Forfront]

CUDA is not MAGIC. there is NO decoders made using CUDA. CUDA is just a compiler for programming shader processors on nvidia videocards and coreavc is using it to access PureVideo hardware for decoding. the same happens with DXVA and OpenCL.
Most of the limitations in the article you posted are just HARDWARE LIMITATIONS (that can be fooled by software in some cases, as it happens in MPC-HC for example...) and they apply to coreavc or any other CUDA based, DXVA or OpenCL software coz THE DECODER IS A PIECE OF SILICON ON THE GPU and without that CoreAVC wont be able to decode ANYTHING except using the CPU. The decoder is not written in CUDA... can you understand that? if not, go trolling away...

well, everything has his pro and cons, but still the "average user" doesnt use MadVR. on the other side, coreavc was plagued with bugs and customers had to wait for months to be fixed.
the good thing with free alternatives is usually there are more than one and usually bugs are fixed faster. also they're free...
ok, so the advanced user, like me, for example, doesnt need coreavc at all coz my CPU is enough and im also not forced to buy an nvidia card... im not limited by the decoder on the videocard, so i can play UHD streams or even 10bit encoded avc streams without a problem. the advanced user doenst want to wait for months for bugs to be fixed in a stupid decoder... expecially if he paid for it. the advanced user does not confuse CUDA with the holy grail and gets informed before spreading bull$hit.
so, you're not and advanced user nor an average user. you're just a cuda fanboy spreading bull$hit and not even conscious that the applications that could be run on GPUs are very, very, very limited.None of its been worth responding to...

The article didn’t say cuda has a decoder:confused:, that wasn’t remotely the point, obviously gpu accel with pv or uvd (the central focus is the usage concept)... The implementations are, and always will be a “MEANS TO AND END” the end was the point not the means. Once again the hole purpose is “AviSynth” the scrips I run could easily max out a quad at 4.1ghz, so I’m using gpu accel to take some of the strain off the cpu (playback only). All of this works to gather flawlessly (kind like Magic!!!;)). Theres noway to do this with ATI (uvd) currently...
If I’m a fanboy of anything its openCL not cuda. I own ATI & NV graphic solutions, they both have advantages & disadvantages but nevertheless great products whichever a person owns.:)

[Audionut]

If Don was still here, he would have handed out numerous strikes and cleaned this thread.

You ladies should get each others MSN details or something.

[Sharktooth]

None of its been worth responding to...

The article didn’t say cuda has a decoder:confused:, that wasn’t remotely the point, obviously gpu accel with pv or uvd (the central focus is the usage concept)... The implementations are, and always will be a “MEANS TO AND END” the end was the point not the means. Once again the hole purpose is “AviSynth” the scrips I run could easily max out a quad at 4.1ghz, so I’m using gpu accel to take some of the strain off the cpu (playback only). All of this works to gather flawlessly (kind like Magic!!!;)). Theres noway to do this with ATI (uvd) currently...
If I’m a fanboy of anything its openCL not cuda. I own ATI & NV graphic solutions, they both have advantages & disadvantages but nevertheless great products whichever a person owns.:)
if it's for playback only (as you said) then MPC-HC has GPU accelerated avc decoder (dont know how many times i have to repeat myself...) that works on UVD too (thru DxVA) . MPC-HC project also has "external filters" (directshow) and the AVC decoder is included. So i still dont know what you're talking about...

[ranpha]

if it's for playback only (as you said) then MPC-HC has GPU accelerated avc decoder (dont know how many times i have to repeat myself...) that works on UVD too (thru DxVA) . MPC-HC project also has "external filters" (directshow) and the AVC decoder is included. So i still dont know what you're talking about...

What he says is MPC-HC by itself cannot replicate the powerful combination of MPC-HC (or PotPlayer) + CoreAVC CUDA + madVR (anyone who cares about image quality will use this) + ffdshow avisynth capabilities.

If you know how to enable DXVA-assisted playback with madVR and also with avisynth post-processing capabilities (gradfun2DBmod + seesaw + LimitedSharpenFaster et. al.) in MPC-HC, then please enlighten us on how to do it.

Oh BTW, JanWillem32's deband shader operators and gradfun2DBmod does two different things, just so you know.

[Sharktooth]

there's no actual way to enable ffdshow filtering with DxVA coz no data is returned from the video card after decoding. however, there are alternatives.
in the scenario you just described, i would use dgindexnv and its source filter, that is hardware accelerated as well (still using cuda) and apply avisynth filtering or ffdshow filtering as necessary.
result is the same or even better (coz directshow is weird) plus you get a frame accurate decoder.

[ranpha]

there's no actual way to enable ffdshow filtering with DxVA coz no data is returned from the video card after decoding. however, there are alternatives.
in the scenario you just described, i would use dgindexnv and its source filter, that is hardware accelerated as well (still using cuda) and apply avisynth filtering or ffdshow filtering as necessary.
result is the same or even better (coz directshow is weird) plus you get a frame accurate decoder.

You have to make an avs script for each and every video you want to play, which is not convenient at all. Plus, your method doesn't work with ATI/Intel GPUs, and I believe the DGDecNV is not free too.

[weasel_]

@weasel_: sure, everyone uses what they want, but dont come here advertising CoreAVC as there is "no direct competition" and telling false stuff believing in a youtube video without further investigating on the real stuff...
im not saying that others are fanboys... im saying ONE person is a fanboy (not directed to you).
Ok ;), i just saying its good option for some users...
I agree with you it`s not holy gral
I dont use it and dont believe i will

[Sharktooth]

You have to make an avs script for each and every video you want to play, which is not convenient at all. Plus, your method doesn't work with ATI/Intel GPUs, and I believe the DGDecNV is not free too.
you're making an avs anyway (if the scenario was what weasel described). also, coreavc hardware acceleration wont work on ati/intel GPUs as well... and coreavc is not free as well.

[nm]

you're making an avs anyway (if the scenario was what weasel described).
ffdshow has AviSynth filtering option where the source is added automatically. I don't know how other source filters would work with it.

[Sharktooth]

you cant add a source filter in ffdshow avisynth filtering option. or at least i dont think you can.
btw, if you need all that filtering during playback, you better re-encode...

[Forfront]

@Sharktooth, be careful not to contradict ur self...

[Sharktooth]

im not contradicting myself. you cant use DxVA and ffdshow FILTERING together. you have to use GPU shaders for that... like MPC-HC does.

[ranpha]

you're making an avs anyway (if the scenario was what weasel described). also, coreavc hardware acceleration wont work on ati/intel GPUs as well... and coreavc is not free as well.

With MPC-HC + CoreAVC CUDA + ffdshow avisynth support + madVR, you only have to create the script once. Maybe more if I want to make profiles depending on what I am watching (I have 2). If I were to watch a 20-episode TV series, I do not have to make 20 avs scripts to be played in MPC-HC. Plus, I can also swap the player with the likes of Pot Player/Zoom Player and it will still work (haven't tried the latter though).


im not contradicting myself. you cant use DxVA and ffdshow FILTERING together. you have to use GPU shaders for that... like MPC-HC does.

Not all ffdshow filters/avisynth plugins has shaders equivalent. For example, do you really think that JanWillem32 deband pixel shader operator works the same way gradfun2DBmod avisynth/ffdshow deband filters works? Those two deal with different problems. Plus, with GPU shaders, you are stuck with EVR custom presenter and cannot use madVR.

[Sharktooth]

i know they're not the same. still i dont understand why applying all those filters during playback.
when i backup my movies i ensure the encoding looks like the original. obviously, sometimes it happens i miss something, but i dont need that heavy filtering to fix that.
if that is the case, i just re-encode from the original, so the next time i want to watch that movie/whatever, i just do it...

[ranpha]

i know they're not the same. still i dont understand why applying all those filters during playback.
when i backup my movies i ensure the encoding looks like the original. obviously, sometimes it happens i miss something, but i dont need that heavy filtering to fix that.
if that is the case, i just re-encode from the original, so the next time i want to watch that movie/whatever, i just do it...

Because even the source Blu-ray material may have banding problems (looking at that god-damn Mushishi Blu-rays)!

[weasel_]

That need to be fix at encoding not after with filters

[ranpha]

That need to be fix at encoding not after with filters

But doesn't sharktooth says that a direct rip of a Blu-ray shouldn't have any problems? Re-encoding is not really an option mainly because most of the time (or actually all the time) I watch Blu-rays off the disc with MPC-HC (alongside Passkey). I don't back-up my video DVDs/BDs.

[Sharktooth]

nope. rip and encode are 2 different terms. rip = copy, encode = compress.
i said i tend to make my encodings similar to the original. that's when it makes sense. i mean, if there are obvious artifacts that can be reduced or eliminated by filtering, i apply the necessary filtering before encoding.
also i always back up my original discs coz the chance of damaging them are reduced significantly by using the backup for regular watching.

[ranpha]

nope. rip and encode are 2 different terms. rip = copy, encode = compress.
i said i tend to make my encodings similar to the original. that's when it makes sense. i mean, if there are obvious artifacts that can be reduced or eliminated by filtering, i apply the necessary filtering before encoding.
also i always back up my original discs coz the chance of damaging them are reduced significantly by using the backup for regular watching.

Well, I don't rip or recompress my optical discs because I don't watch movies/TV series/anime more than once or twice (unless in exceptional circumstances), therefore post-processing during playback is important for me at least. In this regard, MPC-HC GPU shaders is simply no match for the power, flexibility and quality that ffdshow + avisynth + madVR can do (and still has hardware acceleration if you use CoreAVC).

[Forfront]

Ranpha: good point, Of course avs scrips can be loaded in meGui but who wants to wast time encoding every single vid or one that will only be watched once. Thats just impractical when we can do this in realtime.:cool:

[Zero1]

Forgive me for slowpoking; but I just got a new laptop and decided to give encoding a go after a few years away. Long story short is that I use the x264 cli, and it often becomes unresponsive, eg if I click on the window or try to minimize it. x264 continues to run in the background normally and then the window regains responsiveness once the encode has finished, and the rest of the batch continues to execute.

I believe I've narrowed this problem down to CoreAVC. I'm using v2 for decoding on Windows 7 64 bit (but all my decoders and encoding software is 32 bit). When I disable CoreAVC and use FFDShow, I do not get the freezing problem. I tried with and without CUDA as I thought there was a remote possibility that it was a GPU driver bug or some conflict with Aero or something, but it made no difference.

Is this a known issue, and is there something I can do about it? It won't kill me to use FFDShow or whatever, but I like CoreAVC for decoding because my GPU decodes the video and leaves the CPU free to encode.

http://doom10.org/index.php?topic=523.0

This guy seemed to have a similar problem.

Thanks.

[Sharktooth]

get DGNVTools. they're much more reliable...

[paulvdb]

I assume you are using an Avisynth script with DirectShowSource() to decode a h264 source. Do you have the tray icon enabled in CoreAVC? If I remember correctly that was the cause when I had that problem and disabling the tray icon fixed it.

[Zero1]

I assume you are using an Avisynth script with DirectShowSource() to decode a h264 source. Do you have the tray icon enabled in CoreAVC? If I remember correctly that was the cause when I had that problem and disabling the tray icon fixed it.
Can't thank you enough. That was exactly the problem. I can't believe something like the tray icon would cause that to happen. Much appreciated.

[eddman]

Apparently v2.5 is available for OEM.

http://twitter.com/CoreCodec/status/42963261569777664

Also, they are saying the retail version will be available by mid march. We'll see. :D

http://twitter.com/CoreCodec/status/43278830122713088

[BetaBoy]

We are close but want to get some feedback.... we have just prepared the first one of two betas for CoreAVC 2.5 that are going out to testers starting today. The main focus of 2.5 is four fold:

- Filling some voids in ASM. For example you should see a nice speed increase in 64bit playback.
- Further optimizations (CPU specific, speed)
- Bug fixes
- Adding DXVA support

With DXVA 1/2 being the biggest focus of this release, we expect a series of post 2.5.x releases to address any issues that come up.

For those that will ask... High 10 support is coming but in 3.x and above only, and we don't expect 3.0 to be out till later this year.

Additionally.... since its based on CoreAVC, once 2.5 is out we will be sending out beta versions of our 3D MVC video decoder CoreMVC. More details on it post 2.5, but our MVC SDK is already available for OEM licensing, licensing@corecodec.com . You'll see the first products with it to market later this month.

[Virtual_ManPL]

Will this bug be fixed in CoreAVC 2.5 release ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600

[Gleb Egorych]

BetaBoy, is hw deinterlacing support improved in 2.5? Can we expect CUDA deinterlacing (if it is suppported by Nvidia) in 2.5?

[BetaBoy]

Will this bug be fixed in CoreAVC 2.5 release ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600

That should be fixed.

[BetaBoy]

Can't thank you enough. That was exactly the problem. I can't believe something like the tray icon would cause that to happen. Much appreciated.

Because a command prompt has no UI pump.

[BetaBoy]

Looks like we have a green light for CoreAVC 2.5 later next week. DXVA QA with the beta testers has gone very well. We might leave a few TODO's for a follow up release or two, but no show stoppers!

[Cyber-Mav]

i wonder if coreavc can now match the speed of diavc when it comes to cpu decoding. only time will tell.

[Virtual_ManPL]

That should be fixed.

Thank you! I will be waiting for release :devil:

[BetaBoy]

i wonder if...
I've stated that with each release you will see speed increases, 2.5 is no exception and you will see across the board speed boosts but mostly you will see big improvements in 64bit OS's.

[BetaBoy]

Peter has just pushed out a beta of his Stereoscopic Player that includes CoreMVC. So you can get an early glimpse on CoreAVC 2.5 as it is included in CoreMVC which is out now for OEM licensing for 3D MVC playback.

[arapkadri]

hi Will there be support for 10 bits?

[CruNcher]

http://www.3dtv.at/Downloads/StereoscopicPlayer169_en.msi ;)

Though i have no time to test as im currently to much into my GPU Screen Capture Framework

[Nick [D]vB]

Peter has just pushed out a beta of his Stereoscopic Player that includes CoreMVC. So you can get an early glimpse on CoreAVC 2.5 as it is included in CoreMVC which is out now for OEM licensing for 3D MVC playback.I've just been testing it and it's working great, you've made a lot of projector owners very happy, AFAIK this is the only solution for playing 3D Bluray on the more obscure 3D display setups, and the only way nvidia card owners can do it without having to buy a 3Dvision kit. It would be great if we could get CUDA working with MVC for users of older nvidia cards that don't support MVC acceleration through DXVA. It doesn't seem to be enabled at the moment and the decoder properties seem to be locked out through stereoscopic player, will it be availible in the full version of 2.5? I helped test CoreAVC with the first BBC HD streams years ago, I've not checked-in here for a while but its great to see you guys are still at the cutting-edge, keep up the good work! :)

[BetaBoy]

Thank you Nick glad you like it... it has been a hard year working on everything for both CoreAVC and CoreMVC... and we are not done for sure.... there is still plenty if todo's for both products in 2.x and for 3.0 form.

[Nick [D]vB]

Can you clear something up for me Dan? Will MVC support be included in the CoreAVC 2.5 update or in CoreAVC 3? If not will CoreMVC be available to end-users as a stand-alone product in the future? There seems to be some confusion about this on the 3D forums. Also is there a technical reason why CUDA hasn't been enabled for MVC yet? I notice Peter patched a MPC-HC filter to add SSIF support, is this the only demux filter CoreMVC will connect to at the moment or are there others? Sorry for so many questions, thanks again.

[BetaBoy]

No problem.. the confusion is that the 3D Vision Blog stated it was a part of a 'pack' and that is not correct. Although the 'core' of CoreAVC is obviously shared with CoreMVC it is a brand new product altogether. Anytime a CoreMVC release comes out it will include the latest 'core' of CoreAVC. CUDA is a TODO and we need to jump through a few issues.

On splitters... Peter used a custom MPC filter for his player.... but I can tell you that Haali's filter is on the horizon.

On CoreAVC 3.0... it is being worked on now and its 'core' is different then the current 2.x as we are adding High 10 support which is no small task. The plan is to get it out later this year, but we will see as the next few weeks/months progress.

[CruNcher]

Dan does CoreAVC 2.5 DXVA implements a fallback to Software Decoding for to many reference frames streams, Mainconcepts Decoder does that i was quite surprised of this feature, seems they are also the only ones yet doing this :)
CoreAVC 2.0 introduced some nice fallbacks for non compatible nvcuvid situations so it would be great if it would be as smart for DXVA too :)

[Nick [D]vB]

Thanks, I look forward to the full CoreMVC release, CUDA support will be a great USP, HTPCs with ION GPUs should be up to the job now, which is great news because the new AMD Fusion APUs can't do MVC DXVA either. CoreAVC 3 sounds really promising, good luck with it.

[BetaBoy]

Dan does CoreAVC 2.5 DXVA implements a fallback to Software Decoding for to many reference frames streams, Mainconcepts Decoder does that i was quite surprised of this feature, seems they are also the only ones yet doing this :)
CoreAVC 2.0 introduced some nice fallbacks for non compatible nvcuvid situations so it would be great if it would be as smart for DXVA too :)

DXVA resizing and software fallback was one of our last todo's for 2.5.... not sure if they will make it, but they are on the table atm with a few days left for QA and final release.

[madshi]

@BetaBoy, can you already publish the exact input/output pin "specification" of CoreMVC? That might help speed up development of splitters and renderers. Thanks.

[BetaBoy]

madshi.... email me directly: betaboy AT corecodec DOT com and i'll get you into the internal discussions with Peter, Haali and our staff.

[BetaBoy]

Got the email madshi... and sent it off to everyone to comment.

[madshi]

Thanks, appreciated.

[BetaBoy]

Madshi.... also find the MPC patches here... that will show you how its done. http://www.3dtv.at/OpenSource/

I also see you are talking to Peter about it here: http://forum.doom9.org/showthread.php?p=1479589#post1479589

[madshi]

@BetaBoy, thanks for the link. As far as I can see, those patches show me the splitter -> CoreMVC connection. That's a good start. But I also need the CoreMVC -> renderer connection. Actually, that's more important for my needs, as I'm writing a renderer and not a splitter... :)

[BetaBoy]

We are compiling a CoreAVC 2.5 GM version to QA now. If all goes well emails will be going out soon on its availability.

[BetaBoy]

We have now released CoreAVC 2.5 Professional Edition for Windows. Current customers are being notified now.

CoreAVC 2.5 represents over a years worth of work by the CoreCodec teams. This milestone release includes the major addition of DXVA 1 and DXVA 2 support and unifies our core 32/64 bit code which inturn has increased the overall effeciency of playback (ie; it's faster than before!).
While the changelog is shorter then most of our milestone releases, it does not even touch on the total amount of work that went into 2.5 as many of the changes also relate to both the upcoming additions of High10 support as well as the release of CoreMVC, our 3D MVC based decoder.


HOW TO UPGRADE/INSTALL FROM 2.0 to 2.5
-------------------------------------------------------------
- Log into the customer portal: http://customers.corecodec.com
- Click 'View My Products'
- Click 'Software - CoreAVC 2.0.0'
- Click the top link 'Product upgrade is available.' to upgrade.
- Click through the two pages to get the upgrade confirmation.
- Now go back to 'Client area > View my products' and click on CoreAVC 2.5 to download it.
- Copy the CoreNumber on your product page.

NOTE: CoreAVC 2.5 SERIAL NUMBERS HAVE CHANGED!!!
This means that once you upgrade to 2.5 your 2.0 serial number will not work. This also means if you try and install CoreAVC 2.5 over 2.0 it will not work since the serial numbers are different.

1 - Uninstall CoreAVC 2.0 (Start > Control Panel > Programes > Uninstall > CoreAVC)
2 - Enter the email you used to purchased CoreAVC.
3 - Now paste the CoreNumber from the customer portal into installer when asked.
4 - Click though the installer to finish.

For those that want to work around the restriction that Windows 7 Media Foundation imposes,
We recommend using the Win7DSFilterTweaker

Download it here:
http://www.codecguide.com/windows7_preferred_filter_tweaker.htm


What's new in this release
======================================================
CoreAVC H.264 Video Codec - Version 2.5.0.0 (20110326)
- ADD: DXVA1 support (with red tray icon)
- ADD: DXVA2 support (with red tray icon)
- ADD: new x64 blit asm code (unified with x86)
- FIX: SPS memory leaks
- FIX: Properly support SPS resolution changes (soft/cuda decoding)
- FIX: Bug in YUV->YUV blit code
- CHG: Unify x86 and x64 CUDA asm code
- CHG: Unify x86 and x64 AVC asm code, enabling SSE2/SSE3/SSSE3/SSE4 for x64
- CHG: Increase max supported resolution (approx 8100x8100)
- CHG: Refactor directshow frontend code
- CHG: Modify CUDA locking method
- CHG: Rearrange/enlarge settings dialog
- OEM: YASM padding bug for OSX target
- OEM: Android support added to SDK


Haali Media Splitter (20110303)
- ADD: AC3 in MP4 support
- ADD: WebM support
- ADD: More H264 aspect ratio options
- FIX: Show error code in GDSMux when muxing is aborted
- FIX: Accept more AAC media types in the muxer
- FIX: Use correct timescales when processing MP4 edit lists
- FIX: Scan the folder for more segments only if the file references external segments
- FIX: Fixed a lot of issues with the mp4 muxer
- FIX: Better support for VC1 in MPEG Transport Streams
- FIX: Aspect ratio processing in certain Matroska files
- FIX: Bug in uninstaller that prevented it from properly unregistering all filters
- FIX: Unrecognized video track in some transport streams
- FIX: Occasional excessive disk I/O when paused

[BetaBoy]

While 2.5 gets around we are still working on a few of the last todo's for CoreAVC 2.5.x, those being:

-----------
- DXVA Fallback when the stream isn't compatible
- DXVA Handling mid-stream resolution changes
- Different handling of quant matrices for ATI/NVidia
- Long slice mode / intel support
- Clean up/merge DXVA defines

[pankov]

BetaBoy,
I've just installed CoreAVC 2.5 Pro and I'm sad to report that my long standing problem with Deinterlace field order (Ticket #175597) is still not fixed.
I've also found a bug in the installer - despite the fact that I selected to not install Haali Media Splitter (cause I've already installed it a couple of weeks ago) it changed the registry value for "Use custom media for H.264" from the "No" that I've been using to "Yes" - the default value.

[BetaBoy]

Pankov..... we will look into the Haali bug... But in the deinterlace field order, iirc we commented on that a long time ago in this thread and that we could not duplicate your results. I will double check internally.

[BetaBoy]

pankov... pls do send me a sample so we can look more closely at that potential bug.

[pankov]

Here is the sample
http://www.mediafire.com/?fwxb108j7l2asrw

I was about to make you .grf file so you can see the exact configuration that I use but I've also noticed that CoreAVC 2.5 can't be inserted as a filter in Monogram GraphStudio - it crashes, while v2.0 didn't have any problems. So I guess I'll just have to explain it now:

Haali's Splitter -> CoreAVC -> EVR
-> FFDShow Audio Dec. -> Def. Direct Sound Device

[CiNcH]

DXVA2 seems to be working for ATi.

HOWEVER!!!

After years I still experience jaggyness with interlaced (1080i) content when using NV12 color space and hardware deinterlacing. It looks as if fields have the wrong order.

Me and several others reported it a thousand times in this thread...

These are the final screenshots from me. If you still don't think it is worth fixing, I'll give up...

CoreAVC / NV12 / hardware deinterlacing:
http://forum.doom9.org/attachment.php?attachmentid=12150&stc=1&d=1301145259

CyberLink / NV12 / hardware deinterlacing:
http://forum.doom9.org/attachment.php?attachmentid=12151&stc=1&d=1301145584

[CiNcH]

Sidenotes to the interlace/field order problem for reproduction:

- use VMR or EVR with NV12 colorspace and hardware deinterlacing (do not use Haali Renderer!)
- happens with both, ATi and nVIDIA
- same problem with ffdshow (http://forum.doom9.org/showthread.php?p=1300535#post1300535)

[madshi]

Update to 2.5 worked fine here - and it's free, as promised. Thanks to BetaBoy and Core! :)

[betaking]

TO betaboy.last Haali Media Splitter not support dts-hdma audio ,but mpc-hc Splitter is Support! can you Report it to haali?

[Gleb Egorych]

Sidenotes to the interlace/field order problem for reproduction:
...
- same problem with ffdshow (http://forum.doom9.org/showthread.php?p=1300535#post1300535)
ffdshow does not have the problem with the clip (Win 7, EVR, YV12 & NV12), try the latest version.

[Barlow]

Nice update :)

Unfortunately I've found a file which causes corruption in DXVA mode, whereas it's fine when decoded by the MPC Videodecoder (with DXVA) or CoreAVC in software mode.

Screenshot (http://i.imgur.com/VW0Wf.jpg)

Sample (http://www.mediafire.com/?rd24yzq8cer9o4m)

Edit: forgot to mention, card is a Radeon 4850. OS is Win7 64bit.

[BetaBoy]

DXVA2 seems to be working for ATi.

If you still don't think it is worth fixing,


Of coarse we do... and we thank you for the report!!

[CiNcH]

Another issue...

CoreAVC pretty much relies on the source filter's information. Thought this was once fixed already.

Source material is 720p50. If the source filter propagates the following (wrong) information...

1. [DVB Source]/(Video) -> [CoreAVC Video Decoder]/(Input)
Major: MEDIATYPE_Video
Subtype: {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}
bFixedSizeSamples: FALSE
bTemporalCompression: FALSE
lSampleSize: 1
cbFormat: 136
Format: FORMAT_MPEG2_VIDEO
VIDEOINFOHEADER2:
rcSource: (0,0,0,0)
rcTarget: (0,0,0,0)
dwBitRate: 10000000
dwBitErrorRate: 0
AvgTimePerFrame: 400000
dwInterlaceFlags: 1
dwCopyProtectFlags: 0
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0
BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1088
biPlanes: 1
biBitCount: 24
biCompression: 0x34363248
biSizeImage: 6266880
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 0
dwProfile: 0
dwLevel: 0

video looks like that...

http://forum.doom9.org/attachment.php?attachmentid=12152&stc=1&d=1301162176


If the source filter passes...

1. [DVB Source]/(Video) -> [CoreAVC Video Decoder]/(Input)
Major: MEDIATYPE_Video
Subtype: {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}
bFixedSizeSamples: FALSE
bTemporalCompression: FALSE
lSampleSize: 1
cbFormat: 136
Format: FORMAT_MPEG2_VIDEO
VIDEOINFOHEADER2:
rcSource: (0,0,1280,720)
rcTarget: (0,0,0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 200000
dwInterlaceFlags: 0
dwCopyProtectFlags: 0
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0
BITMAPINFOHEADER:
biSize: 40
biWidth: 1280
biHeight: 720
biPlanes: 1
biBitCount: 24
biCompression: 0x34363248
biSizeImage: 2764800
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 0
dwProfile: 77
dwLevel: 40

... everything is OK.

Most other decoders detect the format on their own without relying on the source filter's information.

[CruNcher]

Nice also the changes (fixes) in Hallis splitter are there any estimations of how much the CUDA part efficiency improved compared to 2.0 ? :)
We have 2 other free filters now for CUDA (nvcuvid) based decoding via dshow benchmark of their efficiency will sure come, btw Betaboy you should go for Nvidia based DSPs the way of Bad/Incompatible stream(DXVA)->Bad/Incompatible stream(CUDA)->Bad/Incompatible stream(Software Core) ;)
Mainconcept is a simple Bad/Incompatible stream(DXVA)->Bad/Incompatible stream(Software Core) fallback as they dont yet implement nvcuvid :)
Also a nice feature would be entirely avoiding 10 bit decoding and 4:2:2 stream and falling directly back into the Dshow chain this would make it possible to pair CoreAVC for now with other solutions for optimal Decoding results (creating such dynamic decoding chains manually currently is rather complex, most of the times decoder try to playback everything and obviously fail with a lot of streams they do not support crash or visual errors, its hard to understand why only a few leave such streams untouched or fallback as Mainconcept does for too much reference streams and DXVA) :)

[Chumbo]

@BetaBoy,
I just installed 2.5 and plays the 23.976 stuff fine, however, I have some interlaced stuff that's not so good. I uploaded a sample here (http://www.mediafire.com/file/njnk9zijvq23m6i/interlaced-sample.mkv) if you want to take a look. I use MPC-HC 1.4.2744.0 x64 version under Windows 7 Ultimate x64 with Sp1. Plays the same on laptop with ATI Mobility HD5730 and desktop with HD4830.

These are my settings
http://img268.imageshack.us/img268/4795/coreavcsettings.jpg

[BetaBoy]

You are using 'low latency' for any specific reason?

[Chumbo]

You are using 'low latency' for any specific reason?
Actually, no. I just checked it temporarily to see if it would help "fix" the playback and forgot to uncheck it. Thanks for reminding me. ;)

[EDIT] I updated the settings image to the correct one.

[BetaBoy]

Keep the reports coming! Although this is a the first DXVA release, i'd like to see is anyone would like to do performance diffs from 2.0 to 2.5.

[BetaBoy]

Also, we had to delay the emails going out a few hours to fix a portal bug. So mass emails are going out now to all registered users.

We have also made CoreAVC 2.5 available now for purchase: https://customers.corecodec.com/cart.php?a=add&pid=10

As a thanks use the code "25launch" for $4.00 off for friends, family, Twitter, new PC, etc.

[BetaBoy]

btw Betaboy you should...
Thx for the suggestion! We are hoping to get DXVA fallback into one of the next 2.5 follow-up releases.... and i'll address your suggestion with the teams.

[Tom Keller]

CoreAVC 2.5 crashes GraphStudio (http://forum.doom9.org/showthread.php?t=133928) for me, when trying to load the decoder filter. Since CoreAVC 2.0 worked pretty well, i assume it's in some way related to v2.5!? Could someone confirm this problem?

[pankov]

Tom,
I've reported the same problem a few posts up.

[Twingo]

Just try to help a little bit, I have same problem after using ATI DXVA today. I was using software on my HD5570 card before to decode h264 movies, but today I updated Coreavc to use DXVA for ATI cards, then my MPC-HC is asking me to update my directx after I set it to vmr9-renderless as described on MPC-HC website. It was okay before I updated directX but after I updated my directx to june 2010 release then the same problem (as reported by Barlow) occurred to me, my original directx is from windows xp sp3, never updated before today.

Nice update :)

Unfortunately I've found a file which causes corruption in DXVA mode, whereas it's fine when decoded by the MPC Videodecoder (with DXVA) or CoreAVC in software mode.

Screenshot (http://i.imgur.com/VW0Wf.jpg)

Sample (http://www.mediafire.com/?rd24yzq8cer9o4m)

Edit: forgot to mention, card is a Radeon 4850. OS is Win7 64bit.

[Tom Keller]

Tom,
I've reported the same problem a few posts up.
Sorry... must have missed it :o . In the meantime i tested DSGraphEdit - it crashes too. Only the "good" old Microsoft GraphEdit seems to work though...

[BetaBoy]

Can anyone elaborate on an MKV seeking bug in WMP. Seems in certain systems it does not seek. What we are looking for is your settings (DXVA or CUDA) and content type.

[Twingo]

Can anyone elaborate on an MKV seeking bug in WMP. Seems in certain systems it does not seek. What we are looking for is your settings (DXVA or CUDA) and content type.

I have exactly the same bug with my laptop using intel X3100 integrated video, I tried various settings but it won't work, dxva on/off, deterlacing on/off, low latency on/off or agressive on/off they all won't let me seek by pulling the progress bar. I was playing Mad Love 720p X264 mkv by Dimension.

[BetaBoy]

We have samples now and can reproduce it. Thank you for the follow-up.

[cmbe]

Hi,

after upgrade from CoreAVC 2.0 to 2.5 with MediaPortal 1.1.2 i always get "Unable to play video" error on mkv files, besides everything works in Windows Media Player.

Before the upgrade everything works with CoreAVC 2.0 .

If I switch to another h.264 Codec in MediaPortal configuration as: MPCVideoDEc, FFDSHOW, etc. everything works fine.

I have tried to get more info with GraphStudio but it crashes (as reported a few posts back) with CoreAVC 2.5.

Has anyone experienced such problem?

[BetaBoy]

ok... we found the bug for ImediaPosition and ImediaSeeking (WMP not being able to seeking in some MKV's).... gonna take a look at the issue with MediaPortal and Rad's Graph Studio next.

[BetaBoy]

- ImediaPosition and ImediaSeeking bug, FIXED.
- Graphstudio bug, FIXED.

Going to see about MediaPortal next but I am assuming its fixed as well as it was the same bug as Graphstudio.

[Ruklaw]

Is an updated download available yet to fix the seek bug?

[Chumbo]

@BetaBoy,
I found a playback corruption issue on a file I edited. Playing it using either ffdshow or MPC decoder has a fairly clean break at the edit point where CoreAVC 2.5 shows much corruption. Small sample here (http://www.mediafire.com/?jko7mjc53hcu4b3).

[oddball]

Anyone got a direct download link? Your crabby portal does not recognise my email. Why paid up members should have to go through your portal to download the codec (which requires a registration number regardless) baffles me.

[BetaBoy]

We are working on a quick followup release once we are confident the current reports are fixed.

We will send an update notice as soon as it's available. We already have an RC build compiled that we are testing.

[BetaBoy]

Oddball... Do not ask for a direct download link... And you will need a new corenumber as they have changed with 2.5.

PM me with your info and I'll take care of it.

[BetaBoy]

We are sending a test build (v2.5.1) to those who submitted support tickets on the seeking, graphstudio, and mediaportal bugs.

[ajp_anton]

What advantages does CoreAVC's DXVA have over for example MPC-HC's internal one?

[desta]

I've just upgraded to 2.5. Before doing so I quickly played some of my own 1080p encodes with 2.0 and all was fine. After upgrading to 2.5 I now get jerky, stuttered playback with 1080p mkv's. If I disable cuda then playback becomes smooth. 720p and below is fine with and without cuda.

I've opened a ticket through the portal.

[robpdotcom]

I updated to 2.5 yesterday, and when using DXVA I'm getting a corrupted image (not sure how to describe it, I can get some screen shots if necessary).

I haven't seen anyone else describe anything similar. Should I open a ticket, and, how do I open a ticket?

[BetaBoy]

I've just upgraded to 2.5. Before doing so I quickly played some of my own 1080p encodes with 2.0 and all was fine. After upgrading to 2.5 I now get jerky, stuttered playback with 1080p mkv's. If I disable cuda then playback becomes smooth. 720p and below is fine with and without cuda.

I've opened a ticket through the portal.

What NVIDIA drivers do you have installed? Have up upgraded to the newest ones?

[BetaBoy]

I updated to 2.5 yesterday, and when using DXVA I'm getting a corrupted image (not sure how to describe it, I can get some screen shots if necessary).

I haven't seen anyone else describe anything similar. Should I open a ticket, and, how do I open a ticket?

We have received other similar reports... if you have a sample that shows this it would help trying to see whats going on.

[desta]

what nvidia drivers do you have installed? Have up upgraded to the newest ones?
266.58

[BetaBoy]

We have released CoreAVC 2.5.1... current customers just need to log into the customer portal to download the update. http://customers.corecodec.com

This release fixes:
- WMP seeking with MKV
- Media Portal crashes
- Graphstudio crashes

[hajj_3]

any changes since 2.5.1 RC?

[pankov]

I've just installed v2.5.1 and I'm glad to report that the problem with GraphStudio is fixed.
Sadly the installer again changed the settings for using custom media format for .mkv.
Why is this happening despite the fact that I don't even select the Haali splitter to be installed !?!?

BetaBoy, did you manage to replicate the problem with the wrong field order with the sample that I posted?
Any chance for a fix?

[desta]

We have released CoreAVC 2.5.1... current customers just need to log into the customer portal to download the update. http://customers.corecodec.com

This release fixes:
- WMP seeking with MKV
- Media Portal crashes
- Graphstudio crashes
Still the same issue for me with 2.5.1.

[robpdotcom]

We have received other similar reports... if you have a sample that shows this it would help trying to see whats going on.

For me, it happens with all H.264 from Blurays, whether straight from the disc or in mkv. Here are 4 screen shots - 2 using CoreAVC, 2 using Microsoft's decoder:

CoreAVC 1 (http://img848.imageshack.us/img848/6579/coreavc.png)
Microsoft 1 (http://img819.imageshack.us/img819/4383/microsofts.png)
CoreAVC 2 (http://img200.imageshack.us/img200/4695/coreavc2.png)
Microsoft 2 (http://img822.imageshack.us/img822/3780/microsoft2l.png)

[oddball]

Does CoreAVC 2.5 support DXVA on Intel (laptop) HD chipsets?

[BetaBoy]

I've just installed v2.5.1 and I'm glad to report that the problem with GraphStudio is fixed.
Sadly the installer again changed the settings for using custom media format for .mkv.
Why is this happening despite the fact that I don't even select the Haali splitter to be installed !?!?

BetaBoy, did you manage to replicate the problem with the wrong field order with the sample that I posted?
Any chance for a fix?
We are working with Haali on how to best handle the custom media format for a future release.

The teams are looking into the field order... but they already commented on how you get random field order changes when starting and seeking and how most renderers break.

[BetaBoy]

Still the same issue for me with 2.5.1.

You are the only report that it still has issue.s Please confirm your running 2.5.1 and have even tried a reboot.

[BetaBoy]

Does CoreAVC 2.5 support DXVA on Intel (laptop) HD chipsets?
If your referring to: http://software.intel.com/en-us/articles/mp4avc-decode-using-the-intel-media-sdk/

DXVA sure... but not yet for the Intel Media extentions. Once we are happy with the DXVA feature set being complete in 2.5 and above, we will then extend it further.

[pankov]

We are working with Haali on how to best handle the custom media format for a future release.
10x
Please, do consider that not installing Haali's splitter through CoreAVC's setup should not change any setting of the splitter. I'm not sure (don't remember from the past) if your installer simply uses Haali's one and calls it during setup but nevertheless no settings should be changed if it's not started.

The teams are looking into the field order... but they already commented on how you get random field order changes when starting and seeking and how most renderers break.I'm not sure I understand your words exactly. Where did they comment? Who said that I get random filed order changes when starting/seeking? Btw isn't it decoder's responsibility to send the fields in the correct order? In PAL countries Top Field First is the most used configuration and I sense that CoreAVC is sending the opposite. Am I right?

[Twingo]

You are the only report that it still has issue.s Please confirm your running 2.5.1 and have even tried a reboot.

I have the same problem with a h264 mkv file, using DXVA on a hd5570 card. I just opened a ticket but don't have idea how to send sample to you, it's about 17MB.

[LoRd_MuldeR]

I just opened a ticket but don't have idea how to send sample to you, it's about 17MB.

Usually it's best to upload samples at http://www.mediafire.com/ or a similar service and provide a link...

[mkanet]

Should I even bother to try Haali with DTS-HD/True-HD in MKV, M2TS, and TS containers in version 2.5.1?

I ended up uninstalling Haali and using the latest LAV splitter for all the above to work Edit: In version 2.5.. I havent tried 2.5.1 yet.

[Twingo]

Usually it's best to upload samples at http://www.mediafire.com/ or a similar service and provide a link...

Thanks for the hint, I uploaded and the link is at

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

[Twingo]

Just a little more update. Tried the same sample on my del xps 1340 laptop with G210M video, it's using CUDA and the video looks normal.

[BetaBoy]

Thanks for the hint, I uploaded and the link is at

http://www.mediafire.com/?lmnu387cdk0572r
Thank you for the sample.... What are you using for a renderer? We are seeing mixed results here, it plays properly with most renderers but not all.

[mkanet]

I just tested on my PC.... I can now play 1080p/i H.264, TRUE-HD, DTS-HD, AC3, etc in ALL popular/standard containers (TS, M2TS, and even MKV!) with perfect quality, timing, synch, etc in ANY directshow player.. not confined to one software player (any player that lets your system build the filtergraphs).

This is a big deal to me since up until just recently, I could only play an audio format in one container, but not in others, or heavy audio and/or video stuttering, no audio, or video distortion, synch issues, etc (ie, like all the weird issues mentioned above).

Now everything works regardless of container, audio format, directshow software player.

And, best of all, I didn't have to install FFDshow or any other software suites/bloat. I try to keep things as minimal/lean as possible without any issues and full flexibility.

Filters used
Splitter: LAV (Splitting MKV, TS, M2TS, MPLS)
H.264 Video: CoreAVC 2.5.1 with Cuda fully supported
DTS-MA: Arcsoft-HD standalone with filter wrapper (to keep 24bit/5.1)
True-HD: LAV audio - Only TrueHD is enabled

In a perfect world, if CoreCodec included a splitter, video, audio filter pack that just worked without any of the on going issues, it's value would be increased exponentially; however, I wouldnt hold my breath to see a package like that.

I'm a very happy camper now!
-MKANET

Should I even bother to try Haali with DTS-HD/True-HD in MKV, M2TS, and TS containers in version 2.5.1?

I ended up uninstalling Haali and using the latest LAV splitter for all the above to work Edit: In version 2.5.. I havent tried 2.5.1 yet.

[namaiki]

If your referring to: http://software.intel.com/en-us/articles/mp4avc-decode-using-the-intel-media-sdk/

DXVA sure... but not yet for the Intel Media extentions. Once we are happy with the DXVA feature set being complete in 2.5 and above, we will then extend it further.

Are you going to try implement ModeH264_VLD_NoFGT_ClearVideo as some Intel GPUs do not support the standard DXVA thing?

[CruNcher]

http://forum.doom9.org/showpost.php?p=1487694&postcount=52

CoreAVC also brakes in this very interesting scenario (it also drops frames but not after 12 seconds like nevs LA CUVID Decoder it drops them immediately after load) in both CUDA and DXVA mode (i yet cant explain why Cyberlink DXVA is the only Decoder that survive this MPC-HC configuration (Nvidia VP2 + XP + VMR9 Renderless (VMR9 Mixer mode,Alternate Sync,3D surrface,bicubic) + 1080p 60 FPS stream + ffdshow audio decoder + MPC-HC internal Mp4 splitter + Minimal Energy Profile) :(

Makes me crazy (not being able to find the cause of it) especially as no one could confirm this issue yet, but im surely not imagine this ;) :(

http://e.dl.playstation.net/e/wipeouthd/assets/WipEoutHD_EN_1080p.zip

So Cyberlinks DXVA Decoder is again the only one who doesn't drop frames in this configuration (using a Hardware decoding mode)

Arcsoft DXVA = drop (immediately)
CoreAVC 2.0 CUDA = drop (immediately)
CoreAVC 2.5 CUDA/DXVA = drop (immediately)
CoreAVC 2.5.5 CUDA = drop (immediately)
CoreAVC 2.5.5 DXVA = switches to CPU decoding (it's a workaround but its not really a fix or improvement of the main issue ;) )
CUDA Video Decoder DXVA = drop (immediately)
Cyberlink DXVA = OK fluid 0-1 jitter
Divx DXVA = drop (immediately)
ffdshow DXVA = drop (after 12 seconds)
LA CUVID CUDA = drop (after 12 seconds)
Mainconcept DXVA = drop (after 12 seconds)
MPC-HC DXVA = drop (after 12 seconds)

PS: I was wrong in the LA CUVID thread also CoreAVC 2.0 with CUDA suffers from the frame dropping, actually Cyberlinks DXVA Decoder is really the only one which doesn't (so practically the worlds only).

Especially the 12 second pattern difference for some Decoder is interesting (2 at least same codebase, could be a indication for a buffering difference) :)

[desta]

You are the only report that it still has issue.s Please confirm your running 2.5.1 and have even tried a reboot.
http://img715.imageshack.us/img715/7550/251q.png

Sample: http://www.mediafire.com/?n4rlu8qja6b7ldd

[Twingo]

Thank you for the sample.... What are you using for a renderer? We are seeing mixed results here, it plays properly with most renderers but not all.

I'm using vmr9-renderless for it's required by MPC-HC to load the subtitle itself, so I don't know exactly which renderer it is, though I see coreavc decoder showing up in the filters section togerther with vmr9 renderless.

[dead_screem]

betaboy, I can't login to the core account portal. I forgot my password and I can't receive the reset emails, aol seems to be blocking them (and comcast as well, as I tried changing to a comcast email last time I had account access and they were blocking your emails too.)
I already have a support ticket open at http://support.corecodec.com/ open since the 24th but so far nobodys responed. Please look into it. The ticket number is #WMO-768-18430. Thanks.

[Ice =A=]

Just tested 2.5.1 and it works well and seems to be a few percent faster (on a SandyBridge 2600) as well.
I'll test it on an Atom processor sometime where speed is more important than on a "real" cpu... :)

Also a bug in 2.0 which caused stuttering in some videos seems gone.

Good work as far as I can tell! :)

[BetaBoy]

Just tested 2.5.1 and it works well and seems to be a few percent faster (on a SandyBridge 2600) as well.
Reports so far point are close to a 4-5% increase in speed.

[BetaBoy]

betaboy, I can't login to the core account portal. I forgot my password and I can't receive the reset emails, aol seems to be blocking them (and comcast as well, as I tried changing to a comcast email last time I had account access and they were blocking your emails too.)
I already have a support ticket open at http://support.corecodec.com/ open since the 24th but so far nobodys responed. Please look into it. The ticket number is #WMO-768-18430. Thanks.

PM me your info.... i'll look into it.

[dead_screem]

PM me your info.... i'll look into it.

pm sent. thanks.

[BetaBoy]

Sample: http://www.mediafire.com/?n4rlu8qja6b7ldd
Im not seeing anything wrong with that clip here on my 3 systems.

Are you using Haali's splitter? or any custom renderer?

[Chumbo]

@BetaBoy,
I just installed 2.5.1 and wanted to follow up on the two issues I reported earlier.

Regarding the smooth playback issue (http://forum.doom9.org/showthread.php?p=1487664#post1487664), still broken in software decoding and worse in DXVA as no video is rendered at all (MPC-HC using EVR Custom Pres). When it worked earlier via software and was smooth, it was because I forgot I had used the Haali Renderer temporarily.

Regarding the corruption issue (http://forum.doom9.org/showthread.php?p=1487886#post1487886), no video is rendered using MPC-HC EVR Custom Pres. With Haali Renderer, corruption still there and no DXVA which is expected.

[BetaBoy]

CoreAVC pretty much relies on the source filter's information. Thought this was once fixed already. Most other decoders detect the format on their own without relying on the source filter's information.

They are doing it wrong. CoreAVC 'has to' propose an output format before it even sees any of the stream info, so it has no choice but to rely on the info from the source filter.

[madshi]

They are doing it wrong. CoreAVC 'has to' propose an output format before it even sees any of the stream info, so it has no choice but to rely on the info from the source filter.
True, but once you start to receive bitstream and detect that the bitstream contradicts the source filter's information, it might make sense to do a dynamic format change (http://msdn.microsoft.com/en-us/library/dd388731%28v=vs.85%29.aspx). At least if there'd be corruption or crashes otherwise.

[CiNcH]

They are doing it wrong. CoreAVC 'has to' propose an output format before it even sees any of the stream info, so it has no choice but to rely on the info from the source filter.
Well it works correctly with the SW path of your decoder. Which means that even if the source filter propagates the wrong parameters the output is correct. Different story with the DXVA path as mentioned.

Other decoders work properly with wrong information too, even with DXVA.

[desta]

Im not seeing anything wrong with that clip here on my 3 systems.

Are you using Haali's splitter? or any custom renderer?
I used Haali's splitter along with every renderer available in MPC-HC (x86 and x64).


update: Just downgraded my nvidia drivers from 266.58 to 258.96 and CoreAVC 2.5.1 now works with cuda enabled. Nvidia broke something?

[dead_screem]

betaboy, any news on getting my password changed?

[BetaBoy]

True, but once you start to receive bitstream and detect that the bitstream contradicts the source filter's information, it might make sense to do a....
Thanks madshi.... we are taking a look.

[BetaBoy]

betaboy, any news on getting my password changed?

PM sent with a new one.

[BetaBoy]

Well it works correctly with the SW path of your decoder. Which means that even if the source filter propagates the wrong parameters the output is correct. Different story with the DXVA path as mentioned.

Other decoders work properly with wrong information too, even with DXVA.
ok for the info... we are gonna look into it more.

[dead_screem]

PM sent with a new one.

Thanks much! I also sent a new PM with additional info, be sure to read it.

[desta]

update: Just downgraded my nvidia drivers from 266.58 to 258.96 and CoreAVC 2.5.1 now works with cuda enabled. Nvidia broke something?
Any news on this or do I need to keep my nvidia drivers out of date to use CoreAVC now?

[thewebchat]

Just tested Core 2.5.

About performance: exactly the same as 2.0 (lol @ "faster overall" --> 139.5 fps vs 139.2 fps)
About 64-bit support: still slower than 32-bit version (133 fps vs 139 fps)

I think this release is pretty much the definition of underwhelming. Unless there's something magical about Core DXVA that's not already in 9001 other decoders (frame read-back to system memory?), I'm struggling to find a reason for anyone to get this.

Pretty much every niche that Core tries to cover is already occupied by free software:

Software decoding: DivX H264, ffmpeg-mt
DXVA: Windows 7, MPC-HC
CUDA: nevcairel's CUVID decoder

Too bad, too sad. It's too late for CoreCodec to try to remain relevant with their sub-standard products.

[kieranrk]

Too bad, too sad. It's too late for CoreCodec to try to remain relevant with their sub-standard products.

Lets just ignore their licensing business, right?

[BetaBoy]

thewebchat thx for your opinion and fud. But I think our customers and OEM partners might think otherwise and we thank them for their continued support.

[hajj_3]

what app can i use to check the fps with?

[Virtual_ManPL]

Will this bug be fixed in CoreAVC 2.5 release ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600
That should be fixed.

I got reports that it's not fixed in version 2.5.1 :(

[NikosD]

Updated benchmark results with CoreAVC v2.5.1 (CPU & DXVA) vs CoreAVC v2.0 & others here:

http://forum.doom9.org/showthread.php?t=159486

Two comments:

1) CoreAVC v2.5.1 CPU is the fastest codec. Second best is CoreAVC again (previous version v2.0)

2) CoreAVC v2.5.1 DXVA has almost identical results with MPC-HC DXVA & FFDShow DXVA

[eddman]

I'm confused. Is 2.5's DXVA path Radeon only?

[CruNcher]

Nope its suited for both ATI/NVIDIA

CUDA support is only for NVIDIA though is almost useless (Playback) except for the to much reference bitstream case their it can help enourmously without losing hardware accelleration to display such streams on Nvidia Cards :) though it has a overhead compared to DXVA on Windows so it shouldn't be enabled by default and CoreAVC should get a Adaptive mode where it depending on the Bitstream can switch from DXVA/CUDA/SOFTWARE.
Mainconcept are the first ones who borrowed the idea from ffdshow and MPC-HC (the idea came from doom9) and implemented this Adaptive mode switching from DXVA to SOFTWARE if necessary to avoid Playback problems in their commercial decoder.

[eddman]

Thank you, CruNcher.

[BetaBoy]

We hope to have DXVA adaptive switching done within the next 2 releases.

[hajj_3]

so what can we expect in the next release?

[BetaBoy]

These are planned...

- DXVA Fallback when the stream isn't compatible
- DXVA Handling mid-stream resolution changes
- Different handling of quant matrices for ATI/NVidia
- Long slice mode / intel support
- Clean up/merge DXVA defines

However you can now add a fix to the 'seeking Open GOP issue' as we are going to add it as an option to turn it on or off, as it will effect seeking speed in directshow if on.

[hajj_3]

could you clarify what the intel support is, i've got a core i5 laptop, would i see any benefit? Do you think you can make the cpu decoding any better than it is now or have you pushed it to it's limit as my single core 32bit intel core solo 1.83ghz laptop still uses alot of cpu for 720p files and higher bitrate 720p is 100% cpu and jerky.

[pankov]

Guys,
I've just switched from ATI to NVidia and I have a question about frequencies/clocks and power consumption:
Is it normal that my new GeForce GTX460 switches to max 3D core/shader/memory clocks when I use CUDA decoding?
My old integrated NV9400 could decode the same H.264 video files so I can't believe that this new card which has 10 times the computing power will need to go in full power mode to decode them.
Currently I'm very disappointed because with full 3D clocks the card goes hot very quickly and the fans start to get loud. My old ATI 5750 (in DXVA mode) was switching clocks from the idle/desktop ones but not to the max ones and it's temperature raised just a little.
Can I control what frequencies/clocks does the card use for CUDA decoding? ... or at least for a given application ... or at least is there a way to switch power profiles via command line?

[PaxRoma]

tried coreAVC 2.5.1 to play x264 1080p movie and the picture will be jerky/stutter every 15-30 secs in full screen.Audio is not jerky but the picture is. This does not seem to happen in windowed mode. Is there a way to fix this. I have
Windows 7 Ultimate - N53JF Asus laptop. Nvidia driver 267.76
Player: WMP Decoder: CoreAVC CUDA on Splitter: Haali. Laptop is being used as a HTPC hooked up to a Sony TV

[Maccara]

The teams are looking into the field order... but they already commented on how you get random field order changes when starting and seeking and how most renderers break.

On my system (XP x64, AMD, ATI 4850) I noticed this is also dependent on the splitter used. (Re-seeking a few times usually fixes this also)

With MP4 files (VMR9 renderless)
Haali: after seek random field ordering
MPC-HC internal splitter: same problem
LAV : OK (haven't managed to get wrong field order yet)

[Anakunda]

Hello, I Installed this codec for a try, and got following problem: KMPlayer won't use it's default codec anymore, instead ffdshow(libavcodec) is used to decode played AVC, resulting in improper AR including other impropernss. Anybody who also faced this problem knows why directshow is used although in KMPlayer internal codec is preferred?
Anyway do I need to use CoreAVC if I don't have speed issues with HD video? (In fact I have a small freezing on FullHD videos but I don't own much of them so it's not such a problem).

[desta]

tried coreAVC 2.5.1 to play x264 1080p movie and the picture will be jerky/stutter every 15-30 secs in full screen.Audio is not jerky but the picture is. This does not seem to happen in windowed mode. Is there a way to fix this. I have
Windows 7 Ultimate - N53JF Asus laptop. Nvidia driver 267.76
Player: WMP Decoder: CoreAVC CUDA on Splitter: Haali. Laptop is being used as a HTPC hooked up to a Sony TV
You might want to try downgrading your Nvidia drivers. Going back to 258.96 worked for me.

If it works I'm not suggesting this as a permanent fix, but just to test. If it does work though then obviously there's either a problem with the drivers or coreavc. I'm still waiting for anyone from the corecodec team to get back to me about it (even from the customer portal).

[BetaBoy]

Desta.... we are looking into your report, thanx.

[Fadeout]

I tried to see if it fixed the problem of OP and ED not working in certain anime that use different files/chapters. It does (while default DXVA would give problems).

On the other side there are blocks of colors everywhere, while standard DXVA works without any problems.

This on a ATI 4850.

[BetaBoy]

Strike the option for the opengop fix as it will be on by default, as seeking speed is no excuse to ignore the spec.

[Virtual_ManPL]

I would gladly see fix for this bug (http://forum.doom9.org/showthread.php?p=1390600#post1390600) in next version...

Any plans on this BetaBoy ?

[Anakunda]

nobody knows why CoreAVC steals KMPlayer internal AVC codec?

[Episodio1]

LOL ANAkunda... But you got late, April 1st was yesterday. ;)

[Anakunda]

that's no LOL

[ChronoCross]

nobody knows why CoreAVC steals KMPlayer internal AVC codec?

Got anything to back that up?

@BetaBoy

BTW it's good to see that 1.25 years of QC and this release was still buggy as hell. Might want to fire your QC team.

[Anakunda]

Got anything to back that up?


Got something to back that up, but wanna know why CoreAVC interfers with KMPs codecs.

[me7]

Got something to back that up, but wanna know why CoreAVC interfers with KMPs codecs.

Do you mean to say that Core AVC steals code from KMPlayer or that it forces itself to be loaded on playback instead of some internal decoder?
You previous post sounds like the former.

[Anakunda]

Do you mean to say that Core AVC steals code from KMPlayer or that it forces itself to be loaded on playback instead of some internal decoder


Yes this is it. Registering CoreAVC codec forces KMP to use directshow extern codec instead of internal dependless I have chosen to prefer it.

[BetaBoy]

Might want ....
The teams did and amazing job testing and considering the vast amount of work that went into CoreAVC v2.5, some of which your not even seeing yet.

Bugs are common place with major milestones... and we are following through with fast releases for 2.5 and 2.6 to adapt to this. We thank the beta teams for all their hard work with testing.

Otherwise on kmplayer... Pls refrain from FUD... post reg diff's to show we have done something diff from 2.0 to 2.5.. but from a short look at the code commits, we have not touched anything related to file association/type since 2.0 in the installer unless Haali did something with his. Ill ping the team on it.

[BetaBoy]

I would gladly see fix for this bug (http://forum.doom9.org/showthread.php?p=1390600#post1390600) in next version...
madshi and I spoke about this several pages back.

[CruNcher]

http://forum.doom9.org/showpost.php?p=1489508&postcount=1196

No bad result :)

http://www.multiupload.com/PYBILYB30E <- file tested

Actually this happens with almost every .m2ts stream and Haali + CoreAVC 2.5.1 DXVA @ least slice borders become always visible (NVidia VP2)
most x264 streams are fine (no slices no mbaff)

http://img43.imageshack.us/img43/2044/sliceborders.png

The more i look through my database the more streams i find that show strange results with CoreAVC DXVA and Nvidia, so i guess that you say for ATI UVD cards only currently has a valid reason so Nvidia user better switch to the green tray icon even if its a tad slower http://forum.doom9.org/showpost.php?p=1489410&postcount=48 that way you avoid seeing such rendering problems as above for some streams and of course the complete to much reference frames block attack ;)

[BetaBoy]

Thx for the report CruNcher!

[Fadeout]

Nope, I have that problem with ATI.

Not those bars, but those blocks of colors everywhere on the image. See this:
http://img402.imageshack.us/i/45370501.jpg/

Works fine in MPC-HC DXVA and CoreAVC CPU. Is bugged with CoreAVC DXVA.

[PaxRoma]

You might want to try downgrading your Nvidia drivers. Going back to 258.96 worked for me.

If it works I'm not suggesting this as a permanent fix, but just to test. If it does work though then obviously there's either a problem with the drivers or coreavc. I'm still waiting for anyone from the corecodec team to get back to me about it (even from the customer portal).

still not working after the downgrade. Weird thing is that this picture stutter/jerk only happen in full screen mode.

[CruNcher]

Dan maybe some of your CoreCodec guys has a answer to this and know where the bottleneck might be (at least you worked a heavy time on implementing NVCUVID into CoreAVC with Nvidia) :) ?
http://forum.doom9.org/showpost.php?p=1490026&postcount=67
or do i get it wrong and the playback behavior is what should be expected on XP and G92 (VP2) ? compared to VMR7/9 windowed ?

[Pyroshock]

Nope, I have that problem with ATI.

Not those bars, but those blocks of colors everywhere on the image. See this:
http://img402.imageshack.us/i/45370501.jpg/

Works fine in MPC-HC DXVA and CoreAVC CPU. Is bugged with CoreAVC DXVA.

I have the same problem with my ATI card, and only when DXVA is enabled. My Blu-ray movies will have annoying blocky bands, or terrible glitches. It doesn't happen on lower bitrate files though, around 15,000 seems to be where it starts.

http://i.imgur.com/UdRKI.jpg
http://i.imgur.com/AAl2k.jpg
http://i.imgur.com/m0IUf.jpg

My card is a Mobility Radeon HD 4670.

[Episodio1]

CRUNCHER, i sent you a PM the other day, but I got no reply. :(

How did you get that M2TS from Canal+? Did you extract it straight from the official DVR ?

[CruNcher]

Sorry missed it, it's not by me its a sample floating around dunno how it was acquired from the source

[BetaBoy]

Dan maybe some of your CoreCodec guys has a answer to this and know where the bottleneck might be (at least you worked a heavy time on implementing NVCUVID into CoreAVC with Nvidia) :) ?
http://forum.doom9.org/showpost.php?p=1490026&postcount=67
or do i get it wrong and the playback behavior is what should be expected on XP and G92 (VP2) ? compared to VMR7/9 windowed ?
Ill have squid comment on it.

[neograniceni]

still not working after the downgrade. Weird thing is that this picture stutter/jerk only happen in full screen mode.

The same problem here. 257.21 works OK.

[BetaBoy]

Thanks for the hint, I uploaded and the link is at

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

Bug confirmed. We have not done a fix yet, but it is DXVA related.

[desta]

Desta.... we are looking into your report, thanx.
Thanks, but the last time I heard anything from support was March 29th.

[BetaBoy]

Thanks, but the last time I heard anything from support was March 29th.

That's because I replied to you here. The support staff monitors this thread daily.

[Anakunda]

I have found a HD video that causes CoreAVC to crash. Using it together with KMPlayer and Haali Splitter. Can I generate an diagnostic report, or change some settings to be able play this video with CoreAVC?

[toomyzoom]

I feel like wasting $10 for this pathetic performance in DXVA. I got the same problem like http://forum.doom9.org/showpost.php?p=1489520&postcount=6232. On the same video, MPC-HC's internal DXVA decoder gave no problems. It does a better job than Coreavc. Moreover, CoreAVC's DXVA mode can't be used together with MadVR renderer, only EVR or EVR-CP. Taking too long to release an unfinished product.
Even with CUDA, there are a lot of playback problems that's not even exist in 2.0. Coreavc 2.5.1 takes forever to load and sometimes just stuck at opening the videos.

[Anakunda]

and sometimes just stuck at opening the videos.

exactly

[madshi]

Moreover, CoreAVC's DXVA mode can't be used together with MadVR renderer, only EVR or EVR-CP.
That's not really Core's fault, though. madVR simply doesn't support DXVA (yet?).

[CruNcher]

I guess you both ask the guy who develops it, who was it again, wasn't it this German guy geez cant remember his Online name maradshi ? ;)

[toomyzoom]

That's not really Core's fault, though. madVR simply doesn't support DXVA (yet?).

Hi madshi, I hope you can make MadVR support DXVA. EVR-CP gave me terrible black level and sharpness.

[BetaBoy]

exactly

Pls post samples of any such videos for us to look at

As far as DXVA is concerned... Give us a little time to address both the bug reports and upcoming dxva specific features we have planned in the todo. We will continue to push out fast releases as they pass QA.... and to that you can likely expect a new version this coming week if all goes well.

Our timeline is short for finishing DXVA (3 months) compared to almost a year of preparations and work to get it to where we are at now.... We thank everyone for their continued support and the D9 community for some amazing feedback.

[BetaBoy]

I feel like.... I see that your new here to Doom9, welcome. While we are grateful for your opinion... We ask that you post 'facts'. To help with this pls post in a manner to better help us help you... To that, things like hardware specifics, software configuration, splitter info, renderer info, and sample content always helps.

Thank you.

[mkanet]

On my setup (Nvidia + Intel Quadcore CPU), DXVA seems to generally have slightly better performance than CUDA. Such as AVC/1080i from DishNetwork. However, I see weird video quality issues with CoreAVC 2.5.x using DXVA that I didnt have in CoreAVC 2.0; at least under SageTV Media Center 7 with EVR enabled. In fact, I used to use only DXVA under CoreAVC 2.0 as my primary AVC video decoder under SageTV and all other directshow players without significant issues. Ever since I upgraded to CoreAVC 2.5.1, I've been forced to use CUDA; or, I have video issues such as the below with DXVA.

I might have to either revert back to CoreAVC 2.0.

EDIT: However, CoreAVC 2.5.1 (with CUDA) and LAV splitter still does a better job than the latest MPC-HC using it's own internal splitter and respective AVC DXVA decoder on my PC for certain material.

Bottom line, I dont know if CoreAVC 2.5.1 using Cuda is better or CoreAVC 2.0 with DXVA. I dont mind the extra performance hit in CUDA if there's something it can do better than DXVA (if CoreAVC DXVA is working correctly).

http://i67.photobucket.com/albums/h283/mkanet/Screenshot-14642.jpg

http://i67.photobucket.com/albums/h283/mkanet/Screenshot-14652.jpg

I hope this isn't a dumb question, but what were the "intended" benefits from CUDA over DXVA in CoreAVC 2.5.1? I dont seen anything that CUDA does better; at least it's not obvious to me.

[Cyber-Mav]

coreavc 2.0 doesnt even support dxva , so when you say "CoreAVC 2.5.1 using Cuda is better or CoreAVC 2.0 with DXVA" you come across as being clueless. coreavc 2.5.1 does both cuda and dxva support. coreavc 2.0 is cuda only for gpu acceleration.

[mkanet]

Ok, I dont remember what Coreavc 2.0's default nvidia hardware acceleration was called. I thought it used DXVA. So whatever method CoreAVC 2.0 used for nvidia hardware acceleration is what I was referring to. It probably wouldn't be wise to completely dismiss the symptoms I mentioned based on that; especially if they appear to be consistent with what others have reported.

Just to be clear, whatever method was used under 2.0 for nvidia hardware acceleration (without "Prefer CUDA acceleration" being selected), it seemed to work better than 2.5.1's "DXVA" on my PC. It also appeared to be less hardware intensive than 2.5.1 "Cuda" support, IIRC.

coreavc 2.0 doesnt even support dxva , so when you say "CoreAVC 2.5.1 using Cuda is better or CoreAVC 2.0 with DXVA" you come across as being clueless. coreavc 2.5.1 does both cuda and dxva support. coreavc 2.0 is cuda only for gpu acceleration.

[namaiki]

Just to be clear, whatever method was used under 2.0 for nvidia hardware acceleration (without "Prefer CUDA acceleration" being selected), it seemed to work better than 2.5.1's "DXVA" on my PC. It also appeared to be less hardware intensive than 2.5.1 "Cuda" support, IIRC.

That would be decoding on the CPU.

[CruNcher]

On my setup (Nvidia + Intel Quadcore CPU), DXVA seems to generally have slightly better performance than CUDA. Such as AVC/1080i from DishNetwork. However, I see weird video quality issues with CoreAVC 2.5.x using DXVA that I didnt have in CoreAVC 2.0; at least under SageTV Media Center 7 with EVR enabled. In fact, I used to use only DXVA under CoreAVC 2.0 as my primary AVC video decoder under SageTV and all other directshow players without significant issues. Ever since I upgraded to CoreAVC 2.5.1, I've been forced to use CUDA; or, I have video issues such as the below with DXVA.

I might have to either revert back to CoreAVC 2.0.

EDIT: However, CoreAVC 2.5.1 (with CUDA) and LAV splitter still does a better job than the latest MPC-HC using it's own internal splitter and respective AVC DXVA decoder on my PC for certain material.

Bottom line, I dont know if CoreAVC 2.5.1 using Cuda is better or CoreAVC 2.0 with DXVA. I dont mind the extra performance hit in CUDA if there's something it can do better than DXVA (if CoreAVC DXVA is working correctly).

http://i67.photobucket.com/albums/h283/mkanet/Screenshot-14642.jpg

http://i67.photobucket.com/albums/h283/mkanet/Screenshot-14652.jpg

I hope this isn't a dumb question, but what were the "intended" benefits from CUDA over DXVA in CoreAVC 2.5.1? I dont seen anything that CUDA does better; at least it's not obvious to me.

DXVA is a tad faster (being the native Microsoft API) though Nvcuvid is more error prone so it makes sense to switch based on different stream scenarios between them dynamically that's what's coming up in CoreAVC :) also i guess CoreCodec is already working on implementing OVD additionally to Nvcuvid for ATI/AMD UVD users. The overhead of Nvcuvid seems to become more visible also the Higher you push it to it's borders (depending also on the Hardware) see my Benchmark in the DXVA thread comparing DXVA vs Nvcuvid on rather old G92 VP2 XP without memcopy Hardware improvements http://forum.doom9.org/showpost.php?p=1490026&postcount=67.

[mkanet]

Update: It looks like Cyber-Mav was correct. I was clueless. :) It looks like the sluggishness I was seeing was NOT caused by CoreAVC 2.5.1 CUDA mode. The sluggishness was caused by something completely different. I had installed Reclock at the same time I upgraded to CoreAVC 2.5.1. As soon as I uninstalled Reclock, videos play back without any sluggishness. Unfortunately, I still see the same display issue with DXVA under sageTV EVR mode. I'm fine with using CoreAVC 2.5.1 CUDA now.

I know this may be like comparing apples and oranges, but are there any video quality differences between CoreAVC 2.0 (without cuda) and CoreAVC 2.5.1 cuda mode? I haven't looked at CoreAVC 2.5.1 Cuda mode closely enough to see picture quality improvements.

Thanks again,
MKANET
DXVA is a tad faster (being the native Microsoft API) though Nvcuvid is more error prone so it makes sense to switch based on different stream scenarios between them dynamically that's what's coming up in CoreAVC :) also i guess CoreCodec is already working on implementing OVD additionally to Nvcuvid for ATI/AMD UVD users. The overhead of Nvcuvid seems to become more visible also the Higher you push it to it's borders (depending also on the Hardware) see my Benchmark in the DXVA thread comparing DXVA vs Nvcuvid on rather old G92 VP2 XP without memcopy Hardware improvements http://forum.doom9.org/showpost.php?p=1490026&postcount=67.

[Tom Keller]

I know this may be like comparing apples and oranges, but are there any video quality differences between CoreAVC 2.0 (without cuda) and CoreAVC 2.5.1 cuda mode? I haven't looked at CoreAVC 2.5.1 Cuda mode closely enough to see picture quality improvements.
Afaik ALL available H.264 decoders (as long as they are following the H.264 specs) should deliver exactly the same output, since the DCT coefficients (http://en.wikipedia.org/wiki/Discrete_cosine_transform) for H.264 are standardized. It doesn't matter if you're using CUDA, DXVA or pure software decoding - "exactly the same" in this case means: bit-exact!

So: apart from possible bug-related distortions there shouldn't be any video quality differences between CoreAVC 2.0 and CoreAVC 2.5.1, since CoreAVC follows the H.264 specifications.

[molitar]

Hi Betaboy, I have done posts in the past not alot but around 15.. but now when I login to the forum I can not post or reply to anything. I have tried the support site and submitted a trouble ticket.. I been ignored :( I even done a web feedback form and again been ignored.. CoreAVC 2.5.1 has been artifacting in mpc-home with CCCP pack on Windows 7 32 bit but can not submit this problem on the actual forums since my account is broken. Can you please fix my forum access for corecodec and find out why my trouble ticket has been ignored all this time? Thanks.

[BetaBoy]

We are looking into the forum issue, sorry for any issues there... and the ticket was not being ignored just waiting to hear back on what the issue is with the password reset.

[molitar]

We are looking into the forum issue, sorry for any issues there... and the ticket was not being ignored just waiting to hear back on what the issue is with the password reset.

Ok Thanks Betaboy. Would of been nice to had that mentioned in the ticket but good to know it's being worked on :) I finally moved to Windows 7 and I am seeing artifacts for short periods of time using DXVA currently.

[techouse]

I am noticing some weird artefacts with CoreAVC 2.5.1 DXVA enabled (ATi Radeon HD 5750, Catalyst 11.3) when watching cartoons (i.e. SouthPark). Example:
http://anony.ws/dt-HIWB.png (http://anony.ws/di-HIWB.png)

With DXVA acceleration disabled these artefacts do not occur.

However there are no artefacts when watching standard movies with DXVA enabled.

[molitar]

Betaboy, Their is a seek bug in 2.5.1 when using DXVA also.. when forwarding the playback will slow way down as if I had used playback rate. I even turned off playback rate by keyboard in mpc-home to make sure I wasn't accidently triggering it. I am not.. I try to do 5 second or 20 second jumps in mpc-home using DXVA and playback will stop functioning correctly and be like I hit slow motion or pause. Only method to fix when this happens is to usually stop.. manually move slider to the time it happened and start the show again.

[Virtual_ManPL]

@ molitar - try it with different splitter like internal MPC-HC, LAV Splitter or Haali
because it can be splitter issue

[Roobaj]

I get this error whenever I switch video window from primary monitor to secondary (1080p HDTV):

http://i.imgur.com/apbFF.jpg

Setup:

CoreAVC 2.5.1 + latest CCCP with MPC-HC internal subs ON + DXVA ON (red icon).

ATI AMD Radeon HD 4850 with latest Drivers to date version 11.3.

Windows 7 SP1 64bit.

NOTE: This only happens with DXVA enabled.

[BetaBoy]

A heads up... We were gonna jump to v2.6 and add some new DXVA features, but we have opted to call it v2.5.5 and focus the release more on DXVA bug fixes and other CORE fixes including the outstanding one for opengop.

[hajj_3]

so v2.5.5 will just be a bugfix release? Or will it add some DXVA features too? Any eta on it?

thanks.

[CruNcher]

Its pretty clear what Dan wrote they skipped the features to bring out the fixes faster to market so they dropped down to 2.5.5 and not a major version as they planed 2.6 with new features but that will be released later fixes have priority (especially DXVA ones as this is practically since release not usable for many streams, and needs to be fixed urgently as more and more reports are arriving @ CoreCodec and as long as they leave it unfixed as more customer commercial as well as private they risk to lose).

[hajj_3]

yeah i mis-read it. Bug fixes sound good to me, no rush on adding new features.

[ChronoCross]

So many bugs that they have to push out releases outside of their normal bi-century release schedule? crazy.

[CruNcher]

If the Beta testers would have done their job properly i guess it could have been avoided, though yeah somehow it is awful to think about that someone who implements this let all the responsibility for testing @ it's beta testers ;)

[ChronoCross]

If the Beta testers would have done their job properly i guess it could have been avoided, though yeah somehow it is awful to think about that someone who implements this let all the responsibility for testing @ it's beta testers ;)

Ultimately the programmers are primarily responsible for buggy applications. Their corporate QC is next, followed lastly by beta testers. For a company that took so long to make this release it seems a bit odd that it still had so many bugs.

[Gleb Egorych]

Are there in 2.6 any fixes related to interlaced content?

[BetaBoy]

We have compiled v2.5.5 RC. We are gonna take the weekend to do QA. The changelog as it stands now:

- FIX: Clean reference lists when seeking to a SEI recovery point
- FIX: matrix ordering for buggy ATI DXVA implementation
- FIX: non-transposed matrices for NVIDIA DXVA mode
- FIX: validate GPU type, driver version and stream parameters before using DXVA

[Roobaj]

@BetaBoy

Just wondering but does 2.5.5 fixes my problem?

[CiNcH]

- FIX: Clean reference lists when seeking to a SEI recovery point
- FIX: matrix ordering for buggy ATI DXVA implementation
- FIX: non-transposed matrices for NVIDIA DXVA mode
- FIX: validate GPU type, driver version and stream parameters before using DXVA
Aha. Sounds like a lot bla bla to me. I am out of here guys...

[molitar]

Excellent glad to hear.. Because currently I had to disable Corecodec completely to even watch videos it got so bad on many of them. So using ffdshow in CCCP pack for now until the fix is released. BTW what about the forums? I really would like to be able to post there again.

[ChronoCross]

Excellent glad to hear.. Because currently I had to disable Corecodec completely to even watch videos it got so bad on many of them. So using ffdshow in CCCP pack for now until the fix is released. BTW what about the forums? I really would like to be able to post there again.

Why would you want to post on their forums? They sensor and/or ban people who say things they don't like.

[BetaBoy]

Chrono.... That's the 5th time in the past few pages for your FUD and Off topic interjections. Moderators notified.

[madshi]

Chrono.... That's the 5th time in the past few pages for your FUD and Off topic interjections.
Agreed, he's clearly trolling, a thread cleanup and a ban from this thread would be appropriate.

[Cyber-Mav]

these bugs are to be expected, at the end of the day what more can you expect from someone called "BetaBoy". wonder what would happen with software from "AlphaBoy"

[BetaBoy]

:-)

We are prepping the site and email for v2.5.5 now. Everyone should see emails on the update availability later tonight.

[BetaBoy]

CoreAVC 2.5.5 released. Current customers can login to our customer portal to download the latest release: http://customers.corecodec.com

Here is the changelog:
CoreAVC H.264 Video Codec - Version 2.5.5.0 (20110426)
- FIX: Clean reference lists when seeking to a SEI recovery point
- FIX: matrix ordering for buggy ATI DXVA implementation
- FIX: non-transposed matrices for NVIDIA DXVA mode
- FIX: validate GPU type, driver version and stream parameters before using DXVA


Emails are going out now announcing the release.

[Mixer73]

CoreAVC 2.5.5 released. Current customers can login to our customer portal to download the latest release: http://customers.corecodec.com


Thanks BB, clearly people here like to piss and moan, as someone who's worked in software companies for a long time, no testing can ever do what releasing something into the field can, and I applaud the fast fixes.

[robpdotcom]

2.5.5 fixed the issue I was having with DXVA - thanks for the quick work.

[Barlow]

All files I threw at it so far worked fine.
Also ordered chapters work fine, where other decoders fail (MPC video decoder and MS DTV decoder).
I'll use CoreAVC as my main decoder from now on :)

[ChronoCross]

Chrono.... That's the 5th time in the past few pages for your FUD and Off topic interjections. Moderators notified.

It's not FUD, I've watched you do it and there was even a complaint about it in this very thread from another user.

I'm sorry that I don't agree with you on how you handle your business but I have every right as a customer who purchased your product to make commentary and provide potential customers insight into your product. If you don't like it then close your business down.

The fact that it took over 1 year for you to make an additional release, combined with the fact that it has so many bugs is something that people should be aware of before investing any cash into it.

[eddman]

I'm sorry that I don't agree with you on how you handle your business but I have every right as a customer who purchased your product to make commentary and provide potential customers insight into your product. If you don't like it then close your business down.

You're not providing "insight". You're just bashing the product and corecodec left and right with no reason.

The fact that it took over 1 year for you to make an additional release, combined with the fact that it has so many bugs is something that people should be aware of before investing any cash into it.

If they were deliberately delaying 2.5.0 then tell me why they released 2.5.1 and 2.5.5 so fast. They even decided to postpone 2.6.0 and instead go with the bug-fixing 2.5.5 just to be able to release it sooner.
Bugs in major updates are to be expected and besides a DXVA decoder is more complicated than a software one and there are so many non-standard videos and different GPUs that it won't be possible to test it for all possible cases.

[Fadeout]

All files I threw at it so far worked fine.
Also ordered chapters work fine, where other decoders fail (MPC video decoder and MS DTV decoder).
I'll use CoreAVC as my main decoder from now on :)

Same here. It seems doing everything to perfection. DXVA also works on SD videos.

[ChronoCross]

You're not providing "insight". You're just bashing the product and corecodec left and right with no reason.

umm.....please re-read the last 9 pages of bugs. My insight is directly related to the historical behavior of the company. Which are perfectly valid points.


If they were deliberately delaying 2.5.0 then tell me why they released 2.5.1 and 2.5.5 so fast. They even decided to postpone 2.6.0 and instead go with the bug-fixing 2.5.5 just to be able to release it sooner.

That would be because the product was so epicly broken that they couldn't justify putting the fixes off until 2.6.0. Which has been the typical standard for their bug fixing in previous editions aka "it only occurs with certain circumstances so we will put off the fix for the next release" bugfix schedule.

[BetaBoy]

It's not FUD...
Oh look, it's more of the same... FUD and bashing with nothing of relevance to interject into the thread.

Will a moderator pls...

[hajj_3]

That would be because the product was so epicly broken that they couldn't justify putting the fixes off until 2.6.0. Which has been the typical standard for their bug fixing in previous editions aka "it only occurs with certain circumstances so we will put off the fix for the next release" bugfix schedule.

To be fair it appears that all known bugs have now been fixed with v2.5.5 which is released around 3 weeks after v2.5.0 was released, pretty quick at fixing the bugs if you ask me! I do agree with you about the bugs in regards to v2.5.1, there's no way the WMP bug should have been present in the final release but thats in the past now.

[BetaBoy]

The fact that it...

Facts are this.... good code done 'right' is not easy even though we have some of the brightest engineers here at CC, and with help (icydnk) from some of the lead engineers from x264, VLC, FFmpeg, etc., we all want those HIGH standards. But bugs are just that bugs, even with a large amount of testing they pop up and its something we will address as soon as we can in a followup release. We hope that with 2.5.x you now see we are committed to just that.

Like many engineers/companies we try to strive for those high standards and always will. Nothing has changed from us creating and working on Matroska, EBML, Core-C, CoreMAKE, CorePlayer, CoreAAC, CoreMVC, CoreAVC or any of our other 20+ products/technologies.

We want to adapt our products to come out or be updated as fast as the technology/standards change. Its always been a goal of ours, but its not always achievable given the tasks required.

We continue to thank those for their support by buying our products, or helping the community with amazing feedback.

Without you we are nothing.

[dead_screem]

Facts are this.... good code done 'right' is not easy even though we have some of the brightest engineers here at CC, and with help (icydnk) from some of the lead engineers from x264, VLC, FFmpeg, etc., we all want those HIGH standards. But bugs are just that bugs, even with a large amount of testing they pop up and its something we will address as soon as we can in a followup release. We hope that with 2.5.x you now see we are committed to just that.

Like many engineers/companies we try to strive for those high standards and always will. Nothing has changed from us creating and working on Matroska, EBML, Core-C, CoreMAKE, CorePlayer, CoreAAC, CoreMVC, CoreAVC or any of our other 20+ products/technologies.

We want to adapt our products to come out or be updated as fast as the technology/standards change. Its always been a goal of ours, but its not always achievable given the tasks required.

We continue to thank those for their support by buying our products, or helping the community with amazing feedback.

Without you we are nothing.
You sure? Because CoreAAC has a huge channel order/mapping bug I mentioned on the core codec forums awhile ago.
http://forums.corecodec.com/threads/2386-Incorrect-channel-order-in-5.1
And no comment from anyone on a possible fix... It's nice to see timely quick bugfix only releases for CoreAVC (this is where you guys have been lacking in the past) It'd be nice to get an update for CoreAAC...
And with CoreAAC as it is its completelty useless for anything but 2 channel stereo, even Mono is wrong. CoreAAC treats it as Stereo so sound is only in one speaker instead of properly as Mono/Center channel output.

and there is still no CoreAAC Support ticket section (there is also no General section, wasn't there one before?)

[BetaBoy]

and there is still no CoreAAC Support ticket section (there is also no General section, wasn't there one before?)

I pinged the guys on it, I also see the CoreAAC support is active in the customer portal, but let me why you cannot see it.

[dead_screem]

I pinged the guys on it,What does this mean exactly, will you be posting any info that you get when you hear from the devs? here or in the thread that is on the corecodec coreaac thread I linked?


CoreAAC support is active in the customer portal, but let me why you cannot see it.
Its there in the knowledge base/faq page, but on "new tickets" page only CoreAVC is visible. no CoreAAC and no General (didn't there use to be a general section for site related or other misc support?)

[BetaBoy]

I pinged them on the bug report. Yes there was a full FAQ for it.... looks like a glitch in the portal. We are looking into it, thx for the report.

[Roobaj]

I get this error whenever I switch video window from primary monitor to secondary (1080p HDTV):

http://i.imgur.com/apbFF.jpg

Setup:

CoreAVC 2.5.1 + latest CCCP with MPC-HC internal subs ON + DXVA ON (red icon).

ATI AMD Radeon HD 4850 with latest Drivers to date version 11.3.

Windows 7 SP1 64bit.

NOTE: This only happens with DXVA enabled.

Problem still present with 2.5.5 :(

Can someone please help? Or is this a bug with AMD Catalyst v11.3?

[eddman]

Problem still present with 2.5.5 :(

Can someone please help? Or is this a bug with AMD Catalyst v11.3?

Installing these might help.

http://www.microsoft.com/downloads/en/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c68ccbb6-75ef-4c9d-a326-879eab4fcdf8

[Roobaj]

Installing these might help.

http://www.microsoft.com/downloads/en/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c68ccbb6-75ef-4c9d-a326-879eab4fcdf8


http://i.imgur.com/5QhLy.jpg

Pretty sure these are the same. I have Windows Update on too so my system should be up to date.

[hoborg]

@Roobaj:
You are missing VC++ 2010 x86 SP1. Lates revision is 10.0.40219 and can be download here (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c32f406a-f8fc-4164-b6eb-5328b8578f03).But i am not sure if this fix your issue.

[nussman]

2.5.5:

- no DXVA with DVBViewer Pro Splitter anymore! Is this the DXVA fallback "feature"? This happens because of ... ?
- interlaced content: the field order is still wrong ( http://forum.doom9.org/showthread.php?p=1487593#post1487593 ) => dxva on/off doesnt matter

[BetaBoy]

I'm not aware of any dvbviewer issue ATM, but I'll note it as an issue and check about it.

[Roobaj]

@Roobaj:
You are missing VC++ 2010 x86 SP1. Lates revision is 10.0.40219 and can be download here (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c32f406a-f8fc-4164-b6eb-5328b8578f03).But i am not sure if this fix your issue.

Still the same. :(

Here is the full tech details:

Source
Media Player Classic - Home Cinema

Summary
Stopped working

Date
‎4/‎27/‎2011 12:10 AM

Status
Report sent

Description
Faulting Application Path: C:\Program Files (x86)\Combined Community Codec Pack\MPC\mpc-hc.exe

Problem signature
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.4.2677.0
Application Timestamp: 4cb0edb4
Fault Module Name: CoreAVCDecoder.ax
Fault Module Version: 2.5.5.0
Fault Module Timestamp: 4db127e8
Exception Code: 40000015
Exception Offset: 000c7755
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 808a
Additional Information 2: 808ac3c62dfa0157e801aca65f1c959b
Additional Information 3: 98c9
Additional Information 4: 98c99f52d5f496cb6c4ff08fd879b222

[nussman]

I'm not aware of any dvbviewer issue ATM, but I'll note it as an issue and check about it.
Really?

Haali Splitter => DXVA =on (haali splitter, coreavc, evr custom)
DVBViewer Splitter => DXVA =off (dvbviewer splitter, coreavc, evr custom)


Tested with normal Digital Video Broadcasting (dvb-s2) Source (LiveTV and recording).

If you need a test sample please let me know ...

[CruNcher]

Dan this http://forum.doom9.org/showpost.php?p=1488268&postcount=6181 seems fixed now but only because your DXVA1 decision logic for G92 VP2 512mb seems to be on the trip to avoid any 60p file to be DXVAed @ all im not sure if this is a good way.
The Sony 1080 60p Clip seems fully interoperable with DXVA1 on VP2 (also complexity wise) to fix this Stuttering issue (which only happens on VMR9 Renderless) with 60p files now turning of DXVA1 entirely for all 60p streams seems to be just a workaround not really a fix ;)
Obviously all Visual issues are gone for all other test samples (so that is indeed fixed).

So now i can only DXVA1 1080 60p Streams successfully anymore with Cyberlinks DXVA1 without any issues on any renderer (that supports DXVA) everything else fails stuttering playback (or switches to CPU decoding).
It's crazy too see that only 1 ISV seems to manage this efficiently and even the very big ones fail here they are using btw their 264dsse3.dll
Core I5 2400 here, maybe that plays a role too :)

[hajj_3]

cruncher, have you tried powerdvd 11 to see if their decoder has changed?

[CruNcher]

It's the same stability wise :) there is only 1 test sample where their decoder fails (black screen) :) and others work but that is a combination of Splitter/Decoder issue as with their splitter the file (Old Gpac muxed multi audio stream) magically works ;)

here is another Real Life example of a Stream that switches unnecessarily to CPU Decoding http://www.fileplanet.com/219665/210000/fileinfo/Battlefield-3-%27Fault-Line%27-Complete-12-Minute-HD-Gameplay-Footage but would be perfectly DXVA1ed (and works fine with Cyberlinks DXVA1) :(
Though i see the problem in this deciding which 1080 60p to DXVA and which not based on its complexity and VP2s capability is virtually impossible so (playing safe going the CPU decoding route) is a very valid option. As on some streams (though based on H.264 specs also impossible to create such streams, but easily to brake them for every custom stream done by a not so knowledgeable x264 user for example) Cyberlinks DXVA1 is going to die where CoreAVC would switch to CPU Decoding and work ;)

Do you see the logic Betaboy, why not disabling 1080p 60p DXVA for every stream where x264 is signaled in the user SEI and Bitrate is above a certain level range (taking cabac into account) and leave it available for the rest of Streams that would be a very dirty workaround but fix most issues and be a tad better with what your guys came up with punishing Nvidias VP2 for every 1080 60p stream ;)

Obviously also taking Levels into account as a 1080p H5.1 60p is very unreasonable to work on VP2 fluid for any encoder (though this would be bad again for wrong level signaled streams all old x264 files practically) So building the decision logic based on Resolution,Bitrate,Cabac,ref frames,and FPS should be pretty error prove :)

The 4 Gilrs Clip is a very good one to analyse in those decision regards as its on the Edge (slightly over) of the VP2 capabilities and that for sure should switch to CPU Decoding instead of DXVA (VP2) :)

x264 over the Edge sample Nvidia (VP2)


Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 3mn 21s
Bit rate : 20.7 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.166
Stream size : 485 MiB (97%)
Writing library : x264 core 68 r1183M f21daff
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=2 / 8x8dct=1 / cqm=0 / deadzone=21,11
/ chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=2
/ b_bias=0 / direct=3 / wpredb=1 / keyint=300 / keyint_min=30 / scenecut=40 / rc=2pass / bitrate=20665
/ 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


compared to the Real Life non x264 60p streams VP2 Edge complexity (streams that would work perfectly fine on VP2 DXVA Hardware Decoded)

Sony


Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.2
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=32
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 11s
Bit rate mode : Variable
Bit rate : 19.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.159
Stream size : 169 MiB (99%)
Language : English
Encoded date : UTC 2008-08-01 17:57:05
Tagged date : UTC 2008-08-01 17:57:43
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


Apple


Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.2
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=32
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12mn 7s
Bit rate mode : Variable
Bit rate : 20.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.168
Stream size : 1.77 GiB (99%)
Language : English
Encoded date : UTC 2011-04-06 01:36:51
Tagged date : UTC 2011-04-06 01:38:27
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


So just looking at those even from the Level and Bitrate signaling alone (also cabac is interesting here as bitrate is the same for all) you could build a logic that wouldn't be perfect but at least avoid to switch for every 1080p 60p file unnecessarily to CPU Decoding (and the more you test the more you can refine it) :)


Could somebody on UVD test if 1080p 60p fallsback to CPU Decoding their as well ?

PS: Yep those 2 streams seem to come from the same Encoder (my tip Apple Encoder :P) so many matching things

Before i was on Sandy Bridge i never came to the idea to measure instead of the CPU utilization the Fan Speed but it's crazy Fan Speed is nowdays a very reliable indicator for CPU (Power Consumption) Utilization, especialy with Multicores it's much easier to spot then to watch 4 different Graphs over time (even on the Desktop) :) i realized immediately on the Sound that CoreAVC was running in CPU decoding mode compared to DXVA Cyberlinks Sound (just a crazy tidbit) :)
Especially how fast the Fan speed changes nowdays take place compared to years ago is amazing (latency got so heavily improved hardware wise).
Though even more reliable obviously on SB is the S0 state :)

[desta]

This 2.5.5 release hasn't made the slightest difference to the problem I reported here and on support.... the same support that STILL haven't got back to me. I know I've been told they monitor the forums daily but I find that hard to believe considering the only time Core support contacted me was to ask the exact same question betaboy already had, a day after betaboy asked it.

[Roobaj]

Did you guys test this with the just released AMD Catalyst 11.4?

The situation is a lot worse, videos freeze for sec when opening them and there is no picture as well, just sound.

As for my crashing problem, it still happens but if I move MPC-HC to my other TV and open a video after that it will keep playing normally; in other words it only happens when I switch MPC-HC from one monitor to the other.

Talking about AMD DXVA here only.

[BetaBoy]

This 2.5.5 release...The support staff has not answered because I replied here and the fact that none of the 30+ beta testers cannot duplicate your results. What Video card do you have?

[BetaBoy]

Did you guys test.....Yes, it was tested and no issues were found. I am noting a possible issue, can anyone else confirm?

[BetaBoy]

It's the...

Keep up the amazing feedback! We are listening ;-)

[Roobaj]

Keep in mind that I am using CCCP which comes with outdated filters and MPC-HC.

That could be my issue but I don't wanna get rid of CCCP.

[Virtual_ManPL]

So that's your problem for using it.
Why not use newest MPC-HC and ffdshow? Setting for each can be exported.



@ BetaBoy - I got reports that CoreAVC 2.5.5 still have problems with DxVA mode in this files. Picture is turning green with some small blocked squares.

SAMPLE1 - download (http://www.mediafire.com/?59premeu0e0xrur)

General
Unique ID : 223561937957946125069459676318320399063 (0xA830768C01EBD840A89FB9415D3992D7)
Complete name : C:\Users\Virtual_ManPL\Desktop\sample1.mkv
Format : Matroska
File size : 25.0 MiB
Duration : 24mn 59s
Overall bit rate : 140 Kbps
Encoded date : UTC 2011-04-26 22:42:07
Writing application : mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0
Cover : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 59s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Title : Moshidora - 02
Writing library : x264 core 112 r1834+3 ef18685
Encoding settings : cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.30 / psy_rd=0.40:0.10 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / fgo=5 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 24mn 59s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : Stereo AAC
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : ass
Language : English



SAMPLE2 - download (http://www.mediafire.com/?cv0ip6utyz3240p)
General
Unique ID : 195828972745552006935081273975453852172 (0x935349CB563FDEEFA7391FA0EA65220C)
Complete name : C:\Users\Virtual_ManPL\Desktop\sample2.mkv
Format : Matroska
File size : 25.0 MiB
Duration : 23mn 34s
Overall bit rate : 148 Kbps
Encoded date : UTC 2010-11-18 02:59:52
Writing application : mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 3 2010 22:54:08
Writing library : libebml v1.0.0 + libmatroska v1.0.0
Cover : Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Title : h.264
Writing library : x264 core 107 r1745 4785e8e
Encoding settings : cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x13 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=9 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=130 / rc=crf / mbtree=1 / crf=19.5 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Language : Japanese
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 23mn 34s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : aac 2ch
Language : Japanese

Text #1
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : subtitles & notes
Language : English

Text #2
ID : 4
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : subtitles
Language : English

Menu
00:00:00.000 : en:Opening
00:03:17.614 : en:Recap
00:06:12.622 : en:Part 1
00:14:44.584 : en:Part 2
00:23:04.592 : en:Preview

[BetaBoy]

Virtual_ManPL... thx for the sample, it helps.

[CruNcher]

@ Dan i gonna bring your Engineers heads to glow i promise, there is more to come ;)

lav splitter becomes a very interesting thing and nothing against Haali but his own Splitter is slowly making big drawbacks especially with DVB Transport Streams good interoperability with lav splitter (the first very solid multipurpose Open Source dshow ffmpeg based splitter) would be a big thing on my wishlist for CoreAVC (DXVA,CUDA,OVD,IMSDK) in the future and support from CoreCodec being the Circle of Open Source Multimedia Technologies seems natural doesn't it ;)

[desta]

The support staff has not answered because I replied here and the fact that none of the 30+ beta testers cannot duplicate your results. What Video card do you have?
Windows 7 Ultimate x64
Intel Core2 Quad 9550 OC'd @ 3.4GHz
2GB Crucial Ballistix
Nvidia Geforce 9500 GT-OC (downgraded to driver 266.58 as nothing above this works with coreavc + cuda/dxva enabled)

The only time I heard from support was for them to ask a question you had already asked. I answered yourself and support. I never got any reply from support and limited replies from yourself. I understand that you will obviously be inundated with messages and so on from people on the forums, but surely then that's why there is supposedly a support section on the site, and if you're unable to give answers then isn't that 'supports' job? The name would appear to imply it.

I directed questions to both yourself and support that never received a response and all the information I have given you I have already given support, with no reply.

The fact that you mention only the beta testers seems to imply that the 'support' haven't looked into this issue at all... considering the beta has been and gone.

There have been others members here reporting the same or similar playback problems, so I know mine isn't a solitary case.

[pdanpdan]

@cruncher
lavf by corecodec => 0.24->0.25 in 2.5 years :)

[ilkertezcan]

My feedback (DxVA1 mini-test):

Sample video: http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_other_samsung_led_tv_series.rar
(AVC (H.264), High Profile, Level 4.1, 1920x1080, 23.976 fps)

Test Application: DxVA Checker (http://bluesky23.yu-nagi.com/en/#DXVAChecker)

Renderer: Video Mixing Renderer 7
Decoder Device: ModeH264_VLD_NoFGT

System Info:
* CPU: AMD Phenom II X3 710 2.6Ghz
* GPU: ATI Radeon HD 3200 (mainboard chipset AMD 780G)
* OS: Windows server 2003 sp2 (32-bit)
* Catlayst Display Driver: 11.4
* Mpeg Splitter: MPC HC SVN 3052

Tested DxVA1 decoders:
* ArcSoft Video Decoder 2.27.432.126
* CyberLink H.264/AVC Decoder 2.4.0.3007
* MPC - Video decoder 1.5.2.3052
* CoreAVC DirectShow Video Decoder 2.5.5.0

Tests:

Decoder: ArcSoft Video Decoder
Time: 00:13.439
Average FPS: 52,682
Min/Max FPS: Min: 50 Max: 55
CPU Usage (%): Avg: 05 Min: 02 Max: 07
GPU Usage (%): Avg: 99 Min: 00 Max: 100

Decoder: CyberLink H.264/AVC Decoder
Time: 00:13.129
Average FPS: 53,850
Min/Max FPS: Min: 46 Max: 63
CPU Usage (%): Avg: 04 Min: 00 Max: 07
GPU Usage (%): Avg: 100 Min: 00 Max: 100

Decoder: MPC - Video decoder
Time: 00:13.187
Average FPS: 53,462
Min/Max FPS: Min: 51 Max: 56
CPU Usage (%): Avg: 05 Min: 01 Max: 08
GPU Usage (%): Avg: 100 Min: 00 Max: 100

Decoder: CoreAVC Video Decoder
Time: 00:13.596
Average FPS: 52,001
Min/Max FPS: Min: 49 Max: 54
CPU Usage (%): Avg: 35 Min: 33 Max: 41
GPU Usage (%): Avg: 100 Min: 00 Max: 100


Tested with VMR-9 too. Same scores. Example;

Renderer: Video Mixing Renderer 9
Decoder: CoreAVC Video Decoder
Time: 00:13.867
Average FPS: 50,984
Min/Max FPS: Min: 49 Max: 52
CPU Usage (%): Avg: 35 Min: 33 Max: 40
GPU Usage (%): Avg: 100 Min: 00 Max: 100

PS-1: Besides, tested with Catalyst Display Driver 10.10. Same scores.
PS-2: Besides, tested with Haali Splitter 03/03/2011. Same scores.

I hope, this mini-tests will be useful for you.

[Roobaj]

Did you guys test this with the just released AMD Catalyst 11.4?

The situation is a lot worse, videos freeze for sec when opening them and there is no picture as well, just sound.

As for my crashing problem, it still happens but if I move MPC-HC to my other TV and open a video after that it will keep playing normally; in other words it only happens when I switch MPC-HC from one monitor to the other.

Talking about AMD DXVA here only.

Did a complete reinstall for AMD Catalyst 11.4/CCCP/CoreAVC and now everything is working correctly except for moving MPC-HC window with DXVA enabled.

Dunno how to fix that.

[BetaBoy]

Ilkert... The sample link does not work, can u reupload it? Thx

[ilkertezcan]

Sorry. Sample video link: http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_other_samsung_led_tv_series.rar

[molitar]

Hi Betaboy! I got a serious problem with CoreAVC now.. When I go fullscreen I have MPC switch video over to my secondary Display.. but now whenever I do that I get a fatal application error and it crashes mpc-home.exe.

Faulting application name: mpc-hc.exe, version: 1.5.1.2903, time stamp: 0x4d6bfd6d
Faulting module name: CoreAVCDecoder.ax, version: 2.5.5.0, time stamp: 0x4db127e8
Exception code: 0x40000015
Fault offset: 0x000c7755
Faulting process id: 0xeec
Faulting application start time: 0x01cc06e6380d797f
Faulting application path: C:\Program Files\Combined Community Codec Pack\MPC\mpc-hc.exe
Faulting module path: C:\Program Files\CoreCodec\CoreAVC Professional Edition\CoreAVCDecoder.ax
Report Id: 7ca08966-72d9-11e0-bab2-8000600fe800

I turn off CoreAVC so it's rendering with ffdshow it works perfectly fine.. just coreavc will no longer let me switch screens without crashing. BTW I am running Catalyst 11.3 so it has nothing to do with driver version of Catalyst..

[CruNcher]

@ Dan
http://www.mediafire.com/?fwxb108j7l2asrw <- CoreAVC seems to be unable to recover after the stream error @ 1:32 it becomes unstable

[Roobaj]

My problem even happens with latest version of Potplayer:

http://i.imgur.com/QPeyx.jpg

Is there really no way to enable DXVA with extended displays?

[pankov]

We are working with Haali on how to best handle the custom media format for a future release.10x
Please, do consider that not installing Haali's splitter through CoreAVC's setup should not change any setting of the splitter. I'm not sure (don't remember from the past) if your installer simply uses Haali's one and calls it during setup but nevertheless no settings should be changed if it's not started.

The teams are looking into the field order... but they already commented on how you get random field order changes when starting and seeking and how most renderers break.I'm not sure I understand your words exactly. Where did they comment? Who said that I get random filed order changes when starting/seeking? Btw isn't it decoder's responsibility to send the fields in the correct order? In PAL countries Top Field First is the most used configuration and I sense that CoreAVC is sending the opposite. Am I right?
I'm sad to report that both problems are not addressed in the new 2.5.5 release
:(
What is so hard to do in both?
The first one should be simply a switch in the installer.
and if the second one is hard to be detected automatically why don't you put a configuration option for the user to select the field order "Auto/TFF/BFF" and probably if it should be applied to PAL content only or everything? And probably change the default for PAL so the users can get better results with "Auto".

[molitar]

Well CoreAVC is still unusable since it crashes if you switch screens.. Also how hard is it to fix the forums? Go hire a real web admin to fix them so we can again post bugs where we should be posting them, because whoever is doing web admin now I hate to say is an idiot it if he/she can't fix a simple posting on forums issue.

[AtenXL]

is there any fix or update for new core avc ?
coz, dxva is disabled when i'm running movies with madVR & daum pot player...
my card is ATI HD3300 & HD5670 :)

[madshi]

madVR does not support DXVA (yet?).

[AtenXL]

ow, only CUDA maybe...
but, DXVA still not running when i'm using daum pot player with video renderrer EVR....
the tray icon color is blue....

[CruNcher]

For UVD users they would have to implement OVD to make Hardware Decoding work with Madshis renderer the only usable solution for ATI user is Cyberlink in its HAM mode (which is somekind of OVD implementation).
For Nvidia their are already much more dshow based nvcuvid filter available like CoreAVCs Cuda mode LAV CUVID or Cuda Video Decoder :)
Lav Cuvid currently being almost as advanced as CoreAVC CUDA mode and gets improved with a lot of community feedback and has some very unique stuff also already ;)
Though @ least for Nvidia their seem to be performance issues on certain renderer (VMR9) with 1080p 60 fps streams and VPx 512mb Hardware that so far only 1 ISV solved for DXVA

[someone`]

@AtenXL
Use this :
Added DXVA support without rendering mode (Ctrl+F > Video Decoder > Built-in codec settings > Use DXVA without rendering mode)
It works with madVR .

[CruNcher]

@someone
If that is what i think it is that will be slow especially for ATI Hardware :P

[someone`]

It plays 1080p content just fine . Watching 2 hours movie , 0 drop/delay frame , 0 glitch .
ATI 4670 512MB madVR 0.61
Also Cyberlink decoder is buggy as hell
http://forum.cyberlink.com/forum/posts/list/16748.page

[AtenXL]

@AtenXL
Use this :

It works with madVR .
still not working...the tray icon is blue...:confused:

[Barlow]

I found a file which CoreAVC stops decoding after a few seconds when using DXVA.
It works fine with the MPC videodecoder with DXVA.

This is with CoreAVC 2.5.5 on a Radeon 4850.

Sample (http://www.mediafire.com/?243lm9h1wcnz1zo)

[toomyzoom]

@AtenXL
Use this :

It works with madVR .

How do you get it to work with madvr in mpc-hc?

Thanks.

[desta]

The support staff has not answered because I replied here and the fact that none of the 30+ beta testers cannot duplicate your results. What Video card do you have?
Windows 7 Ultimate x64
Intel Core2 Quad 9550 OC'd @ 3.4GHz
2GB Crucial Ballistix
Nvidia Geforce 9500 GT-OC (downgraded to driver 266.58 as nothing above this works with coreavc + cuda/dxva enabled)

The only time I heard from support was for them to ask a question you had already asked. I answered yourself and support. I never got any reply from support and limited replies from yourself. I understand that you will obviously be inundated with messages and so on from people on the forums, but surely then that's why there is supposedly a support section on the site, and if you're unable to give answers then isn't that 'supports' job? The name would appear to imply it.

I directed questions to both yourself and support that never received a response and all the information I have given you I have already given support, with no reply.

The fact that you mention only the beta testers seems to imply that the 'support' haven't looked into this issue at all... considering the beta has been and gone.

There have been others members here reporting the same or similar playback problems, so I know mine isn't a solitary case.

And once again I answer a question and receive no reply!

[BetaBoy]

And once....

In fact I did say we were looking into your report. Thank you supplying the additional info.

[pankov]

BetaBoy,
what about my problem with field order?
I guess you've missed my post here
http://forum.doom9.org/showthread.php?p=1497014#post1497014

[BetaBoy]

No I did not miss it and replied promptly. We are talking internally about adding options like you have suggested.

[pankov]

sorry, but I don't see your reply?
can you, please, point it to me?

[ForceX]

still not working...the tray icon is blue...:confused:
You can't use CoreAVC for that (unless and until they try to implement a non-rendering DXVA mode), you'll need to select Built-in Decoder for AVC1 and H264 from Preferences > Filter Control > Video Decoder in PotPlayer. Mind you though, it'll not be as fast as a pure DXVA you can get with EVR.

It's still pretty fast though.

Of course none of it will work if the video you are trying to play is not DXVA compatible.

[NikosD]

The use of DXVA renderless mode in PotPlayer up to 27701 beta is very slow on ATI cards and HD video, even with EVR custom renderer and uses a lot of CPU power, too.

For SD video is OK and for low bitrate/fps HD video is affordable.

If you add madVR as a renderer you make things even worse, because of the increased CPU usage that madVR adds and the result is choppy video playback performance.

So for ATI cards the best solution remains pure DXVA mode + EVR custom renderer or if you have fast CPU (like quad core CPU or very fast dual core CPU like Core i5) and a decent card then software decoding (CoreAVC, FFMpeg-mt) + madVR renderer has best results.

[CruNcher]

NikosD thats the problem one says it works fine another says it doesn't so without testing it on your specific config i wouldn't say it works for everyone bad (depending on his preferred playback scenario) though i absolutely can't judge it myself as im on XP and that rendering mode isn't existing their but i wondered a little and seeing that you describe it also with cpu utilization i would say makes you more believable than someone who says it works just fine (their must be drawbacks) ;)
Referring to this guy http://forum.doom9.org/showpost.php?p=1497214&postcount=6336

[flapane]

ACCELERATION
This sets the preferred method of hardware acceleration for decoding H.264 streams. Changes to this option will not take effect until playback is restarted.

CUDA - Use a compatible NVIDIA graphics card if the stream is encoded using compatible features.
DXVA - Use an ATI or NVIDIA DXVA1/DXVA2 compatible graphics card if the stream is encoded using compatible features with a renderer filter connected.
NONE - Use software decoding only.

TRAY ICON STATES
When the "Use Tray Icon" option is enabled, the tray icon indicates whether or not hardware acceleration (GPU) is active in CoreAVC.

Blue - CUDA or DXVA is not active or in use.
Green - CUDA acceleration is active and in use.
Red - DXVA acceleration is active and in use.


With latest version of CoreAVC (2.5.5) on 7 x64 and HD5670, DXVA worked great with MPC-HC, but I couldn't enable it on WinTV live HDTV. The tray icon remains blue and the cpu sits at about 60%.
Furthermore, a guy from the WinTV tech support asked for more informations on CoreAVC API needed to set the GPU acceleration. I suppose that it may help to better understand the problem.
Any hints?
Thanks

[deets]

came on to say the same thing, no DXVA in live TV with DVB viewer. have nothing but trouble finding a good solution for watching live TV :(

[Pyroshock]

CoreAVC 2.5.5 has solved my earlier problem (http://forum.doom9.org/showthread.php?p=1490141#post1490141), thanks!

[flapane]

came on to say the same thing, no DXVA in live TV with DVB viewer. have nothing but trouble finding a good solution for watching live TV :(

Glad I'm not the only one, that means that it's an issue related (maybe) to the codec. Let's see if the devs can gives us help. :)

[nussman]

Of course this is related to CoreAVC decoder.
DVBViewer Splitter works fine with other DXVA decoder like Powerdvd, Arcsoft, Microsoft, ...

[molitar]

Betaboy, is the issue being addressed that we can not switch screens with the latest CoreAVC when using DXVA?

[BetaBoy]

Yes... we are looking into a fix.

[CruNcher]

Dan did you look into this http://forum.doom9.org/showpost.php?p=1496944&postcount=6326 it happens also in Software Decoding other Decoder recover fine after the error only CoreAVC becomes unstable dropping frames after it regularly till the end.

[flapane]

BetaBoy do you also have any hints for us with hdtv dvb issues as posted above?
Thanks

[BetaBoy]

CruNcher... thx for the files and info... we are looking into that as well.

[nussman]

I uploaded a testfile (1080i50) with some screenshots so you can test the deinterlacing issue and the dxva problem with dvbviewer splitter.

http://www.file-upload.net/download-3423885/coreavc_dxva_test.zip.html

P.S. My System: Win7 32bit, Ati HD5670 (latest driver)

[CiNcH]

with some screenshots
So what's the conclusion of these screenshots? The TV image is too small to determine whether fields are swapped...

Are fields swapped with all three splitters? Guess not?

Here is how I interpret the screenshots:

With DVBSource we see a jitter of 20ms at the renderer, which is exactly the duration of one frame at 50 fps which is constructed of one field.

With Haali Media Splitter everything seems fine? At least according to the EVR statistics.

[nussman]

The conclusion should be that Betaboy or the other dev's see what i did.

Fields swapped with all three splitters.
With my testfile (quick sport- real interlaced content) the issue is obviously.
Imho there is no need of other screenshots to show it ...

[dead_screem]

I uploaded a testfile (1080i50) with some screenshots so you can test the deinterlacing issue and the dxva problem with dvbviewer splitter.

http://www.file-upload.net/download-3423885/coreavc_dxva_test.zip.html

P.S. My System: Win7 32bit, Ati HD5670 (latest driver)
a question about this for tech people.
Mediainfo detects his sample as "Interlaced", does this mean PAFF? as mediainfo will Show MBAFF if it is. Mediainfo also detects TFF field order, Is interlace filed order even specified in the h264/avc stream or is it specified in the ts container only? If it is not in the stream does that mean CoreAVC always assumes BFF? (which would really warrant a field order Auto/TFF/BFF option if it is always assuming one order...) If it is only specified in the ts container, could haali or other splitters pass on the correct field order to the decoder?

Also media info doesnt show filed order for the mbaff files ive seen, is this because they were actually mbaff progressive or some other reason?

[flapane]

Of course this is related to CoreAVC decoder.
DVBViewer Splitter works fine with other DXVA decoder like Powerdvd, Arcsoft, Microsoft, ...

Here's also a screenshoot of WinTV with the CoreAVC blue tray icon even if DXVA is enabled.
HD5670 also here.
http://i.imgur.com/4Neoys.jpg (http://i.imgur.com/4Neoy.jpg)

[dipl_ing]

Same issue here with DVBVIEWER and HD channel.
Hope to get a bugfix soon.

[desta]

In fact I did say we were looking into your report. Thank you supplying the additional info.Nearly 3 weeks since your last reply and still nothing. Infact, 2 months since I first raised a ticket.

[desta]

Are your support on some sort of wind up?!

Just received this email:

CoreCodec, Inc.

This is a notification to let you know that we are changing the status of your ticket #XXXXXX to Closed as we have not received a response from you in over 72 hours.

Subject: Jerky playback with Coreavc 2.5
Department: CoreAVC
Priority: Medium
Status: Closed

----
The CoreCodec Team
http://CoreCodec.com

I have been waiting since 29th March to hear back anything from your backwards support. Each time I've mentioned it here, all I'm told is "we're looking into it" or "they don't reply via the portal as they monitor the forums"... really??! What forums do they monitor, pray tell, because they don't seem to have a clue what's going on here.

Worst service ever!

[flapane]

all I'm told is "we're looking into it"

I wish I received a "we're looking into it" as well... All I got was... nothing :)

[pankov]

Are your support on some sort of wind up?!

Just received this email:
CoreCodec, Inc.

This is a notification to let you know that we are changing the status of your ticket #XXXXXX to Closed as we have not received a response from you in over 72 hours.

Subject: Jerky playback with Coreavc 2.5
Department: CoreAVC
Priority: Medium
Status: Closed

----
The CoreCodec Team
http://CoreCodec.com



I have been waiting since 29th March to hear back anything from your backwards support.
....
Today I received the same ridiculous e-mail only in my case it's about ticket 175597 - Wrong field order.
Why would CoreCodec close a ticket which they haven't solved or even bothered to respond to.
I'm really disappointed with their support.
:(

[BetaBoy]

I closed the ticket... I did state we were "looking" into the potential issue 3x to you here on D9. Please have patience while we continue to work hard on the next few releases.

[pankov]

BetaBoy,
I just thought it's strange to close an unresolved ticket especially with such a reason "...we have not received a response from you in over 72 hours". How am I supposed to know that I'm supposed to respond to something since you've never bothered to write anything there?
And about being patient - don't you think that an year and almost a half is patient enough? About a field order problem? I may oversimplify things but I can't believe that it's so hard to implement a proper field order detection ... or if it's really that hard - simply make it an option for the user to choose ... it's not that CoreAVC makes a mistake in the detection from time to time - it's always wrong so a simple option should solve it ... I hope. If you have more information on the subject that will help me understand the complexity of the problem, please, do say, cause it's very frustrating to be left in the dark. "we are looking into it" isn't enough.

[dead_screem]

betaboy, could you post an update on these statuses

still CoreAVC is the only support ticket option... No CoreAAC and no General (should there be others?)

the Corecodec forums are busted I think someone else here mentioned, apparently it's impossible to post.
And forgot password doesn't work for the corecodec forum, or possibly it works but comcast can't receive it?

[BetaBoy]

No CoreAAC and no General (should there be others?)


CoreAAC department database bug fixed. Thx for the report, you can post tickets again to it.

[BetaBoy]

"we are looking into it" isn't enough.
Sorry that's not good enough for you, but we are looking at your reports. When we have more to report we will post to your ticket or here on D9. Thank you for your help.

[desta]

I closed the ticket... I did state we were "looking" into the potential issue 3x to you here on D9. Please have patience while we continue to work hard on the next few releases.
2 months!!

It's really not worth doing the "I told you 3 times" routine, when you and your own support don't know what the other is doing!

I first went to your support and got no response, so came here and had to give the same info I'd already given to them. When I did eventually hear from your support it was to ask a question you had already asked. Despite the fact I had already said it and they already apparently "monitor the forums" I gave the info again. I then supplied additional info to support, which... guess what... I had to give again to you here.

You told me your support is looking into it. Doubtful. You told me "30+ beta testers" cannot duplicate my results. I'm not having issues with a beta... though it might as well be. Try getting your support to do it instead. Look through this very thread and you'll see other customers who have the same or very similar problems and those that even had to roll back their Nvidia drivers to fix it.

[BetaBoy]

I first went to ..
This has nothing to do with Support atm as its out of their hands... it has to do with the engineers duplicating and finding the issue first. While we have had a few reports of this the engineers and the all beta testers have not come across it.

We will continue to see what the issue might be.

[Audionut]

engineers

Plural? :eek:

[upyzl]

forget to update 2.5.5 info here?

[CiNcH]

This shit is in such a bad shape... no support in DVBViewer with DVB Source at all, still no proper deinterlacing, no on-the-fly format change in DXVA mode...

Are you serious guys? Come on! Now you tweet that you are working on 10-bit support for CoreAVC 3.0? You just can't be serious!

[BetaBoy]

We are more then capable to multi-task. We are continuing to work on DXVA features and reported issues. This includes us adding support for 10bit to both CoreAVC 3.0 and CoreMVC.

[flapane]

Lack of dxva acceleration while watching DVB HDTV should be a priority (and it isn't just because I have this problem, too), just my two cents... Hope you're working on it.

[BetaBoy]

We are and other features for the next release.

[flapane]

Thanks

[molitar]

Wonders if a fix will ever come out with the lock up when switching screens is ever going to be fixed. I have had to stop using CoreAVC completely because of this very horrendous bug.

[cyberbeing]

Now that coding CoreAVC 9/10-bit support is well underway, is it clear whether you plan to support actual 10-bit output (to madVR for example) from the get-go, or will all high bit-depth output be dithered down to 8-bit?

[BetaBoy]

We completed 10 bit support in CoreAVC 3.0 last week and are on assembly optimization's now and looking into DXVA GMA support. We also just finished adding MVC 3D support to Haali's Splitter for CoreMVC which should be out around the same time or soon after CoreAVC 3.0 next month.

[cyberbeing]

So will CoreAVC 3.0 always be doing 10-bit to 8-bit conversion similar to FFDShow/libav w/ swscale, or will it actually be able to output 10-bit as 10-bit or 16-bit? Not immediately important for 3.0, but it would be nice to have it supported at some point. If you can beat FFDShow in the turtle race to support high bit-depth output, that would be a bonus. I assume CoreAVC has the advantage of a clean codebase to implement such a thing.

[BetaBoy]

The CoreAVC 3.0 SDK Library (for OEM's) will output 10-bit yuv (Technically 3.0 already supports 16-bit as well). However, the directshow filter will initially dither the output to 8-bit... We are working on adding some additional output options like you mentioned on 10/16 as 3.0 progresses, including 4:4:4 and 4:2:2 support. We are trying to keep up with the x264 features set ;-)

[Barlow]

With all this talk about CoreAVC 3.0 I'm wondering whether DXVA will still be fixed in 2.X. Because as it is now, it's unusable for me (Radeon 4850) as a lot of files cause the decoder to stop decoding. I reported this a while back.
I hope it will still be fixed as this makes the whole 2.5/2.6 series pointless :(

[Maccara]

With all this talk about CoreAVC 3.0 I'm wondering whether DXVA will still be fixed in 2.X.
Probably not.

[nussman]

and are on assembly optimization's now and looking into DXVA GMA support.
Please dont forget about the deinterlacing issue.

Without fixing this problem your decoder is completly useless for any real interlaced content.

[molitar]

The issue hasn't been fixed that I seen with 2.5.x where switching to full screen doesn't crash the player. And your already talking about 3.x.

[BetaBoy]

molitar... I have asked you before, but pls stop spamming the thread. We have your report on the issue, thank you.

[josephwright]

Please dont forget about the deinterlacing issue.

Without fixing this problem your decoder is completly useless for any real interlaced content.

Yes please fix the deinterlace field order issue. I purchased CoreAVC for use with UK Freesat HD content but it's been unusable due to this. After reading through this thread I find it incredible that such a simple core issue has remained unresolved for so long.

[BetaBoy]

You think this is 'simple'? It's not... if it were we would have a work around for it. But to be clear here.... EMR7 = Fine with no issues.... VMR9/EVR has a bug that allows field order to become random at times in directshow/dxva/xp (play, pause, etc.). The staff here along with Haali himself has confirmed the VMR9 bug and that CoreAVC sets the field order properly when playback begins like it should.

MS had released a patch that was supposed to fix the issue, but it did not fix it for everyone.

NOTE: Try the hotfix here to see if it helps: http://support.microsoft.com/kb/919071

[Chumbo]

I noticed today that CoreAVC does not play back correctly nor deinterlace streams captured with the Hauppauge HD PVR 1212. I just don't get any smooth playback of these with DXVA or without. Here's the MediaInfo info on one of the files. Let me know if you guys want a sample. I'm using an ATI HD 5670.
General
Unique ID : 198612688816049830842616612295414293371 (0x956B6997CE0FF7CE81B1037D4AF6A37B)
Complete name : E:\Media\video.mkv
Format : Matroska
Format version : Version 2
File size : 101 MiB
Duration : 1mn 16s
Overall bit rate : 11.0 Mbps
Encoded date : UTC 2011-07-03 17:09:05
Writing application : mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 16s
Bit rate mode : Variable
Bit rate : 10.4 Mbps
Maximum bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 60.000 fps
Original frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.084
Stream size : 95.4 MiB (95%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 1mn 16s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 3.52 MiB (3%)
Language : English

[BetaBoy]

I noticed today that CoreAVC does not play back correctly nor deinterlace streams captured with the Hauppauge HD PVR 1212. I just don't get any smooth playback of these with DXVA or without. Here's the MediaInfo info on one of the files. Let me know if you guys want a sample. I'm using an ATI HD 5670.


What OS? What renderer?

[Chumbo]

What OS? What renderer?
Win7U64 using MPC-HC x64 with EVR Custom Pres.

[EDIT] I went ahead and uploaded a sample (http://www.mediafire.com/?z6bg69q1nqiwgri) anyway. I also get different results playing the files. My desktop has a HD 4800 series card and laptop has a HD 5700 series mobility. Laptop hardware deint is a little better.

[josephwright]

You think this is 'simple'? It's not... if it were we would have a work around for it. But to be clear here.... EMR7 = Fine with no issues.... VMR9/EVR has a bug that allows field order to become random at times in directshow/dxva/xp (play, pause, etc.). The staff here along with Haali himself has confirmed the VMR9 bug and that CoreAVC sets the field order properly when playback begins like it should.

MS had released a patch that was supposed to fix the issue, but it did not fix it for everyone.

NOTE: Try the hotfix here to see if it helps: http://support.microsoft.com/kb/919071

Hi BetaBoy,

I think we are talking about different problems.

The problem I am refering to is not 'random'. In my experience all UK DVB h.264 streams get deinterlaced incorrectly when using hardware deinterlacing. I believe this problem has been reported numerous times within this thread. To highlight a few of these:

pankov's posts numbered 4984, 5840, 6122, 6125, 6172, 6328 & 6369.

CiNcH's posts 6126 & 6127.

nussman's posts 6303 & 6358.

Just to confirm this issue only occurs when 'hardware' is selected as the deinterlacing option in the CoreAVC configuration panel. The symptom is nasty jaggies on sharp diagonal edges. I have attached cropped images of the same scene decoded with both CoreAVC and Microsoft codecs. Both were using EVR and hardware dxva deinterlacing (ati vector adaptive). I'm not certain if the problem is field order related, although that would make sense going by the way it looks. If it is the field order then pankov's suggestion of an "Auto/TFF/BFF" configuration option would seem like a easy way to deal with it.

I am using these codecs within Mediaportal to play live/recorded UK h.264 DVB streams (BBC HD, BBC ONE HD, ITV HD, CHANNEL 4 HD). OS is Win7 32 bit, GPU is an ATI 5570GT (same results with both 11.4 and 11.6 drivers).

Please let me know if I provide any more info to help you fix this issue.

[BetaBoy]

josephwright.... please send the attachment to: betaboy AT corecodec DOT com

Thank you for all your help and we will review what you sent.

[The Seeker]

When I bought CoreAVC 2.0, I was of the understanding that I was purchasing a lifetime license. Why is it that I now have to pay to upgrade to 3.0 when it's released?

[BetaBoy]

Nothing has changed in upgrades and how we handle them for milestone releases, other that with 3.0 we have had a longer period of time spent on the 'Core' work (almost 2 years) Meaning what that while 2.x shares the same 'cores' they are not the same and we have made huge investments in making our code more modular and highly optimizing 'anything' assembly. In return we added 10bit support, that instead of slowing playback (FFmpeg saw a 1-2% hit when they added 10-bit), it has actually improved performance playback for some CPU instruction sets.

Bottom line its a milestone release... 2.x got you 2.x updates, not 3.x.

We thank you for your continued support.

[pankov]

BetaBoy,
can you tell us a little more about your plans.
Will CoreMVC be a separate product which we'll have to buy separately or it will be part of the new CoreAVC 3.x? If it's the first will there be any discount if we buy one more license for CoreAVC now or it'll be better to wait?
I'm willing to support your work and buy a new license but I'm kind of reluctant to buy CoreAVC only for the added 10-bit support. I've hoped for something more ... may be fix the deinterlace issue ;)

[josephwright]

josephwright.... please send the attachment to: betaboy AT corecodec DOT com

Thank you for all your help and we will review what you sent.

I have emailed the screenshots, should I also file a bug report on the CoreCodec website or is this enough?

To correct my previous post I am using an ATI HD5570 (not 5570GT!). I have also tested on a second system with a NVidia GPU (460GTX) and can confirm I see the same problem there too.

[BetaBoy]

BetaBoy,
can you tell us a little more about your plans.
Will CoreMVC be a separate product which we'll have to buy separately or it will be part of the new CoreAVC 3.x? If it's the first will there be any discount if we buy one more license for CoreAVC now or it'll be better to wait?
I'm willing to support your work and buy a new license but I'm kind of reluctant to buy CoreAVC only for the added 10-bit support. I've hoped for something more ... may be fix the deinterlace issue ;)

We will have 3 AVC based products: CoreAVC, CoreMVC and CoreSVC. MVC and SVC are based on our work with CoreAVC 3.0 and each are separate products.

We will offer a discount for CoreMVC when its released for current CoreAVC customers. We expect it to be release soon after we CoreAVC 3.0 next month.

CoreSVC will likely be later this fall.

On the deinterlaced issue.... me too.

[BetaBoy]

I also wanted to follow up on the 'just 10 bit'. While I hear what your saying its far from 'it' as I've already indicated 3.0 now allows us a much smoother path to true 4:2:2 and 4:4:4 of which we are hopeful to complete 4:4:4 soon after 3.0 is released.

[pankov]

BetaBoy,
don't get me wrong - I respect your work but I'll believe it when I see it.
As a fellow developer I know it's not easy to keep up with the deadlines but your release / QA schedule is way off from your promises.
I hope you'll get my words not as an assault but as a constructive criticism.
;)

[BetaBoy]

Not at all... I/We appreciate all your feedback.

[cyberbeing]

Bottom line its a milestone release... 2.x got you 2.x updates, not 3.x.

Just to confirm, purchasers who bought CoreAVC 2.5.x this month during the mid-summer sale get a free upgrade to CoreAVC 3.0 as promised? And I assume they will get 3.x updates as well?

[toomyzoom]

I feel I was cheated. I purchased Coreavc 2.5.0 in 4/4/2011 for its "broken" DXVA support, and after over 3 months, the only update was version 2.5.5 with no significant change. My problems with green block and artifact still exist. MPC-HC's internal decoder does a better job than this piece of shit. My purchase date is over 60 days so the update is not in option. I don't think I will purchase anything from CoreCodec ever again.

[ChronoCross]

Just to confirm, purchasers who bought CoreAVC 2.5.x this month during the mid-summer sale get a free upgrade to CoreAVC 3.0 as promised? And I assume they will get 3.x updates as well?


Here is a copy of their poorly written and formatted newsletter.


Hello,

We are emailing you to clarify about the upcoming CoreAVC v3.0

release and our upgrade policy for 2.x customers.

AVC is a patented format, and we pay royalties for the use of these
patents.

Each new decoder comes at a cost to us, including upgrade copies.
Furthermore,

CoreAVC v3.0 is a major milestone for us here at CoreCodec; our
engineering staff

has been working on it for well over 2 years. We have reworked the
v3.0 'core' to

support many new h.264 features and profiles.

As such, we are unable to offer free upgrades to all existing users.
When CoreAVC

3.0 launches (around the end of next month), all customers who have
purchased

within the last 60 days will receive a free upgrade. This includes
customers who

purchase during our current promotion. In preparation for the 3.0
launch, we have
reduced the price by $5.00 (to $7.95) - it will be going up at launch.
This is the
cheapest way to get CoreAVC 3.0.

This offer is a 'time limited' (10 day) discount code for $5.00 off
our $12.95 purchase price = $7.95 with discount.

Get it here: https://customers.corecodec.com/cart.php?a=add&pid=10

Use Discount code: SUMMER2011

Once this coupon expires in 10 days, the price will return to $12.95.

Thank you for your continued support.

Regards,


I feel I was cheated. I purchased Coreavc 2.5.0 in 4/4/2011 for its "broken" DXVA support, and after over 3 months, the only update was version 2.5.5 with no significant change. My problems with green block and artifact still exist. MPC-HC's internal decoder does a better job than this piece of shit. My purchase date is over 60 days so the update is not in option. I don't think I will purchase anything from CoreCodec ever again.

Welcome to the club.

[cyberbeing]

When CoreAVC 3.0 launches (around the end of next month), all customers who have purchased within the last 60 days will receive a free upgrade. This includes customers who purchase during our current promotion.

Thanks ChronoCross, that answers my question.

[deets]

hmm not happy at all...

[BetaBoy]

Chrono.... Pls step from this thread as you have nothing to contribute except for 'drama'.

Tommy... Pm me your account info and I'll look into the purchase.

[The Seeker]

I must admit, I'm a little miffed as when I purchase a lifetime license, I expect it to be oh, I don't know, lifetime?

[BetaBoy]

Lifetime has never been implied nor has it been for our previous 1.x and 2.x milestones as each had upgrade costs. We added related questions to the KB to assit those people who need clarity.

[Disabled]

Did they advertise "lifetime license" somewhere?
Every software you buy has a lifetime usage license. (Unless you buy a limited usage license) Thus advertising a "lifetime license" might imply a lifetime update guarantee, like for instance slysoft and many other companies understand it.
But in the end, you didn't get screwed like the 1.x buyers did. You bought a high profile decoder, you got a high profile decoder.

[BetaBoy]

Not to poke at Slysoft and that 'guarantee', but are they even licensed to sell AVC? http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx

Same for Via and Dolby, I see no Skysoft licensee.... and that's my point.... Its easy to make such guarantees when you are not paying (allegedly) for any royalties that come with restrictions on licensing.

[Disabled]

Not to poke at Slysoft and that 'guarantee', but are they even licensed to sell AVC?
Do they even sell an AVC decoder? (Your point is probably valid for AACS/BD+ though)
Its easy to make such guarantees when you are not paying (allegedly) for any royalties that come with restrictions on licensing.
If its so easy then make a "10 bucks + 0.50 per redownload for lifetime" guarantee. I wouldn't have bitched a bit about 1.x not being a high profile decoder with that model.

[CiNcH]

You should first debug the old stuff before you go to a new major version.

You are able to multitask? You can't even get one job done properly.

Sorry guys, but this is really bad business. I am done here. This time I mean it.

[toomyzoom]

Tommy... Pm me your account info and I'll look into the purchase.

Lol, tried to send a PM, got this "BetaBoy has exceeded their stored private messages quota and cannot accept further messages until they clear some space."

[BetaBoy]

Space made... Try again.

[dead_screem]

So will there be a 2.x->3.x upgrade path like 1.x->2.x had? IIRC Click 1.x license then click upgrade button then pay 5.95 to upgrade it into 2.x. So will there be a way to do that for 2.x to 3.x or are we stuck paying either full price or settling with re-buying 2.5 with time limited 7.95 code and getting 3.x free?

[BetaBoy]

Disabled... It's amazing how your postings of 'no value' still continues in this and other D9 threads (re:http://forum.doom9.org/showpost.php?p=1432058&postcount=95 ) with no moderator consequence.... We welcome and greatly appreciate constructive feedback both good and bad. But your posts continue to attack and add nothing but drama to an otherwise valuable forum.

dead_screem.... No 2.x > 3.x... The current sale price gets you 3.0 and 3.x milestone releases.

[Audionut]

Disabled... It's amazing how your postings of 'no value' still continues in this and other D9 threads (re:http://forum.doom9.org/showpost.php?p=1432058&postcount=95 ) with no moderator consequence.... We welcome and greatly appreciate constructive feedback both good and bad. But your posts continue to attack and add nothing but drama to an otherwise valuable forum.

Get off your high horse. You were happy to join in on the conversation when it suited you, and then just as happy to berate another member when they continued the discussion in a manner you didn't approve of.

This isn't the first time you've happily had off topic conversations, and then 'disapproved' when that conversation has led down a path you do not approve of.

The release of core 3 with core 2 in it's current form is a joke.

"Purchase a lifetime upgrade".

"Oh wait, we've decided we need more money, deal with our buggy decoder, or give us some more money."

And no Betaboy, I am not going to keep this thread on topic as you see it. See the thing is, you are not a moderator here.
If you have a problem with posts on this forum, instead of prancing around on your high horse, you should follow the rules you preach and not continue the conversation in public domain, but report the post and leave it alone.

[BetaBoy]

It's not a matter of 'approval'... Liked or disliked comments are all welcome. But when a contributor such as 'disabled' does nothing but post unmoderated FUD over and over and over again, it gets kind of old... and only helps proliferate alternative forums like Doom10.

[Audionut]

It's not a matter of 'approval'... Liked or disliked comments are all welcome. But when a contributor such as 'disabled' does nothing but post unmoderated FUD over and over and over again, it gets kind of old... and only helps proliferate alternative forums like Doom10.

Meh.

When a software company charges money for software, and posts claims of grandeur, and promises of fixes over, and over, and over and over, and over, and promises of releases (sometime this century), over, and over, and over, and over, it gets kind of old... and only helps proliferate the user base to other alternatives.

It also doesn't help when the 'software founder' contributes to this forum with ideals of, 'we can do wonders and eat cucumbers', "We are really good at multi-tasking", when clearly this is not the case, and then has the hide to call out those customers who have paid money to support your software, given that there are other means of obtaining your software rather then payment, and, there are other free open source alternatives.

This on top of the fact, that these customers also paid for life-time upgrades, only for the 'software founder', to then require those same customers to re-purchase the software. In the vain hope that somehow in amongst the 9 million promises you have provided to this community of the bug fixes, the software will become functional and usable.

Coreplayer mobile for Symbian 5th edition was promised in the summer of 2009. 2 years ago. You can sit there and type up all the excuses you want as to why it hasn't been released (though generally if your history is any indication, you will simply tell me that this is off topic).
If you cant see, and don't understand how and why this upsets your paying customers, then obviously you should remove yourself from a customer service roll.

With regards to your constant disapproval of the so called lack of moderator action.
If you feel that strongly about it, you should raise the issue with Doom9. If you have, then clearly you have no respect for Doom9 and this community as you continue to berate the lack of 'moderator action' in the public domain. If you haven't, then again, it just goes to show that you are to busy prancing around on your high horse, berating other users of this community when clearly you cannot follow the guidelines and rules of this community yourself.

[ChronoCross]

Chrono.... Pls step from this thread as you have nothing to contribute except for 'drama'.


I provided your customer with the information he/she requested and then welcomed another one of your disappointed members to the club, both comments being on topic.

I do apologize that you can't just ban people like you do on your forum when they say things you don't like. It must be tough to actually have people who are willing to call you out on things that they have experienced with you, your company, and your product.

It is amazing that you have the gall to tell your customers, who paid you money for a product to stop participating in discussion of the product. Just because you don't like what someone has to say doesn't mean you shouldn't spend time fixing the issues that are brought up.

[BetaBoy]

Audionut.... Chrono... Thank you both for proving my points.

We check every report posted here with each release and have found it to always be an amazing resource and since I joined Doom9 back in 2001 when I was working for DivX. I have had nothing but respect for Doom9 and his community since then, and nothing will change that.

[ChronoCross]

Your obliviousness is astounding.

[CiNcH]

The release of core 3 with core 2 in it's current form is a joke.
"Oh wait, we've decided we need more money, deal with our buggy decoder, or give us some more money."
This is very true. I don't even think that this is a matter of opinion anymore. BetaBoy, you should take this as constructive criticism. What you do is a complete no-go.

I bought CoreAVC 2.0 and never used it since. No on-the-fly format changes in DXVA, still no proper hardware deinterlacing with MS standard renderers (you got plenty of samples already, and it is not random), no DXVA with DVBViewer/DVBSource at all. And now you are going to 3.0? Well...

[madshi]

IMHO, adding 10bit and eventually 4:4:4 support warrants a new "major" release and an upgrade price. We shouldn't expect new features to come for free. That's not how commercial software works.

That said, I would expect nothing less from Core than to release another 2.* bugfix release to fix all showstopper bugs which affect the advertized 2.* functionality. Or alternatively, if Core is not able to make the advertized features work properly in version 2.*, the upgrade to version 3 should be free for all customers affected by the 2.* bugs.

Just my 2 cents.

[Disabled]

Very true madshi. 10bit, 444 and MVC are features not in h264 high profile, so if you want them, buy a new decoder. Bugfixes and advertised functionality should be fixed in 2.x or at Cores choice give them a 3.x license.

[CiNcH]

I totally agree! Now this is constructive, isn't it?

[pankov]

I have two CoreAVC licenses - just to support the team, but I do agree with madshi that asking money for bugfixes is not nice.
I'm not saying it's expensive but it's a principal matter.

[Guest]

Your obliviousness is astounding. No ad hominems per rule 4, please. Thank you.

[BetaBoy]

I have two CoreAVC licenses - just to support the team, but I do agree with madshi that asking money for bugfixes is not nice.
I'm not saying it's expensive but it's a principal matter.

Thank you all again for your feedback. We have listened to your concerns and will release an updated 2.x version for those not opting to migrate to 3.0. We are working on the details now but it will likely have to come after 3.0 is out as we will have to back port many of the 3.0 changes to it to address some of the reports.

[madshi]

That sounds very good to me. Personally, I'll likely upgrade to 3.0, anyway. But I think releasing a 2.x bugfix version will go a long way to improve customer satisfaction. And as weird as it sounds: Releasing a 2.x bugfix version might motivate some people to actually upgrade to 3.0, which they might not do otherwise.

Maybe we should make a list of the showstopper bugs? From what I've read in this thread there seem to be at least 2:

(1) Hardware deinterlacing seems to sometimes have the fields swapped. From what I've read some of the open source decoders don't seem to have this problem, so it should be fixable.
(2) There seem to be some problems with DXVA.

Probably (2) consists of more than one problem. Anybody willing to fill in the gaps? But please don't go overboard. We should ask for bugfixes for showstopper bugs, only.

[nussman]

2.1 - on the fly format changes (i.e. 720p => 1080i) with DXVA
2.2 - no DXVA with dvbviewer sourcefilter

[molitar]

What gets me is that the upgrade offer is only for a short time.. Why would I pay out $7.95 without knowing if the problems are resolved.. Now we should still have the upgrade offer after it's released and we trial it and find it working. I been using mpc-hc and ffdshow internal since 2.5 because all 2.5 have had some major bugs with them. Crashing while switching from one monitor to another, green artifacts, ect. I don't mind paying the $7.95 upgrade AFTER I know it is working but not before.

[mkanet]

Sorry to go off subject. I have a very basic questiion. Does coreavc 2.5.5 and/or 3.0 have equivalent or better picture quality than the hardware accelerated nvidia setting (I use nvidia 8800) when using pure software decoding? I have an issue with FF/REW (no video for several seconds when I press REW/FF) if I use hardware acceleration. I doubt the issue I have with hardware acceleration mode is related to coreavc. I just want to make sure software mode is just as good as hardware (other than requiring more CPU usage). If someone know why I have the FF/REW problem, resolving that issue would be nice too.

Thanks,
MKANET

[nevcairiel]

The output of all H264 decoders is the same, as long as the decoders are not flawed. There is no quality difference between hardware or software decoders.

[LigH]

Modern video formats often have rather long "decoding units" (GOPs / GOVs), and their beginning is the only place where decoding may start without the risk of corrupt video output.

The ability to seek to either exactly the wanted timestamp (and decode quickly from the previous keyframe) or to the nearest decoding start keyframe is a matter of both the container splitter filter and the video decoder. And a more or less fluid FF / REW behaviour is only possible for video with rather limited complexity = rather low compression efficiency (like Blu-ray compatible video). Not all AVC videos are Blu-ray compatible. Not all AVC videos are suitable for such features. The longer the GOVs and the more multiple references, the less probable such features will work.

[mkanet]

Thanks. Having said that, how does that apply to remuxed bluray m2ts (AVC)->mkv container? What could have changed on this machine for FF/REW to cause no video for several seconds (I can still hear audio during this time). Right before the video is displayed again, I can see a few frames trickling in before video returns to normal. This problem seems to have started when I started messing with LAV splitter. I had set the below registry settings. Not sure if that has anything to do with the problem or how I would reset the problematic registry info.

[HKEY_CLASSES_ROOT\Media Type\Extensions\.m2ts]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.ts]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.mkv]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.mpls]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

Now, if I try installing Haali or LAV they both have this issue. If I switch to software decoding in my AVC decoder, the problem immediately goes away.

I would greatly appreciate any tips that would help fix this problem without having to reimage my machine.

Thanks again,
MKANET

Modern video formats often have rather long "decoding units" (GOPs / GOVs), and their beginning is the only place where decoding may start without the risk of corrupt video output.

The ability to seek to either exactly the wanted timestamp (and decode quickly from the previous keyframe) or to the nearest decoding start keyframe is a matter of both the container splitter filter and the video decoder. And a more or less fluid FF / REW behaviour is only possible for video with rather limited complexity = rather low compression efficiency (like Blu-ray compatible video). Not all AVC videos are Blu-ray compatible. Not all AVC videos are suitable for such features. The longer the GOVs and the more multiple references, the less probable such features will work.

[mkanet]

If that's true, then why are people so excited about CoreAVC 3.0 with 10bit decoding? Doesn't this affect picture quality? Is this feature software only decoding?

The output of all H264 decoders is the same, as long as the decoders are not flawed. There is no quality difference between hardware or software decoders.

[Underground78]

If that's true, then why are people so excited about CoreAVC 3.0 with 10bit decoding? Doesn't this affect picture quality?

It's 10bit encoding that improves the quality. Of course you will need 10bit decoding to use it but two decoders that support this feature will/must have exactly the same output.

[LoRd_MuldeR]

...but two decoders that support this feature will/must have exactly the same output.

Only if they output at 10-Bit.

Generally you won't have a full 10-Bit chain, including 10-Bit renderer and 10-Bit display. Instead dithering (or clipping) will happen at some point.

Even if the decoder outputs dithered 8-Bit from a 10-Bit source, 10-Bit encoding still has a lot of advantages (less "internal" rounding errors in the encoder/decoder).

But then the output may not be identical anymore, depending on what dithering algorithm is used by the individual decoder...

[edison]

I think the CRT display can do true 10-bit display.

[mkanet]

Thanks for explaining guys. I dont have any 10bit ended sources. The only H.264 video I watch is bluray.

If anyone happens to have any ideas what might cause the FF/REW "blank out" issue (only tested with bluray remuxed to mkv), please let me know. It's weird, as soon as I set acceleration to "none" I dont get that issue anymore. I can't use DXVA at all since I see the "green distortion artifact" issue with coreavc.

[BetaBoy]

Today we increased 9/10-bit decoding by 15% with the latest assembly changes for 3.0 ;-) We still have some time left before we call it final, so we are looking to finish some IDCT work. Also... I was asked by PM..... yes, we will support more 'Output' options for 10bit.

[nussman]

Please concentrate on the showstoppers!
10bit decoding is interesting but until now its a academic probelm.

[mkanet]

BetaBoy (or anyone):

Will CoreAVC 3.0 fix the problem with DXVA where video is distorted with green penalized artifacts. There have been screenshots posted here in the past with this issue. I dont have this problem when using MPC homecinema video filter using DXVA for AVC bluray material on the same machine.

Today we increased 9/10-bit decoding by 15% with the latest assembly changes for 3.0 ;-) We still have some time left before we call it final, so we are looking to finish some IDCT work. Also... I was asked by PM..... yes, we will support more 'Output' options for 10bit.

[BetaBoy]

We have several groups working on DXVA from several fronts, as with 2.x you will continue to see 3.0 refine DXVA 1/2 support with each 3.0 release. However 3.0 combines all of their efforts. It will become more apparent on whats been done after 3.0 is out.

We have reports of the 'green' issue and if I am not mistaken it has been fixed. I just sent a PM asking to confirm this.

[mkanet]

Thanks for asking. This alone would give me reason to upgrade.

PS: My weird FF/REW issue (mentioned above) is fixed. All I had to do was change to acceleration to disable on CoreAVC, then set it back to Cuda. I also upgraded my LAV splitter from version .29 to .30 (but seriously doubt that would make a difference).

-MKANET

We have several groups working on DXVA from several fronts, as with 2.x you will continue to see 3.0 refine DXVA 1/2 support with each 3.0 release. However 3.0 combines all of their efforts. It will become more apparent on whats been done after 3.0 is out.

We have reports of the 'green' issue and if I am not mistaken it has been fixed. I just sent a PM asking to confirm this.

[CruNcher]

Dan could you please check this
http://forum.doom9.org/showthread.php?t=162021

[BetaBoy]

CruNcher.... I have the guys looking into it.

[CruNcher]

Hehe i could fix the issues also with CoreAVCs DXVA, it's interesting if PTEs are to low DXVA (needs a lot of PTEs) cant be used with High resolutions anymore so for users using the /3GB switch you need to carefully balance it out with /USERVA= (User/kernel pools) you can take this into your help system for crazy XP users, using /3GB alone can cause DXVA problems (and most probably you need to manually adjust it for best Results in Video Acceleration/and Application Memory Efficiency above 2 GB for 32bit) ;)

[Nick [D]vB]

Sorry to go off-topic but have we got an ETA for CoreMVC yet? Any news on CUDA support for it? I just read something on AnandTech that gave me an idea, ATI seem to have worked out a way to partially accelerate MVC decoding on older UVD2.2 hardware (some Fusion APUs and the rebranded HD5750 -> HD6750s cards etc) Somehow they are treating the left stream as AVC and accellerating it with DXVA, then doing the right stream in shaders / software. This approach might allow for some acceleration on older nvidia cards (VP2/A), could it work for CoreMVC?

http://www.anandtech.com/show/4479/amd-a83850-an-htpc-perspective/6

http://forums.anandtech.com/showpost.php?p=31940090&postcount=17

[BetaBoy]

We have finished CoreMVC 3D's 'CORE', OMF (Open Media Format), directshow work and changes to the Haali Splitter to add support for MVC (and some minor splitter fixes). Also please see Peters post on OMF as its related to our initial CoreMVC 3D release: http://forum.doom9.org/showthread.php?t=156051

(Beta testers just got a new build this morning which adds Haali's new splitter as we are not using the MPC splitters Peter created for his Stereoscopic Player)

However we will are on hold for the next 2/3 weeks till we complete the changes for CoreAVC 3.0... 10-bit output options, ASM work, DXVA 1/2, deinterlacing issue, DXVA fallback, etc. We are planning however to release CoreMVC soon after CoreAVC 3.0 is out.

I'll have the guys look into the anandtech articles, thanx!

[Nick [D]vB]

Cool, I look forward to the CoreMVC release then! I had always hoped that any card with dual-stream H.264 support would be able to decode MVC in hardware with a few driver updates, at least the AVC part, but it seems to be "all or nothing". I suppose that sort of partial MVC acceleration would have to be engineered at driver level, or eveyone would be doing it right? Neither AMD or Nvidia have any real incentive to do it, if they want to sell new cards, except for in special cases like Fusion / rebrands.

I realise it's too late to add any major features to this version but it would be great if you could look into the idea for the future, maybe you could achieve something similar using CUDA? That would be another great USP for CoreCodec. I have been keeping an eye on that OMF thread but most of it goes straight over my head! lol Just out if interest, would it be possible to use the new splitter to send the left "AVC like" stream to a standard AVC codec (using DXVA) and the right MVC delta stream to CoreMVC? I suppose that would need some sort of custom renderer though?

Anyway, thanks for the update.

:)

[madshi]

We have finished CoreMVC 3D's 'CORE', OMF (Open Media Format)
We're still discussing the final OMF spec, though. Do you mean just the pin connection types Peter is currently using? They're not based on OMF yet, he has recently stated.

[BetaBoy]

We're still discussing the final OMF spec, though. Do you mean just the pin connection types Peter is currently using? They're not based on OMF yet, he has recently stated.

Peter will comment more on it.

[BetaBoy]

CoreAVC deinterlacing issue resolved.... we think. Still more testing to do but it looks like adding more checks has worked.

[nussman]

:thanks:

What do you think about an open Beta-Test for customers?
So that all showstopper-bugs can be fixed once and forever before the next release?

[clsid]

I don't use CoreAVC, so I don't know if the current version still has this bug, but has the thumbnailing crash been solved yet? That bug has been present for years.

[BetaBoy]

It was an issue with Haali's splitter and not CoreAVC. Haali disabled thumbnails a while back as he was tired of trying to work around the many shell bugs still present in Win 7.

[clsid]

I am not talking about Haali's shell extension. I am talking about thumbnailing with Microsoft's shell extension.

[BetaBoy]

Just added NVIDIA Cuda and DXVA directshow fallback to software when high bit is detected in CoreAVC 3.0.

[Mixer73]

I guess I'm not alone in recieving the following:

We are down to our last 48 hours to be able to get an upgrade to CoreAVC 3.0 for $7.95 with a purchase of CoreAVC 2.x now, before our price goes back to $12.95.

This is the cheapest way to get CoreAVC 3.0, as we will not be offering upgrades for this milestone to our current users.

CoreAVC 3.0 is the culmination of over 2 years of work and brings many new features:

- Full DXVA 1 / DXVA 2 support
- DXVA Fallback
- AVC 10-bit decoding support
- 4:4:4 profile support (in a later 3.x release)
- Additional hardware support (more info the 3.0 press release)

I added the bold for emphasis.

Dan, is this correct? Will owners of 2.0 not even be offered an upgrade to 3.0, and have to buy again?

I'm someone who has defended you on here, but honestly I'm struggling to find a real reason to use CoreAVC these days, and if I am not misunderstanding, and this is your intention, then you've definitely lost me.

[Maccara]

I added the bold for emphasis.


They worded it really ...badly.

I don't appreciate, as a customer, receiving an ultimatum...

[BetaBoy]

As stated we will continue to release 2.x with the reported issues (but not sell 2.x any longer once 3.0 has been released). So the choice to upgrade for the new features in 3.0 is up to the end user for their needs.

As always we are grateful for everyone's continued support.

[desta]

As stated we will continue to release 2.x with the reported issues (but not sell 2.x any longer once 3.0 has been released). So the choice to upgrade for the new features in 3.0 is up to the end user for their needs.

As always we are grateful for everyone's continued support.
Hardly! I paid for a product which never worked properly, which I never received any support for, despite requesting numerous times (and let's face it, you never tried) and now I'm being told that if I want the new version I've basically got to pay (again) a discounted price for the version I've already got. Genius.

[BetaBoy]

desta... While I understand what you are saying, as noted we 'will' still continue to release 2.x for the users that purchased it to address the reports we have. This means you will continue to get those 2.x updates as a part of your 2.x purchase and as stated a few pages back, we plan on releasing a new 2.x release soon after 3.0 is out.

Also for users that have recently purchased 2.x in the past 60 days, they get teh upgrade to 3.0 as a part of the purchase and will be the first ones notified on its availability.

[Mixer73]

As stated we will continue to release 2.x with the reported issues (but not sell 2.x any longer once 3.0 has been released). So the choice to upgrade for the new features in 3.0 is up to the end user for their needs.

Dan, please clarify that 2.0 owners cannot buy 3.0 at a cheaper price, and in fact must purchase 3.0 outright. This is how I have read your email.

[Ice =A=]

Is it so hard to understand?!?
You can get 3.0 cheaper for one more day by buying the 2.x version - AGAIN... :)

[Ice =A=]

@BetaBoy:

Are there any plans to implement advanced features into CoreAVC like motion compensation (computing pictures between pictures for more fluid movements)?
That (apart from nearly everything else) would truly be a unique feature!

And by the way: Are there any plans to release CorePlayer for Android (not just the Codec as SDK)?!?
I still renenber the old one for Windows Mobile, that just great!

Thanks!

[dead_screem]

Dan, please clarify that 2.0 owners cannot buy 3.0 at a cheaper price, and in fact must purchase 3.0 outright. This is how I have read your email.

He already did when I asked this a few pages back. http://forum.doom9.org/showpost.php?p=1514426&postcount=6422

If you own 2.x there will be no 2.x->3.0 upgrade discount at all. you need to re-buy. The good news is that after 3.0 is released they will still release bugfixes for 2.x version so it won't just go unsupported/deprecated like 1.x did.

[Audionut]

we plan on releasing a new 2.x release soon after 3.0 is out.

Unfortunately, corecodecs definition of "soon", differs from the english definition.

Just incase you guys are losing something in the translation, here you go. (http://dictionary.reference.com/browse/soon)

[Mixer73]

If you own 2.x there will be no 2.x->3.0 upgrade discount at all. you need to re-buy. The good news is that after 3.0 is released they will still release bugfixes for 2.x version so it won't just go unsupported/deprecated like 1.x did.

Thanks, thought personally I found CoreAVC a necessary requirement on a Vista or XP system, with Win7 I personally think there are other alternatives I'll pursue, I can't understand a company that doesn't first want to look after its installed userbase.

Anyway my last comment on the topic.

[Virtual_ManPL]

Is this bug finally fixed in version 3.0 ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600

[Abradoks]

Is this bug finally fixed in version 3.0 ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600
Man, that bug has been reported (http://forum.doom9.org/showthread.php?p=1367251#post1367251) and described (http://forum.doom9.org/showthread.php?p=1390804#post1390804) in details only 18 months ago, so you should be patient and shouldn't ask for fix again before January 2012. Don't get it wrong: you are ignored not because BetaBoy doesn't care, but because CoreCodec high qualified engineers have to save the world before they can get to that single-line-fix bug.

[dead_screem]

Is this bug finally fixed in version 3.0 ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600

Looks like CoreAVC is overriding the aspect set by the splitter with whatever it detects, which is fine, but it then sets it wrong in the output in _both_ cases.

CoreAVC+haali
output pin from haali splitter. aspect is set corectly as 853:480
Filter : Haali Media Splitter - CLSID : {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 39
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: avc1
biSizeImage: 0
biXPelsPerMeter: 720
biYPelsPerMeter: 853
biClrUsed: 0
biClrImportant: 0

CoreAVC+haali
output pin from CoreAVC. CoreAVC changes 853:480 display aspect to a completely ridiculous 14557:8192, which somehow gets changed to 71:40, either by the player or renderer (not sure). which gives an 852:480 display which is one pixel off on the X, should be 853.
Filter : CoreAVC Video Decoder - CLSID : {09571A4B-F1FE-4C60-9760-DE6D310C7C31}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: NV12 1024x480 (14557:8192) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 14557
dwPictAspectRatioY: 8192
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: NV12
biSizeImage: 737280
biXPelsPerMeter: 8192
biYPelsPerMeter: 9705
biClrUsed: 0
biClrImportant: 0

CoreAVC+gabest
output pin of gabest splitter. aspect set correctly as 853:480.
Filter : sample.mkv - CLSID : {0A68C3B5-9164-4A54-AFAF-995B2FF0E0D4}

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 166

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 34
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

CoreAVC+gabest
output pin of CoreAVC. CoreAVC is now changing the 853:480 aspect to 3:2, which is a 1:1 display so no aspect correction.
Filter : CoreAVC Video Decoder - CLSID : {09571A4B-F1FE-4C60-9760-DE6D310C7C31}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: NV12 1024x480 (3:2) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 720
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: NV12
biSizeImage: 737280
biXPelsPerMeter: 1
biYPelsPerMeter: 1
biClrUsed: 0
biClrImportant: 0

FFMPEG + haali
output pin of haali. 853:480 aspect
Filter : Haali Media Splitter - CLSID : {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}

- Connected to:

CLSID: {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}
Filter: MPC Video Decoder
Pin: Video

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 39
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: avc1
biSizeImage: 0
biXPelsPerMeter: 720
biYPelsPerMeter: 853
biClrUsed: 0
biClrImportant: 0

FFMPEG + haali
output pin of ffmpeg. 853:480 aspect still correct
Filter : MPC Video Decoder - CLSID : {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: YV12 1024x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 737280
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

FFMPEG + gabest
output pin of gabest. 853:480 aspect
Filter : sample.mkv - CLSID : {0A68C3B5-9164-4A54-AFAF-995B2FF0E0D4}

- Connected to:

CLSID: {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}
Filter: MPC Video Decoder
Pin: Video

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 166

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 34
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

ouput of ffmpeg. 853:480 aspect still correct
Filter : MPC Video Decoder - CLSID : {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: YV12 1024x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 737280
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

[BetaBoy]

On Aspect Ratio.... We have commented here several times, but let me address the post.

"CoreAVC doesn't respect AR when it's specified only in MKV header, but not in the stream."
What should take priority? The container? The header? What about all those broken MKV files that are out there?

"CoreAVC changes 853:480 display aspect to a completely ridiculous 14557:8192, which somehow gets changed to 71:40, either by the player or renderer (not sure). which gives an 852:480 display which is one pixel off on the X, should be 853."
Add it up... 853:480 and 14557:8192 are practically the same. The conversion to 71:40 is what is broken, and is causing the 'off by one' error.

[clsid]

For those who want Hi10P support right now, the latest versions of ffdshow, LAV Video, and MadVR all have support for decoding it.

[nevcairiel]

What should take priority? The container? The header? What about all those broken MKV files that are out there?

Since you ship by default with Haali anyway, which overwrites the stream AR with the container AR - i guess go with that?

For MKVs, its usually better to trust the container. Other formats might not have a container AR, like MPEG-TS. For MPEG-TS TV recordings its actually quite common to change mid-stream (between content and ads) which would of course only work if you use the stream value.

Adding an option to configure the behaviour doesn't sound too bad to me.

[BetaBoy]

Adding an option to configure the behaviour doesn't sound too bad to me.

Agreed.

[dead_screem]

"CoreAVC changes 853:480 display aspect to a completely ridiculous 14557:8192, which somehow gets changed to 71:40, either by the player or renderer (not sure). which gives an 852:480 display which is one pixel off on the X, should be 853."
Add it up... 853:480 and 14557:8192 are practically the same. The conversion to 71:40 is what is broken, and is causing the 'off by one' error.which begs begs the question, what is causing the conversion to 71:40?

And practically the same is not the same. 14557 / 8192 = 1.7769775390625 853 / 480 = 1.7770833333333 (repeating) while 14557:8192 should also give an 853x480 resolution the aspect should always be expressed in the lowest form. which is 853:480 in this case. The question is, is 14557:8192 what was actually in the avc bitstream or is CoreAVC coming up with this high value on its own? with gabest splitter and CoreAVC with that file, CoreAVC sets 3:2 aspect, was 3:2 what was actually set in the bitstream? ???

If Haali is actually modifying the AVC bitstream on the fly based on the container, there needs to be an option to disable that. In addition, there should also be an option in CoreAVC to enable/disable reading of the AR from the bitstream (and with it disabled just passthrough the AR from the splitter).


and another example of the off by one error.
but with a h.264 TS
output pin of gabest mpeg splitter gabest correctly sets 16:9 from the container (or its cheating and reading it from the bitstream, because there is no aspect in TS from what i hear?)
Filter : file.ts - CLSID : {1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 1440x1080 (16:9) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 187

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 55
dwProfile: 0x0000004d
dwLevel: 0x00000028
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 1440
biHeight: 1080
biPlanes: 0
biBitCount: 0
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

output of CoreAVC, it sets a weird 14563:8192 instead of 16:9. this somehow results in a off by one 1919:1080 final display...
Filter : CoreAVC Video Decoder - CLSID : {09571A4B-F1FE-4C60-9760-DE6D310C7C31}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: NV12 2048x1080 (14563:8192) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3317760
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000025
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 14563
dwPictAspectRatioY: 8192
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 2048
biHeight: -1080
biPlanes: 1
biBitCount: 12
biCompression: NV12
biSizeImage: 3317760
biXPelsPerMeter: 4096
biYPelsPerMeter: 5461
biClrUsed: 0
biClrImportant: 0

[leeperry]

BTW, I've got a wattmeter but I'm kinda lazy...anyone's ever compared the actual power consumption between CoreAVC CUDA and plain CPU decoding? I've just received my yearly energy bill, and it's substantially smaller than the year before http://forum.slysoft.com/images/smilies/agreed.gif

All I see in this thread is naysayers threadcrapping pretty much every page, but this would be useful information for a change...maybe I've missed it, though :o

[CruNcher]

BTW, I've got a wattmeter but I'm kinda lazy...anyone's ever compared the actual power consumption between CoreAVC CUDA and plain CPU decoding? I've just received my yearly energy bill, and it's substantially smaller than the year before http://forum.slysoft.com/images/smilies/agreed.gif

All I see in this thread is naysayers threadcrapping pretty much every page, but this would be useful information for a change...maybe I've missed it, though :o

you would have to compare CoreAVC Cuda vs DXVA vs Software DXVA should in theory save the most energy though if you go from this standpoint you could even save more energy with a ARM or MIPS Decoding setup and abond the PC ;)

the cheapest craziest thing currently is the Apple TV 2 for 99 bucks you get a complete XBMC player though using tricks to get 1080p->720p playback with scaling (though with crazy energy performance) ;) http://www.youtube.com/watch?v=wJ26L4nTy4s

Or if you adventurous a Pandaboard their you would get 1080p native without tricks @ low power ;)

With such a thing you would save much more money then with anything you do on your IBM PC either with CUDA,DXVA or any Software Decoder ;)

Though Tegra 3 will be the craziest of all finally Nvidia is going to bring all the Power of their Desktop Decoder to the Mobile space and go even beyond http://cdn.static.viddler.com/flash/as3/simple-publisher.swf?key=6dbeeef0 (after the Tegra 2 vs Intel CE Atom disaster on the Boxee Box (heavy playback limitations of their SOC no weighted prediction low bitrate ect)) :D

A good Decoder IP core these days needs no more then 500mw for full 1080p AVC decoding :)

Tegra 3 stuff and Sonys Vita are the most interesting upcoming things :)

[namaiki]

If/Since CoreAVC 2.x won't support decoding of Hi10P/10-bit video, would it be possible for you to please do a maintenance release for 2.x so that it automatically won't be used when a 10-bit video is played?

[mandarinka]

That would indeed be great.

[mkanet]

Sorry if this has been brought up before. I'm curious how the latest CoreAVC CUDA compareS to the latest LAV CUVID CUDA. It looks like LAV CUVID has a lot more features; including a nice surprise... VC1 decoding; which makes sense if you need your decoder for bluray playback.

[ney2x]

^
LAV CUVID = Free to use but expect to have some bugs/problems. Regular updates.
CoreAVC = You need to pay. Updates annually.

[mkanet]

Yeah, I already found that out. I couldn't get the LAV video decoder to connect to any video renderers. I first thought I was doing something wrong, but it looks like it's just a problem with the decoder (at least on my system; which works perfectly with CoreAVC CUDA).

^
LAV CUVID = Free to use but expect to have some bugs/problems. Regular updates.
CoreAVC = You need to pay. Updates annually.

[BetaBoy]

A heads up. We are preparing to release final builds of CoreAVC 3.0 to beta testers after tomorrow.

[hajj_3]

any chance of a changelog?

[BetaBoy]

Ill post the changelog once all the new changes are verified by the larger pool of beta testers.

Also pls note for 2.x users it will be a few weeks for us to back port some of the changes/fixes we made for 3.0... but as stated we do plan a follow-up 2.6 release.

[BetaBoy]

If/Since CoreAVC 2.x won't support decoding of Hi10P/10-bit video, would it be possible for you to please do a maintenance release for 2.x so that it automatically won't be used when a 10-bit video is played?
I threw it at the devs to think about how to handle.

[TheShadowRunner]

BetaBoy, will decoding hi10p contents benefit from the current acceleration methods (CUDA, DXVA..) in CoraAVC 3.0, or will it be 100% software only?
I can imagine DXVA is a no go, but I wonder about CUDA..
Thanks for the info.

[BetaBoy]

Ill comment once 3.0 is out, but you're not far off.

[TheShadowRunner]

Thanks for the fast reply. The wait starts now ;)

[mandarinka]

What conversion method does CoreAVC use to convert 10bit to 8bit yv12 in software?

Madshi reported earlier that the method used by x264 and ffdshow/lavvideo/mplayer/etc (everything using swscale for the job) is somewhat wrong and possibly disagrees with Microsoft's specification. Some details in this thread: http://forum.doom9.org/showthread.php?p=1517620#post1517620

Will CoreAVC mimic FFDshow&friends' method, or will it use something like what Madshi suggests (and is using in madvr I assume)?

[nevcairiel]

What that thread was about was really conversion from 8bit to 10bit (for encoding), not the other way around.

For 10 to 8, there really is only one proper way to do it, and that is dithering, with saturation/clipping.

[madshi]

What that thread was about was really conversion from 8bit to 10bit (for encoding), not the other way around.

For 10 to 8, there really is only one proper way to do it, and that is dithering, with saturation/clipping.
Agreed.

(Of course ideally no downconversion should be done at all, passing the full bitdepth downstream, but only very few DirectShow filters accept high bitdepth content.)

[mandarinka]

However, doesn't x264's upconversion match swscale's downconversion? I was under the impression that when x264 converts 128 to 514, swscale will convert the 514 back to 128, which is why nobody noticed this shift in 10bit, initially.
While the proper process would be 128 -> (x264) -> 512 -> (swscale) -> 128. Dithering only makes the conversion higher quality, but doesn't help when the conversion uses wrong relation, does it?

[nevcairiel]

The downconversion in swscale uses dithering and shifting, there is nothing special there.

[cyberbeing]

However, doesn't x264's upconversion match swscale's downconversion? I was under the impression that when x264 converts 128 to 514, swscale will convert the 514 back to 128, which is why nobody noticed this shift in 10bit, initially.
For 10-bit -> 8-bit conversion it seems to be a swscale implementation problem, rather than a swscale problem.

Implentation #1: madVR, MPlayer (swscale), and FFMS2 (lav?) overall match the color/hue of each other.

Implentation #2: FFDShow (swscale) and LAV Video (swscale) match the color/hue of each other.

Implemation #1 is assumed to be correct way, but nobody on the FFDShow/LAV-Video side has taken the time to figure out why their swscale results differ from MPlayer swscale results and others...


The downconversion in swscale uses dithering and shifting, there is nothing special there.

The nothing-special 10-bit -> 8-bit near-matching downconversion of swscale implementation in FFDShow/LAV-Video, does come much closer to reversing the skewed encoded levels of x264 swscale 8-bit -> 10-bit than the 10-bit -> 8-bit near-matching downconversion of madVR, ffms2, and the swscaled implementation in MPlayer.

Since nobody seems to have any desire to fix swscale in x264 anytime soon, I think this is a valid question for CoreCodec.

A) For the time being does CoreAVC assume all 10-bit x264 encodes have skewed levels, and actively attempt to reverse the problem in 10-bit -> 8-bit conversion? When x264 is fixed, a quick 3.0.x release is pushed out with proper 10-bit -> 8-bit conversion?

B) Does CoreAVC support both a skewed x264 10-bit levels correction as well as proper conversion from the start, and add a toggle in the settings dialog?

C) Does CoreAVC only do proper 10-bit -> 8-bit conversion and show the skewed levels in the source as madVR, ffms2, and MPlayer do?

D) Does CoreAVC do none of the above and just mimic FFDShow/LAV-Video 10-bit -> 8-bit?

[nevcairiel]

I looked at the conversion in swscale that was used before, and it does use some scaling logic that trys to avoid overflows, maybe that logic was tuned against a broken encode - on the first glance it didn't look all that special, but i didn't double check the math, as its not needed for my case.

The next LAV Video will do proper 10bit -> 8bit conversion, because i implemented my own algorithm for dithering (which is much faster then swscale, because i wrote it using SSE2, and avoids overflows automatically).
If the source is broken, then the source is broken. For the best quality, you shouldn't convert it to 8-bit anyway (which means you'll see the encoder error with madVR, too)

You should instead pressure x264 to fix it, rather then trying to get every 10-bit capable decoder out there to implement hacks to work around bugs in the encoder.

[cyberbeing]

You should instead pressure x264 to fix it

I just did a Google search, and it looks as if today, a libav dev finally took interest in fixing the problem. So maybe this actually will get resolved in the near-future:

http://thread.gmane.org/gmane.comp.video.libav.devel/9285

[JEEB]

Implentation #1: libav swscale (by BBB)

Implentation #2: ffmpeg swscale (by michaeln)
And they are both broken at the moment, as you have found out (at least when comparing to BT.709 and MS's limited YUV range implementations) :)

Also, it would be possible to use the borked algorithm based on the SEI encoder version information in case it exists in the stream, but the possibility of this should only be thought about after x264 gets fixed in this sense :) .

[mandarinka]

That would however try to "fix" the skew in all encodes from affected x264 revisions, which could be wrong - for example, if you feed x264 with video that already is 10bit, it won't run its conversion (I assume?), video will have the proper levels and thus the workaround will mess it up.

[nevcairiel]

Indeed, the conversion to 10bit needs to be fixed to match native 10bit material as closely as possible, so that one playback processing path can be devised that works perfectly, no matter what was the source.

[madshi]

@BetaBoy, allow me to follow up on the discussion about RGB output levels we had in the other thread. Please have a look at this sample file:

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

It's a smooth 8bit gray ramp. Now please playback that ramp with CoreAVC, by outputting NV12 to madVR and switch madVR to PC levels. Afterwards switch CoreAVC to RGB output and use any renderer you like. Compare image quality. Here are screenshots for a quick comparison:

screenshot 1: (http://madshi.net/levelsChange1.png) CoreAVC outputs NV12 (video), madVR converts to RGB (PC)
screenshot 2: (http://madshi.net/levelsChange2.png) ffdshow outputs RGB (video), madVR converts to RGB (PC)
screenshot 3: (http://madshi.net/levelsChange3.png) CoreAVC outputs RGB (PC), madVR displays the result untouched
screenshot 4: (http://madshi.net/levelsChange4.png) ffdshow outputs RGB (PC), madVR displays the result untouched

You see the problem?

Changing levels in 8bit is a very bad idea, and that's what CoreAVC is doing (and ffdshow, too). The same banding artifacts will occur with YUV output, too, of course, if you modify the input/output levels. IMHO the default configuration of CoreAVC should be to leave levels untouched. If the source is encoded in limited range (16-235) then CoreAVC should output both YUV and RGB as limited range by default. If the source is encoded in full range (0-255) then CoreAVC should output both YUV and RGB as full range by default. Only this way gradients will stay smooth. madVR performs any necessary levels conversions in floating point math and dithers the result down to 8bit, which is of course much higher quality. So levels changes should best be left to the renderer, at least by default.

Of course this is just my personal opinion. If you want to implement a better quality algorithm for changing levels (using higher internal bitdepth, with a final dithering pass), that'd be fine with me, too.

Ideally, whatever you do with the levels, it would be great if you could inform the downstream filters about it. That way the renderer would be able to automatically adjust. The easiest way to pass this information along would be to use the DXVA_ExtendedFormat structure (which is an optional part of the VIDEOINFOHEADER2 structure), as mentioned in the other thread. For the output levels information you'd just have to fill the "NominalRange" part of the structure. Of course if you want to fill the other parts, too, that'd be nice. You'll find more information about how to convert the h264 header elements into DXVA_ExtendedFormat values in the following post:

http://forum.doom9.org/showthread.php?p=1519740#post1519740

[BetaBoy]

Madshi.... Thx again. We cannot do much for CoreAVC 3.0 considering we are about to go 'gold' and release it but we are looking at the suggestions for followup releases.

[madshi]

That's just fine, BetaBoy. After all CoreAVC works well with its default settings. So my suggestions are not urgent.

[TheFluff]

IMHO the default configuration of CoreAVC should be to leave levels untouched. If the source is encoded in limited range (16-235) then CoreAVC should output both YUV and RGB as limited range by default. If the source is encoded in full range (0-255) then CoreAVC should output both YUV and RGB as full range by default.

Excuse me for a second here, but how is it that the phrase "limited range RGB" makes any sense whatsoever to you? I'd very much like to be enlightened, because you seem to be in the possession of some truly Lucy-in-the-Sky-with-Diamonds-level shit and I'd like to try it.

[mandarinka]

I was under the impression that projectors (and maybe some TVs) commonly expect limited range in rgb too, meaning that if you feed them full range, you'll get overcontrasted image with darks and brights clipped to black/white.
In any case ffdshow (and other decoders) do have a setting to output 16-235 range RGB, apparently for this reason...

(please correct me if that's not true...)

[madshi]

Excuse me for a second here, but how is it that the phrase "limited range RGB" makes any sense whatsoever to you? I'd very much like to be enlightened, because you seem to be in the possession of some truly Lucy-in-the-Sky-with-Diamonds-level shit and I'd like to try it.
There are 2 types of displays:

(1) Computer monitors, mostly LCD.
(2) CE (Consumer Electronics) displays, like LCD TVs, plasma TVs, projectors etc.

In the computer world, black has historically always been RGB(0,0,0). So if you send RGB to a (1) display, the display expects black to be at RGB(0,0,0). However, in the CE world, things are quite different. There we have things like BTB (blacker than black) and WTW and black is usually expected to be at RGB(16,16,16). Standalone hardware DVD players and Blu-Ray players usually output black at RGB(16,16,16), if you switch them to RGB output. Some DVD/Blu-Ray players and some TVs/projectors can be switched between limited range (black = 16) and full range (black = 0) mode, but not all. The PS3 and Xbox360 can be switched between limited and full range, too, AFAIK. There are different names for that switch, e.g. Limited vs. Full, or Studio vs. Computer, or TV vs. PC, or Normal vs. Extended etc...

99.9% of all h264 consumer content is encoded in YCbCr 4:2:0 with black at Y = 16 and white at Y = 235. If you switch the h264 decoder to output RGB, the decoder can either output black at RGB(0,0,0) or at RGB(16, 16, 16). The latter requires less processing. Outputting black at RGB(0,0,0) means that after YCbCr -> RGB conversion you need to perform a stretch operation to get black from 16 to 0 and white from 235 to 255. This stretch operation introduces visible banding if you perform it in 8bit. That's why I'm asking Core to skip this stretch operation and to inform the downstream filters about whether the CoreAVC RGB output has black at 0 or 16.

All cleared up now?

[fastplayer]

All cleared up now?
By the way, you explain technical "stuff" very comprehensible. :)

[madshi]

Thanks. :)

[Stephen R. Savage]

Outputting black at RGB(0,0,0) means that after YCbCr -> RGB conversion you need to perform a stretch operation to get black from 16 to 0 and white from 235 to 255. This stretch operation introduces visible banding if you perform it in 8bit.

This is a completely illogical claim. Conversion between YUV and RGB and from limited to full-range are both linear processes, so there is no reason that they must be done in two steps.

[madshi]

This is a completely illogical claim.
You could have left this sentence away, you know. No need to be impolite.

Conversion between YUV and RGB and from limited to full-range are both linear processes, so there is no reason that they must be done in two steps.
Doing it in two steps is how it's usually done, and probably done by CoreAVC. You're right, though, in that it could be done in one step. But even if you do it in one step, you'll still get banding, if you use simple rounding. The only way to avoid banding would be to use dithering or to output a higher bitdepth than 8 bit.

[Stephen R. Savage]

Doing it in two steps is how it's usually done, and probably done by CoreAVC. You're right, though, in that it could be done in one step. But even if you do it in one step, you'll still get banding, if you use simple rounding. The only way to avoid banding would be to use dithering or to output a higher bitdepth than 8 bit.

Everything that you say here is correct, and yet it still doesn't logically follow that "limited-range" RGB is a preferable output format. Even if the default output range in CoreAVC were changed, it would still be rounded (probably truncated, actually), etc. Further, a direct conversion from limited YUV to full-range RGB does not add any more rounding error than a conversion from limited YUV to limited RGB, since both involve the same number of 8-bit multiply/divide operations.

The only thing that will change is that suddenly everyone will have broken levels in something that used to work just fine.

[madshi]

Everything that you say here is correct, and yet it still doesn't logically follow that "limited-range" RGB is a preferable output format. Even if the default output range in CoreAVC were changed, it would still be rounded (probably truncated, actually), etc. Further, a direct conversion from limited YUV to full-range RGB does not add any more rounding error than a conversion from limited YUV to limited RGB, since both involve the same number of 8-bit multiply/divide operations.
I'm sorry, but I disagree. Let's look at a simple gray ramp:

Y: 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, ...
Cb: 128, 128, 128, ...
Cr: 128, 128, 128, ...

Try to convert that to full range RGB and to limited range RGB with rounding. You'll get smooth output with no banding with limited range RGB, but you'll get banding with full range output. The simple reason for that is that with a gray ramp the Y values map directly to the limited range RGB output. E.g. YCbCr 16,128,128 converts to exactly RGB 16.0,16.0,16.0. Of course it would be preferred to perform dithering after the YCbCr -> RGB conversion. When dithering is used, both limited and full range output should be banding free.

If you don't believe me, just look at the screenshots I posted. Compare ffdshow limited vs. full range RGB output. These screenshots undeniably proof what I just said. Unless you believe that I faked the screenshots or made a mistake? If so, it should be easy for you to double check yourself.

The only thing that will change is that suddenly everyone will have broken levels in something that used to work just fine.
All renderers (other than madVR) passthrough RGB untouched. If CoreAVC always outputs PC levels, users which have a projector/TV which needs TV levels will get broken levels, while users with a computer type monitor will get correct levels. IMHO this behaviour is already broken right now. CoreAVC has three switches for output levels, "PC", "TV" and "Auto detect". All I'm asking for is to honor these switches for RGB output, too. If users need CoreAVC to output RGB with PC levels, like it does now, it should be no problem for them to manually change the CoreAVC settings accordingly.

[Stephen R. Savage]

All renderers (other than madVR) passthrough RGB untouched. If CoreAVC always outputs PC levels, users which have a projector/TV which needs TV levels will get broken levels, while users with a computer type monitor will get correct levels. IMHO this behaviour is already broken right now. CoreAVC has three switches for output levels, "PC", "TV" and "Auto detect". All I'm asking for is to honor these switches for RGB output, too. If users need CoreAVC to output RGB with PC levels, like it does now, it should be no problem for them to manually change the CoreAVC settings accordingly.

Shocking! Computer software is written to specifications that match typical computer hardware!

[Audionut]

Shocking! Computer software is written to specifications that match typical computer hardware!

That might have made sense 10 years ago. Now it just goes to show that your a typical user who thinks his setup is default and anything else shouldn't be accounted for.

[robpdotcom]

Isn't the fact that madVR does things differently from "all other renderers" one of the things that makes it better than all other renderers?

[Stephen R. Savage]

That might have made sense 10 years ago. Now it just goes to show that your a typical user who thinks his setup is default and anything else shouldn't be accounted for.

What about my typical user?

As for this meaningless ad hominem attack, what madVR and CoreAVC do make no difference to me, seeing as I use neither. I merely wanted to point out the delusion required to claim that "limited-range RGB" as a default made any sense.

[Nevilne]

Honestly adding a menu choice of how to handle RGB input seems to be the best option for madvr, you can see some valid points from both camps.

But back to coreavc, are there any benchmarks from 3.0 beta or is it under NDA?

[madshi]

Shocking! Computer software is written to specifications that match typical computer hardware!
In case you didn't know, a key market for both CoreAVC and madVR is HTPCs. And if you look up "HTPC" at wikipedia, it says:

> Standard PC units are usually connected to
> a CRT or LCD display, while HTPCs are designed
> to be connected to a television

And "televisions" typically expect limited range RGB, not full range RGB. So designing CoreAVC to forcefully always output full range RGB doesn't make much sense.

I merely wanted to point out the delusion required to claim that "limited-range RGB" made any sense.
Delusion? You want to ignore the fact that (rounded or truncated) full range RGB output results in visible banding, while limited range RGB output does not (see screenshots)? You want to ignore the fact that TVs and projectors need limited-range RGB? Ok, I give up. If you choose to ignore hard proof and facts then there's really no point in discussing this any further.

[Stephen R. Savage]

Delusion? You want to ignore the fact that (rounded or truncated) full range RGB output results in visible banding, while limited range RGB output does not (see screenshots)? You want to ignore the fact that TVs and projectors need limited-range RGB? Ok, I give up. If you choose to ignore hard proof and facts then there's really no point in discussing this any further.

If some esoteric hardware requires a different, obscure RGB format, the answer is not to change the default behavior and break compatibility with the majority of end-users. As for your claim regarding banding, first of all, essentially no end-user cares about quality; this is a verifiable fact. More importantly, if you really cared about quality, you would only use the YV12/NV12 format anyway, since any RGB, regardless of range, will already be rounded or truncated to 8-bit.

When someone chooses RGB output, especially in something like CoreAVC which doesn't even pretend to have high-quality conversion, chances are they aren't concerned about banding or anything like that, but merely want to quickly display something in some application that requires RGB. And chances are, such legacy applications will require full-range RGB, the standard format.

Besides, even if the default behavior for RGB conversions were changed, you would still be on here telling people to use YV12 and trust in the Magic Power (TM) of madVR color conversions. So, really, I don't see why it's such a big deal to you.

[ranpha]

If some esoteric hardware requires a different, obscure RGB format, the answer is not to change the default behavior and break compatibility with the majority of end-users. As for your claim regarding banding, first of all, essentially no end-user cares about quality; this is a verifiable fact. More importantly, if you really cared about quality, you would only use the YV12/NV12 format anyway, since any RGB, regardless of range, will already be rounded or truncated to 8-bit.


Since when TVs and projectors has been categorized as 'esoteric hardware'? I bet that TV/projectors that supports limited range will greatly outnumber those that support full range RGB. And since when limited range RGB has become a 'different,obscure RGB format'? Engineers from AMD (the champion of limited range RGB) will want to have a word with you about that.

BTW, 'quality' and 'RGB' are not mutually exclusive options even in the context of CoreAVC. All CoreCodec needs to do is to fix the bug mentioned in this thread before. You can have your cake and eat it too you know.

When someone chooses RGB output, especially in something like CoreAVC which doesn't even pretend to have high-quality conversion, chances are they aren't concerned about banding or anything like that, but merely want to quickly display something in some application that requires RGB. And chances are, such legacy applications will require full-range RGB, the standard format.

If one of the 'applications that requires RGB' (which definitely is not mainstream video players like MPC-HC or WMP or KMPlayer et. al.) can actually use CoreAVC, you can definitely subvert its requirements and make it output YV12 or NV12.

Oh BTW, can you give an example of an 'application that requires RGB' that can also use CoreAVC? I cannot think of one.

[ryrynz]

I believe this argument has gone beyond logical debate.
I think your time could be much better spent doing something other than arguing the merits of implementing a feature for which the both of you have successfully proven the benefits of implementing. ;)

[BetaBoy]

We just went 'gold' with CoreAVC 3.0. We will release CoreAVC 2.6 later today and have set a release date of Tuesday Sept 6th for CoreAVC 3.0.

[BetaBoy]

The release is being sent now...


CoreAVC H.264 Video Codec - Version 2.6.0.0 (20110830)
- ADD: DXVA fallback to software
- ADD: Improved DXVA handling for interlaced streams
- ADD: DXVA 2 Long slice support
- CHG: Use container AR when there is no stream AR
- FIX: Improved Frame order handling
- FIX: Hardware deinterlacing field order

Haali Media Splitter - Version 1.11.233.7 (20110830)
- FIX: Various DTS Audio bugs
- ADD: Improved DTS support
- ADD: Support for MVC 3D videos

[BetaBoy]

As you can see we also pushed out a new Haali splitter that addresses some (not all) of the leading issues as well as adding support for MVC. This is ahead of of releasing CoreMVC 3D which we expect to do after the CoreAVC 3.0 dust settles.

[TheShadowRunner]

If/Since CoreAVC 2.x won't support decoding of Hi10P/10-bit video, would it be possible for you to please do a maintenance release for 2.x so that it automatically won't be used when a 10-bit video is played?

Guess not :/

[BetaBoy]

Try it and see.

[nevcairiel]

Try it and see.

I did, and 2.6 does infact not refuse, it trys to decode, and ends up with a black screen. It doesn't fallback to a decoder that is 10-bit capable.

[TheShadowRunner]

Try it and see.

Oh an unadvertized feature? This sounds promising ;)
A somewhat related question, I'm stuck with nvcuvid.dll version 266.58 because of a nVidia bug that has Windows XP BSOD when playing flash videos with certain cards (8x00 / 9x00) and any drivers above 266.58.
Does the nvcuvid.dll version make a difference when it comes to decoding with CUDA? (I guess I could replace my current nvcuvid.dll 266.58 by one from the latest 280.26 driver package if it does)

[BetaBoy]

You beat me too it (on the feature) ;-)

nevcairiel... correct 2.6 will not fallback to another codec, but show a black screen for hi10 content.

TheShadowRunner... From our discussions internally, no it should not matter what DLL you are using.

betaking... Sorry about that... the accounts are a 'rolling' update and sometimes emails get ahead of the update to your account. Check back in a lil bit, it should be there.

[betaking]

Hi.betaboy I received e-mail prompted me to go to the website to update to 2.6, but I found that after landing, or you can still download version 2.5.5!
and i can not found Haali Media Splitter - Version 1.11.233.7 (20110830) in haali's website!

[TOM_SK]

[Off-topic]
@Marlin: Hi, is there any affiliate/reseller program for CoreAVC Professional Edition ? I looked everywhere on CoreCodec website but can't find any.

Thanks.

[BetaBoy]

TOM_SK... sure.... once you login to your account... Under 'Corporate' you'll see 'Affiliates', just hi the 'activate' button to enable it for your account. It will then give you the info you need.

RE: https://customers.corecodec.com/affiliates.php

[CiNcH]

2.5.5 broke DXVA with DVBViewer DVBSource filter

2.6 breaks compatibility with DVBViewer DVBSource filter "completely". Tray icon is blue (indicating no DXVA) and picture inside the DVBViewer stays black. It seems as if no data arrives at the renderer.

You promised us to look into the thing!?

[BetaBoy]

and i can not found Haali Media Splitter - Version 1.11.233.7 (20110830) in haali's website!
You will not find this version on Haali's site yet as its only in CoreAVC 2.6 and 3.0 because of all the work we have done to it.

I'll sync with him on updating his site.

[BetaBoy]

CiNcH.... the testers we had for DVBViewer did not indicate anything was broken. We are looking into it (again).

[BetaBoy]

A note... we are rolling out the 2.6 update to current customers first. We will list it's availability to the public next.

[nussman]

2.5.5 broke DXVA with DVBViewer DVBSource filter

2.6 breaks compatibility with DVBViewer DVBSource filter "completely". Tray icon is blue (indicating no DXVA) and picture inside the DVBViewer stays black. It seems as if no data arrives at the renderer.

You promised us to look into the thing!?

Same here ...
Maybe you need some new testers for dvbviewer? :rolleyes:

[BetaBoy]

We also found that some people are getting the error: Error loading C:\Program Files\CoreCodec\CoreAVC Professional Edition/CoreAVCDecoder64.ax
The specified module could not be found.

Added to the todo.

[TOM_SK]

We also found that some people are getting the error: Error loading C:\Program Files\CoreCodec\CoreAVC Professional Edition/CoreAVCDecoder64.ax
The specified module could not be found.

Added to the todo.

Got the same error when installing CoreAVC on 32-bit Windows 7 HP. Btw, pls. check your pm.

[BetaBoy]

yeah.... everything installs fine. It just looks like for some 32bit users they get the error.

[nussman]

I got the same message @Win7 32bit, but thats not the main problem with coreavc 2.6! ;)

[CiNcH]

Happened to me too. Did not mind either. There are indeed more important things to fix... still... things that have been called showstoppers within this thread.

[nussman]

Deinterlacing issue:

Seems to work with haali splitter, but the field order is still wrong with mpc-hc splitter (and i guess with all other splitters too?)!

[CiNcH]

So we have to find out what Haali Splitter does differently and how CoreAVC determines field order.

[BetaBoy]

32bit installer bug fixed for the next release.

[BetaBoy]

CiNcH.... Can you try and play local files in DVBViewer and see if u get the same results. Since we dont have any DVB service we just tested local content and it plays fine.

[betaking]

32bit installer bug fixed for the next release.

Next week or tomorrow?Another new version of coreaac planned it?

[CiNcH]

Local file does not work either...

http://members.inode.at/762450/coreavc/dvbsource_coreavc.jpg

Do you use latest version?

[BetaBoy]

Yes... and it works on 2 different systems.

[BetaBoy]

Next week or tomorrow?Another new version of coreaac planned it?

We are gonna push out a silent update for the installer issue in the next few hours.

[betaking]

We are gonna push out a silent update for the installer issue in the next few hours.

Thanks!

[CiNcH]

Yes... and it works on 2 different systems.
I have done some further tests with the DVBViewer 4.8.1 stock DVBSource version 3.5.5.

Additionally I tried various CoreAVC settings, I tried different renderers (EVR-CP, EVR Standard, VMR9 Renderless, VMR9 Standard, Overlay with Aero off under W7). No chance to get a picture.

[Guest]

I received this in email from Core:

---
This is a free upgrade. To get the 2.6 update, log in to your account
at https://customers.corecodec.com <https://customers.corecodec.com/>
and download it from the 'My Products' area.
---

But when I try to download there is no download offered and instead I get this in email:

---
We have received your order and will be processing it shortly. The details of the order are below:

Order Number: 8321699570

Upgrade Software: CoreAVC 2.5 (Free Upgrade from 2.0) => CoreAVC 2.6 (Free Upgrade from CoreAVC 2.5)
Billing Cycle:
Total Due Today: $0.00 USD

You will receive an email from us shortly once your account has been setup. Please quote your order reference number if you wish to contact us about this order.
---

I already have an account! I just want to download my free update. Why is this happening and when will I be able to download my update?

Thank you.

[nussman]

CiNcH.... Can you try and play local files in DVBViewer and see if u get the same results. Since we dont have any DVB service we just tested local content and it plays fine.
As far as i know there is no difference between "LiveTV" and "Playfile" when using dvbvsource filter.

Are you sure that dvbvsource filter was used in your tests?
Could you tell us your CoreAVC / DVBViewer settings?

[Romario]

What about 3.0 final, when we can expect it ?

[Chumbo]

I don't see 2.6 under My Products & Services on web site. What's the point of the email being sent out BEFORE the product is actually available?

[clokkevi]

The new CoreAVC 2.6.0 itself seems to work very well (for all the files I have),
however, after I installed the new Haali Media Splitter 1.11.233.7
most of my .mp4 files were not handled properly anymore.
The audio-streams were OK, but not the video-streams.
Haali would not connect to any of my AVC/H.264 decoders;
neither CoreCodec CoreAVC 2.6, MPC-HC's built-in H264/AVC (DXVA/FFmpeg) 6.4.0.2 , nor FFDShow 1.1.3611
(I always set the "Output" -> "Use custom media type for H.264" option in Haali Media Splitter to "no")

So I re-installed the old Haali Media Splitter 1.11.96.14,
and now all the .mp4 files are working again.

(The only .mp4 files I had that still continued to work with 1.11.233.7 installed,
were some that had "mp4v" / "MP4V" instead of "avcC" / "avc1" video-streams.)

[Chumbo]

I don't see 2.6 under My Products & Services on web site. What's the point of the email being sent out BEFORE the product is actually available?
Not very intuitive, but I figured it out. You have to click on your existing 2.x purchase and then there's a link to the "there's an upgrade available" at the top. Not the most obvious. It would be more helpful to have an "upgrade available" icon or something on the main products page.

[CiNcH]

@ BetaBoy,

did you actually play a TS/M2TS file via the DVBViewer with DVBSource in use? Please check 'View' -> 'Filters' within the DVBViewer to check which DirectShow filters are being used. Just to make sure that both, DVBSource and CoreAVC, are in the graph...

As far as i know there is no difference between "LiveTV" and "Playfile" when using dvbvsource filter.
Not quite. It's push vs. pull. Anyway, file playback (pull) is also affected.

[pankov]

BetaBoy,
you should consider finding a beta tester who actually has a DVB Service ... or at least somebody else with good upload speed who can share his existing one using the DVB Recording Service. It's pretty easy to do it but sadly my international upload speed won't be enough to sustain a HDTV channel (which is the one I have the deinterlace issues with)
:(
if you can't find one just PM me and we can try to clear the connection details and try with SD channel

[CiNcH]

I think that all problems so far were (or could have been) sorted out with files...

A push scenario can also be simulated BTW.

[mkanet]

I just upgraded to CoreAVC 2.6. I am currently use Cuda mode. It seems some of my videos have that screwed up green distortion issue I used to see only in DXVA mode. This issue is consistent with certain videos. If I were to guess, it looks like CoreAVC 2.6 is trying to use DXVA for certain videos; even though it doesnt work correctly and I have Cuda selected.

Any way I can fix this without reverting back to version 2.5.5?

PS: I'm sure you guys already know this, but there's a bug in the 2.6 installer, it complains that the 64bit coreavc decoder is missing. I'm using a 32bit OS.

Thanks

[josephwright]

Hi BetaBoy. I'm still experiencing the same hardware deinterlacing issue in 2.6 (with UK DVB in Mediaportal). Please let me know if I can provide any details to help get this fixed! Maybe a I could upload a test recording somewhere?

[BetaBoy]

The silent update to address the installer error is now live in the portal.

[BetaBoy]

Hi BetaBoy. I'm still experiencing the same hardware deinterlacing issue in 2.6 (with UK DVB in Mediaportal). Please let me know if I can provide any details to help get this fixed! Maybe a I could upload a test recording somewhere?
josephwright... yeah I will need a sample as all known hardware deinterlacing issues had been resolved.

[CiNcH]

josephwright... yeah I will need a sample as all known hardware deinterlacing issues had been resolved.
Just play the various samples that you already have within MediaPortal (or whatever player) with a different splitter than Haali (e.g. the MPC-HC MpegSplitter). You may still stumble over the field order issue...

[CiNcH]

Just for the records, plain and simple, field order for interlaced content is not fixed at all with splitters other than Haali:

Haali -> CoreAVC 2.6 (DXVA) -> EVR: OK
http://members.inode.at/762450/coreavc/haali_coreavc.jpg

MPC-HC MpegSplitter -> CoreAVC 2.6 (DXVA) -> EVR: FAILED
http://members.inode.at/762450/coreavc/mpcsplitter_coreavc.jpg

Just compare the station logo at the top right corner of the two above screenshots.

As I said, you have plenty of samples already. It should not be too hard to build a graph with MPC-HC MpegSplitter and EVR. Let me guess... it is a splitter bug? I am afraid it is not that simple. Haali is the only one who gets it straight? How about all the other decoders that manage to output a correct field order with all these buggy splitters?

So again, CoreAVC fixed nothing for me but only made things worse when it comes to the DVBViewer issue. So is this going to be the old game again? People post bug reports and samples and BetaBoy will leave the stage for a couple of months, finally returning to announce a new major version that fixes nothing at all? How nice you fixed the installer issue. A big one...

But I am sure you "will be looking into the issue"...

[BetaBoy]

@ BetaBoy,

did you actually play a TS/M2TS file via the DVBViewer with DVBSource in use? Please check 'View' -> 'Filters' within the DVBViewer to check which DirectShow filters are being used. Just to make sure that both, DVBSource and CoreAVC, are in the graph....

Yes, and we are not seeing any issue here.

[CiNcH]

Yes, and we are not seeing any issue here.
Try to get some 1080i content through. 720p seems to be working. But it is still SW only, no DXVA. This needs to be fixed too.

Summary:
- 1080i not working within DVBViewer with DVBSource and CoreAVC
- DXVA not working within DVBViewer with DVBSource and CoreAVC

[BetaBoy]

CiNcH... while I appreciate your feedback, I do not appreciate the remark but understand your issue. Simply put... Haali's is our official splitter and has always been and it works as it should. We will look into (as you say) and work with any other ones with reported issues.

[BetaBoy]

Try to get some 1080i content through. 720p seems to be working. But it is still SW only, no DXVA. This needs to be fixed too.

Summary:
- 1080i not working within DVBViewer with DVBSource and CoreAVC
- DXVA not working within DVBViewer with DVBSource and CoreAVC

We are trying now.

[CiNcH]

It seems as if the DVBViewer does not perform video pre-format detection anymore. Still I believe that you should not rely on the splitter propagating the correct values for the connection format.

Some versions back (before you added DXVA), CoreAVC worked happily with splitters propagation completely wrong information. Also format changes (720p <-> 1080i) worked. Now nothing works anymore.

[TheShadowRunner]

TheShadowRunner... From our discussions internally, no it should not matter what DLL you are using.

Thanks for the info!

[dansus]

2.5.5 broke DXVA with DVBViewer DVBSource filter

2.6 breaks compatibility with DVBViewer DVBSource filter "completely". Tray icon is blue (indicating no DXVA) and picture inside the DVBViewer stays black.


Ditto.

Wouldnt be so bad if we could downgrade.

[mkanet]

I just redownloaded 2.6 (after the silent update mentioned on this forum thread). The installer issue is still there (see below).

I also verified after a reboot that no matter what, CoreAVC 2.6 has a problem with a few of my ripped bluray files.

The best way I can describe the video problem is... I see a weird repetitive "1 second loop" from some parts of the video. So... Illl see someone's head nod up and down over and over again while the audio is going. Or someone swinging their arm back and forth over and over again. This happens when using DXVA, Cuda, and None. The problem goes away as soon as I revert back to CoreAVC 2.5.5 (or earlier).

I'm using the latest Nvidia drivers from their website and an Nvidia 8500GT display adapter. I dont see this problem with MPC-HC DXVA, ffdshow, or any other H.264 video decoders I have.

I have never been able to get DXVA to work with CoreAVC. I have no problems using DXVA with free MPC video decoder.

I only playback standard bluray spec files only (H.264).

http://i67.photobucket.com/albums/h283/mkanet/CoreAVC26-2.jpg

[BetaBoy]

I just redownloaded 2.6 (after the silent update mentioned on this forum thread). The installer issue is still there (see below).

This just means your account did not get the new version yet. Its takes a little time for it to be applied to all the accounts.

[CiNcH]

BTW, I reported the thing with the connection format some time back, see here (http://forum.doom9.org/showthread.php?p=1488503#post1488503).
As I said, in previous versions you did not rely on proper information from the splitter. Almost any decoder I tested so far doesn't. They are fine with some standard values. You again promised to have a look (http://forum.doom9.org/showthread.php?p=1488610#post1488610). I am sure you did. Guys, this is really getting ridiculous.

[BetaBoy]

As are your continued put downs. It would be easier if we simple state use Haai's splitter, but we won't. We have found on one of our dev boxes where we can duplicate the deinterlacing issue when not using HMS.

Haali: all frames are rendered correctly
MPC: two equal frames in a row (looks like deinterlaced first field)

It looks like Haali produces (first field, second field) and mpc (first field, first field).

[CiNcH]

Does a splitter even operate at such a deep level and know anything about fields? DVBSource for example knows nothing about this kind of stuff (like NALU's, fields and the like). It just propagates fixed size Elementary Stream chunks.

As are your continued put downs.
Another one of your standard phrases here at D9. Why don't you just bring it on? You have been putting us down for months or even years. We are willing to help as you see. Hope this time we can get some things sorted.

[CiNcH]

MPC-HC MpegSplitter -> CyberLink Video Decoder (PDVD11) -> EVR: OK
http://members.inode.at/762450/coreavc/cyberlink_interlaced.jpg

CyberLink gets the job done with MPC MpegSplitter.

[BetaBoy]

As always we are appreciative... and like with any product bug duplication is always the hardest part of support. As stated with the DVB issue, neither our testers or us could duplicate it till now.

[dansus]

Yes, and we are not seeing any issue here.

Not sure if it makes any difference, but im using DVB-T2 with DVBViewer in the UK and all i get is a black picture with 2.6
.

[betaking]

BUG REPORT,Last Haali Media Splitter 1.11.233.7 Haali MP4 Parser can not Connection some h.264 or x.264 videocodec(Including the latest version of the coreavc 2.6) to decoder mov mp4 (encoder by H.264 or X.264) use 1.11.96.14 no problem!

[Fadeout]

The problem I had in the previous version is still there: with some videos and DXVA (ATI, no matter the driver version and tested across different videocards models) the video freezes (the player is responsive and the audio goes on, but the image completely freezes, including the stats graph). CoreAVC CPU decoding works fine, DXVA in the internal MPC works fine. Only CoreAVC DXVA freezes. If I enable V-synch or frame correction the video doesn't freeze but I still get unusual stutters here and there (that aren't there with MPC internal DXVA).

So this is an issue specific to CoreAVC DXVA implementation.

Can't post a sample because it's an anime. If you want to look up the specific file, it's this:
[Commie] Tiger & Bunny - 01 [39E1E59A].mkv

One freeze happens at 00.44, and also usually happens 3-4 seconds before a different chapter in the file. The stutters instead happen every few seconds.

[CiNcH]

OK, it seems I was wrong. Today I also cannot get 720p working inside the DVBViewer with CoreAVC. Only black picture.

In an internal DVBViewer version, the video pre-format detection is fixed. So the DVBSource propagates correct values for the connection format. Still there is only a black picture with CoreAVC.

Maybe a random access problem?

[CiNcH]

I now tried to play a properly mastered m2ts (1080p) file via DVBSource -> CoreAVC. It does not play with video either.

[Tanuki]

What is the CRC of the corrected 2.6, because I can only download the one that have "bf806391", and it has the installation error message, and CoreAVC doesn't work anymore (makes Zoom player crash when loading)...

[BetaBoy]

We are working with CiNcH and have fixed the DVBViewer bug in software mode... Also we tracked down the issue with third party splitters and are working on that now.

What remains is a DXVA bug with DVBViewer... We will continue to work with CiNcH to test.

[CiNcH]

We now also know why DXVA does not work. It is because the DVBSource filter does not deliver the info (SPS/PPS) that CoreAVC needs in order to decide whether to use DXVA or not. So CoreAVC decides not to use DXVA. So either the DVBSource delivers this information or CoreAVC parses it from the stream by itself (which it does anyway). We made the experience that when the DVBViewer does this stuff, channel switching takes quite a bit longer as we have to serialize quite some work before we can actually build the graph and start playback (maybe this increased delay is more of perceptual nature because we can at least directly start playing audio). Most other DXVA decoders do not rely on this information.

[MOS-Marauder]

What remains is a DXVA bug with DVBViewer... We will continue to work with CiNcH to test.

Not only DXVA .. same if CUDA enabled.

Black Screen (DVBViewer 4.8.1)

Chris

[blaster00]

Coreavc 2.6 did not work with mpc-hc x64, no video output. Tried internal , haali and LAV splitter, both the same. But other h264 decoder and 2.5.5 works fine.

[betaking]

Coreavc 2.6 did not work with mpc-hc x64, no video output. Tried internal , haali and LAV splitter, both the same. But other h264 decoder and 2.5.5 works fine.

YES coreavc 2.6 can not Connection some mpc-hc internal standalone and LAV splitter,but use 2.5.5 no problem!:confused:

[Fadeout]

What remains is a DXVA bug with DVBViewer...

There's also the problem I reported in my previous post (stutters or video freeze in DXVA on specific videos), that was there already in 2.5.5 and will probably be there in 3 too.

[CiNcH]

We reviewed the cause of the DXVA/CUDA problem in the DVBViewer team in more detail now and came to the conclusion that it is a CoreAVC restriction. Taking actions inside the DVBSource filter would only be a workaround which may have bad side effects in a streaming environment. The DVBSource perfectly adheres to the MSDN H.264 streaming rules.

[devil-strike]

We reviewed the cause of the DXVA/CUDA problem in the DVBViewer team in more detail now and came to the conclusion that it is a CoreAVC restriction. Taking actions inside the DVBSource filter would only be a workaround which may have bad side effects in a streaming environment. The DVBSource perfectly adheres to the MSDN H.264 streaming rules.


Hmm whene using dvbviewer it wont work, like some say's here.

But here its goes back to microsoft codec, and ignore coreavc completly, whene i go back to old version of coreavc it works.

[CiNcH]

But here its goes back to microsoft codec, and ignore coreavc completly
Hmm, did you disable certain media subtypes or color spaces within the CoreAVC settings?

[BetaBoy]

The DVBSource perfectly adheres to the MSDN H.264 streaming rules.

CiNcH as we pointed out in email which you seem to now want to post to the public rather then continue our emails discussions (which is fine by us).

The SPS and PPS are normally sent as part of the AVC/H264 connection info. Is it mandatory? No but it is describe as the preferred method.

See: https://msdn.microsoft.com/en-us/library/dd757808(v=vs.85).aspx

DVBSource does NOT perform anything like the description on the MSDN page as the normal way to send SPS/PPS via the connection info is by using the dwSequenceHeader field of the MPEG2VIDEOINFO struct.

As stated, for local files this is fine but for live streams its not the proper behavior since the SPS/PPS may not be immediately available. RE: If there's a channel change, the connections need to be torn down and reconnected.

Our determination is that DVBSource doesn't do what it should and because it doesn't, CoreAVC can't be sure DXVA will work so it doesn't use it.

Breaking the proper methodology in DVBSource to save on perceived delays for end users when changing channels is not right, as decoding can't be start until the sps+pps are received anyway.

[devil-strike]

Hmm, did you disable certain media subtypes or color spaces within the CoreAVC settings?

No is on auto, like i said in 2.5 is working after install 2.6 is not working with same settings.

[CiNcH]

DVBSource does NOT perform anything like the description on the MSDN page as the normal way to send SPS/PPS via the connection info is by using the dwSequenceHeader field of the MPEG2VIDEOINFO struct.
In case of MEDIASUBTYPE_H264 a format block does not have to be appended. In this case there simply is no MPEG2VIDEOINFO.

Breaking the proper methodology in DVBSource to save on perceived delays for end users when changing channels is not right, as decoding can't be start until the sps+pps are received anyway.
But it will most likely happen that the splitter will wait for SPS/PPS and then the decoder waits again as it does not expect the SPS/PPS to be appended to the connection info as the MSDN states that you do not have to expect one in case of MEDIASUBTYPE_H264. This may result in >5s channel switching delays depending on the SPS/PPS frequency. SPS/PPS are pretty rare. We won't implement a workaround with such side effects to satisfy CoreAVC.

[BetaBoy]

As stated its not mandatory... and we will not use DXVA without it given the mixed live/local environments.

[nevcairiel]

I agree with CiNcH, the MSDN clearly states that H264 with Startcodes does not require a SPS/PPS block in the media type. It actually doesn't even list the possibility (or how to do it) for H264 with start codes.
It also does not name a preferred method.

DVBSource functions perfectly within the parameters as defined by the MSDN.

To quote the MSDN:
When the bitstream contains start codes, any of the format types listed here is sufficient, because the decoder does not require any additional information to parse the stream. The bitstream already contains all of the information needed by the decoder, and the start codes enable the decoder to locate the start of each NALU.

I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.

[CiNcH]

OK, so DXVA/CUDA won't be supported when using DVBSource together with CoreAVC. You guys told me via mail already that you are also not going to take further actions for the time being. I am fine with that. The reason why I made this public is because both sides won't do anything about it. I just wanted both, CoreAVC and DVBViewer users, to know about this restriction (leaving out the details) and our point of view. It was not meant to insult you. If you have another opinion or understand things differently, you can of course also state it (which you did) and I am fine with that too. We do not have to be of same opinion ;) . I am not using CoreAVC anyway. The only thing I am concerned with is customer/user satisfaction and that is why I went into all this debugging. (OK you can now hand me the medal of honor for special service ;) )

If people want to use CoreAVC within the DVBViewer they can still do so for content that does not make use of the DVBSource filter (obviously not for DVB) or simply give up on DXVA/CUDA.

[MOS-Marauder]

"If you want to use CoreAVC within the DVBViewer you can still do so for content that does not make use of the DVBSource filter. " ....


Witch makes it allmost unusable. I guess the same behaviour will be in CoreAVC 3.0.. so .. WHY should i buy this ?

For me.. i got CoreAVC for use @DVBViewer. Not its no longer possible..guess what?


Chris

[BetaBoy]

I don't understandNobody is in the wrong here... they do it one we, we another. But don't misunderstand us, we want DVBViewer w/DXVA to work and we are discussing on how best to handle it.

[BetaBoy]

We are releasing CoreAVC 2.6.1


CoreAVC H.264 Video Codec - Version 2.6.1.0 (20110906)
- FIX: Installer uses 32-bit filter for post-install configuration
- FIX: SPS/PPS identification regression
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams

Emails are about to be sent now. It will take a few hours for them all to go out.

[nussman]

Betaboy ... you want to stop the discussion right now? :eek:
At a point were we are very close to make CoreAVC useable?


I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.

Thats the point i dont understand too.
Could you explain it?

[CiNcH]

- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
Can you get into detail here too? We actually want to fix it inside the splitter. DVBSource also suffered from bad field order with hardware deinterlacing inside the renderer when using CoreAVC.

[squid_80]

But it will most likely happen that the splitter will wait for SPS/PPS and then the decoder waits again as it does not expect the SPS/PPS to be appended to the connection info as the MSDN states that you do not have to expect one in case of MEDIASUBTYPE_H264. This may result in >5s channel switching delays depending on the SPS/PPS frequency.
That's just silly. If the decoder expects SPS/PPS to be part of the connection info why would it then ignore it? If a filter doesn't know how to read the SPS/PPS data from the connection info, you could also prepend it to the first sample - thus preventing the decoder from discarding any NALUs due to them referencing non-present/inactive SPS/PPS (which would actually reduce the "perceived" latency rather than increase it).
OK, so DXVA/CUDA won't be supported when using DVBSource together with CoreAVC.
CUDA isn't affected at all, I don't know where you're getting that information from.
I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.
It can't be postponed - the renderer handles DXVA decoding and must be configured during pin connection. This happens before any samples are sent between the splitter and CoreAVC.For me.. i got CoreAVC for use @DVBViewer. Not its no longer possible..guess what?It works just fine, but won't use DXVA with DVBSource. Could be worse - try using MPC's decoder with DVBSource and see what happens.
Can you get into detail here too? We actually want to fix it inside the splitter. DVBSource also suffered from bad field order with hardware deinterlacing inside the renderer when using CoreAVC. Given that your splitter sends chunks of elementary stream, it would be virtually impossible to fix it there - you need to send a whole frame per sample with correct start and end times set. For unknown durations or end times, MS says it is allowable to set the end time to start time + 1, but it has been discovered that their renderers don't like this very much.

[CiNcH]

If the decoder expects SPS/PPS to be part of the connection info why would it then ignore it?
Hmm, seems my English is not good enough to explain myself properly... Sorry for that.

In case of MEDIASUBTYPE_H264 the decoder may not expect SPS/PPS to be part of the connection info as it is not really defined for H.264 with start codes. And also due to the fact that the format may have changed already, the decoder may be better off using the most recent info from the stream. So we end up waiting for SPS/PPS twice.

CUDA isn't affected at all, I don't know where you're getting that information from.
I was referring to user MOS-Marauder. But he of course was referring to the general issue within 2.6 where SPS/PPS was not properly read at stream time which is now fixed in 2.6.1. So CUDA may work then. Sorry for that.

It can't be postponed - the renderer handles DXVA decoding and must be configured during pin connection. This happens before any samples are sent between the splitter and CoreAVC.
So let us all just be happy that some other DXVA decoders are able to handle this case.

[hajj_3]

will CoreAVC 3.0 still be released today? Do you have a changelog for it yet?

p.s you should put changelogs for each version on your website.

thanks.

[CruNcher]

Dan do you also plan on implementing Intel (SB and newer) and AMD (APU,UVDx) Native API Hardware support @ the side of Nvcuvid or do you propose for Performance reasons DXVA for those 2 platforms :) ?

[dansus]

2.6.1

Emails are about to be sent now. It will take a few hours for them all to go out.

Is the download live? Still says 2.6 on the page.

[MOS-Marauder]

I was referring to user MOS-Marauder. But he of course was referring to the general issue within 2.6 where SPS/PPS was not properly read at stream time which is now fixed in 2.6.1. So CUDA may work then. Sorry for that..

Yep i tested yesterday 2.6.0 resulting in Black Screen with Audio.

Chris

[TOM_SK]

Is the download live? Still says 2.6 on the page.

Add me to the list, too (invoice number 33689).

[MOS-Marauder]

Add me to the list, too (invoice number 33689).

Well give them some Time... some Hrs more or less doesnt count...


Chris

Edit: ok some hrs later.. still no 2.6.1 @Account(s)

[BetaBoy]

Is the download live? Still says 2.6 on the page.

As we were releasing 2.6.1 we found a DXVA1 bug and pulled it from the portal. We finished compiling a new one and are signing it... releasing it will be next.

Then on to the CoreAVC 3.0 launch.

[BetaBoy]

Dan do you also plan on implementing Intel (SB and newer) and AMD (APU,UVDx) Native API Hardware support @ the side of Nvcuvid or do you propose for Performance reasons DXVA for those 2 platforms :) ?
I can comment more on our Intel efforts after we release CoreAVC 3.0 in a few hours.

[MOS-Marauder]

As we were releasing 2.6.1 we found a DXVA1 bug and pulled it from the portal. We finished compiling a new one and are signing it... releasing it will be next.

Then on to the CoreAVC 3.0 launch.

Ok, thx for Info.

Chris

[BetaBoy]

will CoreAVC 3.0 still be released today? Do you have a changelog for it yet?

p.s you should put changelogs for each version on your website.

thanks.
We post each changelog from each release, see:
http://corecodec.com/products/coreavc/changelog

[hajj_3]

ahh, there it is, silly me!

[Tanuki]

thanks god there are some alternative to CoreAVC, because I have been blocked with the buggy 2.6 for 3 days (with no possibility to downgrade to 2.5.5 since the license key isn't archived anywhere in my client area)...
I REALLY hope the Hi10P support won't be a disappointment.

[TheShadowRunner]

I REALLY hope the Hi10P support won't be a disappointment.

Don't we all ;)

[BetaBoy]

backing up.... gonna release 2.6.1 next... then take down 2.x purchasing in preparation for the CoreAVC 3.0 launch.

[hajj_3]

isn't it better to use new version numbers instead of silent updates as those people who downloaded the buggier versions of 2.6.0.0 and 2.6.0.1 may not be aware new versions are available. I'd name it 2.6.0.2 if i were you.

[BetaBoy]

CoreAVC 2.6.1.0 released on our customer portal. https://customers.corecodec.com

To upgrade to 2.6.1 (or any product) click 'My Products' and then click the product you purchased. At the top you will see an upgrade notification link, click through it and the updated product will then be in your account.

CoreAVC H.264 Video Codec - Version 2.6.1.0 (20110906)
- FIX: Installer uses 32-bit filter for post-install configuration
- FIX: SPS/PPS identification regression
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams

[TOM_SK]

coreavc 2.6.1.0 released on our customer portal. https://customers.corecodec.com

Thanks!

[BetaBoy]

Any feedback related to DVBViewer/DVBSource and third party splitters would be appreciated as this was the primary focus of this release. As noted in previous posts DXVA will not work with DVBViewer/DVBSource till we sort out the SPS issue (same goes for CoreAVC 3.0).

[nussman]

CoreAVC 2.6.1:

dvbviewer:
seems to work fine in software mode
no dxva as expected .... :mad:

deinterlacing:
Seems to work properly now with dvbviewer sourcefilter and mpc-hc splitter

installer:
64bit errormessage is gone


Not so bad at all.
Please take your time and think about the SPS/PPS issue!

[BetaBoy]

nussman... awesome... thx for the fast feedback!

[dansus]

Any feedback related to DVBViewer/DVBSource and third party splitters would be appreciated as this was the primary focus of this release. As noted in previous posts DXVA will not work with DVBViewer/DVBSource till we sort out the SPS issue (same goes for CoreAVC 3.0).

I can watch BBCHD now and globe is green, good enough for me.

[mkanet]

I totally didn't expect this (since I didnt notice anyone else report this issue), but the problem with 2.6.0 went away where a few of my videos would have this weird repetitive 1-sec video loop over and over again on certain parts of the video (for example a person's head nodding up and down or arm flapping back and forth). I can also confirm that the install error went away.

Both issues are fixed for me.

Thanks for all your hard work,
MKANET

[Chumbo]

Some feedback on 2.6.x. The hardware deinterlacing is working great. The 30fps media files from Hauppauge HD-PV4 1212 now play nice and smooth in both DXVA and None with Hardware deinterlacing (I use MPC-HC). Single field and Bob are better than they were but still unwatchable by the way.

[BetaBoy]

green = DXVA... nice.

We are tracking 3 potential issues... not show stoppers but we are working with the reporters on the issues.

- Haali .MP4 bug where the container is not supported (for some users)
- Interleave MP4 videos (might be field order related)
- ZoomPlayer having issues as well

[Fadeout]

The problem I had in the previous version is still there: with some videos and DXVA (ATI, no matter the driver version and tested across different videocards models) the video freezes (the player is responsive and the audio goes on, but the image completely freezes, including the stats graph). CoreAVC CPU decoding works fine, DXVA in the internal MPC works fine. Only CoreAVC DXVA freezes. If I enable V-synch or frame correction the video doesn't freeze but I still get unusual stutters here and there (that aren't there with MPC internal DXVA).

So this is an issue specific to CoreAVC DXVA implementation.

Can't post a sample because it's an anime. If you want to look up the specific file, it's this:
[Commie] Tiger & Bunny - 01 [39E1E59A].mkv

One freeze happens at 00.44, and also usually happens 3-4 seconds before a different chapter in the file. The stutters instead happen every few seconds.


This was also partially fixed in 2.6.1 in the sense that now the video doesn't freeze/stop anymore.

The problem that is left is that there are still stutters here and there, it seems especially on some scenes change. MPC-HC DXVA is instead always smooth.

[cyberbeing]

Haali .MP4 bug where the container is not supported (for some users)
I have this bug on WinXP SP3 x86 with the new Haali Splitter 1.11.233.7. All MP4 have no video with an empty video output pin.

[BetaBoy]

CoreAVC 3.0 is a major milestone for us here at CoreCodec and adds features like 9/10 bit support, Full DXVA 2, DXVA 1, GMA support, DXVA fallback, Intel Media SDK support, New Assembly 'Core', etc.

What's new in CoreAVC 3.0?
CoreAVC H.264 Video Codec - Version 3.0.0.0 (20110906)
- ADD: 9 bit support
- ADD: 10 bit support
- ADD: DXVA fallback to software
- ADD: Intel Media SDK Support (DXVA2)
- ADD: Intel GMA Support (DXVA2)
- ADD: 10 bit output format (P010)
- ADD: 16 bit output format (P016)
- ADD: Directshow dithering when filter output is downsampled
- ADD: Improved DXVA handling for interlaced streams
- ADD: Colorspace conversion from 10 bit formats to 8 bit formats
- ADD: DXVA 2 Long slice support
- ADD: Initial 4:4:4 integration (No decode support yet)
- ADD: New assembly engine
- ADD: New assembly IDCT
- ADD: New assembly motion compensation
- ADD: New assembly inter-prediction
- ADD: New assembly weighted prediction
- ADD: New assembly 9-bit
- ADD: New assembly 10-bit
- ADD: Improved assembly 8 bit performance
- CHG: Use container AR when there is no stream AR
- FIX: Improved Frame order handling
- FIX: Hardware deinterlacing field order
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams
- SDK: Updated xcode support for iOS and OS X
- SDK: Improved APIs
- SDK: Fix: Missing APIs
- SDK: Initial support for MVC (CoreMVC) integration

Haali Media Splitter - Version 1.11.233.7 (20110830)
- FIX: Various DTS Audio bugs
- ADD: Improved DTS support
- ADD: Support for MVC 3D videos


For current 2.x customers, if you have purchased CoreAVC within the past 60 days, you will automatically get 3.0 as a part of the purchase.

CoreAVC 3.0 can be purchased here:
https://customers.corecodec.com/cart.php

[BetaBoy]

Customers who purchased CoreAVC 2.x (not a 1.x upgrade) in the past 60 days get the update first.

After the emails are sent we will make it available for purchase.

[BetaBoy]

Also a heads up... although it did not make it into 3.0 before we went 'gold', we have also added:
- 4:4:4 profile support
- Intel AVX support (SandyBridge / IvyBridge)

You will likely see those in one of the next updates starting with 4:4:4 first.

[cyberbeing]

CoreAVC 3.0 software decoding has an extremely massive memory leak when used with madVR and MPC-HC. Every time a video is opened or re-loaded without closing the player, memory usage increases by the initial amount... For a 10bit 1080p video this means ~+250MB for every video you open until you are out of memory.

[BetaBoy]

cyberbeing... we cannot duplicate the memory leak here... can you provide versions numbers so we can dig deeper?

[BetaBoy]

We have taken down 2.x purchasing.... about to push 3.0 live for everyone.

[cyberbeing]

cyberbeing... we cannot duplicate the memory leak here... can you provide versions numbers so we can dig deeper?

The problem only seems to happen with when CoreAVC 3.0 is used with madVR 0.74. What seems to be happening is instead of old CoreAVC instances being killed or reused, a new CoreAVC instance is created for each new video opened while the old instance(s) just hang around idle, holding onto memory. That would explain why memory usage increases as it does.

MPC-HC r3677
madVR 0.74
Haali Splitter 1.11.96.14 (until MP4 bug is fixed)
WinXP SP3 x86


madshi would need to chime in, since for all I know this could be half a madVR bug. I rolled back to madVR 0.73 and the bug disappeared. The odd part is it only happens with CoreAVC and madVR 0.74. FFDShow or other decoders with madVR 0.74 are fine.

[Kurtnoise]

We have taken down 2.x purchasing.... about to push 3.0 live for everyone.
After selecting CoreAVC 3.0 and clicking in "order now", CoreAAC is selected instead...

[nevcairiel]

madshi would need to chime in, since for all I know this could be half a madVR bug. I rolled back to madVR 0.73 and the bug disappeared. The odd part is it only happens with CoreAVC and madVR 0.74. FFDShow or other decoders with madVR 0.74 are fine.

This is actually a madVR bug. It keeps a reference to the decoder around, and therefor its never properly destructed when the directshow graph is re-built.
madshi knows, and confirmed that its fixed for the next version (whenever that'll be)

To avoid huge memory leaks like this in CoreAVC, i would however recommend to free the memory buffers when the input pin is disconnected, and not wait until the filter is destructed. (Which is why it doesn't show up on other filters, they do exactly that)

[BetaBoy]

After selecting CoreAVC 3.0 and clicking in "order now", CoreAAC is selected instead...

Fixed... thx for the report. We are also about to 4x the VM resources since the load is high atm.

[cyberbeing]

BetaBoy, are 10bit optimizations for older AMD processors like my X2 4800+ (939) already in CoreAVC 3.0? Doing some benchmarks with VMR9, CoreAVC seems to struggle considerably more than FFDShow with sudden sudden bitrate fluctuations where my CPU is struggling to playback in real-time. Peak CPU is higher and Min FPS dips lower compared to FFDShow in such situations. Average FPS is usually marginally better with CoreAVC though, but that doesn't help much if Min FPS drops below real-time.

CoreAVC 3.0 compared to FFDShow r3978 (3-threads)
AMD X2 4800+ @ 2.64Ghz | WinXP SP3 x86
Various 1080p/720p 10bit H.264 samples

-5% to +10% Avg FPS (CoreAVC is better)
-2% to +1% Avg CPU (CoreAVC is better)

-15% to +5% Min FPS (FFDshow is better)
+2% to +10% Peak CPU (FFDshow is better)


Using 10bit (P010) or 16bit (P016) output to madVR is even worse, seemingly adding an additional 5-10% overhead to Avg and Peak CPU and worse FPS all-around.

Hopefully you can sort out these higher CPU spikes from sudden bitrate fluctuations in a future 3.x version. It's the difference between smooth playback (ffdshow) and dropped frames (coreavc) on some 10bit 1080p samples, especially once subtitles enter the picture.

[nevcairiel]

I would've thought P010 output uses less CPU (afterall, you don't need to apply dithering) - unless madVR itself uses more CPU with 10-bit input.

You should compare using a codec benchmark like in GraphStudio, taking the renderer out of the equation. If someone does, i would appreciate also including LAV Video in that comparison (both in 8-bit dithered and 10-bit native mode). ;)
I would do it, but i'm not sure i'll be buying 3.0, i have no need for it.

[ranpha]

You should compare using a codec benchmark like in GraphStudio, taking the renderer out of the equation.

I would have done so if GraphStudio doesn't crash when I tried to do benchmarking 10-bit clips with LAV Video. timecodec also cannot be used because of the same problem.

As a last resort, I tried using DXVA Checker to do the benchmarking, and there are some 'interesting results'. I don't really trust DXVA Checker as a benchmarking tools though. DXVA Checker and Graphstudio gives different results for the same clip when benchmarking with CoreAVC 3.

[CruNcher]

DiAVC kills both though the features of DiAVC are still limited so overhead might be lower still but it looks very good designed (and optimized for Intel) overall :)

http://img560.imageshack.us/img560/2003/comparex264performancei.png

[nevcairiel]

DiAVC kills both

How can it, it doesn't even play 10-bit files yet. :p

I would have done so if GraphStudio doesn't crash when I tried to do benchmarking 10-bit clips with LAV Video. timecodec also cannot be used because of the same problem.

With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p

[devil-strike]

I read here that the new coreavc is working again with dvbviewer? but here is not working at all, dvbviewer sees the codec in the cofig page, but it wont work and falls back to microsoft dtv codec, but if i disable ms codec it also wont work with coreavc2.6.1, if i install old 2.5.1 or 2.5.5 it working again.

btw, using win7 64bit.

[CruNcher]

How can it, it doesn't even play 10-bit files yet. :p



With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p


That's true but he seems to be optimizing it to the last drop schweinsz remembers me of Picard when everything started with CoreAVC, he is really fast for a 1 man machine (though CoreAVC is hardly that 1 man machine anymore) ;)
Also as you see i didn't compared with CoreAVC 3.0 yet and if you compare features vs overhead surely he would lose then currently ;)

also


- ADD: DXVA fallback to software
- ADD: New assembly engine
- ADD: New assembly IDCT
- ADD: New assembly motion compensation
- ADD: New assembly inter-prediction
- ADD: New assembly weighted prediction
- ADD: Improved assembly 8 bit performance


good feeling :)

And the 3.0 update is so evil huge (including all the DXVA2 improvements and additions) i hope alot of good beta tester where involved here :)

[ranpha]

With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p

It happened with all 10-bit clips I have, whether the ones I made myself or the ones 'made by others'.

[nevcairiel]

It happened with all 10-bit clips I have, whether the ones I made myself or the ones 'made by others'.

I think i found the cause, any follow up should be moved over to the appropriate thread, though.

http://forum.doom9.org/showthread.php?p=1524388#post1524388

[Fadeout]

Surely there's something wrong. I have at least twice the CPU usage with CoreAVC DXVA compared to native MPC-HC DXVA. Also some very high peaks.

CPU is being used somehow even if the video is in DXVA. I have almost the same CPU usage with DXVA and software (DXVA is enabled as it shows both the red icon and [DXVA] on MPC).

[Barlow]

I just noticed the same thing. This is with 3.0 btw.

[CruNcher]

I hope they don't enabled the 1080p 60 fps fallback to Software for every DXVA scenario (config), though that you see the RED icon would be strange :(

[Fadeout]

This CPU usage on DXVA seems to happen already in 2.6.1.

EDIT: Yep, 2.5.0 is fine. The problem shows up in 2.6.0 and continues in all following versions.

EDIT2: More things. I'm testing with this file: Planet_Earth_From Pole_to_Pole_1080p_sample_16ref.mkv

And DXVA can't produce smooth playback. Very stuttery. 2.5 worked fine, as well MPC-HC internal DXVA.

[CruNcher]

What OS and Card (DSP) ?

[Fadeout]

I'm on W7 64b and ati 4850 if you're asking me.

Tried to use a x32 version of MPC-HC but it seems to deliver the same problems. Playback isn't smooth in DXVA. Software mode instead performs similar to 2.5, but it also has the tendency to go crazier if you repeat tests. 2.5 was usually more constant.

Summarizing: it's a problem that shows up in 2.6. High CPU usage in DXVA, and very stuttery playback. Especially evident with this clip:
Planet_Earth_From Pole_to_Pole_1080p_sample_16ref.mkv

[Fadeout]

Also, testing the various version and codecs at the moment I get the best performance with MadVR internal codecs even compared to CoreAVC or DiAVC.

Very low CPU usage with MadVR and smooth playback with that sample.

[BetaBoy]

Thank you for the reports everyone.

[sawg]

Please forgive me if I make any errors; my English is a little weak.

http://i.imgur.com/fuckK.jpg
http://i.imgur.com/jrtX4.jpg
Open CUDA and 1080p video, EVR Buffers >17 will error.

[dansus]

I have this bug on WinXP SP3 x86 with the new Haali Splitter 1.11.233.7. All MP4 have no video with an empty video output pin.

Same here, XP SP3 x86.

[Stephen R. Savage]

CPU: Intel Core 2 Duo T7250 "Merom" (2.00 GHz)
OS: Microsoft Windows Server 2008 R2 Standard

GraphStudio 0.3.2.0 was used for all measurements.
Reported values are the average of three independent trials.
Standard deviation was below 1% of mean for all tested software.
Output accuracy was evaluated visually for each decoder.

All software used was 32-bit. 10-bit samples were decoded to
8-bit formats in all cases to better represent typical usage
scenarios.

Software Tested:
DiAVC 1.2.6
CoreAVC 3.0
ffdshow (CLSID) r3978
LAV Filters 0.34

1080p, 10-bit, 8750 kbps
========================
CoreAVC: 30.4 fps
ffdshow: 35.7 fps
LAV Filters: 38.2 fps

720p, 10-bit, 1850 kbps
========================
CoreAVC: 60.4 fps
ffdshow: 67.3 fps
LAV Filters: 77.5 fps

720p, 8-bit, 2620 kbps
======================
DiAVC: 157.6 fps
CoreAVC: 133.6 fps
ffdshow: 125.6 fps
LAV Filters: 129.4 fps

480p, 8-bit, 1830 kbps
======================
DiAVC: 390.4 fps
CoreAVC: 340.6 fps
ffdshow: 309.9 fps
LAV Filters: 335.0 fps


It's sad to see CoreCodec fall this low. What used to be cutting-edge software continues its trend into obsolescence. I mean, even I would be embarrassed at releasing a supposedly "high-performance" software that's 30% slower than a free offering. Claims for improved 8-bit performance are also unable to be verified, as CoreAVC 3.0 scores no higher than 2.5.5 (not shown in data, see previous).

What's more interesting is how far libavcodec development has come. Nevcairiel's optimized LAV Filters now lead CoreAVC in 10-bit decoding by as much as CoreAVC 1.0 lead the earliest versions of libavcodec. Another victory for open source software. No wonder CoreCodec has to try gouging its ever-dwindling customer base for repeated "upgrade" fees.

[Kurtnoise]

@Stephen : could you post/link the samples you use for your benchmark please ?

[SSH4]

hmm, cuda and dxva not work on CoreAVC 3.0?

oops no cuda/dxva on 10bit ?

[BetaBoy]

Stephan.... Please take the drama else where.

[Mixer73]

No wonder CoreCodec has to try gouging its ever-dwindling customer base for repeated "upgrade" fees.

You know what... I complained when Core announced that 3.0 would be a new license and not an upgrade on 2.0... Now they have offered a $3 discount for 2.0 owners, against a license that is what $12.95?

Can we really complain about such low priced software? I dunno that we can, really.

[Tanuki]

@BetaBoy
Can you elaborate on the Zoom Player problem (since I seem to have one myself) ?

[SSH4]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

[Barlow]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

I'm not sure about CUDA, but DXVA won't decode 10bit on any card yet.

[kerimcem]

my graphics card Ati HD 2600 PRO (UVD)+ 7300 gt (old card)

CoreAVC 2.5.5 DXVA works perfectly

CoreAVC 2.6.0 DXVA not working
CoreAVC 2.6.1 DXVA not working
CoreAVC 3.0.0 DXVA not working

[nevcairiel]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

Both CUDA and DXVA use the hardware decoder on your GPU, and that one is limited to 8-bit.

[CiNcH]

Having criticized CoreCodec for the way they do business a lot in the past (and I am not alone, I have never seen anyone getting more heat than they do), I can also give credit where it is due.

Version 2.6.1 is finally usable within the DVBViewer (not perfect though, and I am not talking about DXVA) and the eventualities in a streaming environment where decoders have to deal with fast channel hopping, random access, on-the-fly format changes, interlaced content a.s.o.

All my reports have successfully been processed (except for DXVA of course). Finally proper vector-adaptive deinterlacing when using NV12 is possible. I consider this being a much more critical task than hardware decoding.

Maybe it is better that DXVA is not supported within the DVBViewer as of yet. Who knows what would have happened if format changed on-the-fly or one would have switched between 720p and 1080i channels without the DVBViewer rebuilding the graph...

Looking back some years, it also took MPEG-2 decoder developers some time to embrace all the eventualities in a streaming environment. CyberLink has come a long way and this may be the reason why they still rock in this area (even with DXVA). I am pretty sure that others will arrive there too one day.

[Stephen R. Savage]

@Stephen : could you post/link the samples you use for your benchmark please ?

Stephan.... Please take the drama else where.

@Kurtnoise: I will try to make them available later today.

@BetaBoy: This is not the first time I've shown clear evidence of failings in CoreAVC. Each time you have summarily dismissed them as "drama" and have consistently failed to improve your software in any meaningful manner. The fact that you refuse to acknowledge shortcomings reflects poorly on both your company and on you personally. In fact, I am not the only user to have noticed that CoreAVC no longer lives up to the standard it once set.

To those in this thread: CoreCodec thrives off of uninformed users. Please don't be such a person. Every usage case that CoreAVC might have had is now supplanted by free software.

CPU Decoding: LAV Filters
CUDA (NVIDIA): LAV CUVID Decoder
DXVA (Intel/AMD): MPC-HC, ffdshow, Windows 7, all sorts of things

Let's not forget all the things CoreCodec promised but failed to deliver:

GPU Encoding: lol
Decoding 1080p on Intel Pentium 4: lol
MKV DVD-style menus: lol
Full support for High Profile: wait, what was that about weighted prediction?
GPU Decoding: on NVIDIA only, AMD and Intel users are stuck with useless DXVA

Edit:
@Mixer73: $12.95 is infinitely more than $0, and hence you are being infinitely ripped off.

@hajj_3: I don't know, extrapolating from my tests, and estimating that a 1.73 GHz Core Solo is 40% as fast as my 2.00 GHz Core 2 Duo, 3200 kbps 720p still decodes at over 50 fps with LAV, more than enough for viewing in a basic renderer like EVR (esp. w/ D3D Fullscreen).

Also, in case anybody is wondering, the free software I am mentioning is LAV Filters/LAV CUVID. I am not shilling for DiAVC, and I personally don't recommend anybody buy it unless you want to use neuron2tools for some reason.

[hajj_3]

well atleast they are getting pretty quick at fixing bugs, they have fixed the majority of bugs in 2.6.0 in a matter of days which is pretty impressive. Judging by reports it seems there are a ton of bugs in 3.0 so i'm sure it will be months until that is stable. Its better than nothing though, i can play 3200 bitrate 720p on a single core 1.73ghz core solo, haven't tried diavc as only the 64bit is free and the cpu is only 32bit.

[squid_80]

Come now Stephen, without the sample clips as evidence to back up your findings your comparison is useless and your statements have absolutely no merit. For all we know you specifically chose clips to make CoreAVC look bad or even worse, outright fabricated the results. At the very least, allow someone else to post their own comparisons (using an i5-661, null renderer, same filter versions/testing setup).

Let's try a monster clip that most people are familiar with:
Life in the Garden (http://www.youtube.com/watch?v=N0m1XmvBey8), 4096x2304, null renderer
==============================
CoreAVC: 109.1267 fps
FFDShow: 93.1857 fps
LAV Filters: 83.2946 fps

I noticed you didn't test any interlaced material. Should we believe this was on oversight on your behalf?
premiere-paff.ts (http://www.mediafire.com/?onyymjatwjq), 1080i, null renderer
==============================
CoreAVC: 95.5605 fps
LAV Filters: 74.6953 fps
FFDShow: 67.0859 fps

Now you can consider yourself informed. Although I wonder, since you already had such a poor opinion of CoreCodec/CoreAVC, what prompted you to purchase the 3.0 upgrade?

[CruNcher]

Come now Stephen, without the sample clips as evidence to back up your findings your comparison is useless and your statements have absolutely no merit. For all we know you specifically chose clips to make CoreAVC look bad or even worse, outright fabricated the results. At the very least, allow someone else to post their own comparisons (using an i5-661, null renderer, same filter versions/testing setup).

Let's try a monster clip that most people are familiar with:
Life in the Garden (http://www.youtube.com/watch?v=N0m1XmvBey8), 4096x2304, null renderer
==============================
CoreAVC: 109.1267 fps
FFDShow: 93.1857 fps
LAV Filters: 83.2946 fps

I noticed you didn't test any interlaced material. Should we believe this was on oversight on your behalf?
premiere-paff.ts (http://www.mediafire.com/?onyymjatwjq), 1080i, null renderer
==============================
CoreAVC: 95.5605 fps
LAV Filters: 74.6953 fps
FFDShow: 67.0859 fps

Now you can consider yourself informed. Although I wonder, since you already had such a poor opinion of CoreCodec/CoreAVC, what prompted you to purchase the 3.0 upgrade?

Something was wrong sorry (new results later) :(

[wanezhiling]

CoreAVC 3.0.......

Believe it or not , CPU Usage is still very high when dxva on.

[cyberbeing]

AMD X2 4800+ (939) @ 2.64Ghz
WinXP SP3 x86
Haali Media Splitter 1.11.96.14

Here are a few GraphStudio 10bit h264 tests with P010 vs YV12 (dithered) on CoreAVC 3.0.0 with NULL output:

Update: Added LAV Video 0.35 results, now that nevcairiel posted a fixed build.

33.9615 FPS NULL CoreAVC 3.0.0 YV12
33.0268 FPS NULL CoreAVC 3.0.0 P010 (2.8% slower)
34.0204 FPS NULL FFDSHOW r3978 YV12
37.9940 FPS NULL LAV Video 0.35 YV12
37.4290 FPS NULL LAV Video 0.35 P010

37.7804 FPS NULL CoreAVC 3.0.0 YV12
36.5628 FPS NULL CoreAVC 3.0.0 P010 (3.3% slower)
38.5740 FPS NULL FFDSHOW r3978 YV12
42.5697 FPS NULL LAV Video 0.35 YV12
41.7282 FPS NULL LAV Video 0.35 P010

43.3645 FPS NULL CoreAVC 3.0.0 YV12
41.6692 FPS NULL CoreAVC 3.0.0 P010 (4% slower)
42.6866 FPS NULL FFDSHOW r3978 YV12
47.8580 FPS NULL LAV Video 0.35 YV12
47.0682 FPS NULL LAV Video 0.35 P010

122.3882 FPS NULL CoreAVC 3.0.0 YV12
116.3716 FPS NULL CoreAVC 3.0.0 P010 (5.2% slower)
116.4711 FPS NULL FFDSHOW r3978 YV12
131.6452 FPS NULL LAV Video 0.35 YV12
128.0310 FPS NULL LAV Video 0.35 P010

Note: I didn't list them, but CoreAVC P016 results near-identical to P010 results.
__________

Here are the DXVAChecker 10bit h264 benchmarks I did with VMR9 yesterday (a bit messy):

Decoder: CoreAVC Video Decoder | Average FPS: 34.171 | Min/Max FPS: Min: 23 Max: 43 | Playback CPU Usage (%): Avg: 71 Max: 100
Decoder: ffdshow Video Decoder | Average FPS: 33.946 | Min/Max FPS: Min: 25 Max: 43 | Playback CPU Usage (%): Avg: 71 Max: 92
Decoder: LAV Video Decoder |Average FPS: 37.764 | Min/Max FPS: Min: 26 Max: 50 | Playback CPU Usage (%): Avg: 63 Max: 84

Decoder: CoreAVC Video Decoder | Average FPS: 38.281 | Min/Max FPS: Min: 30 Max: 55 | Playback CPU Usage (%): Avg: 63 Max: 80
Decoder: ffdshow Video Decoder | Average FPS: 38.685 | Min/Max FPS: Min: 32 Max: 49 | Playback CPU Usage (%): Avg: 62 Max: 75
Decoder: LAV Video Decoder | Average FPS: 42.336 | Min/Max FPS: Min: 33 Max: 54 | Playback CPU Usage (%): Avg: 55 Max: 68

Decoder: CoreAVC Video Decoder | Average FPS: 43.683 | Min/Max FPS: Min: 35 Max: 50 | Playback CPU Usage (%): Avg: 54 Max: 66
Decoder: ffdshow Video Decoder | Average FPS: 42.413 | Min/Max FPS: Min: 38 Max: 46 | Playback CPU Usage (%): Avg: 55 Max: 64
Decoder: LAV Video Decoder | Average FPS: 47.837 | Min/Max FPS: Min: 42 Max: 52 | Playback CPU Usage (%): Avg: 48 Max: 55

Decoder: CoreAVC Video Decoder | Average FPS: 84.311 | Min/Max FPS: Min: 70 Max: 107
Decoder: ffdshow Video Decoder | Average FPS: 87.385 | Min/Max FPS: Min: 74 Max: 111

Decoder: CoreAVC Video Decoder | Average FPS: 118.340 | Min/Max FPS: Min: 85 Max: 139
Decoder: ffdshow Video Decoder | Average FPS: 113.697 | Min/Max FPS: Min: 87 Max: 128

Decoder: CoreAVC Video Decoder | Average FPS: 45.284 | Min/Max FPS: Min: 37 Max: 62
Decoder: ffdshow Video Decoder | Average FPS: 41.258 | Min/Max FPS: Min: 36 Max: 54

Playback CPU usage = non-benchmark normal speed VMR9 playback in DXVAChecker

CoreAVC 3.0.0 was released late last night, so I went to sleep without doing Playback CPU usage for all of them, but you should be able to see the trend. CoreAVC 3.0.0 struggles with sudden high-complexity/high-bitrate fluxuations in the stream, making it not so good for older CPUs like my AMD X2 which risk falling below real-time. The test I listed on top is very representative of the problem I'm seeing. CoreAVC hits 100% CPU usage with a hard to decode section during normal playback and falls below real-time when benched, while FFDSHow doesn't go above 92% CPU usage and stays slightly above real-time when benched.

Update: LAV Video 0.35 results are surprisingly faster than both CoreAVC 3.0.0 and FFDShow.
Update: It looks like LAV Video 0.35 also has a P010 overhead, but it's half that of CoreAVC 3.0.0, so it seems there is room for improvement.

[TheFluff]

I've been seeing several reports of CoreAVC 3.0 exhibiting decoding errors with some 10-bit clips, as well.

Sample file (http://x264.fushizen.eu/encodan/10bit/railgun_op1_10bit.mp4)
The errors should be obvious, but here's a screenshot (http://vfrmaniac.fushizen.eu/OtherStuff/CoreAVC3.0_damages_railgun_op1_10bit.mp4.png) as well. The file works correctly when decoded with libavcodec, but I haven't tested any other decoders.

[cyberbeing]

Tested a few things and found another sample with similar corruption to what TheFluff posted:

Sample (http://www.mediafire.com/?bkdqlxuwmrxjfbx) | Screenshot (http://img696.imageshack.us/img696/7283/coreavc30corruption.png)

Edit: And another... I guess I should actually be watching things instead of benching, since the corruption problem must be semi-widespread

Sample2 (http://www.mediafire.com/?9830yforq4yc647) | Screenshot2 (http://img14.imageshack.us/img14/6517/coreavc30corruption2.png)

[mandarinka]

I noticed similar jumps in 10bit decoding cpu load with ffdshow /libavcodec in general/ when testing on an Athlon XP.
Maybe the decoders only have codepaths for cpus with better SSE performance. (Athlon XP would need MMX asembly since it lacks SSE compeltely, maybe some functions in ffh264 aren't SIMDed in MMX, in libavcodec; as for coreAVC, maybe it doesn't take the slowness of SSE2 on K8 into account?)

BTW, anyone tested on non-sse2 cpu?

[sneaker_ger]

Athlon XP would need MMX asembly since it lacks SSE compeltely

That is not true, Athlon XP has SSE(1).

[nevcairiel]

Did it occur to you that the Athlon XP is maybe just slow in general? :)

I can only speak for myself, but i will not waste time writing the code that i wrote in SSE2 already again in MMX, for some CPU thats around 10 years old. :D

[BetaBoy]

We are tracking a few annoying 10bit related bugs. Ones that stand out are the ones that affect Anime (of all things) and a few specific CPU's types.

[TheRyuu]

We are tracking a few annoying 10bit related bugs. Ones that stand out are the ones that affect Anime (of all things) and a few specific CPU's types.

Why does the content matter?

BTW, anyone tested on non-sse2 cpu?

No, just no.
Why should decade old hardware matter?

[eddman]

GPU Decoding: on NVIDIA only, AMD and Intel users are stuck with useless DXVA


You don't even know what you're talking about, and you expect everyone to take you seriously!

Coreavc is NOT a GPU decoder. It uses CUDA, only to access the built-in video decoder (Purevideo). It works almost like DXVA.

[BetaBoy]

Why does the content matter?
It doesn't It was meant to point out the Anime crowd being early adopters. RE: Hi10

[TheRyuu]

It doesn't It was meant to point out the Anime crowd being early adopters. RE: Hi10

And why exactly should that matter?

It's typical usage, you're watching a 10bit encoded video. Surely that's something that quality control should catch... It's not some obscure bug that takes some really weird set of steps to reproduce. From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.

[Stephen R. Savage]

Useless ad hominem and fabricated numbers.

I purchased CoreAVC 3.0 because my work requires evaluating decoding software. I am certainly not going to download gigabytes of special-case content (3840x2160? seriously?) to test as I have neither the CPU cycles nor the bandwidth. Moreover, I am only interested in scenarios that have a basis in reality. Your defensiveness betrays the weakness of your claims.

You don't even know what you're talking about, and you expect everyone to take you seriously!

Coreavc is NOT a GPU decoder. It uses CUDA, only to access the built-in video decoder (Purevideo). It works almost like DXVA.

Perhaps I should have put "GPU Decoding" in quotes. Rest assure that I know full well how the "GPU" decoding is implemented. Note that this entire thread was in an uproar when this was announced, as it was certainly not what CoreCodec had been advertising with their "GPU decoding" marketing claim. DXVA is useless because it doesn't do memory copies of frames, and if you just wanted to see a picture, there are dozens of free applications to do that.

And why exactly should that matter?

It's typical usage, you're watching a 10bit encoded video. Surely that's something that quality control should catch... It's not some obscure bug that takes some really weird set of steps to reproduce. From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.

If this is true, that puts CoreAVC's already low 10-bit performance under even more scrutiny. Not only is it slow, it's also wrong.

[BetaBoy]

I purchased CoreAVC 3.0 because my work requires evaluating decoding software.
:eek: I am truly speechless given your analyses and continued ignorance in posting biased opinions rather then well rounded evaluations like most d9's do.

Good or bad we want to hear whats going on so we can address it.... oh yeah we get the OSS argument in fact most of our developers here at CoreCodec are the ones working on libav and x264... there is room for all of us here.

[BetaBoy]

From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.
We are adding more regression videos to cover a wider range of 10bit content... but overflow errors are harder to catch naturally.

End result is each release as it relates to 10bit should be better then the last.... especially the next 2-3 releases as we are focusing in on performance (on top of bugs).

[TheRyuu]

We are adding more regression videos to cover a wider range of 10bit content... but overflow errors are harder to catch naturally.

End result is each release as it relates to 10bit should be better then the last.... especially the next 2-3 releases as we are focusing in on performance (on top of bugs).

No one thought to just watch a video?

Pretty much any 10bit video will break it (from what I hear) so I don't really understand your first statement.

[benus]

May I just ask, since there are some voices claiming poor performance of new CoreAVC 3.0

Is there any chance for implementing Cuda support in decoding 9 and 10-bit files to offload any given CPU?

If yes, will it still be a part of 3.x generation so I can safely purchase it now or are we talking about further development.

Please let me know. Thanks.

[Stephen R. Savage]

:eek: I am truly speechless given your analyses and continued ignorance in posting biased opinions rather then well rounded evaluations like most d9's do.

Good or bad we want to hear whats going on so we can address it.... oh yeah we get the OSS argument in fact most of our developers here at CoreCodec are the ones working on libav and x264... there is room for all of us here.

It's kind of hard to take you seriously when you complain about numbers being biased. It's also unclear what agenda you're trying to accuse me of promoting.

Edit: Actually, you are half right. My analyses are misleading and I should retract them. Just now, I opened a 10-bit file that I didn't use for my benchmark and found that CoreAVC shifted the image right by 16 pixels, with the right-most pixels reappearing on the left. If I had spent more time verifying the functionality of this alpha-quality software, I would not even have bothered to include it.

[BetaBoy]

It's...
Please reference my post to you:
http://forum.doom9.org/showpost.php?p=1524492&postcount=6678

[Stephen R. Savage]

Please reference my post to you:
http://forum.doom9.org/showpost.php?p=1524492&postcount=6678

Impersonating moderators is a bannable offense, BetaBoy. This isn't the first time someone has warned you about this behavior.

[TheRyuu]

Please reference my post to you:
http://forum.doom9.org/showpost.php?p=1524492&postcount=6678

Please forgive us for talking about broken software being broken in a thread specifically about said software.

Are you trying to pass blame to the user?
"Please avoid playing these files since it doesn't work with them."

[TheFluff]

:eek: I am truly speechless given your analyses and continued ignorance in posting biased opinions rather then well rounded evaluations like most d9's do.

Well, regardless of how much you complain about drama, the fact (or well rounded evaluation, if you prefer) is that until a bugfix release comes out, upgrading from 2.6 to 3.0 is definitely a bad idea. The killer feature most people were waiting for (10-bit decoding) is very broken, and for many testers I've spoken with the decoding performance is slower than in 2.6 (not to mention that in some cases it's actually slower than libavcodec as well).

oh yeah we get the OSS argument in fact most of our developers here at CoreCodec are the ones working on libav and x264... there is room for all of us here.

I'm not sure if you've realized the difference between you and libavcodec. People expect libavcodec to be broken. They expect libavcodec developers to be rude, hard to reach and slow to react to bug reports. That's just how open source is, after all.
However, when the same people encounter you, they tend to have different expectations, because you're a representative of a for-profit corporation. As such, you're expected to have certain QA standards, as well as have a customer support that consists of something more than whining about forum drama or blaming broken software on anime watchers.

[pirlouy]

Sorry to be such an ass-kisser, but even if you don't like this new version, you don't have to insult developers like that. It's not if there were a spyware... :/

[AzraelNewtype]

Sorry to be such an ass-kisser, but even if you don't like this new version, you don't have to insult developers like that. It's not if there were a spyware... :/

You're right, it's not spyware. It is, however, a product that they took our money for that does not work.

Oh, and I know BetaBoy has since backpedaled on his weird assertion that the bugs are anime related, but for reference this is not anime (http://i26.lulzimg.com/a864e7.png). If the developer is going to be this defensive of his product when it does not work (it should look like this (http://imgur.com/wcovB.png)), and is in fact shifting blame back onto the paying customers, there is little reason to be polite.

[mandarinka]

To be honest people sure seem to enjoy that ("paid-for"?) right to complain a bit too much. It could have been expressed less internet-like, imho. True that if CC tested a bit more thoroughly, they woudln't give the crowd the chance, but mistakes happen.

[BetaBoy]

Oh, and I know BetaBoy has since backpedaled on his weird assertion that the bugs are anime related
??? I was referencing Anime community as being early adopters and reporting the issues before anyone else.

and for many testers I've spoken with the decoding performance is slower than in 2.6 hearsay.. If you can provide us with content that shows this speed difference it would be appreciated.

Please forgive us..
Not at all.... I've said this 100x in this thread that we value everyone's support and awesome feedback. Having someone like Stephan however jump in and continue to post biased FUD brings nothing of value to the discussions.

That being said we are reacting faster the ever before to our customers as the past few releases show and we continue to do so with 3.x (and with the fact we are about to releases CoreMVC 3D as well).

[SEt]

BetaBoy, if you are started to fix bugs, please correct your wrong mediatype on DXVA2 connections: it should be subtype/compression 'NV12'/'dxva' not the 'NV12'/'NV12'. Sure I can detect it as DXVA2 later but it's still wrong and produce strange effects like the following one:

Set DXVA mode in CoreAVC, allow only YV12 output format. Now connect it to filter that rejects DXVA but accepts NV12 - result is connection with NV12.

PS: After writing for some time for DirectShow you understand that like every single filter has obvious bugs, haha (sad)... For example CyberLink that was in DXVA field forever won't work with you if you follow only standards.

[BetaBoy]

SEt... thx for the report I posted it for the devs to look into.

[TheShadowRunner]

A couple extremely simple questions as the 3.0 "what's new" doesn't make it clear ("CUDA" doesn't even appear anywhere!):

1. Is hi10 decoding in CoreAVC 3.0 strictly (=100%) done by the CPU?

2. If so, is it because CUDA acceleration CANNOT technically be implemented for hi10 sources or is it a limitation of the current 3.0 build?

3. If limitation of current build, can we imagine a scenario in the future where hi10 decoding gets hybrid: CPU + partial CUDA offloading?

Thanks for these infos..

[BetaBoy]

We just fixed the 'high depth bug' re: blockiness, for the next release.

[Keiyakusha]

If limitation of current build, can we imagine a scenario in the future where hi10 decoding gets hybrid: CPU + partial CUDA offloading?

Maybe a little OT but... do you know any decoders that do "partial CUDA offloading" which makes you expect something like that from CoreAVC? And why you asking only for 10bit but not for 8bit?

[TheShadowRunner]

Maybe a little OT but... do you know any decoders that do "partial CUDA offloading" which makes you expect something like that from CoreAVC? And why you asking only for 10bit but not for 8bit?

No, i certainly don't, just wondering.
And I don't ask for 8bit, because i know CUDA acceleration takes care of it already :P

Betaboy, please at least answer question 1/2!

A couple extremely simple questions as the 3.0 "what's new" doesn't make it clear ("CUDA" doesn't even appear anywhere!):

1. Is hi10 decoding in CoreAVC 3.0 strictly (=100%) done by the CPU?

2. If so, is it because CUDA acceleration CANNOT technically be implemented for hi10 sources or is it a limitation of the current 3.0 build?
Thanks,

TSR

[cyberbeing]

and for many testers I've spoken with the decoding performance is slower than in 2.6 hearsay.. If you can provide us with content that shows this speed difference it would be appreciated.

This had me a bit concerned, so I tested a few random 8bit videos. Thankfully I can say that CoreAVC 3.0.0 x86 is consistently about 1% faster than 2.6.1 on my old AMD X2. Nothing to write home about, but a speed-up is a speed-up. So if there is an issue, it doesn't seem to affect old AMD processors.

68.5356 CoreAVC 3.0.0
67.9791 CoreAVC 2.6.1

65.3254 CoreAVC 3.0.0
64.5945 CoreAVC 2.6.1

62.0784 CoreAVC 3.0.0
61.3808 CoreAVC 2.6.1

64.3769 CoreAVC 3.0.0
63.8261 CoreAVC 2.6.1

183.4490 CoreAVC 3.0.0
182.8061 CoreAVC 2.6.1

157.7797 CoreAVC 3.0.0
157.0646 CoreAVC 2.6.1

[LoRd_MuldeR]

The term "CUDA decoding" or "CUDA offloading" is misleading. Actually I am not aware of any H.264 decoder that is implemented as a CUDA kernel, i.e. running on the GPU. Instead all those "CUDA" enabled/accelerated decoders simply use the hardwired H.264 decoder chip that is integrated on the graphics card. That decoder chip is a dedicated piece of hardware. It may be accessed via the "CUDA Video API" (CUVID), but that is very different from a "real" CUDA kernel. The latter would be running on the programmable GPU (shader cores). Also the decoder chip is the very same one that would be used by a "DXVA" enabled/accelerated decoder. This also means: What can (or can not) be decoded "in hardware" does not depend on the individual decoder software (may it be CoreAVC or something else), but on the decoder chip on the graphics card! If, for example, the decoder chip on the graphics card does not support 10-Bit H.264, then there is nothing that the decoder software could do about that - except for falling back to pure software decoding, of course. Hardware decoder chips can not be updated. If you want new hardware decoder features, then you have to wait for the next generation of graphics cards...

[Keiyakusha]

And I don't ask for 8bit, because i know CUDA acceleration takes care of it already :P
Actually no... not really. What i mean is, you asked about partial acceleration (for weaker hardware i guess?), which means some real CUDA-based decoder should be created. Current implementation only passes video to the chip, located on the videocard and nvidia does the rest, so its nowhere near any partial stuff.
EDIT: oops i'm so slow... so much of good stuff was written before me...

[SEt]

If you are interested, I can also confirm DXVA2 cpu usage regression. GraphStudio speed test to Null Renderer, some random 720p anime (fps/cpu):

DXVA2:
86 13.5% CoreAVC 3.0.0
103 1% CoreAVC 2.5.5
103 1% FFDS

CUDA:
87 1.5% CoreAVC 3.0.0 and 2.5.5
102 2% LAV

Software:
1640 CoreAVC 3.0.0
1573 LAV

As you can see from software speed it's a lot of wasted CPU resources.

[ajp_anton]

But what if this 8-bit hardware decoder in fact does output *something* from a 10-bit clip that is not pure garbage, with enough real data that it's worth patching the bad spots in software.

[STaRGaZeR]

This thread is always so fun to read, specially after a release. :)

[TheShadowRunner]

This also means: What can (or can not) be decoded "in hardware" does not depend on the individual decoder software (may it be CoreAVC or something else), but on the decoder chip on the graphics card! If, for example, the decoder chip on the graphics card does not support 10-Bit H.264, then there is nothing that the decoder software could do about that - except for falling back to pure software decoding, of course.

Thank you very much, finally.
So CoreAVC 3.0's hi10 decoding cannot and never will be "CUDA accelerated" with the current nVidia cards in the market.
CoreAVC's 3.0 hi10 decoding is 100% CPU.

Actually no... not really. What i mean is, you asked about partial acceleration (for weaker hardware i guess?), which means some real CUDA-based decoder should be created. Current implementation only passes video to the chip, located on the videocard and nvidia does the rest, so its nowhere near any partial stuff.
EDIT: oops i'm so slow... so much of good stuff was written before me...

Roger that, I didn't know. I though CoreAVC's CUDA implementation just used the horsepower of the chip on the nVidia card but instructed it HOW to decode, which made it different from DXVA.

But what if this 8-bit hardware decoder in fact does output *something* from a 10-bit clip that is not pure garbage, with enough real data that it's worth patching the bad spots in software.

That was pretty much my question too, maybe I formulated it badly ^^;

[SEt]

Nothing useful can be done with wrong decoding result of h264. But you have good chances to find something in hardware that can do correctly part of algorithm (like, stream decoding, IDCT,...) and use that hardware part with the rest of software. It will be partial hardware acceleration. How much can it help to free cpu? Who knows...

[LoRd_MuldeR]

But what if this 8-bit hardware decoder in fact does output *something* from a 10-bit clip that is not pure garbage, with enough real data that it's worth patching the bad spots in software.

A hardware decoder chip either supports 10-Bit or it does not. In the latter case it would probably reject 10-Bit streams and not output anything at all. And, if it does not reject the unsupported stream for some reason, the output will simply be "undefined" (or in other words: random garbage). This cannot be "patched" in software, except by throwing away the hardware decoder's broken output and properly decoder the source in software! Also: Even if it was possible to recover the broken output somehow, why should anybody want to use a hardware decoder for something that it never was designed for (and therefore cannot handle correctly), just to spend a whole lot of CPU cycles for "repairing" the broken output afterwards? Sounds like a rather bizarre idea to me...

But you have good chances to find something in hardware that can do correctly part of algorithm (like, stream decoding, IDCT,...) and use that hardware part with the rest of software. It will be partial hardware acceleration. How much can it help to free cpu? Who knows...

Doesn't the whole decoding pipeline have to support 10-Bit precision to properly decode 10-Bit streams?

[SEt]

I'm not expert in h264 internals, but likely no. Decoder has to use >8 bit internal precision for decoding 8 bit content anyway and it means likely 16 bit precision that could be ok for 10 bit too.

[LoRd_MuldeR]

Decoder has to use >8 bit internal precision for decoding 8 bit content anyway.

I don't think so. H.264 uses integer math. And when decoding 8-Bit streams the decoder has to truncate everything to exactly 8-Bit internally for correct output.

(It is the other way around: Using more than 8-Bit internal precision is beneficial, even for 8-Bit sources. But it requires a "high bit-depth" capable H.264 encoder + decoder).

[TheShadowRunner]

BetaBoy, will decoding hi10p contents benefit from the current acceleration methods (CUDA, DXVA..) in CoraAVC 3.0, or will it be 100% software only?
I can imagine DXVA is a no go, but I wonder about CUDA..
Thanks for the info.

Ill comment once 3.0 is out, but you're not far off.

So, I guess I was REALLY far off after all...

[SEt]

Encoder/decoder be it software or hardware 'truncates everything' as rare as it can, likely only at the very last stage. And 8 bit is not enough for processing 8 bit with something more complex than inverse or average of two values.

[BetaBoy]

This had me a bit concerned, so I tested a few random 8bit videos. Thankfully I can say that CoreAVC 3.0.0 x86 is consistently about 1% faster than 2.6.1 on my old AMD X2.

You should see some additional 8-bit speed increases soon enough as we had been working on some more (8-bit) optimization's but because of time constraints they did not make it into 3.0.

[LoRd_MuldeR]

This is getting off-topic, but for proper output all decoders have to truncate all intermediate results in the same way. Otherwise it couldn't be guaranteed that all decoders deliver the identical (correct) output for a given input stream. So when decoding 8-bit streams, all intermediate results are truncated to 8-bit internally. That is also the reason why using an higher internal precision (e.g. 9-bit or 10-bit) gives better encoding efficiency, even if the source was "only" 8-bit: There are fewer rounding errors in the encoding/decoding pipeline. But, as encoder and decoder have to agree on the internal precision (and must truncate accordingly), 9-bit or 10-bit encoding also requires a 9-bit or 10-bit decoder. Moreover 8-bit internal precision mainly is a shortcut for speed improvement. So if the stream was encoded with 8-bit precision, you want to decode with 8-bit precision (and not some higher precision, even if you could), simply because it is faster. That's also the reason why hardware decoders that don't officially support more than 8-bit precision will probably not be prepared for 9-bit or 10-bit precision internally. Why would you waste silicon for something that you don't expose/sell as a feature?

[Fadeout]

Can we also have DXVA fixed since it was working fine in 2.5 and it's not involved in hi10?

Current problems: high CPU usage and non-smooth performance on some complex videos.

[BetaBoy]

We just fixed the DXVA memory resources bug.... We are onto the reports of high bitrate Hi10p videos next, but given that it might take some time to work on the assembly code (and address the Haali MP4 bug), we will likely release an update ASAP. CoreAVC 3.0.1 incoming ;-)

[eddman]

People, how about providing detailed bug reports? Simply saying that it's not working or it's slow for me won't really help. It should be something like this:

1. Describe the problem throughly and provide video sample if possible, if not then at least provide screenshots (if applicable)
2. OS - Win XP SP3
3. CPU - Core 2 Duo E6700
4. GPU - Geforce 9600 GT
5. Video Driver version - 260.89
6. Player - MPC-HC 1.5.0.2827
7. Renderer - VMR-9 windowed
8. Splitter - Haali 1.10.262.12
9. Codec - CoreAVC 2.6.1
10. Output - YV12
11. Acceleration - DXVA
12. Other specific things that might help.

[CruNcher]

@Dan
there are several bitstreams where the Full (Intel 2nd Generation) Performance (also in terms of Power output) of CoreAVC 3.0 8 bit 64 bit @ least is not that good in direct compare :(

Here is one of those examples (Yv12):

http://img35.imageshack.us/img35/5793/crysis2gb.png

and overall it losses to DiAVC 64 practically all the time (except some rare bitstreams 4k) and sometimes Lav Video (libav) can take over it too (though lav video never makes it to get to DiAVC Performance)

[hajj_3]

I'm quite suprised that CoreAVC haven't bought out DiAVC to be honest, he said he'd be willing to sell it for $200k and for the sourcecode to be opensourced, i would have thought that coreavc must be making quite a bit of money from commercial usage of their products to buy DiAVC, that would be a seriously fast decoder and there would be no real competition as people don't want to install all the junk divx bundles, they just want a codec to play xvid/x264 videos with low cpu utilisation.

With hd decoding on modern intel/amd/arm processors the uses of coreavc will reduce more and more. Divx could buy DiAVC too, that would be very lucrative for them seeing as thought divx is in so many devices, its a no-brainer for them.

[CruNcher]

The Decision to buy DiAVC IP would be up to Rovi ;) though Mainconcept/Elecard Engineers (which the core of the whole DivX H.264 Framework is based on + Matroska (CoreCodec)) aren't bad either and one of the oldest MPEG standard based digital video codec implementers in the World (they had 10 bit support much earlier then you might imagine) and most probably will reach that Performance soon (or maybe have reached it already) so not sure if they have a real interest in buying his code also buying his code would be not really efficient, employing him directly would be much better ;)

And to your other question, thats Graphstudio from Radscorpion (RadLight) though you have to know what you do as it's based on Directshow if you want to give it a try http://blog.monogram.sk/janos/tools/monogram-graphstudio/

[BetaBoy]

We have fixed the Haali Splitter Bug MP4 recognition and it will be included in our next CoreAVC 3.0.1 release.

[hajj_3]

i presume 2.6.2 will follow that?

[betaking]

We have fixed the Haali Splitter Bug MP4 recognition and it will be included in our next CoreAVC 3.0.1 release.
Next week or tomorrow?:thanks:

[BetaBoy]

i presume 2.6.2 will follow that?

Correct however out of respect for past purchasers we might release it before 3.0.1

[BetaBoy]

Next week or tomorrow?:thanks: Likely later today or tomorrow after we QA.

[betaking]

Likely later today or tomorrow after we QA.

:thanks:

[cyberbeing]

Likely later today or tomorrow after we QA.

To avoid huge memory leaks like this in CoreAVC, i would however recommend to free the memory buffers when the input pin is disconnected, and not wait until the filter is destructed. (Which is why it doesn't show up on other filters, they do exactly that)

Did what nevcairiel suggested make it into 3.0.1 to fix the memory leak issue with madVR 0.74? Would doing so break something else or be undesirable for some reason?

And then there is also the 10-bit to P010/P016 conversion being slower than it should be, at least on my AMD X2, to keep in mind.

[dead_screem]

A couple bugs. Haali will cause Graphstudio video decoder benchmark to crash on the last pass or when I press stop (when the graph is deconstructed I assume). I have to switch to the MPC-HC standalone filters.

When DXVA1 is used CoreAVC is using a weird output 4cc H¾ then two characters that cant render here on the forum, a middle dot and then a left pointing arrow. Instead of "dxva" like MPC-HC. I have no idea if this is really a bug or if it actually affects anything.

[BetaBoy]

Did what nevcairiel suggested make it into 3.0.1 to fix the memory leak issue with madVR 0.74? Would doing so break something else or be undesirable for some reason?

And then there is also the 10-bit to P010/P016 conversion being slower than it should be, at least on my AMD X2, to keep in mind.
The issue with madvr is that it should release the CoreAVC instance. We can add memory releases but the point is we shouldn't as it has the side effect of causing more bad then good, like:
- Having multiple monitors hang
- Causing multiple tray icons
- Possible setting conflicts

Was madshi doing a fix for this?

ok... on the noted conversion slowdown.

[BetaBoy]

We have now added DXVA multi-monitor support.... now to QA it for CoreAVC 3.0.1 (and 2.6.2)

[cyberbeing]

The issue with madvr is that it should release the CoreAVC instance. We can add memory releases but the point is we shouldn't as it has the side effect of causing more bad then good, like:
- Having multiple monitors hang
- Causing multiple tray icons
- Possible setting conflicts

Was madshi doing a fix for this?

That's why I asked. If CoreAVC implementing a workaround creates other issues, we'll just need to wait for madshi to fix it on his end. ;)

nevcairiel said madshi commited to fixing it in the next version of madVR, but his release schedule is semi-random so that could be today... or it may end up being a month or more away... At the very least CoreCodec should add an entry to their Support KB about this issue, directing people to upgrade or downgrade their version of madVR if they experience a leak.

[BetaBoy]

By request we have done a new Haali Media Splitter installer with the MP4 fix... We sent it to Haali to add to his site.

[BetaBoy]

Till Haali adds it, we have made it available for download:
https://customers.corecodec.com/downloads.php

[junh1024]

I have reproduced the "video offset by X pixels" bug Stephen mentioned about on a 10-bit 720*560 video

Picture here (http://i.imgur.com/evGCz.png)

Sample here (http://www.megaupload.com/?d=37QF466B)

[dead_screem]

I have reproduced the "video offset by X pixels" bug Stephen mentioned about on a 10-bit 720*560 video

Picture here (http://i.imgur.com/evGCz.png)

Sample here (http://www.megaupload.com/?d=37QF466B)

I can confirm this. And to add to this, it only happens for YV12 colorspace and even then only some videos. NV12 and other colorspaces arn't affected.

[BetaBoy]

I can confirm this. And to add to this, it only happens for YV12 colorspace and even then only some videos. NV12 and other colorspaces arn't affected.

Fixed for the next release.

[betaking]

By request we have done a new Haali Media Splitter installer with the MP4 fix... We sent it to Haali to add to his site.

:thanks: and can you report to haali .last Haali Media Splitter have ts bug! can not Connection some vc1 decoder,and ps to decoder can not Connection some lpcm audio decoder!

[BetaBoy]

We are doing QA on the final CoreAVC 3.0.1.0 and 2.6.2.0 installers now.

Here is the changelogs:
CoreAVC H.264 Video Codec - Version 3.0.1.0 (20110909)
- ADD: DXVA re-initialization when device is lost
- FIX: Catch samples that don't get properly released by EVR
- FIX: Overflow in high bit depth weighted prediction
- FIX: Bug in 10-bit SSE2 IDCT
- FIX: Missing YV12 bitdepth caused misaligned blits from i010/i009 formats
- FIX: Don't use NV12 for connection if it's disabled and DXVA is unavailable
- CHG: Use "DXVA" FourCC for NV12 subtype when it's used for DXVA connections
- CHG: Reduce CPU usage while polling for DXVA completion
- CHG: Reinitialize decoder context on input pin disconnection
- CHG: Force low latency mode when graph is paused

Haali Media Splitter - Version 1.11.288.0 (20110909)
- FIX: MP4 video output pin regression

CoreAVC H.264 Video Codec - Version 2.6.2.0 (20110909)
- ADD: DXVA re-initialization when device is lost
- FIX: Catch samples that don't get properly released by EVR
- CHG: Use "DXVA" FourCC for NV12 subtype when it's used for DXVA connections
- CHG: Reduce CPU usage while polling for DXVA completion

Haali Media Splitter - Version 1.11.288.0 (20110909)
- FIX: MP4 video output pin regression

[dead_screem]

Bug I just noticed. in the sample linked in this post http://forum.doom9.org/showpost.php?p=1524571&postcount=6692

I get green pixel corruption on some of the letters on the title when used with NV12
http://img508.imageshack.us/img508/5774/railgunop110bitmp4snaps.png (http://imageshack.us/photo/my-images/508/railgunop110bitmp4snaps.png/)

and with YUY2,UYVY and RGB output colorspaces it gets really jaggy
http://img821.imageshack.us/img821/5774/railgunop110bitmp4snaps.png (http://imageshack.us/photo/my-images/821/railgunop110bitmp4snaps.png/)

[squid_80]

Might help if you said which renderer was being used.

[Barlow]

That sample looks fine here with EVR-CP (nv12) and MadVR.

[dead_screem]

Might help if you said which renderer was being used.

After checking this, the NV12 green pixels happen with VMR-7 and VMR-9. EVR is fine.
The jaggys on YUY2,UYVY and RGB happen on VMR-7, VMR-9 and EVR
Windows XP btw.

[cyberbeing]

I get green pixel corruption on some of the letters on the title when used with NV12 and with YUY2,UYVY and RGB output colorspaces it gets really jaggy
I can reproduce both problems with 3.0.1.

YUY2/UYVY/RGB have very blocky chroma.

The green blocks seems to be a bug in NV12 levels conversion. If you using Input = Output levels there are no green blocks. TV -> PC = green blocks.

Happens with all renderers tested (Overlay-Mixer/VMR7/VMR9/EVR/EVR-CP/madVR) on WinXP SP3 x86.




There are also some very significant performance problems with various 10bit to XXX colorspace conversions. No assembly yet?

Below are some quick perf tests I did with the CoreAVC_3.0_Corruption.mkv sample I posted earlier:

YV12/NV12/I420 = ~65.8753fps

P010/P016 = ~62.1560fps

RGB32 = 35.3177fps

Problem colorspaces:
RGB24 = 12.1498fps
RGB16 = 13.2597fps
RGB15 = 13.3949fps
UYVY = 16.1888fps
YUY2 = 16.2040fps

[hajj_3]

have you guys tested out v2.6.2.0 yet? That and v3.0.1.0 are on their website now.

[cyberbeing]

Later I may do some performance testing with 3.0.1, if it doesn't look like CoreAVC is going to push out another bugfix release today. I'm curious if that high bitrate problem got fix yet.

[dead_screem]

The green blocks seems to be a bug in NV12 levels conversion. If you using Input = Output levels there are no green blocks. TV -> PC = green blocks.

Happens with all renderers tested (Overlay-Mixer/VMR7/VMR9/EVR/EVR-CP/madVR) on WinXP SP3 x86.
Looks like the reason it was working with EVR for me was because I had output levels to Auto. And when it's set to auto CoreAVC detects PC out levels for VMR-7/9 but TV for EVR and Overlay. Forcing PC out and I now experience the bug for EVR and Overlay.

I wonder why Auto level output detects different setting depending on what renderer is used?

And a feature request if I may, can we get "No change/passthrough" output level option? Basically if Input is TV then output TV and if PC input then output PC.

[BetaBoy]

Later I may do some performance testing with 3.0.1, if it doesn't look like CoreAVC is going to push out another bugfix release today. I'm curious if that high bitrate problem got fix yet.
Hold off a few more hours till we another release out... then have fun with numbers. :-)

[BetaBoy]

Later I may do some performance testing with 3.0.1, if it doesn't look like CoreAVC is going to push out another bugfix release today. I'm curious if that high bitrate problem got fix yet.
Specifically... we are doing a 3.0.2 release in a few more hours as we already have a new bug to squash. RE: the VMR7 and VMR9 green lines/dot issue.
After checking this, the NV12 green pixels happen with VMR-7 and VMR-9. EVR is fine.
The jaggys on YUY2,UYVY and RGB happen on VMR-7, VMR-9 and EVR
Windows XP btw.
Bug confirmed.

We have also tracked down the Haali's renderer as the cause of most of the high CPU usage complaints for high-bitdepth as it prefers YUY2/NV12

We are talking to Haali on how to handle it.

[cyberbeing]

BetaBoy, is there any timeline for adding optimized assembly for 420p10 to YUY2?
Out of all the problem colorspaces, YUY2 and possibly RGB24 should be prioritized since some filters actually expect them at times.

We are talking to Haali on how to handle it.
That would be amazing if Haali actually started developing Haali Renderer again, since he pretty much abandoned it cold-turkey years ago.

[BetaBoy]

We also confirmed the bug for the jagginess reports (native chroma upsampling)... and working on a fix now.

[BetaBoy]

cyberbeing... Next up is more high10 assembly work we have been working on in an upcoming release.

[dead_screem]

another bug, YUY2,UYVY TV->PC isn't working at all with 10bit, levels are still TV. Also RGB is also TV levels with 10 bit. Is this related to the jaggy bug for these colorspaces?

[blaster00]

What's this?
http://thumbnails42.imagebam.com/14878/78ed67148773422.jpg (http://www.imagebam.com/image/78ed67148773422)

Tried haali, evr(cp) render; ati and intel display card.
MPC-HC r3715 x64, coreavc 3.0.1.0
All x264 video look like this.
Haven't restart after update coreavc yet.
DXVA works fine, though.

Solved

[Keiyakusha]

That would be amazing if Haali actually started developing Haali Renderer again, since he pretty much abandoned it cold-turkey years ago.

Or at least make it opensource. Otherwise whats the point in it if noone is using this renderer anymore (accept maybe someone who don't know that there is better choices)...

[BetaBoy]

What's this?
http://thumbnails42.imagebam.com/14878/78ed67148773422.jpg (http://www.imagebam.com/image/78ed67148773422)

Tried haali, evr(cp) render; ati and intel display card.
MPC-HC r3715 x64, coreavc 3.0.1.0
All x264 video look like this.
Haven't restart after update coreavc yet.
You mind pm'ing me your registration info?

[sawg]

Please forgive me if I make any errors; my English is a little weak.

EVR CP BUG...?
Play 1080p video, CUDA can't use when EVR buffers 10~15 more.
And DXVA can't use in EVR but VMR9 is ok.

http://i.imgur.com/haYHi.jpg
http://i.imgur.com/zXp4m.jpg

[molitar]

Ok this is the worse release yet. I am not even able to play the video file it locks up mpc home completely. MPC stops responding. Even with DXVA acceleration it still failed to run. Runs perfectly fine with ffdshow that came with CCCP pack and even runs with DXVA support.

General
Unique ID : 178621245569138099216868139571076912728 (0x866133578AC06EEF88123C7B23BFD658)
Complete name : D:\01 Incomplete\Itsuka Tenma no Kuro Usagi 08+\Itsuka Tenma no Kuro Usagi - 01 [WhyNot].mkv
Format : Matroska
Format version : Version 2
File size : 517 MiB
Duration : 25mn 0s
Overall bit rate : 2 889 Kbps
Encoded date : UTC 2011-07-11 08:32:15
Writing application : mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58
Writing library : libebml v1.2.0 + libmatroska v1.1.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 25mn 0s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 116 r2019 9cc407d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.50:0.20 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-5 / threads=24 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=19.0 / qcomp=0.70 / qpmin=10 / qpmax=31 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:0.70
Language : Japanese

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : A_AAC
Duration : 25mn 0s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 96.0 KHz / 48.0 KHz
Compression mode : Lossy
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Language : English

Menu
00:00:00.000 : :Intro
00:02:31.960 : :Part A
00:12:31.930 : :Part B
00:24:19.930 : :Preview

[squid_80]

sawg: by setting EVR to use 20 buffers, you're using up all the VRAM and leaving none for CUDA. And if you're able to get VMR9 to use DXVA, you're using windows XP and won't get DXVA with EVR.
molitar: that's a file description, not a bug report. Please refer to this helpful post. (http://forum.doom9.org/showthread.php?p=1524801#post1524801)

[ney2x]

CoreAVC 3.0.1, seeking bug came back. Using WMP12 or MPC-HC.

[squid_80]

I think Doom9 himself would agree (http://forum.doom9.org/showthread.php?t=96137) that's not a proper bug report either. Come on guys, do you want these things fixed or are you just trying to point fingers?

[molitar]

1. Playing file using CoreAVC locks up mpc-home
2. OS - Windows 7 32bit
3. CPU - AMD Phenom 955 Quad Core
4. GPU - Radeon HD 5750
5. Video Driver version - ATI Catalyst 11.6
6. Player - MPC-HC 1.5.2.2368
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 2.6.2
10. Output - unknown
11. Acceleration - DXVA
12. Does not matter if I use DXVA acceleration or no acceleration it still will not play the file.

[blaster00]

Something about colourspace
Start from the haali render post,with the clip rec709 (http://www.mediafire.com/?sfd13vqrgn7vh6i)
Since few people in that post and has something to do with coreavc, I'd like to continue here.
First, I assume the "c yv12 auto evr" is the right one. Which means coreavc(yv12 output)(auto input)==>EVR(cp) render
http://thumbnails44.imagebam.com/14881/3bb8e8148804350.jpg (http://www.imagebam.com/image/3bb8e8148804350)
The internal converter of coreavc seems wrong with default setting.
c rgb32 601 evr
http://thumbnails41.imagebam.com/14881/232f17148804960.jpg (http://www.imagebam.com/image/232f17148804960)
c rgb32 709 evr
http://thumbnails36.imagebam.com/14881/1e4d13148804336.jpg (http://www.imagebam.com/image/1e4d13148804336)
c rgb32 709 hr auto
http://thumbnails50.imagebam.com/14881/073f06148804964.jpg (http://www.imagebam.com/image/073f06148804964)
c rgb32 auto evr
http://thumbnails33.imagebam.com/14881/e1ef9a148804340.jpg (http://www.imagebam.com/image/e1ef9a148804340)
c yuy2 auto hr 601
http://thumbnails45.imagebam.com/14881/a37af2148804343.jpg (http://www.imagebam.com/image/a37af2148804343)
c yuy2 auto hr 709
http://thumbnails45.imagebam.com/14881/a122d5148804347.jpg (http://www.imagebam.com/image/a122d5148804347)
c yuy2 auto hr auto
http://thumbnails35.imagebam.com/14881/8ecc6e148804348.jpg (http://www.imagebam.com/image/8ecc6e148804348)

c rgb32 601 evr == c rgb32 auto evr == c yuy2 auto hr 601, wrong, I guess.
c rgb32 709 evr == c rgb32 709 hr auto == c yuy2 auto hr 709 == c yuy2 auto hr auto == c yv12 auto evr, right, I guess.
So if someone use the default setting with coreavc and evr and another one simply change to rgb32 output in coreavc are not getting the same colour, at least with this 720p clip.

[eddman]

10. Output - unknown


You can determine it this way, I think; while playing the video, right-click on the picture and go to "Filters -> Enhanced Video Renderer (custom presenter)".
Select "Pin Info" tab. It's written there.

http://s1.bild.me/bilder/030611/5020275vo1.JPG

EDIT: Now I'm officially stupid. You can't know what the output is because MPC locks-up, duh!

[blubberbirne]

http://img35.imageshack.us/img35/5793/crysis2gb.png


Where can i download the "video decoder performance test" ?

[nevcairiel]

Where can i download the "video decoder performance test" ?

Its part of GraphStudio (http://blog.monogram.sk/janos/tools/monogram-graphstudio/)

[CruNcher]

Hmm slowly i wonder if you can trust a lot of Dshow based Benchmarks anyways

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:05.169
Average FPS: 401,817
Min/Max FPS: Min: 400 Max: 405
CPU Usage (%): Avg: 00 Min: 00 Max: 01

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:05.206
Average FPS: 399,306
Min/Max FPS: Min: 399 Max: 400
CPU Usage (%): Avg: 00 Min: 00 Max: 01

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:03.108
Average FPS: 334,266
Min/Max FPS: Min: 333 Max: 337
CPU Usage (%): Avg: 10 Min: 09 Max: 11


Trying to compare DXVA2 64 Bit, but how can it be that Render time is faster but fps lower ???? (and what is now preferable, time or speed my logic would say time)

[SEt]

Looks like bug in benchmark OR graphs produced different number of frames.

[CruNcher]

i guess its better not to benchmark with the H.264 stream in *.ts and Mpegsplitter.ax

uhh in CoreAVC 3.0.1 something changed DXVA2 is now displayed (before it only showed DXVA1 but worked anyways)

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:03.130
Average FPS: 331,891
Min/Max FPS: Min: 332 Max: 332
CPU Usage (%): Avg: 09 Min: 09 Max: 09


Results of a H.264 *.mp4 parsed with Mp4splitter.ax

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:02.660
Average FPS: 378,491
Min/Max FPS: Min: 364 Max: 384
CPU Usage (%): Avg: 03 Min: 02 Max: 03

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:02.667
Average FPS: 377,490
Min/Max FPS: Min: 359 Max: 386
CPU Usage (%): Avg: 05 Min: 05 Max: 05

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:02.680
Average FPS: 375,674
Min/Max FPS: Min: 365 Max: 380
CPU Usage (%): Avg: 08 Min: 08 Max: 08

fits much better then the Mpegsplitter.ax *.ts result (of CoreAVC, most probably a interop problem with the splitter, so i guess most results i got with Graphstudio benchmarking H.264 *.ts might be wrong also, if it affects Software Rendering the same) :(

But wait MpegSplitter has this fast stream switch option hmm im not sure if i turned that off and if that might impact CoreAVCs timing behavior :( <- Nope that has no impact seems to be just the Splitter itself

[ebuss07]

similar problems here..... is it just me--new CoreAVCs seem like chewin'gum?! MeGUI/AVS/CoreAVC used to work properly... now either avScript error:directshowsource: renderfile, filter graphmanager won'talk to me OR sometimes work--but load script video preview not only colour is red and footage is upside down {like this one i downloaded:http://d01.megashares.com/?d01=ZW6IYZQ[/EMAIL] (http://d01.megashares.com/?d01=ZW6IYZQ)}

[CruNcher]

@SEt

Funny in Mpegsplitter.ax Software Rendering (now Microsofts Decoder is showing strange results)

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: DiAVC H.264 Decoder (x64)
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:05.606
Average FPS: 185,320
Min/Max FPS: Min: 181 Max: 189
CPU Usage (%): Avg: 97 Min: 94 Max: 98

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:06.691
Average FPS: 155,280
Min/Max FPS: Min: 152 Max: 163
CPU Usage (%): Avg: 81 Min: 75 Max: 84

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:07.445
Average FPS: 139,545
Min/Max FPS: Min: 135 Max: 146
CPU Usage (%): Avg: 89 Min: 80 Max: 93

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.431
Average FPS: 123,346
Min/Max FPS: Min: 120 Max: 126
CPU Usage (%): Avg: 86 Min: 84 Max: 89

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.875
Average FPS: 234,242
Min/Max FPS: Min: 227 Max: 241
CPU Usage (%): Avg: 93 Min: 91 Max: 96


Lav Splitter *.ts DXVA2

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:05.203
Average FPS: 400,130
Min/Max FPS: Min: 400 Max: 401
CPU Usage (%): Avg: 03 Min: 00 Max: 09

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:05.229
Average FPS: 398,546
Min/Max FPS: Min: 396 Max: 400
CPU Usage (%): Avg: 03 Min: 00 Max: 10

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:03.170
Average FPS: 328,649
Min/Max FPS: Min: 316 Max: 336
CPU Usage (%): Avg: 08 Min: 03 Max: 12

Same CoreAVC result issue:


Lav Splitter *.ts Software

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: DiAVC H.264 Decoder (x64) <- Causes crash in Graphstudio (is being debugged currently see http://forum.doom9.org/showthread.php?p=1524632#post1524632)
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:14.476
Average FPS: 71,912
Min/Max FPS: Min: 72 Max: 73
CPU Usage (%): Avg: 29 Min: 24 Max: 39

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:06.544
Average FPS: 159,222
Min/Max FPS: Min: 146 Max: 170
CPU Usage (%): Avg: 82 Min: 77 Max: 89

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:07.251
Average FPS: 143,419
Min/Max FPS: Min: 132 Max: 150
CPU Usage (%): Avg: 90 Min: 84 Max: 98,

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.134
Average FPS: 128,346
Min/Max FPS: Min: 113 Max: 133
CPU Usage (%): Avg: 86 Min: 82 Max: 89

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.673
Average FPS: 240,271
Min/Max FPS: Min: 221 Max: 252
CPU Usage (%): Avg: 93 Min: 89 Max: 97

Same issue with Microsoft and Lav Splitter in Software Rendering


Puhh so at least i can be sure all my Software Rendering measuring's where right with CoreAVC since now, though the bad results coming out from CoreAVCs DXVA2 with 2 of the most used *.ts splitter don't look good also in terms of what problems this might could produce with Splitter and Audio Decoder for different streams, though it might have todo with the DVBviewer needed changes for DVB playback, but in this case Cyberlink provides expected results and works fine since years with DVB :)

[BetaBoy]

similar problems here..... is it just me--new CoreAVCs seem like chewin'gum?! MeGUI/AVS/CoreAVC used to work properly... now either avScript error:directshowsource: renderfile, filter graphmanager won'talk to me OR sometimes work--but load script video preview not only colour is red and footage is upside down {like this one i downloaded:http://d01.megashares.com/?d01=ZW6IYZQ[/EMAIL] (http://d01.megashares.com/?d01=ZW6IYZQ)}

ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

[TOM_SK]

ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

rofl, busted!

[somms]

Any idea when 3.0.2 will be out for beta testing!?

I haven't had any luck w/3.0,3.01 as both caused major slowdowns with my HTPC where the audio/video would get out of synch...ended up falling back to old reliable 2.5.5...

[STaRGaZeR]

ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

I'm sure you know it already, but pirated copies of CoreAVC 3.0 can be used just fine without any of those symptoms.

[Romario]

@ BetaBoy

I don't want to offend you or your company, but I must say something. It's obvious that, in recent time, CoreCodec developers can't made stable version of CoreAVC ! Even when 2.50 was released, a year or more ago, it wasn't stable. What's going on with you, people ?

Look FFDSHOW devs, they have excellent programers and FFDSHOW never have any problems in video or audio decoding.

[G_M_C]

@ BetaBoy

I don't want to offend you or your company, but I must say something. It's obvious that, in recent time, CoreCodec developers can't made stable version of CoreAVC ! Even when 2.50 was released, a year or more ago, it wasn't stable. What's going on with you, people ?

Look FFDSHOW devs, they have excellent programers and FFDSHOW never have any problems in video or audio decoding.

ffdshow DOES have problems (so does the underlaying ffmpeg), but bugs get squatted faster. I think that is because there are more programmers (i.e. volunteers, cause open source work is like voluntary work) to work on the project. ffdshow is also constantly improved upon, creating new problems. Thats why it's in, some might say, a permenent beta-status.

[eddman]

@ BetaBoy

I don't want to offend you or your company, but I must say something. It's obvious that, in recent time, CoreCodec developers can't made stable version of CoreAVC ! Even when 2.50 was released, a year or more ago, it wasn't stable. What's going on with you, people ?

Look FFDSHOW devs, they have excellent programers and FFDSHOW never have any problems in video or audio decoding.

Are you saying those based on personal experience or just by reading this thread? 2.5.5 is a pretty stable release.

I agree, they abandoned 2.0 for more than a year without releasing a single bux-fix revision, but after 2.5 they magically became super fast for some reason. Just look how fast they are fixing 2.6 and 3.0.

[DeadlyEmbrace]

Having problems when using CoreAVC with DXVA decoding enabled. (It works fine in software only mode)
It has blocks at the bottom, stalls and if you wait long enough creates tearing of the whole image. This error doesn't happen when using MPC-HC built in DXVA decoder or FFDShow DXVA decoder.

CPU: AMD Turion X2 Dual Core Mobile RM-70 2Ghz
GPU: ATI Mobility Radeon HD 3650 (Catalyst 11.8)
RAM: 4Gb

MPC-HC 1.5.3.3704
Haali Media Splitter 1.11.288.0
EVR CS
CoreAVC 3.0.1 or 2.6.2

http://i1091.photobucket.com/albums/i396/CuteD34th/Bug-Report%20images/Image1.jpg
Blocking at bottom of image

http://i1091.photobucket.com/albums/i396/CuteD34th/Bug-Report%20images/Image2.jpg
Tearing of image

[shon3i]

Simmilar behavior on my laptop which has Intel GMA 4500 MHD. Win 7 x64, lastest drivers, CoreAVC 3.0.1, DXVA mode

http://img846.imageshack.us/img846/3651/50201m2tssnapshot004141.th.jpg (http://img846.imageshack.us/i/50201m2tssnapshot004141.jpg/)

in software mode everything is great.

[Portioli]

can anybody send which are the Optimal settings for h264 interlaced material using CoreAVC [DXVA enabled]?

CoreAVC Deinterlacing : None (wave) - Single Field - Bob - Hardware [Aggressive: checked or unchecked] ?

In CCC what i choose ?
Basic Video Quality : Use Automatic or Manual Deinterlacing? If manual what option?
Everything is disabled in advanced quality.


thanks in Advance

[Romario]

Are you saying those based on personal experience or just by reading this thread? 2.5.5 is a pretty stable release.

No, no, I said 2.50, not 2.5.5. CoreAVC IS stable, 2.50 NOT.

So, I urge CoreAVC devs to speed-up development, please. It's shame that every time when you, guys, have something new and fresh ( CoreAVC 3.0 and 3.01 ) it doesn't work well in DXVA mode so well, with lot of bugs.

I again repeat, BetaBoy, I don't want to insult nobody. I am just honest.

[squid_80]

So, I urge CoreAVC devs to speed-up development, please. Version 2.x has had 3 releases in the past week alone and you're complaining development is not happening fast enough?
If you have specific problems that you want fixed, make clear and concise bug reports that will allow it to be easily reproduced (instead of just yelling "it doesn't work!").

[BetaBoy]

I again repeat, BetaBoy, I don't want to insult nobody. I am just honest.
None taken... but like squid_80 said... if you have a report to pass along please try and be as specific as you can on the issue. This helps us first to duplicate the problem and track down the issue.

As far as DXVA... there was alot going on for along time.... I am sure with everyone's help we will track down the remaining issues, but in one weeks time we pretty much squashed most of the major bugs.

So... with that. ATM we are pushing back the new 3.0.x release a day or so as we wanted to address peoples concerns of Hi10p speed. So with the next release you will see a marked improvement in speed there, especially with color adjustment enabled... and by marked I mean some will see as much as a 35-48% gain (in regards to blitting... not overall speed).

[molitar]

Can not play file at all with CoreAVC. Even tried turning off acceleration and CoreAVC 2.62 locks up mpc-home completely. Proper bug report format...

1. Playing file using CoreAVC locks up mpc-home
2. OS - Windows 7 32bit
3. CPU - AMD Phenom 955 Quad Core
4. GPU - Radeon HD 5750
5. Video Driver version - ATI Catalyst 11.6
6. Player - MPC-HC 1.5.2.2368
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 2.6.2
10. Output - unknown
11. Acceleration - DXVA
12. Does not matter if I use DXVA acceleration or no acceleration it still will not play the file.

General
Unique ID : 178621245569138099216868139571076912728 (0x866133578AC06EEF88123C7B23BFD658)
Complete name : D:\01 Incomplete\Itsuka Tenma no Kuro Usagi 08+\Itsuka Tenma no Kuro Usagi - 01 [WhyNot].mkv
Format : Matroska
Format version : Version 2
File size : 517 MiB
Duration : 25mn 0s
Overall bit rate : 2 889 Kbps
Encoded date : UTC 2011-07-11 08:32:15
Writing application : mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58
Writing library : libebml v1.2.0 + libmatroska v1.1.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 25mn 0s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 116 r2019 9cc407d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.50:0.20 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-5 / threads=24 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=19.0 / qcomp=0.70 / qpmin=10 / qpmax=31 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:0.70
Language : Japanese

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : A_AAC
Duration : 25mn 0s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 96.0 KHz / 48.0 KHz
Compression mode : Lossy
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Language : English

Menu
00:00:00.000 : :Intro
00:02:31.960 : :Part A
00:12:31.930 : :Part B
00:24:19.930 : :Preview

[squid_80]

What does "locks up" mean? It becomes non-responsive and has to be killed with task manager? Or it just doesn't play? Or it crashes with an error dialog?
Also please PM your registration info to either BetaBoy or myself.

[molitar]

What does "locks up" mean? It becomes non-responsive and has to be killed with task manager? Or it just doesn't play? Or it crashes with an error dialog?
Also please PM your registration info to either BetaBoy or myself.

Locks up as everything stops responding in Windows 7 and Windows 7 turns that ghosted white color.. I have to end task to kill the process so I can use windows again.

Windows Application log.

Faulting application name: mpc-hc.exe, version: 1.5.2.3268, time stamp: 0x4e070934
Faulting module name: mpc-hc.exe, version: 1.5.2.3268, time stamp: 0x4e070934
Exception code: 0xc0000005
Fault offset: 0x000729e5
Faulting process id: 0xf40
Faulting application start time: 0x01cc704601e208c8
Faulting application path: C:\Program Files\Combined Community Codec Pack\MPC\mpc-hc.exe
Faulting module path: C:\Program Files\Combined Community Codec Pack\MPC\mpc-hc.exe
Report Id: 421a87dd-dc39-11e0-9903-6c626d7151e7

[wanezhiling]

http://www.gokuai.com/f/4181C9d8cXt3H69C

Turn dxva or cuda on and try this sample, please.

[blubberbirne]

Its part of GraphStudio (http://blog.monogram.sk/janos/tools/monogram-graphstudio/)

lol i used graphstudio since years, but i never recognised this feature :thanks:

[Stormbreaker]

After buying today CoreAVC 3.0.1, I experienced a disappointment. For the first version of all, when having checked DXVA the icon for me as a ATi user turns red.

The picture stays black and - if at all anything - diplays garbage.
Mobillity Radeon HD3470
Mobillity modded 11.6 driver

:mad:

Furthermore, still high end videos are being desynced. Also I wonder, though it doesn't work why not always the icon turns red though I've checked DXVA in the options.

:mad:

[BetaBoy]

Strormbreaker... welcome to Doom9.

To better help us help you, please fill in the blanks below:

1. The picture stays black and - if at all anything - diplays garbage. high end videos are being desynced. Also I wonder, though it doesn't work why not always the icon turns red though I've checked DXVA in the options.
2. OS -
3. CPU -
4. GPU - Mobillity Radeon HD3470
5. Video Driver version - Mobillity modded 11.6 driver
6. Player -
7. Renderer -
8. Splitter -
9. Codec -
10. Output -
11. Acceleration - DXVA
12. Other specific things that might help -


Also a sample file might help (if possible).... also define 'High End' videos for us please... and be specific on what features the content was encoded with.

[molitar]

I am awaiting some feedback on my bug. I pm my registration and serial number to squid_80 as I was asked to. Any idea why Corecodec is not working for me at all?

[squid_80]

If I find something I will let you know, but at this point it seems to be a unique issue.

[molitar]

If I find something I will let you know, but at this point it seems to be a unique issue.

Ok thanks for the update squid_80

[BetaBoy]

Those people experiencing issues with ZoomPlayer are urged to upgrade to the latest version v8.0 RC3 as we have a report it fixes the current issues. We are still working with Blight on the other reports.

[nars]

I'm having a weird problem with 2.6.x and 3.0.x versions... with DVB-T streams on DVBViewer (I think also with mpc but I didn't tested it properly yet), while playing I do notice that "timing" doesn't seem "linear"... not sure how can I explain it exactly... imagine a movie film "rotating" at non linear speed, sometimes slower, sometimes faster than normal... it's not a "look and notice it" thing, but after watching for a few minutes we notice it on people motion (suddenly almost running instead of walking...), etc... I did downgraded to 2.5.5 (a few times) and I can't see such problem anymore... I did tried it with every minor version and got same problem with all versions greater than 2.5.5... I did even tried to change some options at codec properties to check if it could help but it doesn't... I did always ended downgrading to 2.5.5 and for sure no problem with this version.

more details:
- noticing it with 576i dvb-t streams
- not using dxva (you know I can't use it on dvbviewer)
- cpu is not overloaded while playing... cpu usage 14% to 20%
- graphics card: ati hd6570
- windows xp sp3

anyone else noticing similar problem? am I becoming mad? :)

maybe related to the increased buffers? do all versions have them?

[mdlenoir]

I have questions. CoreAVC 2.5.5 is fine when playing h264 files before, very low cpu rate. But there exists some problems after i update to 2.6.x or 3.0.1. Is it normal？

Here is a sample：http://wjy.xunlei.com/d/NKPEULZOBETR

2.5.5：lots of Mosaics
2.6.x：still a little
3.0.1：no Mosaics, but very high CPU rate (40~60%)

Intel E8400 3.0G
nVidia GTX260+ (Driver 280.26 WHQL, )
Windows 7 x64
MPC-HC 1.5.3.3720 （EVR custom）
Haali Media Splitter （1.11.96.14）
CoreAVC （CUDA）

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I find high rate cpu problem, CoreAVC doesn't use CUDA acceleration. I don't know why. My setting is ok, cause when I playing other files, the icon shows CUDA mode on and the cpu rate is normal (7~10%). But this file, is it fake? No...... what's the problem?

[nussman]

@nars: Could you upload a testfile?

[CiNcH]

@ nars,

I have experienced the same problem. That is why I said that CoreAVC still does not function perfectly together with the DVBSource filter. It is as if timestamps jitter a lot at the renderer. Jitter grows with time until the renderer has to start dropping frames.

Also in my case, the DVBSource filter sometimes performs a graph stop/run due to a buffer overflow. Seems that CoreAVC is processing slower than data is coming in. Not good since we can't vary the DVB stream speed. The DVBSource uses the stream PTS for timing.

[squid_80]

I find high rate cpu problem, CoreAVC doesn't use CUDA acceleration. I don't know why. My setting is ok, cause when I playing other files, the icon shows CUDA mode on and the cpu rate is normal (7~10%). But this file, is it fake? No...... what's the problem?
It's a 10-bit H264 stream, which requires CoreAVC 3.x (and more CPU power than normal files) and isn't compatible with hardware decoding.

[squid_80]

Also in my case, the DVBSource filter sometimes performs a graph stop/run due to a buffer overflow. Seems that CoreAVC is processing slower than data is coming in. Not good since we can't vary the DVB stream speed. So the DVBSource has to use the stream PTS for timing.

This actually sounds exactly like a DTS vs. PTS problem.

[CiNcH]

This actually sounds exactly like a DTS vs. PTS problem.
Can you get into detail? I am not much into this stuff as I am not developing the DVBSource. But I can forward the information.

[squid_80]

I'd need a sample first to make sure I'm not just guessing.

[mdlenoir]

It's a 10-bit H264 stream, which requires CoreAVC 3.x (and more CPU power than normal files) and isn't compatible with hardware decoding.

So 10-bit files can't be hardware decoded right now？sad...
Hope you genius make it better, cheers....:thanks:

[CiNcH]

I'd need a sample first to make sure I'm not just guessing.
I guess that it is related to the jitter/timestamp issue. I will have to verify it with files first.

[JEEB]

So 10-bit files can't be hardware decoded right now？sad...
Hope you genius make it better, cheers....:thanks:
TL;DR You'll get your support as soon as someone makes the hardware capable of hi10p, and as soon as that can be accessed via some API (be it CUVID, DXVA or whatever). Just don't expect it to be a priority for any company doing user-level hardware.

(the only reason user-level hardware got normal high profile support was the fact that Blu-ray and DTV can use it, hi10p is only used in professional areas [as well as in personal encodes of people lately], so there's no pressing reason for companies to actually add hi10p support onto their hardware :P )

[mdlenoir]

we can hope, we can wait, everything will be fine... somebody gives me a time machine...╮(￣▽￣")╭

[hardkorn]

Has anyone having problems with CoreAvc 3.0.1 in flipping the video? It happens with kmplayer, potplayer, MPC-HomeCinema with video processing disabled. I don't like their internal decoding. If I enable video processing and flip the picture (there's an option in those players) it shows the picture as it should, but eats a lot of memory, almost to a halt.


Also, I can only choose RGB15 AND RGB16 in CoreAvc. All other output formats turn the picture red.

Any thoughts?

[Mixer73]

Has anyone having problems with CoreAvc 3.0.1 in flipping the video? It happens with kmplayer, potplayer, MPC-HomeCinema with video processing disabled. I don't like their internal decoding. If I enable video processing and flip the picture (there's an option in those players) it shows the picture as it should, but eats a lot of memory, almost to a halt.

https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

[Romario]

BetaBoy, I have one little feature request for future release, for example 3.03 or 3.1. I used ffdshow debug decoder lot of years until now, and I love FFDSHOW because he have verz nice debug decoder. Can you, please, at least consider something similiar which FFDSHOW have ?

I mean specificaly on debug decoder (information about codec, audio bitrate and video bitrate during playing )

[CiNcH]

@ squid_80,

I also verified the high jitter with file playback via DVBSource. It only seems to happen with interlaced content though. 1080p24 (m2ts from a Blu-Ray) and 720p50 (either live or file) are both fine.

I think that you already have some 1080i TS samples to test this with? I used the EVR Custom Presenter within the DVBViewer which currently times samples only according to their timestamps. So IMHO the timestamps from the decoder or mixer jitter a lot.

CoreAVC 2.6.2 settings: SW mode, NV12, hardware deinterlacing

I did not try 1080i with other splitters yet. Maybe the problem is present there too.

[clsid]

Have all HMS regressions been fixed?
Why isn't Haali site updated yet?

[BetaBoy]

Have all HMS regressions been fixed?
Why isn't Haali site updated yet?
No, only some of the more immediate issues were fixed and we added support for MVC in preparation for releasing CoreMVC.

Haali not updating the site is mostly attributed to IBC and his lack of time from the day job atm. This is why we updated the splitter and released it in CoreAVC and for download on our site.

[nars]

I made a mistake in my previous post... I'm getting the problem with 576i (not 576p), post edited... I can post some samples later if you are interested, need to find some images where it can be really easy to notice.

CiNcH: did you tested if you notice similar jitter with 2.5.5? Because apparently I don't see the problem (if it's really the same thing) with that version and previous ones... also just for curiosity do you do you have an ati or nvidia?

[CiNcH]

I made a mistake in my previous post... I'm getting the problem with 576i (not 576p)
I actually thought so. Never seen 576p for DVB.

CiNcH: did you tested if you notice similar jitter with 2.5.5?
I didn't as 2.5.5 does not perform proper hardware deinterlacing with most splitters anyway.

also just for curiosity do you do you have an ati or nvidia?
AMD Radeon HD 6570. But it shouldn't really matter IMHO.

[Livias]

I registered this forum, specifically to offer feedback using 3.0.1 on my run of the mill netbook. I bought CoreAVC specifically for 10-bit H264 stream 720p playback on my netbook, and while the performance is descent, it is not stellar. When there is a lot going on in a scene, sometimes coreAvc skipsframes. CoreAVC needs to be faster, have more software optimizations for underpowered hardware especially netbooks users, which I assume are a significant percent of CoreAVC users.

[clsid]

No, only some of the more immediate issues were fixed and we added support for MVC in preparation for releasing CoreMVC.

Haali not updating the site is mostly attributed to IBC and his lack of time from the day job atm. This is why we updated the splitter and released it in CoreAVC and for download on our site.Just to be clear, I was talking about regressions in the new version compared to the 03/03/2011 version.
The MP4 issues were fixed, right? What other regressions are left, if any?

Can you post a link to the latest version?

[squid_80]

Just to be clear, I was talking about regressions in the new version compared to the 03/03/2011 version.
The MP4 issues were fixed, right? What other regressions are left, if any?

Can you post a link to the latest version?

https://customers.corecodec.com/downloads.php

[BetaBoy]

We are planning to do a release this week... Likely sooner then later but we are holding off on features like deblocking for our ASM, more 10bit optimizations, etc. for the followup release (v3.1).

[RoadPizza]

Like several others, I've lurked for quite some time here, and joined just to post my question. It is not a bug report per se, but I will try to stick to the proper format anyway:

1. CoreAVC runs faster/better for me without CUDA enabled
2. OS - Windows XP SP3
3. CPU - Core 2 Quad Q9650
4. GPU - GeForce GTS 450
5. Video Driver version - 6.14.12.8026
6. Player - MPC-HC v1.5.2.3456
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.288.0
9. Codec - CoreAVC all versions from 2.5 up
10. Output - ?
11. Acceleration - CUDA or none

On a whim I downloaded the clip from post #6809. I noticed that there were a couple of freezes & skips when playing the file with CUDA enabled. Not a big deal, but less than perfect. When I tried it with CUDA disabled, it played fine. So I tested some other clips and other versions of CoreAVC and discovered that on my system every clip I tried actually plays better with CUDA off. I've always just assumed that hardware is better that software when it comes to decoding, but for me it seems to be not true.

What I'd like to know is if this is normal behavior given my system, or if I may have a problem somewhere in my setup. Thanks for any answers!

[D.A.S.]

1. Wrong aspect ratio (black bars appear)
2. OS - Windows 7 SP1 32bit
3. CPU - AMD Phenom II X4 940
4. GPU - Radeon HD 5670
5. Video Driver version - 11.8
6. Player - MPC-HC v1.5.3.3731
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 3.0.1
10. Output - NV12
11. Acceleration - DXVA on 8-bit, 10-bit DXVA is not working


8-bit 1080p Print Screen, If use Alt+I screenshot normal
http://img703.imageshack.us/img703/2987/coreavc391printscreen8b.th.png (http://img703.imageshack.us/img703/2987/coreavc391printscreen8b.png)

10-bit 1080p Print Screen
http://img638.imageshack.us/img638/599/coreavc391printscreen10.th.png (http://img638.imageshack.us/img638/599/coreavc391printscreen10.png)

Alt+I
http://img215.imageshack.us/img215/2475/coreavc391alti10bit.th.png (http://img215.imageshack.us/img215/2475/coreavc391alti10bit.png)

If use Ffdshow/Lav all is well.

[squid_80]

I've always just assumed that hardware is better that software when it comes to decoding, but for me it seems to be not true.

Unless you've got an underpowered system (below a core2) software decoding will nearly always outperform hardware. GPU decoding is typically optimized for playing (in real-time, not as fast as possible) streams that match run of the mill blu-ray specs, not high performance.

[eddman]

Unless you've got an underpowered system (below a core2) software decoding will nearly always outperform hardware. GPU decoding is typically optimized for playing (in real-time, not as fast as possible) streams that match run of the mill blu-ray specs, not high performance.

Yes, If you have a strong enough CPU there isn't really much of a reason to use hardware decoding. Software decoding is faster in most cases and there'll be far less compatibility problems with non-standard videos compared to hardware.
For me these are the main usage scenarios for hardware decoding:

1. The CPU is weak and unable to play HD h.264 videos.
2. The CPU is strong but you want to reduce its utilization and use it for some other task while watching a video.

[whiskey]

Any ideas why with version 3.0.1.0 all my vids in MPC are upside down and have no color ? No clue how to fix this maybe somebody had similar issue ?

[squid_80]

Aye matey! Seems the booty you've been plundering was booby trapped! (https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html)

(Happy International Talk Like A Pirate Day, for those unaware. Note however that your pirate impersonations shouldn't include actual stealing.)

[whiskey]

Aye matey! Seems the booty you've been plundering was booby trapped! (https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html)

(Happy International Talk Like A Pirate Day, for those unaware. Note however that your pirate impersonations shouldn't include actual stealing.)


Hmm Now I see I thought there had like 2 versions paid and free one I get it now

[Gav80K]

I'm also experiencing a noticeable performance drop with CUDA acceleration since I upgraded to 3.0.1 and it's now faster with GPU acceleration disabled. My observations are based on the fact that I make regular use of the skip 5 seconds feature in MPC-HT. When you skip it presumably has to decode the video from the last key frame to the point you skip to, making it quite computationally intensive. With version 2.5.1 the skip used to occur pretty much instantly, but in 3.0.1 there is a long delay of 1-2 seconds before the video resumes play. Even with low bitrate 720p it's painfully slow so I went back to 2.5.1 and it's back to it's normal speed.

GPU decoding is typically optimized for playing (in real-time, not as fast as possible) streams that match run of the mill blu-ray specs, not high performance.

That may be so, but there's still no reason for it to be substantially slower than 2.x. The main reason I use CoreAVC is so I can employ a low power CPU, and therefore have an entirely passively cooled media PC. I don't want to have to use a CPU that requires fan cooling, though with the lack of Hi10P CUDA acceleration and the slow CUDA performance in general it looks like I no longer have a choice.

I'll have to get a more powerful processor and was considering these (mostly because they're the fastest 2 and 4 core CPUs with a 65W TDP):

Intel Core i7 2600S with 4 HT cores at 2.8GHz (http://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-%288M-Cache-2_80-GHz%29)
Intel Core i3 2125 with 2 HT cores at 3.3GHz (http://ark.intel.com/products/59080/Intel-Core-i3-2125-Processor-%283M-Cache-3_30-GHz%29)

I was wondering effectively CoreeAVC makes use of multiple cores. Is it better to have four cores or two cores with a higher clock speed?

What about FFDShow (which I use as a backup); does that take full advantage of multi-core processors?

Thanks for your advice.

[squid_80]

I'm also experiencing a noticeable performance drop with CUDA acceleration since I upgraded to 3.0.1 and it's now faster with GPU acceleration disabled. My observations are based on the fact that I make regular use of the skip 5 seconds feature in MPC-HT. When you skip it presumably has to decode the video from the last key frame to the point you skip to, making it quite computationally intensive. With version 2.5.1 the skip used to occur pretty much instantly, but in 3.0.1 there is a long delay of 1-2 seconds before the video resumes play. Even with low bitrate 720p it's painfully slow so I went back to 2.5.1 and it's back to it's normal speed.


That may be so, but there's still no reason for it to be substantially slower than 2.x. The main reason I use CoreAVC is so I can employ a low power CPU, and therefore have an entirely passively cooled media PC. I don't want to have to use a CPU that requires fan cooling, though with the lack of Hi10P CUDA acceleration and the slow CUDA performance in general it looks like I no longer have a choice.

As evidenced by the changelog, there haven't been any changes to the CUDA decoding since 2.5.0 so I can't explain these slowdowns you're seeing.

[nm]

I'll have to get a more powerful processor and was considering these (mostly because they're the fastest 2 and 4 core CPUs with a 65W TDP):

Intel Core i7 2600S with 4 HT cores at 2.8GHz (http://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-%288M-Cache-2_80-GHz%29)
Intel Core i3 2125 with 2 HT cores at 3.3GHz (http://ark.intel.com/products/59080/Intel-Core-i3-2125-Processor-%283M-Cache-3_30-GHz%29)

I was wondering effectively CoreeAVC makes use of multiple cores. Is it better to have four cores or two cores with a higher clock speed?

That 4-core i7 is much faster with both CoreAVC and current libavcodec (in ffsdshow-tryouts etc.).

[Gav80K]

That 4-core i7 is much faster with both CoreAVC and current libavcodec (in ffsdshow-tryouts etc.).

Thanks for the advice. I'll go for that.


As evidenced by the changelog, there haven't been any changes to the CUDA decoding since 2.5.0 so I can't explain these slowdowns you're seeing.

When I noticed the long delay that occurred when skipping in 3.0.1 I tried putting it on my desktop PC (which is probably a violation of the licence agreement) and found the same slow performance with CUDA on that, so there definitely seems to be an issue. I seem to recall that I had to uninstall everything (CoreAVC 3.0.1, Haaali Media Splitter and CCCP) before putting CoreAVC 2.5.1 to get the old performance back so maybe the issue is with Haaali Media Splitter or some other external component.

From what you said in an earlier posts it sounds like software decoding is better anyway so I'll just get a new PC.

[eddman]

I'll have to get a more powerful processor and was considering these (mostly because they're the fastest 2 and 4 core CPUs with a 65W TDP):

Intel Core i7 2600S with 4 HT cores at 2.8GHz (http://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-%288M-Cache-2_80-GHz%29)
Intel Core i3 2125 with 2 HT cores at 3.3GHz (http://ark.intel.com/products/59080/Intel-Core-i3-2125-Processor-%283M-Cache-3_30-GHz%29)

I was wondering effectively CoreeAVC makes use of multiple cores. Is it better to have four cores or two cores with a higher clock speed?

You might want to take a look at these too:

Core i5 2390T / 2 cores / 2.7 GHz / 35 W TDP (http://ark.intel.com/products/53448)
Core i5 2500T / 4 cores / 2.3 GHz / 45 W TDP (http://ark.intel.com/products/52212)

I'd say a quad-core with lower clock speed is better than a dual-core with higher clock speed.

[Gav80K]

You might want to take a look at these too:

Core i5 2390T / 2 cores / 2.7 GHz / 35 W TDP (http://ark.intel.com/products/53448)
Core i5 2500T / 4 cores / 2.3 GHz / 45 W TDP (http://ark.intel.com/products/52212)

I'd say a quad-core with lower clock speed is better than a dual-core with higher clock speed.

Thanks for the suggestions, but I'll probably go with the faster Core i7 2600S to try and keep the skip time as short as possible.

I use the Coolermaster Hyper Z600 which can handle up to an 89W CPU with passive cooling so I should be fine with the 65W i7 2600S.

[nm]

Thanks for the suggestions, but I'll probably go with the faster Core i7 2600S to try and keep the skip time as short as possible.

Well, if skipping was instantaneous with CoreAVC 2.5, it started decoding from the nearest or next keyframe instead of the exact requested frame. If your CoreAVC 3.0 setup does skip to non-keyframe positions and therefore does unnecessary work, I'd suggest finding out the source of the problem instead of throwing hardware and money to work around the issue.

[Gav80K]

Well, if skipping was instantaneous with CoreAVC 2.5, it started decoding from the nearest or next keyframe instead of the exact requested frame. If your CoreAVC 3.0 setup does skip to non-keyframe positions and therefore does unnecessary work, I'd suggest finding out the source of the problem instead of throwing hardware and money to work around the issue.

When I said "pretty much instantly" I meant "an insignificant amount of time that caused no distraction". It now takes about four times as long so you're left with a pause that can last as much as two seconds, which is rather irritating. It does definitely decode from the last keyframe with 2.5.1, otherwise the video would have turned into a mess each time I skipped. It's the same on two PCs with significantly different hardware, so there does seem to be an issue with CUDA acceleration.

With no CUDA support for Hi10P I'd have to get a new PC anyway, so it's not really a major issue, but it is strange the performance has dropped so much.

[ajp_anton]

If you feel adventurous, get a "regular" CPU and undervolt it to get the same result as with a more expensive S or T model. Also, you have access to higher performance when seeking (which is so fast your cooling won't be affected).

[cyberbeing]

We are planning to do a release this week.

Is there a tentative changelog for 3.02 at this point?

[RoadPizza]

Thank you for the answers to my question about software vs hardware decoding. I have one other question that I have seen asked several times in this thread, but never answered. What, exactly, does the deblocking option "skip when safe" do? Thanks!

[BetaBoy]

Is there a tentative changelog for 3.02 at this point?

Its a floating target atm as we want to address both the bugs and speed concerns. But we were side tracked a few days as we have been working on the CoreAVC Developer SDK.... which is now updated to 3.0.2.

[nibus]

Does the new CoreAVC 3 decode 10-bit without the change in colors that is/was present in ffdshow? And has anyone really noticed big improvements from 10-bit in general?

[squid_80]

What, exactly, does the deblocking option "skip when safe" do? Thanks!

From the Help page in the filter properties:
Skip when safe - skip deblocking step when decoding B-frames.

[RoadPizza]

From the Help page in the filter properties:

I found that of course. I know I'm a newbie, but give me a little credit for having searched for my answer first :-)

I'm looking for a bit more detail... For example, from post #3890 in this thread:

"Do you mean NAL units designated as disposable (unreferenced B-frames), or do you really mean all B-frames? If the latter, its certainly not safe."

Also, if it really is safe to do this, why isn't it just part of the spec in the first place? Or at least the CoreAVC default? Thanks for any info.

[squid_80]

It means unreferenced B-frames. Skipping deblocking is not part of the spec at all, it degrades the image quality. The term "safe" means the image errors caused by lack of deblocking won't accumulate over time (because they will only apply to individual frames that aren't referenced by others).

[flapane]

With latest version of CoreAVC (2.5.5) on 7 x64 and HD5670, DXVA worked great with MPC-HC, but I couldn't enable it on WinTV live HDTV. The tray icon remains blue and the cpu sits at about 60%.
Furthermore, a guy from the WinTV tech support asked for more informations on CoreAVC API needed to set the GPU acceleration. I suppose that it may help to better understand the problem.
Any hints?
Thanks

Tried 3.0.1, nothing changed. The tray icon is still blue.

[nussman]

Take a look at page 331.
The infos für WinTV tech support could be found there!

[CiNcH]

Guess this is the same problem as with the DVBViewer. CoreAVC requires the splitter to deliver SPS/PPS at connection time. If the splitter does not deliver, CoreAVC falls back to SW mode.

[nussman]

@flapane: Please let us know how WinTV tech support thinks about it!

[CiNcH]

@flapane: Please let us know how WinTV tech support thinks about it!
They won't have any opinion. Believe me ;) . Does WinTV use the MS MPEG-2 demultiplexer?

[flapane]

I think they'd gladly work together with CoreAVC devs in order to solve the issue, otherwise we'll never get HW acceleration: http://www.hauppauge.co.uk/board/showthread.php?22237-CoreAVC-DXVA-support&p=103351#post103351

[CiNcH]

I now tried WatchTVPro. It uses the MPEG-2 Demultiplexer. Most DVB BDA apps do. The result is no DXVA (see here (http://members.inode.at/762450/coreavc/mpeg_demux_coreavc.jpg)). The WinTV guys can't solve this issue. Only if they develop their own splitter which adheres to the CoreAVC rules.

[flapane]

As you can see on Hauppage forum, they sent an e-mail to CoreAVC devs, without luck.

[CiNcH]

CoreCodec is aware of the issue. All you can do is sit back an wait (hope). nussman posted a reference to the discussion with technical background...

[dead_screem]

betaboy, any news on 3.0.2?

[D.A.S.]

1. Not working DXVA
2. OS - Windows 7 SP1 32bit
3. CPU - AMD Phenom II X4 940
4. GPU - Radeon HD 5670
5. Video Driver version - 11.8
6. Player - MPC-HC v1.5.3.3739
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 3.0.1
10. Output - NV12
11. Acceleration - DXVA on.

Sample
http://www.multiupload.com/4RR117CUFZ

Built-in decoder MPC-HC works with DXVA.

If the file is repackage a new version of mkvmerge then DXVA to work on CoreAVC 3.0.1

[kirakami]

when will CoreAVC 3.0.2 release?
will CoreAVC 3.0.1 also work on my old pc's with Nvidia Ge-Force 4 MX440?
what are steps to enable HW acceleration on CoreAVC with MPC-HC?

[BetaBoy]

An update for all... we are taking a little more time in devel and going right to CoreAVC 3.1 and adding more features, speed enhancements then planned. On apps that that do not conform to proper SPS handling... we added a work around for 3.1.

This new work might delay adding 4:4:4 profile support (which is mostly done anyway) but based on the feedback we feel the potential delay is worth it.

[Mangix]

will CoreAVC 3.0.1 also work on my old pc's with Nvidia Ge-Force 4 MX440?

no. cpu decoding still works though.

that card was released in 2003 i think. 8 years wow...

[mkanet]

I just upgraded my display card to a 4th generation Nvidia Purevideo HD card.. GT545. I was told it has the best decoding that Nvidia has to offer.

I am curious which of the following would take advantage of my graphics card's decoding capabilities the best:

1. Windows 7 64bit "DTV-DVD Video Decoder"
2. CoreAVC 3.0.1 Cuda
3. CoreAVC 3.0.1 DXVA


Above, when I mean "best", I mean in respect to bluray spec H.264 decoding.

Shamelessly, I really, REALLY wanted LAV Video decoder to work since it also supports mpeg2/VC1; however, on my machine, it has unacceptable stability issues under my directshow software. CoreAVC, "knock on wood" works no matter settings I choose... just not sure which is ideal for my needs.

[Asmodian]

Well the GT 545 (I have one too) isn't actually any better than any of the rest of the fermi cards, only the GT520 (as far as I know) has Purevideo HD feature set D, the fifth generation of purevideo.

That said, the GT 545 is one of the better cards as the GT520 doesn't have enough cores to do the best deinterlacing.

CoreAVC Cuda is what you want.

[mkanet]

Thanks. I mean the GT 545 was better than generation 3, 2, and 1. I upgraded from an GT8500.

What's the difference between CoreAVC Cuda and the decoder that comes with Win7?

If I want cuda for mpeg2 and VC1, what decoder can I use if LAV Video has stability issues on my system?

EDIT: I just realized, I also have latest version of TMT5 installed on my machine. I already use it's audio decoder. Doesn't it's video decoder already support cuda for all popular video formats? I vaguely remember that TMT started supporting cuda back in version 3.

This may sound like a dumb question, but isn't this the same kind of cuda that's used in CoreAVC and LAV Video?

Well the GT 545 (I have one too) isn't actually any better than any of the rest of the fermi cards, only the GT520 (as far as I know) has Purevideo HD feature set D, the fifth generation of purevideo.

That said, the GT 545 is one of the better cards as the GT520 doesn't have enough cores to do the best deinterlacing.

CoreAVC Cuda is what you want.

[Mixer73]

This may sound like a dumb question, but isn't this the same kind of cuda that's used in CoreAVC and LAV Video?

You're getting confused by the fact that there's a few different paths to the same hardware decoders.

CoreAVC and TMT will use standard DXVA, where you just offload the processing to the hardware and it gets played.

CUDA is a programming interface to use the shaders on your graphics card, but it also allows a function called CUVID which is a way to interface to the DXVA decoding and let you have access to capabilities which are not available through standard DXVA - like subtitles, madVR etc. I think CoreAVC labelling this "CUDA" is a bit of a misnomer.

Now I'm not half as smart as a lot of the guys here but I hope this clears things up for you.

[LigH]

It has been explained and criticized dozens of times already. The hardware accellerated video decoders don't use CUDA to calculate the decoding, they just use it to let the video pass to the PureVideo hardware decoding engine (V2 or newer). "Misnomer" is indeed a matching rating ... "CUDA" sounds so conveniently advertizing; "CUVID" instead is less famous, although more correct.

[SEt]

It does use CUDA, but not for decoding h264/vc1 itself - for reading decoded data from videocard. It's quite expensive process too.

mkanet, it was said many times that all decoders that correctly decode h264 are equal. Zero quality difference, be it hardware or software. Nowadays there is no much reason for caring about hardware decoding (unless your CPU is seriously outdated or you want to save every possible bit of energy or want hardware deinterlacer). As about problems with LAV - they are likely due to something bad installed on your system (hint: codecpacks).

Also even if different codecs use the same DXVA or CUDA decoders - it doesn't mean they work exactly the same. Because there are plenty of places before and after them where mistakes can be made.

[CruNcher]

It has been explained and criticized dozens of times already. The hardware accellerated video decoders don't use CUDA to calculate the decoding, they just use it to let the video pass to the PureVideo hardware decoding engine (V2 or newer). "Misnomer" is indeed a matching rating ... "CUDA" sounds so conveniently advertizing; "CUVID" instead is less famous, although more correct.

Actually for Mpeg-2 Bitstreams it does use CUDA to fix a Hardware issue in VP2 upto VP4 ;)

Also even if different codecs use the same DXVA or CUDA decoders - it doesn't mean they work exactly the same. Because there are plenty of places before and after them where mistakes can be made.

Yep true true even DXVA decoder can differ greatly especially in efficiency and bugs i remember the 60 fps playback problem on my VP2 that only Cyberlink was able to cope with on VMR9 compared to all the other DXVA implementations (which was really unique) :P
And imho it is still the most efficient DXVA implementation for both NT 5/6 and GPUs compared to others, though it also has it's drawbacks with some not so widespread bitstreams that other implementation again do better with :)

[jmelan]

any update on a release date for coreMVC?

[cyberbeing]

Progress report on CoreAVC 3.1 as well?

[CiNcH]

"QA" must be hard at work...

[BetaBoy]

We finished our current todo for our 3.1 core work. We have added 4:4:4 profile support and fixed most of the reported bugs as well as added a bunch of 10 bit optimizations.

We still have some directshow work to do, so let's see how the next week work goes.

[BetaBoy]

any update on a release date for coreMVC?

With the recent microsoft additions to MVC in directshow/windows 7. We will release a consumer decoder after we add those additions. Also we wanted to wait till we added 4:4:4 support which is now done. So likely sometime at or around CES.

Note that the CoreMVC Library SDK (non-directshow) has aleady been released for Developer / OEM integration and is being used for consumer 3D applications.

[robpdotcom]

Any news on getting a fix for the Haali/TrueHD issue?

[Livias]

@BetaBoy, are you talking about CES as in next January?

[Mitchan81]

I recently purchased CoreAVC 3.0.1 for use DXVA with my Intel G45 GPU - X4500HD

Now I was looking to buy an NVIDIA card (Intel have 23.976hz playback issue) but I did not understand about what parameters should I look to use all features of CoreAVC's CUDA decode? ram? gpu clock? number of cuda core? VPA3-4-5? etc etc

which card should I buy?

[LoRd_MuldeR]

I recently purchased CoreAVC 3.0.1 for use DXVA with my Intel G45 GPU - X4500HD

Now I was looking to buy an NVIDIA card (Intel have 23.976hz playback issue) but I did not understand about what parameters should I look to use all features of CoreAVC's CUDA decode? ram? gpu clock? number of cuda core? VPA3-4-5? etc etc

which card should I buy?

Shouldn't matter, because DXVA as well as "CUDA acceleration" (actually CUVID) doesn't use the GPU at all!

DXVA and CUVID are just two different API's to access the card's built-in "video engine" (called "PureVideo" in NVidia jargon). But these are separate/dedicated circuits, not the actual GPU!

And, most important, the video engine is pretty much identical between "low end", "performance" and "high end" cards.

(Just be sure you buy a card that has the latest incarnation of the "PureVideo" engine on board. The latest version currently is VP5. Funny enough, the "high end" cards still use VP4)

[Mitchan81]

(Just be sure you buy a card that has the latest incarnation of the "PureVideo" engine on board. The latest version currently is VP5. Funny enough, the "high end" cards still use VP4)

Exact!!! The only one with VP5 is GT520 (64bit bus, 1gb ddr3)
So... you're telling me that gt520 is faster then gtx590 (384bit x 2 bus, 3072 MB ram etc etc) with CorAVC - CUDA acceleration (PureVideo HD) ?

[nm]

GT 520 decodes faster (H.264 video at 120 fps instead of 60 fps), but if you also want to postprocess (deinterlace, denoise, ...) HD video on the GPU, then the other parameters such as the number of CUDA cores do matter. GT 520 may not be fast enough when using multiple filters at the same time -- it can barely manage the "temporal-spatial" deinterlacing mode for 1080i30.

[nevcairiel]

I would not buy the 520, its too slow. Go with a 430 or 440, or if you want some more, a 450 or 550.

[Mitchan81]

I would not buy the 520, its too slow.

slow for what? LAV CUVID or madVR?


if you want some more

yes.. but more WHAT??? :D

I need only HTPC video card. No games.

thx for your support ;)

[nevcairiel]

The 520 is too slow for anything. It can't even properly do full quality deinterlacing, be it with EVR or anything else.

[eddman]

I recently purchased CoreAVC 3.0.1 for use DXVA with my Intel G45 GPU - X4500HD

Now I was looking to buy an NVIDIA card (Intel have 23.976hz playback issue) but I did not understand about what parameters should I look to use all features of CoreAVC's CUDA decode? ram? gpu clock? number of cuda core? VPA3-4-5? etc etc

which card should I buy?

Here, read up and decide.

http://www.anandtech.com/show/4380/discrete-htpc-gpus-shootout/1

[rica]

Hi guys!

I just purchased CoreAVC to test its mvc deoding capability.
Can somebody guide me how it is possible on GraphStudio?

Which splitter, which renderer?

Thanks.


_ _ _ _

[LoRd_MuldeR]

I just purchased CoreAVC to test its mvc deoding capability.

Aren't CoreAVC and CoreMVC two different products, with the latter still to be released (as a standalone product)? :confused:

http://forum.doom9.org/showpost.php?p=1535817&postcount=6889

[rica]

Aren't CoreAVC and CoreMVC two different products, with the latter still to be released (as a standalone product)? :confused:

http://forum.doom9.org/showpost.php?p=1535817&postcount=6889

Please checkout changelog:

http://corecodec.com/products/coreavc/changelog

- ADD: Support for MVC 3D videos

[Keiyakusha]

Please checkout changelog:

http://corecodec.com/products/coreavc/changelog

I only see "SDK: Initial support for MVC (CoreMVC) integration" which means you're not getting MVC in CoreAVC.
"ADD" is just for haali splitter. So after all you can't watch MVC with CoreAVC

[LoRd_MuldeR]

I only see "SDK: Initial support for MVC (CoreMVC) integration"

Yup. It means that they have added MVC support to their SDK (Software Development Kit), which other companies can license for their own products.

Still "CoreAVC" and "CoreMVC" are two separate stand-alone products. And only the latter will support MVC.

Also the MVC support that has been added to Haali's Splitter means that you will be able to use Haali's Splitter in conjunction with CoreMVC, once the latter is released. Nothing more.

(Please correct me if I'm wrong...)

[rica]

I only see "SDK: Initial support for MVC (CoreMVC) integration" which means you're not getting MVC in CoreAVC.
"ADD" is just for haali splitter. So after all you can't watch MVC with CoreAVC

I understand with "add", you can watch MVC with Haali?

[Keiyakusha]

I understand with "add", you can watch MVC with Haali?
Well in theory yes, but of course if you also have MVC decoder that can work with it. I don't have such decoders so have no idea if haali really works as advertised.
EDIT: oh, BTW, I was just told that MVC stream is backward compatible with AVC so someone probably tried that already and can tell better if haali really works

[rica]

Then i spend money for nothing.

[madshi]

Well, I think it was pretty clear that CoreMVC would be a separate product. You gotta inform yourself before making a purchase... ;)

[rica]

Well, I think it was pretty clear that CoreMVC would be a separate product. You gotta inform yourself before making a purchase... ;)

I'm lucky; at least the cost of purchasing unless informed was just 12 USD :o

[BetaBoy]

Rica... PM me ill issue you a refund.

As stated CoreMVC is a separate product, but at its core it uses CoreAVC. Technically we already addd support for Haali's splitter for MVC streams with the 3.0 release but we are adding support for the MS directshow MVC spec before we release CoreMVC.

[rica]

Rica... PM me ill issue you a refund.

As stated CoreMVC is a separate product, but at its core it uses CoreAVC. Technically we already addd support for Haali's splitter for MVC streams with the 3.0 release but we are adding support for the MS directshow MVC spec before we release CoreMVC.

Thanks a lot betaboy but this is my fault and i don't need any refund. And i'm happy with my new toy :)

But i wouldn't object to any discount ticket when you released Core MVC :)

[n3w813]

The 520 is too slow for anything. It can't even properly do full quality deinterlacing, be it with EVR or anything else.

I have a GT520 and it can decode 1080p60 Blurays without issues with Lav Video w/CUVID and MadVR. :) I've never tried interlaced content though. :p

[Thunderbolt8]

how many 1080p60 BDs are actually out there?

[nevcairiel]

how many 1080p60 BDs are actually out there?

None, its not a valid format for Blu-ray.
You can get 1080i60 or 720p60, but not 1080p60.

[kirakami]

i have CoreAVC 3.0.1 installed
Can CoreAVC alone Output P010 without using madVR??? have anyone tried.
i m using MPC-HC.

[XRyche]

i have CoreAVC 3.0.1 installed
Can CoreAVC alone Output P010 without using madVR??? have anyone tried.
i m using MPC-HC.

CoreAVC 3.01 can handle P010 but......MadVR is the only renderer that can output P010 atm. If you use haali, any flavor EVR, Overlay, any flavor VMR, etc.... it outputs in 8 bit format. To my understanding (which admittedly is very limited) it all gets displayed on your monitor as 8 bit anyways (dithered or not). I could be wrong though so if someone more knowledgeable could set me straight I'd appreciate it.
Oh MPC-HC tester builds for internal renderer fixes http://forum.doom9.org/showthread.php?t=161047
can surface display 32 bit but it uses shaders to do this and can be very unstable. That said, personally I like it.

[sneaker_ger]

MadVR is the only renderer that can output P010 atm.

IIRC, though madVR accepts P010 input, it can not output 10 bit.

[XRyche]

IIRC, though madVR accepts P010 input, it can not output 10 bit.

It does output 10 bit on the surface but your monitor can't.

[sneaker_ger]

Those are only for its internal processing, I think. Final output is always dithered down to 8 bit max.

[pankov]

It does output 10 bit on the surface but your monitor can't.
I think you are wrong.
madVR always outputs 8bit. When it get's 10bit input it dithers it down to 8bit

[madshi]

AFAIK madVR is the only renderer which *accepts* P010 (unless JanWillems has changed VMR/EVR accordingly). The whole madVR processing chain is 16bit+, so full use of P010 is made. However, final output is currently always dithered down to 8bit, but the dithering makes sure that most of the high bitdepth information is still intact, so the 8bit output is not really a problem. 10bit output is eventually planned for a future version. FWIW, the best solution for image quality is to have the dithering done as the last step in the processing chain. So having madVR do it is better than to have CoreAVC do it.

[SEt]

CoreAVC works just fine with P010 and P016 without MadVR - for example with my renderer (it's private one). So, I think there is no problems in CoreAVC's implementation if that is what you are concerned about.
But if you want P010 for "higher quality" with MPC-HC - don't bother, you won't see the difference between decent renderer fed with 8 and 10 bit data.

[XRyche]

Well...I'm glad that I put that qualifier to my answer. Thanks for setting me straight madshi and company :) .

[LoRd_MuldeR]

Rule #6 post and follow-up's have been removed. Discussion about "pirated" software is not allowed.

[Thunderbolt8]

does coreavc actually use frame-based multi-threading? or only multi-threading based on slices?

if frame-based multi-threading, is there any limitation regarding the number of threads which can be used for decoding?

[LoRd_MuldeR]

CoreAVC does not need slices in the H.264 stream to do multi-threaded decoding:
http://img832.imageshack.us/img832/9826/coreavcperf.png

(It scales up to at least 4 threads, as you can see. I don't have a machine with even more cores)

[kirakami]

Which Nvidia Graphic cards can actually output P010/P016?
Are there even monitor's available yet that can show
10-bit color space without dithering to 8-bit?
Not dithered to 8-bit by monitor before hit the display
even if card can output 10-bit

[Paladin77]

I enjoyed this product. Although I did switch to better free alternatives which provide better performance especially with my 10 bit anime titles. Still it does a great job!

As for 10 bit dithering. So far madVR is unmatched due to what madshi explained. Dithering occurs at final step of processing.

[The Seeker]

Is there a list somewhere detailing CoreAVC's supported ATI GPUs?

Edit: Never mind, mine is supported.

[06_taro]

The latest mmg recognizes ttf font as "application/x-font-ttf" as default MIME type.
Haali(v1.11.288.0) fails to load this type of embedded font, it only load "application/x-truetype-font" fonts, which are detected as default MIME type in old versions of mmg.
Other splitter like LAV/AV/Gabest (All latest, older versions like Gabest before svn r3802 are not included) can load "application/x-font-ttf" fonts.

Forgive me if Haali's issues are not supposed to be here.

[cyberbeing]

The latest mmg recognizes ttf font as "application/x-font-ttf" as default MIME type.
Haali(v1.11.288.0) fails to load this type of embedded font, it only load "application/x-truetype-font" fonts, which are detected as default MIME type in old versions of mmg.
In mmg 5.1.0, OTF fonts are now identified as application/vnd.ms-opentype instead of application/x-truetype-font as well, so I'd assume they are also affected?

[benus]

It seems that the new version of CoreAVC is gonna be released on Monday:

http://twitter.com/corecodec

[LoRd_MuldeR]

It says that the work on finalizing v3.1 begins on Monday. Not that this work will be completed on Monday...

[BetaBoy]

On Monday we will begin working on putting together the various projects we have been working on for CoreAVC 3.1.

[cyberbeing]

Will an updated Haali Splitter which fixes the unsupported MIME type font loading issues be included with v3.1 or sometime after?

[madshi]

Bug report:

It seems that CoreAVC does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2.

[wanezhiling]

Here's a sample (http://uploadingit.com/file/bvjftldv095pahat/no%20dxva.avi), cuda ok, but dxva failed...


Another sample (http://uploadingit.com/file/erzothack7ksfyk3/1%20(1)-001%20(1)-001%20(1)-001.mkv):there's lots of skipped frame with dxva or cuda mode...

[vivan]

This site is down.
http://2.firepic.org/2/images/2011-12/11/rhmeo1mqltdm.png
UPD: now it's up, but it says that file not found. And that their service is broken.

[BetaBoy]

Madshi.... can you supply an example for us to look at?

[madshi]

Sure, try this one:

http://madshi.net/repeatFirstField.evo

If you look at the h264 bitstream, you'll find the following pic_struct variations:

3: top field, bottom field
4: bottom field, top field
5: top field, bottom field, top field
6: bottom field, top field, bottom field

For these pic_struct variations, CoreAVC should output the following flags via IMediaSample2.Get/SetProperties:

3: AM_VIDEO_FLAG_FIELD1FIRST
4: 0
5: AM_VIDEO_FLAG_REPEAT_FIELD | AM_VIDEO_FLAG_FIELD1FIRST
6: AM_VIDEO_FLAG_REPEAT_FIELD

Thanks!

[wanezhiling]

This site is down.
http://2.firepic.org/2/images/2011-12/11/rhmeo1mqltdm.png
UPD: now it's up, but it says that file not found. And that their service is broken.

cuda ok, but dxva failed (http://www.mediafire.com/?4yk1pi21wd0tbuv)...

lots of skipped frame with dxva or cuda mode... (http://www.mediafire.com/?wykw88vi5p8nqi5)

[BetaBoy]

madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.

[madshi]

madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.
There's nothing you can do about hard telecine. But for soft telecine you should pass the flags downstream. You don't need to do anything with the flags yourself, just set them in the properties of the IMediaSample2 you output. That's really all you need to do, should be very easy to do, and there should be no negative side effects at all.

You may wonder why this might be useful. After all if you simply ignore soft-telecine, we get perfect progressive output, right? Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine. The broadcasts might switch between soft-telecine and hard-telecine in the middle of the stream. I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream.

I'm working on an IVTC algorithm for madVR, and it's working pretty well for MPEG2 broadcasts, even if there are mixed hard-telecined and soft-telecined sections, as long as the MPEG2 decoder outputs the proper soft-telecine flags. So this is why I'm now asking you for this, too, just to make sure that IVTC will work well for h264 broadcasts with mixed hard-telecined and soft-telecined frames, too.

[mp3dom]

Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine.

It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.

[madshi]

It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.
Didn't know that. Do you happen to have a sample?

[mp3dom]

I don't have a sample here with me but it can be created. A lot of bd encoders have a built-in IVTC so they can encode both soft and hard pulldown (soft when they catch the pattern and hard when they're unable to detect it).
It can happens with 1080i contents but also with 480i (always referred to AVC encode)

[madshi]

Would it be easy for you to create such a sample? It would be quite useful for testing purposes. If you can do this, maybe you can pick a sample with a lot of movement in it, so that it's easy to see whether IVTC succeeded or not?

[mp3dom]

Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences).
There are 2 segments in each file, first segment is hard pulldown, second is soft.

[madshi]

Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences).
There are 2 segments in each file, first segment is hard pulldown, second is soft.
Thank you!! :)

I can confirm that with these test samples, my (work-in-progress) IVTC algorithm reliably detects a 3:2 cadence in the hard-telecine section with both CoreAVC and LAV Video Decoder. When the soft-telecine section begins, with CoreAVC my IVTC algorithm detects a cadence break and detects a new 2:2 cadence for the 2nd half of the samples. When using the LAV Video Decoder, the cadence stays unbroken at 3:2 for the full runtime of both samples, because LAV Video Decoder forwards the soft-telecine flags to madVR. The SD and HD samples behave identically.

[mp3dom]

Glad it helps :) The samples are bd-compliant, so it's the way an hypothetical bluray could look.

[kieranrk]

I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream.


Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.

[drmpeg]

Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.

Almost every 1080i pay TV channel in the US has IVTC enabled on their encoders.

Ron

[BetaBoy]

madshi... we are on the fence here about your post. It's our general opinion that this is not a bug and that it's more of a feature request. So to that...

CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other so the flags are then useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set.

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.

The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.

[madshi]

we are on the fence here about your post.
"On the fence" isn't too bad, it means you're still open for discussion... :D

CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set.

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.
You're saying that users would get an interlaced picture if you set the telecine flags. But I don't think that's true. Anyway, can you describe a setup for me where setting the telecine flags would result in a loss of quality? The LAV Video Decoder does (always) set the telecine flags, so it should be easy to test. If you're right then LAV Video Decoder should show soft-telecined content at a lower quality compared to CoreAVC with some renderers.

The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.
And that is exactly what I'm working on. But CoreAVC is making things harder than necessary. CoreAVC sets the media type information to 30fps, but for soft-telecined sections only sends 24fps, without telecine flags. So basically CoreAVC is lying. If you remove the telecine flags then you should set the media type information to 24fps. Of course that will make problems with content that has hard-telecine sections, so that brings me back to my argument that there's no reason not to set the telecine flags.

If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless.
I'm sorry to say but this is just not true. If you look at such mixed hard-/soft-telecined streams, if you honor the soft-telecine flags you always end up with exactly 60 fields per seconds, no matter how often the stream switches between soft- and hard-telecine. If you silently drop the telecine flags, the deinterlacer will neither get 48 fields per second, nor 60 fields per second, but something in between, every time the stream switches between soft <-> hard telecine. If you have ever tried writing an IVTC algorithm then you should know that this is not a good situation. Getting exactly 60 fields per second is a requirement of most IVTC algorithms. How else can you detect a 3:2 pattern in the stream? If you get e.g. 55 fields per second, the 3:2 cadence will be broken several times and applying IVTC will become extremely hard to do.

[06_taro]

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.

Then you can provide an option for end users to decide whether to maintain pulldown flags and handle them after decoding, or to drop the flags with 24fps film content output directly as in the present version. Those who never meet mixed soft/hard telecined films and don't use any IVTC/deinterlacing postprocessing can still choose the second one to avoid getting interlaced content, but for those who prefer a more reliable IVTC algorithm which can handle mixed soft/hard telecined contents, the first one is much better for most ( if not all ) IVTC algorithms.

[dead_screem]

CoreAVC already removes soft pulldown by itself.

define remove?

lav and other decoders I used as well (mpeg-2 decoders mostly), leave the indicated output framerate alone at 29.97 so hard telecine parts of a mixed stream play back at 29.97 (or 59.94) but soft telecine parts of the stream play back at 23.976. In coreavc soft telecine plays back at 29.97, the same as hard telecine.

at the very least, this should be an option to do it as in lav, so users can (when madshi's ivtc renderer is done) play back 29.97 hard and soft telecine streams as well as mixed hard/soft at 23.976

[v_spec]

In version 3.01 I noticed a new output option '9/10 bit', but whenever I check the box then hit Apply and OK the box is unchecked when I go back into decoder properties. What does that mean? Is it a problem with CoreAVC or my hardware?

[cyberbeing]

It's neither a problem with CoreAVC or your hardware. The '9/10 bit' check-box is only a toggle for showing/hiding P010 & P016 in the output format box. The '9/10 bit' check-box does not affect anything but the GUI.

The real options to enable/disable high bitdepth output are the P010 & P016 check-boxes. As long as they are checked, they are enabled and available for use with 9/10 bit h264 video and a supporting video renderer. (Currently only madVR supports P010/P016 input).

[v_spec]

Thanks for clearing that up. I've been reading up on madVR for the past couple of hours and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?

[cyberbeing]

There is a noticeable quality difference between 10-bit x264 and 8-bit x264.

Yet there is hardly any quality difference between CoreAVC outputting 10-bit x264 as dithered 8-bit YV12 vs 10-bit P010. Both ways are eventually output to your display as 8-bit.

If you are using madVR there is a minor technical benefit of outputting P010, since madVR can then do other processing gamut/gamma/yuv->rgb using the full 10-bit data and dither to 8-bit for your display as the last step. Would you notice the difference of madVR processing 8-bit input vs 10-bit input, probably not. But depending how close you look, you may notice a difference in dithering quality & noise pattern.

[Keiyakusha]

and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?
You should think of 10bit as "yet another switch in x264 that improves quality during encoding" And resulting 10bit file is "yet another video format"
^very simplified explanation
The switch in the coreavc and other decoders tells what they should do, leave 10bit format as is so it will be dithered to 8bit later (by madvr for example) or dither it by itself. So nothing is wrong if you don't see the difference.

[NikosD]

@BetaBoy

Hello.

Is there any plan of supporting resolutions beyond 1920 x 1088, like 4K x 2K (3840 x 2160) in DXVA mode and suitable hardware of course ?

Thanks!

[hajj_3]

I doubt there is any hardware that can accelerate 4k out there.

The Cortex A8 Allwinner A10 ARM has built-in support for hardware decode of 2k but i'm not aware of anything with 4k.

If Intel/AMD/Nvidia comes out with 4k hardware decode support i'm sure CoreAVC/DiAVC will support it.

[Keiyakusha]

i doubt there is any hardware that can accelerate 4k out there.


gt 520

[wanezhiling]

http://www.mediafire.com/?7vc5zl5tbm9y55p
GF119, dxva 2160p. :D

[NikosD]

Radeon 5000 series with UVD 2.2 are capable of 4K since April 2010 with Catalyst 10.4
But there were no suitable decoders/players to support it due to Nvidia restrictions.

As I have proved here http://forum.doom9.org/showthread.php?t=163110 even UVD 2.2 is more capable than most people think.
UVD3 supports 4K too.

I thought now that there is VP5 which seems capable of 4K, Nvidia should be more flexible to allow 4K in general and pull back the pressure of not allowing 4K decoding on ATI hardware.

[rica]

Still waiting for CoreMVC.

[NikosD]

http://www.mediafire.com/?7vc5zl5tbm9y55p
GF119, dxva 2160p. :D

For me - 5750 UVD2.2 - it's not working even though DXVA checker says about the Device decoders:

"ModeH264_VLD_NoFGT: DXVA2, 720x480 / 1280x720 / 1920x1080 / 3840x2160"
"ModeH264_VLD_NoFGT_Flash: DXVA2, 720x480 / 1280x720 / 1920x1080 / 3840x2160"

So from the side of hardware and driver, UVD 2.2 is capable of 4K x 2K and if CoreAVC DXVA is capable of 4K x 2K, as it is clearly seen by your screenshots, then the problem must be an artificial restriction in everything else but VP5 inside the code of CoreAVC DXVA.

DXVA checker reports for clips beyond 1080p and CoreAVC DXVA the following:

"ModeUnknown (NV12): DXVA1 (VMR)"

and of course it's not working.

@BetaBoy

I would like to check my "fused" 5750-6750 card in 4K x 2K DXVA with its "supernatural" video decoding capabilities as I have clearly demonstrated here:
http://forum.doom9.org/showthread.php?t=163110

[Cyber-Mav]

Radeon 5000 series with UVD 2.2 are capable of 4K since April 2010 with Catalyst 10.4
But there were no suitable decoders/players to support it due to Nvidia restrictions.

what restrictions are these you speak of imposed by nvidia?

[NikosD]

Because VP4 is very slow at high bitrate clips as you can see here http://forum.doom9.org/showthread.php?t=163110, UVD2.2 was forced to be incapable too for 4K x 2K in order to have comparable performance with VP4.

Nvidia had always a few ways to do things like "The Way it's meant to be played"

UVD2.2 in 5xxx series was too fast when introduced back in October 2009 and with Catalyst 10.4 - on April 2010 -it was ready for H.264 L5.1 including 4K, as it is written in Catalyst 10.4 Release Notes.
I can send you the file if you can't find it with google.

As you can see at the above link, UVD2.2 is more powerful than it seems and the reason that is lowered is not Nvidia only, but ATi too, mainly ATi I could say.

ATI wanted to sell UVD3 for MPEG2_VLD, MPEG4ASP_VLD and 4K H.264 playback.

All of them are features of UVD2.2, that have never activated in order to "push" you to buy the next generation card.

Even now if you force MPEG2_VLD, MPEG4ASP_VLD and 4K H.264 playback in UVD2.2, you get a normal playback mode with a GREEN FRAME covering the picture of the video file.

They don't want you to see the clip! :)

Of course all of the above are a joke, just a conspiracy theory I invented with my vivid imagination...

[Cyber-Mav]

if ati uvd 2.2 is so fast then why doesnt it show so in the benchmarks? looks like its either more of a hardware limitation or a driver lmitation. nothing is showing that its being held back by nvidia. last time i checked its the standard dxva mode that ati uses for hardware acceleration, and there is nothing nvidia can do to influence dxva acceleration.

unless you mean that the uvd2.2 is being held back by not having cuda support?

if you get green frame during playback its usually a sign that your hardware cant decode properly due too an out of spec input file. i get that a lot on my old mkv media player if i encode files with too many reference frames.

[clsid]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?

[robpdotcom]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?

I'm interested to know this as well.

[nevcairiel]

Whatever happend to CoreMVC? Wasn't it supposed to be released right after CoreAVC 3?
It seems to have a big marketing advertisement page on their website, but no download/purchase possibility.

[BetaBoy]

Whatever happend to CoreMVC? Wasn't it supposed to be released right after CoreAVC 3?
It seems to have a big marketing advertisement page on their website, but no download/purchase possibility.
It has been out since last February, but only for OEM licensing in both library and directshow forms. Based on feedback we opted to push out a consumer directshow decoder till after we added 4:2:2 and 4:4:4 in CoreAVC. We will revisit a possible release afterwards.

[BetaBoy]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?
The fix will be included in the next CoreAVC release.

[CruNcher]

@Dan
i hope it isn't to late yet, though maybe this is already fixed then you can ignore it :)

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

the issue is after the glitch Lav Splitter,Haali Splitter,MPC-HC splitter (Lav Audio) doesn't Recover with CoreAVC it begins to stutter (frames are dropped) (Software,DXVA,cuvid not tested) it works fine with Lav Video (any mode, cuvid not tested) see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

[NikosD]

@BetaBoy

Is it possible to clarify which path do you enable in order to HW accelerate H.264 files on Intel's QuickSync HW ?

There are a lot of confusing and contradicting issues regarding Intel's HW acceleration.

For example CoreAVC 2.x has DXVA support which utilises ModeH264_VLD_NoFGT but not for Intel.
It doesn't work.
It was Core AVC 3.x which added Media SDK and GMA support.
Do you use ModeH264_VLD_NoFGT or ModeH264_VLD_NoFGT_ClearVideo in order to HW accelerate H.264 files in CoreAVC 3.x ? Or something else ?
Because the performance of CoreAVC DXVA with QuickSync HW, indicates that it uses some direct mode of DXVA and not copy-back like QuickSync decoder by Egur.
At the same time using Intel's Media Checker tool, I saw that CoreAVC 3.x during HW accelerated playback on QS HW doesn't use Media SDK decode operations.
No HW calls, no SW calls of Media SDK.

So what is the mystery of CoreAVC 3.x and what's missing from CoreAVC 2.x ?

Is it a direct use of Media SDK - without copy-back- that Media Checker is not capable to catch ?

Thanks in advance.

[CruNcher]

it uses the ClearVideo mode like any other ISV does, copy back makes no sense for a On screen Decoder if you have Native DXVA support why the heck you would want to use copy back for playback ?
Copy Back makes sense to be used in a Decoding(DSP,GPU)->Encoding(Software,DSP,GPU) scenario where you balance both out so the CPU overhead can be compensated efficiently so the Encoding stays lower Power and Faster then without Copy Back (Software Decoding) :)
Or if you still need acceleration and lower power and combine it with a 3D renderer (for example a Broadcast Editing system with complex layer setups) :)
But for a consumer Playback system it makes no sense and isn't beneficial @ all @ least on Windows

[NikosD]

I didn't say CoreAVC uses copy-back.
I said the opposite, that they don't use it.

But CoreAVC supports Media SDK after CoreAVC 3.x.
ClearVideo support was there in CoreAVC 2.x, but QS HW support in CoreAVC 2.x wasn't.

You put PotPlayer and MPC-HC in ISV's too ?

What do they (PotPlayer and MPC-HC) use with their internal codecs in order to accelerate in QS HW the H.264 video ?

[CruNcher]

I didn't say CoreAVC uses copy-back.
I said the opposite, that they don't use it.

But CoreAVC supports Media SDK after CoreAVC 3.x.
ClearVideo support was there in CoreAVC 2.x, but QS HW support in CoreAVC 2.x wasn't.

You put PotPlayer and MPC-HC in ISV's too ?

What do they (PotPlayer and MPC-HC) use with their internal codecs in order to accelerate in QS HW the H.264 video ?

The same ClearVideo DXVA interface, though CoreAVC uses some clever workarounds the same as Mirillis does for several special decoding issues :)

Not every DXVA decoder is the same only because its using the same interface :)

Arcsoft and Cyberlink are currently also going this way trying to fix issues with workarounds

[NikosD]

Apparently MPC-HC doesn't have access to ClearVideo documentation because they have disabled DXVA acceleration for QS HW.

It doesn't work for them and they haven't found those clever workarounds you mention.

Splash and PotPlayer work fine with QS HW.
But I think PotPlayer doesn't have access to ClearVideo too, like MPC-HC.

How did they do it ?

[nevcairiel]

How did they do it ?

Probably stole it somewhere, like all their other stuff.
Also, PotPlayer uses Erics QS decoder.

[NikosD]

Probably build it by themselves, because there is no free code accessible for that task.
Erics QS decoder is an alternative mode for PotPlayer, like many others.

But their own internal codecs provide native DXVA acceleration for H.264 and MPEG-2, without using quicksync.dll

@Cruncher
If PotPlayer had access to ClearVideo documentation, they would have added VC-1 DXVA acceleration for QS HW, too.
Which is ClearVideo only.

So PotPlayer doesn't use ClearVideo for H.264, either.
They do it natively.

And what about MS DS/MFT ?
Do they use ClearVideo too?

[CruNcher]

they think practical why reinvent if someone did it already though they try to fix things no one tackled yet but give nothing back that's the shame of it :(
Though they don't do very advanced workarounds their workarounds are mostly container analyze based (MediaInfo) and just turning stuff on and off (still they have no automatic QS fallback for some of these issues which is the easiest way to fix them) when they think its better todo so but the other go into the bitstream level itself ;)

[TheShadowRunner]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.

[BetaBoy]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.

We are looking into it, thx for the sample.

[CruNcher]

@Dan

https://forum.doom9.org/showpost.php?p=1554111&postcount=6977

[BetaBoy]

CruNcher.. got it... fixed, thx.

[BetaBoy]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.
Fixed. Thx again for the report!

[dead_screem]

Care to comment on when the next version will be out? Twitter says "Feburary" but that is kinda vague, especially since there was going to be a quick turnaround 3.0.2 bug fix only release, but you guys decided to wait for 3.1 to release those fixes, and 3.1 was supposed to start finalizing last Dec 12... So, when's it coming out?

[BetaBoy]

As with all of our releases its a moving target based on feedback and where we are at with it, so its ready when its done. As you can see above we are also addressing other reported bugs as they are being reported as well as doing some work on Haali's Splitter so this has also affected our timeline.

At the moment it is looking like we are gonna push out adding 422 (444 will likely make it) with the next release to make sure the newer changes are solid before committing it. We will however likely still stick with it as a milestone in calling it 3.1 though considering all the work we have done on it.

We have a few smaller todo's with include Chroma MC ASM and 444 filter work, so we are close.

[kerman]

Doesnt CoreAVC supports VC-1? I have it as the main external filter on mpc-hc but doesnt run on VC-1 streams. It does on h.264/x264, but never with VC-1. I use MPC-HC x32 with madVR and Haali media source. OS Win7x64.

Also, on h.264 decoding doesnt enable dxva2 (tray icon is always blue), although I have dxva checked on properties. I have an AMD HD6950. Should I check/uncheck anything on CCC or mpc-hc?

[nevcairiel]

CoreAVC is only for ... AVC1, as the name suggest, also known as H.264. VC-1 is a different codec entirely, and not supported by CoreAVC.
I'll admit that the "AVC1" and "VC-1" might be confusing at times, but AVC1 is just an alternate name for H.264.

[kerman]

Thanks, yes I just got confused. BTW, is there any "champ" on VC-1 codec performance? Mainconcept, Arcsoft, Cyberlink...? I mean, similar to CoreAVC with H.264

[betaking]

Thanks, yes I just got confused. BTW, is there any "champ" on VC-1 codec performance? Mainconcept, Arcsoft, Cyberlink...? I mean, similar to CoreAVC with H.264

Microsoft>Cyberlink>Arcsoft>Mainconcept!

[Midzuki]

Microsoft>Cyberlink>Arcsoft>Mainconcept!

I agree, Mainconcept's VC-1 decoder is sluggish as hell :p

BUT maybe it's good enough for accurate frameserving via DirectShowSource() :D

[CruNcher]

yep normaly Mainconcept does excellent work but the VC-1 Decoder is far from that and it's funny seeing Cyberlink and Arcsoft beating it but i guess Mainconcept doesn't invest much resources into it's Developing ;)

[robpdotcom]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?The fix will be included in the next CoreAVC release.

I'd also like to request that Haali change the way it deals with subtitle streams - right now it loads default subs automatically, but I think everyone would be happier if it only loaded forced subs.

Also, is there a way to allow the video renderer to do the deinterlacing? I only see the option to set:

None (weave)
Single Field
Bob
Hardware

There is no option to output interlaced frames.

[Thunderbolt8]

I think everyone would be happier if it only loaded forced subs.not me ;)

[Shevek]

not me ;)


me neither!

If you don't want a sub stream to be default then make sure the default flag isn't set when you mux the file.