CoreCodec/H.264 Codec "CoreAVC"

[squid_80]

With your particular sample I get 48fps with CoreAVC and 52fps with MPC's DXVA decoder so it's still slower than realtime. You're probably better off using software decoding, it should be able to handle it as long as you have a dual core CPU.

[nm]

What other hardware limitation should one look at? Number of shaders/stream processors perhaps?

FYI, DXVA has no problem handling this.
Then CoreAVC CUDA might also work on your hardware. Remember that both use the same hardware decoder, only the software layer is different.

[mariner]

With your particular sample I get 48fps with CoreAVC and 52fps with MPC's DXVA decoder so it's still slower than realtime. You're probably better off using software decoding, it should be able to handle it as long as you have a dual core CPU.

May I know your hardware config?

[BetaBoy]

The only things in question for 2.0 atm are:
- Initial 64bit version as Haali's splitter needs more work (the filter is ready though)
- Windows 7 splitter/filter support... don't want to got OT in this thread with this FUD as we'd like to see whats possible in MF w/o hacking the registry/perms.

[clsid]

Another idea for the Windows 7 issue:
Let Haali's splitter (optionally) deny connection with the MS decoder. Then in theory the DirectShow framework should fall back to using the next available compatible filter (CoreAVC, ffdshow, etc). Of course this will only work with Matroska files and not the stuff that MS handles natively.

[BetaBoy]

Yeah we had talked about that.... but it negates the purpose of why the splitter/renderer was created as a universal solution (not just MKV) in the first place. We'll see as we are at least now talking with MS about it.

[the_corona]

The only things in question for 2.0 atm are:
- Initial 64bit version as Haali's splitter needs more work (the filter is ready though)
- Windows 7 splitter/filter support... don't want to got OT in this thread with this FUD as we'd like to see whats possible in MF w/o hacking the registry/perms.

Hi,

Ok, thank you for you're response. But I don't understand (sorry, english is not my mother language), by in question, do you mean

1) these things are the only things that are new in 2.0 or
2) these are the only things we are not yet sure we can get done for 2.0, which would imply that my other statements for 2.0 are true.

Again, sorry if I'm drilling you, but I'm anxiatly awaiting the new release.

PS: why was my previous post deleted, took me along time to find all those quotes and I figured they might be useful to others as a collection?

[Shakey_Jake33]

^It implies the latter, that those features might not be ready for release.

[t3nk3n]

Are there plans to support OpenCL or STREAM for full hardware acceleration HD media decoding?

[BetaBoy]

OpenCL is the first thing after 2.0 is released.

[deekey777]

OpenCL is the first thing after 2.0 is released.

You can get access to VP over OpenCL?

[desta]

OpenCL is the first thing after 2.0 is released.
I'm a little ignorant on this sort of thing, but would that mean possible future hardware acceleration support for ATI cards?

[LoRd_MuldeR]

If CoreAVC is going to use OpenCL, then any OpenCL-capable hardware will be supported. That will include NVIDIA, ATI and others - once they release OpenCL compatible drivers.

For ATI you will need the latest GPU generation though! For NVIDA probably anything that supports CUDA now will support OpenCL in the future. They have a beta of their OpenCL SDK out already.

(Note that OpenCL can even run on the CPU, in case there's no specialized OpenCL hardware available on the machine)

[desta]

Thanks for the info. :)

[CiNcH]

But OpenCL does not mean that the video decoder engines (e.g. PureVideo or UVD) are being used. Instead some video decoding algorithms are out-sourced onto the GPU's shaders which is much more complex to implement then accessing the CUDA Video API's. Good thing is that Core already has the decoding algorithms, but porting them means a lot of work too.

[LoRd_MuldeR]

But OpenCL does not mean that the video decoder engines (e.g. PureVideo or UVD) are being used. Instead some video decoding algorithms are out-sourced onto the GPU's shaders which is much more complex to implement then accessing the CUDA Video API's. Good thing is that Core already has the decoding algorithms, but porting them means a lot of work too.

OpenCL is very similar to CUDA.

The hardest task is to think of tasks and algorithms that are worth running on the GPU and that are highly parallelizable (so they use the GPU efficiently).

If they have that part already for CUDA, implementing their algorithms on a different but similar API shouldn't be too hard...

[CiNcH]

If they have that part already for CUDA, implementing their algorithms on a different but similar API shouldn't be too hard...
Did I miss that they already have it for CUDA?
Are both, CUDA and OpenCL, based on C syntax?

[nm]

Did I miss that they already have it for CUDA?
Nope, haven't heard of such work. So far they have simply been using NVCUVID like you said.

Are both, CUDA and OpenCL, based on C syntax?
Yes, and OpenCL is quite similar to CUDA.

[Rumbah]

If CoreAVC is going to use OpenCL, then any OpenCL-capable hardware will be supported.

I doubt that because as far as I know OpenCL supports extensions like OpenGL. And based on my own experience OpenGL does not run on every OpenGL capable graphics card as everything modern uses an extension that's different for every vendor.

[LoRd_MuldeR]

I doubt that because as far as I know OpenCL supports extensions like OpenGL. And based on my own experience OpenGL does not run on every OpenGL capable graphics card as everything modern uses an extension that's different for every vendor.

On the other hand it doesn't make much sense to make the step from CUDA to OpenCL, but then rely on NVIDIA-specific extensions.

I assume that if they go the OpenCL route, then they will support ATI (latest generation) and NVDIA (CUDA-capable generations) at least.

For others, we'll see...

[BetaBoy]

On the other hand it doesn't make much sense to make the step from CUDA to OpenCL, but then rely on NVIDIA-specific extensions.

I assume that if they go the OpenCL route, then they will support ATI (latest generation) and NVDIA (CUDA-capable generations) at least.

For others, we'll see...

That's correct for both our directshow decoders as well as the CorePlayer Platform.

[Cyber-Mav]

will ati cards be able to support level 5.1 avc streams using opencl like nvidia cards currently do with cuda?

[the_corona]

Hmmm, interesting about openCL once you think about it.

Do all OpenCL certified devices such as GPU (but not nessesarily) need to provide the same Video Decoding (H264) API? I would think not, since OpenCL (AFAIK) is much more general than that.

So to me this would mean that the decoding engine would need to be coded by CoreAVC itself, as opposed to just using an OpenCL API to get acess to the special hardware in the device (as is done right now through CUDA for NV cards).

Is that correct? If so it's a massive undertaking IMHO :-)

[LoRd_MuldeR]

Do all OpenCL certified devices such as GPU (but not nessesarily) need to provide the same Video Decoding (H264) API?

As far as I know, OpenCL does not provide any video decoding API. It provides an API (C extension) to run your own algorithms on the device.

I would think not, since OpenCL (AFAIK) is much more general than that.

Correct.

So to me this would mean that the decoding engine would need to be coded by CoreAVC itself, as opposed to just using an OpenCL API to get acess to the special hardware in the device (as is done right now through CUDA for NV cards).

That is correct, unless you want to rely on vendor-specific OpenCL extensions. But then it would make no sense to move from CUDA to OpenCL.

But maybe there will be video libraries available for OpenCL, that developers can license instead of re-inventing the wheel...

[Shakey_Jake33]

Just a quick n00b question, I have CoreAVC doing the decoding, and ffdshow as raw video filter to perform deinterlace, resize and conversion to RGB32. With this in mind, should I configure CoreAVC to only output RGB32 also? Or leave the conversion to ffdshow?

I ask because there is a noticable difference in colour levels when setting CoreAVC to output as RGB32 only, and I don't actually know which is correct.

[squid_80]

I ask because there is a noticable difference in colour levels when setting CoreAVC to output as RGB32 only, and I don't actually know which is correct.

The method that looks better to you is correct.

[leeperry]

I can't really tell whether it's Asus or CoreAVC's fault, but enabling CUDA in CoreAVC w/ an Asus Essence STX soundcard on XP SP3 gives an almost instant BSOD "IRQL NOT LESS OR EQUAL".
w/o CUDA everything's cool....I'm using the latest build of CoreAVC/nvidia drivers. I've also notified Asus.

[Inspector.Gadget]

leeperry, are you using NVIDIA 1.85.85 drivers?

[leeperry]

yup, and before I put the STX in my box CoreAVC CUDA had always worked just fine(my previous soundcard was USB). same exact problem occured w/ 182.08

[clsid]

CoreAVC causes Windows Explorer to crash during thumbnail generation of .mkv and .mp4 files. I have been able to reproduce it on XPSP3, VistaSP2 and Win7. I have seen several other people that have the same problem.

Here is a reg tweak to enable thumbnails in case you need it:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.mkv\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}]
@="{c5a40261-cd64-4ccf-84cb-c394da41d590}"


[HKEY_CLASSES_ROOT\.mp4\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}]
@="{c5a40261-cd64-4ccf-84cb-c394da41d590}"

(I am not using Haali shell extension)

[BetaBoy]

clsid..... noted for the next release. Thanx for the follow-up!

[clsid]

I have also seen reports of people who have crashes when using Haali's shell extension instead the Microsoft one. The reg keys I posted are for the MS one. So you should test both situations.

Can you give an ETA when the next release will be available? Is Haali making any progress with a new version of his splitter?

[BetaBoy]

A few updates for everyone:

- Based on customer feedback and us going into 2.0, we have EOL'd CoreAVC Standard Edition. Current users will get the upgrade in 1.9.x to Pro as a part of their original purchase of Standard Edition when we release the next version.
- We have decided to combine the Enterprise features into Pro for 2.0 with the one Enterprise feature 4:2:2 being added for the initial 2.0 release and 4:4:4 to be added in a later 2.x release.
- We will now also combine 32bit and 64bit versions into the CoreAVC Pro installer. Its tbd if we will do this with the initial 2.0 release as Windows 7 coming sooner then we had anticipated has effect our plans for the 64bit splitter work.

[Cyber-Mav]

will 64bit coreavc allow h264 video playback in vista windows media center?

[popper]

A few updates for everyone:

- Based on customer feedback and us going into 2.0, we have EOL'd CoreAVC Standard Edition. Current users will get the upgrade in 1.9.x to Pro as a part of their original purchase of Standard Edition when we release the next version.
- We have decided to combine the Enterprise features into Pro for 2.0 with the one Enterprise feature 4:2:2 being added for the initial 2.0 release and 4:4:4 to be added in a later 2.x release.
- We will now also combine 32bit and 64bit versions into the CoreAVC Pro installer. Its tbd if we will do this with the initial 2.0 release as Windows 7 coming sooner then we had anticipated has effect our plans for the 64bit splitter work.

AND OC your Core AVC ENCODER will be out before V2 (or was it before v1.9, we forget as its been a while) as you stated way back when in the thread :devil:

first rule about Core AVC Encoder is Dont Talk About Core AVC Encoder....:eek: :devil:

[BetaBoy]

popper... PM me with FUD like this and let's keep this thread flame free.

[Dark Shikari]

AND OC your Core AVC ENCODER will be out before V2 (or was it before v1.9, we forget as its been a while) as you stated way back when in the thread :devil:

first rule about Core AVC Encoder is Dont Talk About Core AVC Encoder....:eek: :devil:Actually, I'll be nice--I'll leak the CoreAVC encoder for you.

Get it here! (http://tinyurl.com/qlw39)

[popper]

popper... PM me with FUD like this and let's keep this thread flame free.

now Dan, be Nice, theres a good fella, FUD indeed. :search:

10th March 2006, 13:13
#13 http://forum.doom9.org/showthread.php?p=797481#post797481
"The product release schedule for CoreAVC (atm) is:

March 15th CoreAVC Standard and Professional Editions
April 15th CoreAVC Enterprise
May GPU Additions

After that our CoreAVC Encoder will be released.... I will not comment on more specific features of the CoreAVC encoder atm.
__________________
Dan "BetaBoy" Marlin
Ubiquitous Developer Tools and Multimedia Technologies."

OC cant be sure about what might have been redacted without some more indepth searching of caches but no matter.

as i said "first rule about Core AVC Encoder is Dont Talk About Core AVC Encoder...." seems to be correct ;)

[popper]

Actually, I'll be nice--I'll leak the CoreAVC encoder for you.

Get it here! (http://tinyurl.com/qlw39)

:)

actually as per my concept idea's from way back, id still like to see the x264Core Encoder :devil:
developed to a point were it could fit inside a USB2 stick , sat on an FPGA (so as to be able to be reprogramed and updated for any firmware/codec errors found later, or a fixed cheap unfixable ASIC if you must to get it out the door OC),with perhaps an ethernet + sundry SOC capable of H@L4.1 Encode/Decode in and out of the ethernet and USB bus etc as a stand alone bit of HW and Open cross platform API OC.

[BetaBoy]

Thx again for resurrecting OT talks on something I stated sometime ago we had plans to hold off on. x264 is the way to go, end of story.

[CiNcH]

Hi again,

just wanted to inform you that I have the same bad quality with ffdshow + NV12 + VMR9 + Hardware Deinterlacing. And it is not due to field order because within ffdshow it is possible to swap fields.

I am attaching a 1080i sample:

http://bleedingme.dyndns.org/06-27_10-31-33_ASTRAHD+_.ts (~80 MByte)

Please have a look at it and check smoothness with VMR9 (dropped frames within renderer properties) and picture quality (especially at the Astra-Logo on the top left corner).

Maybe NV12 Color-Space-Conversion is buggy. As I said, same with ATi and nVIDIA..

[sarastro]

will 64bit coreavc allow h264 video playback in vista windows media center?

I don't see why not. Admittedly Microsoft has made it a little hard to select your preferred codec. But CLSID fixed that with a small program, for more information on that:
https://forum.doom9.org/showthread.php?t=146910

I run windows 7 x64 so I can't use coreavc anymore. So my media center uses ffdshow for now, using the dxva decoder from mpc-hc is also a no go thanks to the luminance level problem.

[Drifting slightly off topic] If someone form microsoft is following this thread. Why don't you add this tool/ this functionality to windows. I think CLSID has already shown that the program doesn't have to be difficult. And being able to select your favourite decoders should be standard functionality on a OS.
[/Drifting slightly off topic]

[dead_screem]

A few updates for everyone:

- Based on customer feedback and us going into 2.0, we have EOL'd CoreAVC Standard Edition. Current users will get the upgrade in 1.9.x to Pro as a part of their original purchase of Standard Edition when we release the next version.
Does this mean that Standard is EOL effective immediately, and current Standard users get a free upgrade to Pro in 1.9.x?

- We have decided to combine the Enterprise features into Pro for 2.0 with the one Enterprise feature 4:2:2 being added for the initial 2.0 release and 4:4:4 to be added in a later 2.x release.
So Pro and enterprise will be combined for 2.0. Awesome, I was hoping for this. What will 2.0 be named? will it stay as "CoreAVC Professional Edition" or will it be a more generic "CoreAVC Video Decoder"? to reflect that there are no more seperate "editions"?

[benwaggoner]

[Drifting slightly off topic] If someone form microsoft is following this thread. Why don't you add this tool/ this functionality to windows. I think CLSID has already shown that the program doesn't have to be difficult. And being able to select your favourite decoders should be standard functionality on a OS.
[/Drifting slightly off topic]
In general, any time you put in any kind of control, 20% of users who find it will set it to something wrong :).

This is why there's PowerToys and such, so that only users who know what they're doing enough to find the tool try to use it.

Plus, anything in Windows is supported as a Windows component, so we have to balance the utility for the advanced user versus complexity for the broader market.

[halsboss]

Should market a windows-for-the-masses vs a windows-complex-for-people-willing-to-take-the-risk-and-not-call-support.

[3ngel]

I just want to add that CoreAVC permits me to view smooth 720p on EEPC Atom N270.

So thanks :)

[saint-francis]

I just want to add that CoreAVC permits me to view smooth 720p on EEPC Atom N270.

So thanks :)

Is that with CUDA or CPU? Can you give some more details about the file/s you are playing? Including Audio streams and player. This is very interesting.

Thanks

[clsid]

With the Cyberlink PowerDVD filter you can smoothly decode 1080p on netbooks with an Atom CPU and Intel GMA500 chipset.

[BetaBoy]

... and I can play 480p fine with CoreAVC on my 600mhz P3. lol..... ok... nuff of that guys ;-)

[benwaggoner]

Should market a windows-for-the-masses vs a windows-complex-for-people-willing-to-take-the-risk-and-not-call-support.
Yes, there are plenty of features like that. They have a unified GUI called regedit :).

This seems to me like a fine place for a 3rd party to provider their own tweaking tool.