CoreCodec/H.264 Codec "CoreAVC"

[ckjnigel]

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

[BetaBoy]

@betaboy...

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

like quadHD?

and what is the max framerate?

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


KornX

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

[kemuri-_9]

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

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

[STaRGaZeR]

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

Any news?

[Jay Bee]

Any news?

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

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

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

[BetaBoy]

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

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

[CruNcher]

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

[lexor]

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

[Jay Bee]

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


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

[STaRGaZeR]

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

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

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

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

[DigitalDeviant]

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

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

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

[STaRGaZeR]

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

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

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

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

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

[BetaBoy]

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

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

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

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

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

[Cyber-Mav]

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

[CruNcher]

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

[rebkell]

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

[Guest]

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

[LoRd_MuldeR]

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

[Guest]

Not frame accurate.

[BetaBoy]

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

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

[squid_80]

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

[Cyber-Mav]

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

[BetaBoy]

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

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

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

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

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

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

[toytown]

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

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

[CruNcher]

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

[Atak_Snajpera]

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

[BetaBoy]

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

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

[leeperry]

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

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

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

[CruNcher]

Your test is invalid for a Decoding comparison leeperry you compare in a Enviroment where already most cpu cycles are used by the Post Processing so it's normal that it can't get faster and the results are so close

[leeperry]

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

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

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

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

[Ice =A=]

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


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

[LeMoi]

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

[toytown]

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

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

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

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

[BetaBoy]

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

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

[LoRd_MuldeR]

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

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

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

[leeperry]

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

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

[tal.aloni]

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

Tal

[LoRd_MuldeR]

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

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

E:\HD\premiere-paff.ts

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

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

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

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

[leeperry]

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

fastandfurious-tlr1_h720p.mov

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

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

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

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

I will update to 180.100

[LoRd_MuldeR]

fastandfurious-tlr1_h720p.mov

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

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

Since when does CoreAVC have GPU support ???

The official site still says:

GPU support (to be added**)

** GPU scheduled to be added at a later date

[ChronoCross]

@LoRd_MuldeR

Since when does CoreAVC have GPU support ???

The official site still says:

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

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

He's a Cuda Beta tester for coreavc

[LoRd_MuldeR]

He's a Cuda Beta tester for coreavc

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

[ChronoCross]

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

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

[nurbs]

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

[LoRd_MuldeR]

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

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

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

[leeperry]

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

[nurbs]

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

[leeperry]

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

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

[lexor]

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

[ChronoCross]

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

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

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