CoreCodec/H.264 Codec "CoreAVC"

[Jay Bee]

What can I do to get smooth playback of interlaced H264 content (50Hz 1080i - EurosportHD / BBC HD)?


Cyberlink decoder. Free with PDVD demo.

[CiNcH]

blubberbirne... What do you mean by interlaced? If it works fine now... and there is no diff in that regards to 2.0.
What can I do to get smooth playback of interlaced H264 content (50Hz 1080i - EurosportHD / BBC HD)?
Problem is the bad standard renderer support (e.g. VMR) of CoreAVC (especially with interlaced content). I have reported it several times and the interest in it was pretty low. I will check back with 2.0 and see whether the problem is addressed there.. (even though I am not too confident about that)

All I have learnd is that CoreAVC works well with Haali Renderer which DVB apps do not make use of (hint was given by a CoreAVC dev so I think they are pretty much aware..).

[hajj_3]

I don't suppose the new CoreAVC is any closer to release now? Win7 has been out for a few days, hope its out soon:)

[BetaBoy]

We are working on the 2.0 installer now for the release. No time frame... but QA will be next.

[leeperry]

We are working on the 2.0 installer now for the release. No time frame... but QA will be next.
including HMS 2.0? still open for beta-testing if you want http://img514.imageshack.us/img514/8138/icecreamt.gif

[JohnnyFu]

Betaboy, is there a changelog for 2.0?

[BetaBoy]

As soon as it is released sure.... but the focus with the initial 2.0 is:

- Updated Haali splitter
- Merged 32bit and 64bit versions
- Windows 7 Compatible Installer
- CPU instruction set additions (massive)
- Updated CUDA SDK support
- New Installer
- Bug fixes

Plus about 30+ more changes/additions/fixes... but its a well deserved 2.0 Milestone for sure.

[leeperry]

if you could somehow decrease the CUDA initialization time, as discussed in this thread..this would be most fantastic: http://forum.doom9.org/showpost.php?p=1328499&postcount=21

[JimmyZ]

As soon as it is released sure.... but the focus with the initial 2.0 is:

- Updated Haali splitter
- Merged 32bit and 64bit versions
- Windows 7 Compatible Installer
- CPU instruction set additions (massive)
- Updated CUDA SDK support
- New Installer
- Bug fixes

Plus about 30+ more changes/additions/fixes... but its a well deserved 2.0 Milestone for sure.

so i guess OpenCL support is not coming...

[nm]

so i guess OpenCL support is not coming...

Unlike CUDA, OpenCL doesn't have a video API for accessing hardware decoders. Writing a new decoder that runs on the stream processors would be a huge task and probably not worth it anyway.

[dimitrik]

As soon as it is released sure.... but the focus with the initial 2.0 is:

- Updated Haali splitter
- Merged 32bit and 64bit versions
- Windows 7 Compatible Installer
- CPU instruction set additions (massive)
- Updated CUDA SDK support
- New Installer
- Bug fixes

Plus about 30+ more changes/additions/fixes... but its a well deserved 2.0 Milestone for sure.

Does "Windows 7 Compatible Installer" mean that v2.0 will Windows Media Foundation compatible i.e. it will be able to function inside Win7 Media Center?

Or am I hoping for too much?

[Keiyakusha]

BetaBoy
Sorry for asking here, I just can't wait...
Is there some changes to Haali's renderer? I remember you posted something about that.

EDIT: Also this is a bit too long for creating an installer... is there any problems suddenly appeared?

[G_M_C]

After reading this in the "x264 development" thread;

the issues i recall being stated surrounding weightp being broken (haven't seen any confirmation of fixes) were

A) 2pass encoding does not work to a miss constructed check under some situations which i don't recall offhand (x264 errors out and doesn't start processing, so you'll know it if you come across it).
B) weightp 2 triggers an incredibly large number of scenecuts (when scenecut is active) which will cause a quality drop.

on a side note, this email (http://mailman.videolan.org/pipermail/x264-devel/2009-November/006502.html) is relevant.
though it was stated as 'few days' in above email, pengvado/akupenguin is now on vacation for a while
and weightp will not commit until it has his full approval.

CoreAVC broken with "weight-p" in default mode. D'oh! Hope they get the fix out very soon :D

I'll ask the obvious question: When will version 2.0 of CoreAVC see daylight ?

[BetaBoy]

We are aiming for the end of this week/early next week so it does not impact x264 encodes.

[G_M_C]

We are aiming for the end of this week/early next week so it does not impact x264 encodes.

Thx for your quick reply :)

[BetaBoy]

BetaBoy
Sorry for asking here, I just can't wait...
Is there some changes to Haali's renderer? I remember you posted something about that.

EDIT: Also this is a bit too long for creating an installer... is there any problems suddenly appeared?

Well I am waiting on Haali for the full changelog.... but the biggest changes are the removal of the explorer integration and the silent install options. for example Haali's splitter is now integrated into the CoreAVC installer as an additional install component.

The later change for taking a higher priority over MediaFoundation in both the splitter and CoreAVC will come after the 2.0 release for sure. We have argued against fighting MS and don't want to bastardize the OS with any registry hacks... but instead have opted for a simple solution that just gives Directshow the higher priority.

[clsid]

Could you provide some more details about how you have given DirectShow a higher priority?

[BetaBoy]

I'd prefer to just get CoreAVC 2.0 out... but I will PM you with the now method Vs. the later method.

[Disabled]

I'll ask the obvious question: When will version 2.0 of CoreAVC see daylight ?

I thought the obvious question was: What are you doing with buyers of the 1.x Version? As far as I know the 2.x series is not free for 1.x buyers, but if 1.x still does not implement the full specs...?

[buzzqw]

i hope for the 1.9.5 buyer that license upgrade will be free of cost
or.. al least with a significative reduction..

BHH

[Cyber-Mav]

betaboy will you be doing some benchmarks to show the difference in speed between coreavc 1.9.5, divx latest version and coreavc 2.0. i would like to know if coreavc 2.0 manages to best divx this time.

[BetaBoy]

betaboy will you be doing some benchmarks to show the difference in speed between coreavc 1.9.5, divx latest version and coreavc 2.0. i would like to know if coreavc 2.0 manages to best divx this time.

To be clear.... CoreAVC's 1.x CORE beats DivX everytime... its only because of CPU instruction set optimizations that they were faster in 'some' cases.

CoreAVC 2.0 beats DivX in every aspect now from our testing. But that's my 'opinion'.... I'll leave it for you all to tell me if its a fact.

[BetaBoy]

Disabled.... 1.x is EOL and we will not be releasing a new version. 1.x is also fully spec compliant against the features that are included.... there are many features not supported in both CoreAVC and x264 that are being added, and we are tying to match our feature set to that of x264's as they release them. But this will only be in 2.0 and above versions.

[Disabled]

So "the most advanced directshow H.264 Video decoder in the industry" with "H.264 High profile support" will never be able to decode some high profile features... but you never cared about what you were falsely advertising anyway.

[clsid]

As long as those 'missing' features are not actually getting used in real life, I do not see much harm in not supporting such obscure features.

[BetaBoy]

Disabled... this is what, about the 10x you have attacked us in this thread? I thought we were past this OT crap. Mods notified...

[STaRGaZeR]

Why do you report him if he's right?

[Disabled]

The harm is done, when you think you bought a decoder for high profile files, while you bought a decoder for files that use 'some' high profile features. You are right, there is no harm done - until you need those features and are not added for free.

And Betaboy, you never could stand criticism about your business practices. I'm sorry to not be the customer who swallows everything. Be happy that with 2.0 I'm not your customer anymore - I'm not.

[BetaBoy]

The AVC specs today are not the same spec they were 6 months ago no less 2-3 years ago. As far as changes... you are really talking about encoding... and if its encoding, you are talking about x264, and we have been working with Jason and the rest of the devs to ensure our feature set matches that of x264's capabilities.

STaRGaZeR... this has been discussed about 100+ pages back... we are fully open to what is supported and always have been.

[Disabled]

Not that I know a lot about h264 internals, but something that seems like the specs from 05/2003 (http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200305-S!!PDF-E&type=items) states that baseline profile shall not have weighted_pred_flag but main profile can. I don't know much of what that means, but that flag is exactly what --weightp sets with a gsoc git build of x264. The specs from 2005 (http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200503-S!!PDF-E&type=items) also do not restrict high profile to have that flag.
I may have misinterpreted some of those specs, so tell me if I'm wrong.

[ChronoCross]

Disabled.... 1.x is EOL and we will not be releasing a new version. 1.x is also fully spec compliant against the features that are included.... there are many features not supported in both CoreAVC and x264 that are being added, and we are tying to match our feature set to that of x264's as they release them. But this will only be in 2.0 and above versions.

So long as your not going to rape me cost wise to update versions this is fine. However for purely clarification purposes you should probably have a full list of all AVC features currently in the spec in a table that indicates what you currently support and what you plan to support in each revision of coreavc. Disabled does have a point in that you do say you support baseline, main, and high with no asterisk that says "only features we deem are in use in the real world are implemented"

[BetaBoy]

I'll look into a chart... but we do have a list of non-supported features here: http://bit.ly/F1IiS . All of which will soon be moved over to our wiki on CoreCodec.com .

[Forteen88]

"16 reference frame limitation"
It's awesome that CoreAVC supports up to 16 refs with CUDA, but could you please make the same support for ATI-graphicscards?

EDIT: @popper, yeah I mean hardware assisted decoding.

[Dark Shikari]

CoreAVC supports weightp just fine. What it doesn't support is duplicating a frame in the reference list with a different weight more than once.

[BetaBoy]

DS.... Thx... I thought that was assumed with the x264 changes coming.

[LoRd_MuldeR]

CoreAVC supports weightp just fine. What it doesn't support is duplicating a frame in the reference list with a different weight more than once.

Does libavcodec handle that case? :confused:

[Dark Shikari]

Does libavcodec handle that case? :confused:Of course it does.

[LoRd_MuldeR]

Of course it does.

Of course? I still remember there was a time when CoreAVC did support Predictive Lossless (as used by x264), but libavcodec didn't do so :p

But it's good to know that libavcodec (and with it dozens of OSS applications) is 100% ready for weight-p :)

As nobody complained about incomplete weight-p support in CoreAVC until now, is x264 really the first H.264 encoder to make use of that feature ???

[Dark Shikari]

Of course? I still remember there was a time when CoreAVC did support Predictive Lossless (as used by x264), but libavcodec didn't do so :p

But it's good to know that libavcodec (and with it dozens of OSS applications) is 100% ready for weight-p :)

As nobody complained about incomplete weight-p support in CoreAVC until now, is x264 really the first H.264 encoder to make use of that feature ???No. Ateme's broadcast encoders are known to use multi-dupe weightp (don't call it weightp, regular weightp is used everywhere).

[Cyber-Mav]

To be clear.... CoreAVC's 1.x CORE beats DivX everytime... its only because of CPU instruction set optimizations that they were faster in 'some' cases.

you cant blame divx for adding cpu instruction set support which coreavc doesnt have implemented yet. my testing showed divx to be faster on the cpu i tested on, cpu had up to ssse3 support.

betaboy do you have a rough idea on what sort of percentage speed difference there is between coreavc 2.0 and 1.9.5?

also iv read that nvidias new cards have purevideo4 support and can do gpu based decoding of mpeg4 video such as xvid files now. is that something that will be added to the cuda support in coreavc2.0? or is coreavc focused on purely h264 decoding?

[squid_80]

CoreAVC = H264 only. If it handled xvid/divx files it would probably be called CoreASP.

[LoRd_MuldeR]

i hope for the 1.9.5 buyer that license upgrade will be free of cost
or.. al least with a significative reduction..

Any comment on this? Or did I miss it ???

[BetaBoy]

I did post it dozens of pages back.. but purchases within the past 60 days of the initial release date includes the 2.0 update. For each of our other 1.x user they will be sent a email with a custom link for a discounted 2.0 purchase.

[buzzqw]

so only earlier buyer of 1.9.5 wil got 2.0 for free ?

BHH

[LoRd_MuldeR]

so only earlier buyer of 1.9.5 wil got 2.0 for free ?

As far as I understand, he means the initial relaese date of CoreAVC 2.0.

So if you bought CoreAVC 1.x right before CoreAVC 2.0 was released (the limit is 60 days), you get updated to 2.0 for free. Otherwise you need to pay ;)

What about licenses you were given for free by the CoreCodec team? Will I have to pay this time? :D

[buzzqw]

bummer.. since there is no eta for 2.0 how i will know that 60 days is kicking in ?

BHH

[BetaBoy]

purchases within the past 60 days of the initial release date

So 60 days prior to the 2.0 release date... so if we release it on Monday.... users who purchased it 60 days prior, will get the 2.0 update included.

[Rumbah]

And there will be no fix for 1.9.5 to play back the new x264 weighted p mode in CoreAVC although the results are spec compliant? So I have to pay again to play back a perfectly fine stream?

[ranpha]

A question of mine is still not answered: Will CoreAVC 2.0 still support Windows XP?

[Shinigami-Sama]

A question of mine is still not answered: Will CoreAVC 2.0 still support Windows XP?

its a direct show filter... of course it'll work in XP...

[BetaBoy]

Correct it will work on XP, Vista, or Windows 7.

[popper]

"16 reference frame limitation"
It's awesome that CoreAVC supports up to 16 refs with CUDA, but could you please make the same support for ATI-graphicscards?

by "the same support for ATI-graphicscards?" i assume you mean Hardware assisted ?

then it has to be assumed thats a NO,
but thats for BetaBoy to confirm or Not OC, as ATI/AMD have Not released their 'UVD HW ASIC' (ATI's equiv of the CUDA HW ASIC)
data sheets to the likes of Core/Betaboy AFAIK ,or any OSS or small 3rd party business todate.

"
Bridgeman said elswere on 10-29-2009, 09:41 PM "One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".
"


and the AMD/ATI OpenCL codebase for actually using the other Gfx hardware and not just the CPU do not exist in a state good enough to use today even if you wanted to.

the latest word is that decode acceleration will be built on top of Gallium3D drivers in the OSS space in some way using the stream processors/Shaders at sometime in the future, no real guesses as to how good that might work, although Bridgman estimates a HD4* will be required , and no word on anyone even trying to code up a 'proof of concept' Gallium3D decode as yet, so theres no real chance of CoreAVC win32/64 using any of these CL/GL/G3D options eather it would seem.

http://www.x.org/wiki/RadeonFeature
"Feature dependency tree

memory manager -+-> KMS -+-> advanced power management (dynamic control of clocks etc..)
| : |
| : +-> run X without root privileges
| :
+-> advanced 3D (OpenGL 1.5+) via chip-specific Mesa code
| :
+-> DRI2 / RDR -+-> Flicker-free 3D with compositing
: |
+-----------+-> Gallium3D -+-> advanced 3D (OpenGL 1.5+, GLSL) via generic Mesa code
|
+-> video decode acceleration
|
+-> OpenCL
"

[JimmyZ]

Unlike CUDA, OpenCL doesn't have a video API for accessing hardware decoders. Writing a new decoder that runs on the stream processors would be a huge task and probably not worth it anyway.

i know i know, but...

http://forum.corecodec.com/viewtopic.php?f=3&t=1915#p10864

well it's been a long time since that post

[popper]

i know i know, but...

http://forum.corecodec.com/viewtopic.php?f=3&t=1915#p10864

well it's been a long time since that post

Posted: 08 Jun 2009, 18:28 "Both CorePlayer and CoreAVC will support OpenCL in their respective 2.x milestone releases."

well in this case you cant really blame Core, this is down to AMD/ATI and their lack of working gfx OpenCL/UVD datasheets for the CoreAVC x86/64 product to make use of.

and i assume CorePlayer running on non x86/64 cpu's means the likes of ARM and the A8/NEON players are co-operating with freely available datasheets to help make use of these and other HW assisted capabilitys they have in their SOC ?

[popper]

CoreAVC = H264 only. If it handled xvid/divx files it would probably be called CoreASP.

it is... or would have been way back when...

but then it was 1st April 2006, 20:32 but dated after dinnertime so does that count!

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


CoreASP, CoreMP3, CoreVC1, CoreAC3, CoreDTS were all on the this is what we would like to do/release list, when they were all younger and full of hope and dreams way back then... :devil: , never did got a confirmed CoreMpeg2 added to that WWWLTD/R list though ,drat :)

[squid_80]

Those all exist in one form or another, in fact most are included as part of CorePlayer.

[lexor]

Betaboy, could you calrify two things for me from the CoreAVC limitations page you've posted earlier:


- 16 reference frame limitation

I thought neuron2 (or someone in his dev thread) found that CUDA only supports a maximum of 15 ref frames, during his CUDA based development. I am going totally by memory here, so could be absolutely wrong.


- MCE focus requires view port focus (limitation removed in CUDA 2.3 and CoreAVC 2.0)

Is CUDA 2.3 a software upgrade (with newer drivers) or is there a separate hardware support for it (if so, I can't seem to find any chart to that effect).


Thank you.

[avivahl]

CUDA 2.3 requires only software (drivers) update.

[BetaBoy]

it is... or would have been way back when...

but then it was 1st April 2006, 20:32 but dated after dinnertime so does that count!

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


CoreASP, CoreMP3, CoreVC1, CoreAC3, CoreDTS were all on the this is what we would like to do/release list, when they were all younger and full of hope and dreams way back then... :devil: , never did got a confirmed CoreMpeg2 added to that WWWLTD/R list though ,drat :)

All those codecs are already in CorePlayer right now (for the most part):
- CoreASP is included for all platforms
- CoreMP3 is included in platforms that don't support DMO, CoreAudio or Audioqueue (like Symbian)
- CoreAC3/DTS is in the process flow for approval by Dolby atm and is available only for Dolby approved OEM licensee's
- CoreWMV (which is VC1 as well) is not released yet
- CoreMpeg2 (or CoreDVD) is available only for our OEM licensee's

At one time we were going to release a bundle of them as directshow filters, but the market had changed to the point it did not make sense, but rather license them out instead for OEM's in library or source code form when open source decoders don't match their business needs.

Noting that for OEM's that each are available as directshow or GStreamer filters.

[Cyber-Mav]

i see nvidia has a beta driver up that has cuda 3.0 update in it. does cuda 3.0 offer any more benefits towards video decode functionality?

[BetaBoy]

Info on CUDA 3.0 is scarce atm, but here is some info: http://www.siliconmadness.com/2009/11/nvidia-preparing-itself-for-fermi.html

No mention on any VP* engine changes though.

[saint-francis]

Will 2.0 have an api allowing DGAVCDecode to use it?

[BetaBoy]

Well... that's a good question and we wanted to open it up since we have extensive API's in our CoreAVC SDK. But the legal team here put a red light to that for reasons I can't go into. We are however looking into other options.

[Audionut]

http://www.nvidia.com/object/win7_winvista_64bit_195.39_beta.html

Adds support for CUDA Toolkit 3.0 features and performance enhancements. See CUDA Zone for more details.

[mkanet]

I use Core's codec to display the TV channel FashionTV-HD which uses 50fps 1080i AVC. Trying to play this back on a 60Hz 1080p LCD display causes some distortion on faster panning scenes. What are the optimal settings for this?

Thanks
MKANET

[JimmyZ]

it is... or would have been way back when...

but then it was 1st April 2006, 20:32 but dated after dinnertime so does that count!

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


CoreASP, CoreMP3, CoreVC1, CoreAC3, CoreDTS were all on the this is what we would like to do/release list, when they were all younger and full of hope and dreams way back then... :devil: , never did got a confirmed CoreMpeg2 added to that WWWLTD/R list though ,drat :)

and by declaring that there will be a "CoreAVC Encoder", this thread can survive in this section, I think it's now the time to move this thread to the "Software Player" section.

[BetaBoy]

All... just to keep you all in the loop.

We are progressing on the installer.... one thing we were not planning but are now glad to get into CoreAVC 2.0, is the new Haali Splitter. We are testing the new capabilities on Windows7 that gives AVC files a higher priority over MediaFoundation.... but please don't hold me to that yet, as we are now testing to see if it functions as expected... and for those that will ask... no this is not some ugly hack, in fact its pretty cool to know it can be done ;-) But i'll hold off a few more days on the details to let QA do it's thing.

Also a big thanx for clsid for working with Blacksun on parts of the installer.

[Guest]

But the legal team here put a red light to that for reasons I can't go into. Why can't you go into them?

[buzzqw]

All... just to keep you all in the loop.

We are progressing on the installer.... one thing we were not planning but are now glad to get into CoreAVC 2.0, is the new Haali Splitter. We are testing the new capabilities on Windows7 that gives AVC files a higher priority over MediaFoundation...

here two pc with win7 available for testing

EDIT: with gt9500, gt9600 and GPU 9400m

BHH

[Inventive Software]

Why can't you go into them?
Probably lose too much money for the company's flagship product, and him mentioning / confirming it would bring the company into disrepute with the consequences landing in his lap.

[Guest]

What is this flagship product you speak of? And why would it bring the company into disrepute?

[BetaBoy]

Without drilling into specifics, its more about having open third party access as it relates to IP. We are however thinking about simply supplying a conduit DLL that we would allow approved third parties application developers to distribute with their Apps. We are still working through the details.

As far as 'Flagship'... CoreAVC is just one part of our "Pangea", CorePlayer and overall just one of dozens of technologies we are working on.... and yes we proceed cautiously (I think this is where Inventive Software was going).

[Guest]

We are still working through the details. In other words it will never happen. :devil:

[BetaBoy]

Not at all.... in fact it could be one of the best things for CoreAVC, from a developer adoption perspective. We just need to meet all the criteria now for legal to sign off on it.

[Cyber-Mav]

hopefully someone will run coreavc 2.0 through some tests to see where it stands in speed vs divx and coreavc 1.9.5
betaboy not possible for you to get some preliminary tests put up?

[BetaBoy]

I'd prefer if you all did that, this way its not seen as being biased.

[Keiyakusha]

Hopefully CoreAVC will be faster everywhere, but speed can be different depending on your hardware. But there will be trial version of 2.0, isn't it? So you can test by yourself if its faster/better/greater/whatever for you.

[BetaBoy]

The trial for CoreAVC 2.0 will be released after the initial 2.0 version is released in case we need to do a quick follow-up with any changes/fixes/etc.

[Cyber-Mav]

is coreavc 2.0 still scheduled for release on 21st december?

[BetaBoy]

Its just installer work atm... but we did add a new feature to the options dialogue today to match Haali's new splitter capabilities. So we are talking days for the 2.0 release... not weeks or months.

[STaRGaZeR]

Does the new HMS have any splitter related improvements? TrueHD support, fixing of M2TS LPCM bugs, etc.

[BetaBoy]

I'll let Haali know about your post to elaborate on that.

[clsid]

I have just one sample file with TrueHD audio, but it the new splitter does not yet detect it.

[STaRGaZeR]

Thanks BB.

clsid, do you want more? But I bet they won't work, as the TrueHD muxing method has not changed at all with different versions of mkvmerge.

[Mixer73]

I'm personally hanging out for 2.0 and integration with 7. I feel that my upgrade to Windows 7 has resulted in poorer performance with playback of AVC files than I enjoyed with Vista and CoreAVC installed.

I'm not sure what all sniping and bitching is about, CoreAVC is a great product in my opinion and amazingly cheap. If I have to upgrade to 2.0 for $10 or whatever its gonna cost, so be it, I was a fairly recent purchaser of 1.9.5, but I already got what I paid for.

I chose to change OS and I was hoping I wouldn't need any additional codecs but I'm now not sure.

[clsid]

If you would like me to test more samples, just upload them. The current one I have is an .mkv file.

[BetaBoy]

Does the new HMS have any splitter related improvements? TrueHD support, fixing of M2TS LPCM bugs, etc.

Haali has told me the latest splitter fixes those issues... however we just found a few more that's related to the Windows 7 support that was added.

One forward, one back ;-)

[Snowknight26]

Does it fix this issue (http://forum.doom9.org/showpost.php?p=1332512&postcount=938)? Would love to see some back and forth debugging sessions instead of waiting months to yield nothing fruitful.

[STaRGaZeR]

Haali has told me the latest splitter fixes those issues... however we just found a few more that's related to the Windows 7 support that was added.

One forward, one back ;-)

Good. You can tell him about the two samples below to see if they're indeed fixed.

If you would like me to test more samples, just upload them. The current one I have is an .mkv file.

Do you have the lastest splitter BB is talking about? You can test the samples too.

Would love to see some back and forth debugging sessions instead of waiting months to yield nothing fruitful.

+1. BB, can't you just tell Haali to come in here and discuss the bugs with us? Some beta testing would be great too.


MKV, H.264, 2 TrueHD tracks, remuxed from BD. Audio tracks not recognized by HMS: http://www.megaupload.com/?d=5ULGN0RN (22 MB)

M2TS, H.264, LPCM 2.0, straight from the BD. The audio track is not recognized by HMS: http://www.megaupload.com/?d=SSE19JNZ (44MB)

[Mixer73]

Haali has told me the latest splitter fixes those issues... however we just found a few more that's related to the Windows 7 support that was added.

Dan, has it fixed the 'crashing windows with explorer thumbnail integration' bug?

[BetaBoy]

Yes, that's fixed.

[THX-UltraII]

Yes, that's fixed.

Betaboy, do you have a releasedate for Haali Media Splitter 2.0? I have a problem with the current 11-01-2009 version:

When I run a .m2ts file that I muxed from the original BD I select the subtitles I want but they are not displayed.

Will this be fixed with 2.0?

[BetaBoy]

Haali is fixing the bugs as we go into the final CoreAVC 2.0 release. As far as what other bugs are fixed, I think from what he has done so far, has addressed most of them. We have a few more days to go it seems before the CoreAVC release and he is monitoring this thread, so...

[THX-UltraII]

ok, so Haali Media Splitter will be available as separate download too like before?

[BetaBoy]

Sure... No diff then it is now.

[leeperry]

Haali is fixing the bugs as we go into the final CoreAVC 2.0 release. As far as what other bugs are fixed, I think from what he has done so far, has addressed most of them. We have a few more days to go it seems before the CoreAVC release and he is monitoring this thread, so...
improving the 23.976 jitter problem in MKV files and Reclock would be awesome(25 and 29.97 are dead stable but 23.976 is a jitter party), he's well aware of the problem..I've explained it to him on many occasions :o

fixing other bugs in HR would be nice too(ghost lines due to bad PS script sum(1.0 instead of 0.8, which fixes the bug in the PS3 resizing code...PS2 works fine), bad BT601/709 coeffs, etc etc)..but well :devil:

[saint-francis]

I can't believe I forgot to ask this in my last post, but.... 64 bit support for CoreAVC and Haali splitter?

[BetaBoy]

The 2.0 release features both 32/64bit support for CoreAVC and Haali's splitter.

[vwpassion]

Will 2.0 support out of spec MV's which could sometimes produce glitches?

[BetaBoy]

All limitations on MV's have been removed in 2.0.

[ssgg]

x264 core 79 r1332
encoded files doesn't seem to work properly with coreavc 1.95. macroblocks appears every so often.

just read the other posts. guesss my anime is being encoded with weightp = 2 now

[tal.aloni]

BetaBoy, Haali,
clsid have confirmed that his revision of Haali Media Splitter 2.0 still won't detect audio in the following m2ts samples (untouched from "The Sound of High Definition" Blu-Ray, MPC-HC does detect the audio)

DD+:
http://iknowu.net/files/public/Samples/00026%20-%20DD+%207.1%20Channe%20Test.m2ts

TrueHD:
http://iknowu.net/files/public/Samples/00009%20-%20TrueHD%20Introduction.m2ts

I would appreciate if this could be resolved,
Thanks,
Tal Aloni

[Dark Shikari]

All limitations on MV's have been removed in 2.0.Er, I don't think we did, unless someone else has been changing something without telling me :p

[BetaBoy]

Er, I don't think we did, unless someone else has been changing something without telling me :p

Ok.... that's a me bad then. I thought it was from my notes.... I should have confirmed it with the SVN logs.

/me now goes back and changes the readme and changelog.

[STaRGaZeR]

Er, I don't think we did, unless someone else has been changing something without telling me :p

We? :devil:

[khat17]

200+ pages.........lots of reading. No I didn't read them all.

Anyways - my rig is available to you for testing. Purchased DivX so have that to use for testing decoding of h264. Also have CoreAVC Pro, so can test with that if you like. Also have an ATI HD4870 and an 8800GTS in my wife's machine (gave her since I got 4870) so I can test hardware decoding on those using MPC-HC with DXVA. PM me if you want me to do any testing with anything listed.

RE: FFDSHOW and COREAVC - as was previously posted, CoreAVC does a better job. FFDSHOW is an EXCELLENT free alternative IMO - and with MPC-HC supporting DXVA, there's no need to buy PowerDVD's $100 version to use hardware decoding.

As for CoreAVC Pro - 1.9.5 is the last one that I updated. Nothing new since then.

[honai]

I guess DS is doing some last-minute freelance debugging for CoreCodec so that this time they can actually deliver what they promised. ;-)

[BetaBoy]

Last minute? Promised? Pls take the flame elsewhere.

[hydra3333]

Well i 4 1 am certainly eagerly anticipating procuring this thing !
Can't really understand why some seem to want to flame.
Why bother - what does it achieve apart from making the poster feel better and look like a little kiddie with tantrum issues ?

[honai]

I'm a paying customer, it's simple as that. I do understand that the vast majority of software discussions in this forum revolve around bugs and issues in free, open-soure software, and I am indeed grateful for the time people like madshi, albain and many others invest in perfecting their freeware. And I would never, ever demand anything from them because I know myself how precious time is when you have another full-time job and yet do moonlighting as well.

Having said that, it's a totally different matter with CoreAVC. BetaBoy may call it "flaming", but as a paying customer since CoreAVC 1.0 (and actually I bought several licenses) I do take issue with the way CoreCodec is conducting business, and promising and delaying and promising etc.

And now, so it seems, shortly before release (or is it?), we get to know - surprise! - that Dark Shikari is doing bug-fixing for CoreCodec. Let me repeat this: months (!) after BetaBoy stated in this forum that basically they are finished and all (!) known bugs were fixed, and that it were only the release of Windows 7 that were holding them back, we get to know that they had to bring in a freelance consultant to actually squash bugs.

If my confidence in the capability of BetaBoy engineers weren't already shaken, with a history of years (!) of unfixed bugs that in other products were resolved within a single release cycle (!), it would be now.

Also, let me state the main point again: it's not that I'm demanding perfection or raising unrealistic expectations out of thin air. It's simply the fact, and this can be easily verified by browsing this thread, that, what, 6 months ago BetaBoy himself raised expectations about CoreAVC 2.0 being "finished", "bug-free", and so on.

Pointing this out is not flaming, but normal behavior from a normal customer. Just like every other customer has done with, say, any product from Microsoft in the last 10 years. Or are those who pointed out the deficiencies of Vista (and to which Microsoft replied with Windows 7) also flamers? That is what is ridiculous.

[khat17]

I'm yet to see "perfect" software. Maybe "PerfectDisk" is perfect. Heh. I have no issues with CoreAVC - I hardly use it anymore since free players have DXVA and VAAPI/VDPAU abilities. If CoreAVC will have encoding abilities, then I'll look back at it. I think CoreAVC has a filter to allow hardware decoding, but I've still not installed it in a while. Outside of having additional things installed on my machine, I don't have a problem with the program. You say you're not "flaming" or complaining really, but aside from a few bugs - which are eventually fixed - and delays in releases, what issues do you have with the app itself?

@BetaBoy - Do you plan to develop a codec for H264 instead of just a decoder?

[BetaBoy]

This thread for us has been an outstanding resource for amazing feedback... some would say its more like a heartbeat of what is going on with CoreAVC, take that as being good and or bad in building anticipation/disappointment. I like to think its good since it is not OS and there is no means to browse the source code for all the changes we have done. But we are very open to the fact that we have said that CoreAVC 2.0 would not come out till its ready. Now with two things, ie; Windows 7 out and the more recent changes to x264, this has pushed the release to come out now ( and to that, Haali is making his changes and we are testing the latest drops with a few of the Doom9 Elite).

honai... To come out and state there has been "years of unfixed bugs" in 1.9.x is simply untrue, a few sure but I think the D9's would have screamed if any major issues were left unfixed. CoreAVC 1.95 is/was the most stable and bug free version we had ever released (outside of us controlling any issue with the CUDA SDK's). As I have stated this several times in this thread, we have made it a point to work with x264 to align what CoreAVC's capabilities are, to match it. As far as Dark Shikari he has always been a friend and we value his input, but squashing 'last minute bugs'? You could not be any more wrong (but nice guess/flame).

khat17... we will have both H.264 and AAC encoders next year. But they will not be a stand alone products, but rather be integrated into the CorePlayer/CoreUI/CoreOS Platforms.

We continue to thank the community for their continued support and amazing feedback.

[BetaBoy]

BetaBoy, Haali,
clsid have confirmed that his revision of Haali Media Splitter 2.0 still won't detect audio in the following m2ts samples (untouched from "The Sound of High Definition" Blu-Ray, MPC-HC does detect the audio)

DD+:
http://iknowu.net/files/public/Samples/00026%20-%20DD+%207.1%20Channe%20Test.m2ts

TrueHD:
http://iknowu.net/files/public/Samples/00009%20-%20TrueHD%20Introduction.m2ts

I would appreciate if this could be resolved,
Thanks,
Tal Aloni

Fixed.... thx for the samples.

Haali also noted he I can't reproduce the crash when removing the splitter from graph. So that's still a open issue.

[honai]

"years of unfixed bugs" in 1.9.x is simply untrue

but then

a few sure

Exactly what I said.

but I think the D9's would have screamed if any major issues were left unfixed

As it happens, "the" D9s did "scream", including yours truly, and you repeatedly chose to either accuse us of "flaming", or deny that issues exist, or promise to have them fixed in 1.1 ... no, 1.2 ... wait, 1.6 ... ok, but this time, you're going to have them all fixed .. in 1.95 ... no, wait, for some reason they had to be pushed back to 2.0. ... Maybe.

CoreAVC 1.95 is/was the most stable and bug free version we had ever released (outside of us controlling any issue with the CUDA SDK's). As I have stated this several times in this thread, we have made it a point to work with x264 to align what CoreAVC's capabilities are, to match it. As far as Dark Shikari he has always been a friend and we value his input, but squashing 'last minute bugs'? You could not be any more wrong (but nice guess/flame).

You announced back in August that CoreAVC were ready and just awaiting final QA for the installer, and it's November and you're only now finalizing the product. I think "last-minute" is the perfect term, considering that you admit a few posts back that Haali is still working on fixes. And Haali Splitter is actually part of the product you're selling to your customers, and you're paying Haali to work on the Splitter, right?

we will have both H.264 and AAC encoders next year.

Exactly what I meant. Another promise with a concrete time estimate. Why do you continue to promise things?

Anyway, I made my point. In the past I purchased 5 licenses of CoreAVC, and at this point I won't be purchasing any more given the business tactics that your corporation chose.

[Guest]

@honai

What are the outstanding unfixed bugs that have you in such a lather?

[honai]

@neuron2

Besides the bugs and issues mentioned in this thread (and which BetaBoy promised would be fixed in 2.0), take a look here:

http://forum.corecodec.com/viewforum.php?f=3&sid=4807fc9ba4a16e5c8ff53de50521ec6f

Also, and this has also been mentioned by Dark Shikari in another thread, 1.9.5 does not support recently introduced in-spec (!) weight-b modes (he also mentions that only CoreAVC and AppleTV don't support them, while all other decoders they inspected do, even the free ffdshow).

Plus, and I know this has been discussed to no end, only 2.0 will now begin to support out-of-spec MVs. While in the past BetaBoy denied that this is something they have to deliver, they now chose to implement support in 2.0 anyway.

I'm not expecting CoreAVC to be a perfect product, but again, as a paying customer I am indeed "in such a lather" simply for the fact that in the past BetaBoy promised to have outstanding issues fixed "in the next release". Again and again.

Also, I'd appreciate it if it were acknowledged that I'm not talking out of my a** when criticizing CoreAVC. Please take a look here:

http://forum.doom9.org/showthread.php?p=1298469#post1298469

Also, CoreAVC's x86 idct8 is rather crappy as well.

Is his a valid criticism only because of the name attached to the quote? Or why is it that as a paying customer I am not entitled to criticize the product, but instead get accused of "flaming" without a moderator stepping in to his clear violation of forum rules (cf. rude behavior)?

[Guest]

@honai

Discussion of rules and their enforcement is prohibited by rule 17. You can send a PM to a mod about it or report the post.

I asked for you to tell me the "longstanding bugs" which haven't been fixed. Can't you do that? I don't have time to read an entire forum. Just tell me the 3 worst ones. Thank you.

BTW, I don't consider lack of support for out-of-spec streams to be a bug, nor do I consider a slow IDCT to be a bug.

You claimed long-standing unfixed bugs. What are they?

[Dark Shikari]

Is his a valid criticism only because of the name attached to the quote? Or why is it that as a paying customer I am not entitled to criticize the product, but instead get accused of "flaming" without a moderator stepping in to his clear violation of forum rules (cf. rude behavior)?It's crappy because Holger or I haven't written a better one yet ;)

[honai]

I don't have time to read an entire forum. Just tell me the 3 worst ones. Thank you.

I'm not going to jump over that stick.

It's really very simple: In the past I have paid for five (5) licenses of CoreAVC. I have written in this thread and in the CoreCodec support forum (under a different name), as have countless other customers of CoreCodec, about issues and bugs that are not fixed until now. For several releases BetaBoy has promised that those will be addressed in the next release. He also repeatedly announced a new version 2.0 "around the corner" since summer 2009. It's now November, and still no 2.0.

If you want to strike me for not playing your games, fine.

If your point is simply that I should take customer support issues to CoreCodec's forum, please tell so. Otherwise I'd assume that a Doom9 thread with the name "CoreAVC", opened up by the boss of CoreCodec, is indeed for discussing shortcomings of CoreAVC.

[Guest]

If you want to strike me for not playing your games, fine. You claimed several longstanding unfixed bugs. I simply asked what they are. You refuse to answer and instead claim that I am playing games. I will leave it at that as the readers can judge where the beef is or is not.

[BetaBoy]

honai... For any post consumer sales purchases problems, we welcome any reports at our Support Center @ http://support.corecodec.com . The Team here takes pride in helping and is very aggressive in addressing any issues with the engineering staff and me.

[hydra3333]

Anyway, I made my point. In the past I purchased 5 licenses of CoreAVC, and at this point I won't be purchasing any more given the business tactics that your corporation chose.

You're free to feel that way if you want to. I find it's generally not worth getting too upset over these things, in life you tend to get better results with a calmer tone than otherwise... it's also better for your health. If the new version has extra goodies over the current version, and the price is reasonable then I'll buy one.

[popper]

Well... that's a good question and we wanted to open it up since we have extensive API's in our CoreAVC SDK. But the legal team here put a red light to that for reasons I can't go into. We are however looking into other options.

put simply, your extensive API's talked directly with other 3rd partys closed proprietary API and Hardware... in some cases, in such a way as to forbid other non signing 3rd partys from using all your extensive API's as it stands now....

your legal team wont sign off that/your dual commercial API and so your looking to provide a subset of your extensive API's that does not in any way touch these closed [licenced for money] proprietary API's...

in other words Your thinking of producing a newer subset of your 'extensive API' thats not so extensive, and in doing so, then allowing OSS 3rd partys and the like to use what is OK to touch without paying ?

[khat17]

I'm a paying customerAs are others of us.

Also, let me state the main point again: it's not that I'm demanding perfection or raising unrealistic expectations out of thin air.But it seems that way.

Pointing this out is not flaming, but normal behavior from a normal customer. Just like every other customer has done with, say, any product from Microsoft in the last 10 years. Or are those who pointed out the deficiencies of Vista (and to which Microsoft replied with Windows 7) also flamers? That is what is ridiculous.You're entitled to your opinion. If CoreAVC wasn't doing what you needed, you should have found an alternative. I purchased CoreAVC when I needed a good software decoder to use. Since I got the hardware and CoreAVC didn't have hardware decoding at the time, I looked elsewhere. If it works - don't complain - be grateful someone spent the time and creativity to do it. Pay for it if they need the money to go towards development. Be extra grateful and probably donate if it's free and you use it lots.

I'm yet to see "perfect" software. Maybe "PerfectDisk" is perfect. Heh. ..................... You say you're not "flaming" or complaining really, but aside from a few bugs - which are eventually fixed - and delays in releases, what issues do you have with the app itself?

Still waiting to hear what issues you have with using the actual app.

You claimed several longstanding unfixed bugs. I simply asked what they are. You refuse to answer and instead claim that I am playing games. I will leave it at that as the readers can judge where the beef is or is not.

I've seen many updates till 1.9.5 - waiting for the next update. I have no issues with the software - just that the new DivX does a better job IMO for decoding the poorly encoded ones - and for properly encoded ones hardware decoding is best.

honai... For any post consumer sales purchases problems, we welcome any reports at our Support Center @ http://support.corecodec.com . The Team here takes pride in helping and is very aggressive in addressing any issues with the engineering staff and me.

There you have it. If you have problems the developers will listen. I haven't had need to contact CoreAVC - I just looked elsewhere when it wasn't doing what I needed. Persons who are complaining should look into the link.

put simply, your extensive API's talked directly with other 3rd partys closed proprietary API and Hardware... in some cases, in such a way as to forbid other non signing 3rd partys from using all your extensive API's as it stands now....

your legal team wont sign off that/your dual commercial API and so your looking to provide a subset of your extensive API's that does not in any way touch these closed [licenced for money] proprietary API's...

in other words Your thinking of producing a newer subset of your 'extensive API' thats not so extensive, and in doing so, then allowing OSS 3rd partys and the like to use what is OK to touch without paying ?

So technical...........so basically they need to work on getting some of the API's setup in a way that people can use them open source without violating whatever legal mumbo-jumbo is there for the paid parts - right? Anyways, that don't really concern me. It will concern me if it means that there will be development of better decoders and encoders down the line.

[popper]

Without drilling into specifics, its more about having open third party access as it relates to IP. We are however thinking about simply supplying a conduit DLL that we would allow approved third parties application developers to distribute with their Apps. We are still working through the details.

As far as 'Flagship'... CoreAVC is just one part of our "Pangea", CorePlayer and overall just one of dozens of technologies we are working on.... and yes we proceed cautiously (I think this is where Inventive Software was going).

ohh so it is as i said..., your current API gives away to much control of, and access to closed 3rd party pay for API's, from the likes of Arm vendors , and other SOC makers/licences IP id imagine.

so your equating your current extensive API's as the newer "Pangea" 'permian age', and the new subset your Thinking of making are your laurasia/Gondwanaland 'triassic age'.
with 'one and only one' clear restrictive path to take in eather direction and a mass of water stopping you making new 'faster' 'message passing' routes to and from you destination.
http://geology.com/pangea.htm

or even a sub,subset 'present day' with all its chaotic bits? [Chaotic Bits (Chabits) in Quantum and Chaos Computing] a clear non supercontinent.

its funny how you can visualise "Pangea" and the other ages, relating them to the computing age, and lessons learned, or Not, as the case may be....

[plonk420]

i'm just a bit dismayed the weightp w/ dupes isn't going to be in the 1.x version series and that i'm going to have to pay for it. my HTPC currently is CUDA-able, but i'm not sure it's going to stay that way (i'll see once ATI releases budget 5000 series)... i'm using it without CUDA, currently.

[popper]

Not at all.... in fact it could be one of the best things for CoreAVC, from a developer adoption perspective. We just need to meet all the criteria now for legal to sign off on it.

hmm but seriously does a "best things for CoreAVC" corrolate with a matching 'best things' for a open 3rd party "developer adoption perspective" ?

clearly you cant give these open devs access to sections of these off limits pay for API in your current API.

unless all these API vendors also provide, in concert with you to write a new sub API that can interact with or become part of your new sub API.... in full Open co-operation and free useage.

as a basic simple example, does any of your API 3rd partys provide a hardware assisted SAD and related API calls that such as x264 and ffmpeg could then use as an option, to massively reduce the 30% SAD usage they use today for Encoding AVC etc for instance.

and will your New API even consider putting such HW assisted API options into your API product in an open mannor for all to use...

[popper]

All limitations on MV's have been removed in 2.0.

surely you mean all Known (to you!. or assumed by you OC as it appears an everyday mistake was made, as we all do now and then) limitations have been removed?

[popper]

I'm a paying customer, it's simple as that. I do understand that the vast majority of software discussions in this forum revolve around bugs and issues in free, open-soure software, and I am indeed grateful for the time people like madshi, albain and many others invest in perfecting their freeware. And I would never, ever demand anything from them because I know myself how precious time is when you have another full-time job and yet do moonlighting as well.

Having said that, it's a totally different matter with CoreAVC. BetaBoy may call it "flaming", but as a paying customer since CoreAVC 1.0 (and actually I bought several licenses) I do take issue with the way CoreCodec is conducting business, and promising and delaying and promising etc.

And now, so it seems, shortly before release (or is it?), we get to know - surprise! - that Dark Shikari is doing bug-fixing for CoreCodec. Let me repeat this: months (!) after BetaBoy stated in this forum that basically they are finished and all (!) known bugs were fixed, and that it were only the release of Windows 7 that were holding them back, we get to know that they had to bring in a freelance consultant to actually squash bugs.
If my confidence in the capability of BetaBoy engineers weren't already shaken, with a history of years (!) of unfixed bugs that in other products were resolved within a single release cycle (!), it would be now.

Also, let me state the main point again: it's not that I'm demanding perfection or raising unrealistic expectations out of thin air. It's simply the fact, and this can be easily verified by browsing this thread, that, what, 6 months ago BetaBoy himself raised expectations about CoreAVC 2.0 being "finished", "bug-free", and so on.

Pointing this out is not flaming, but normal behavior from a normal customer. Just like every other customer has done with, say, any product from Microsoft in the last 10 years. Or are those who pointed out the deficiencies of Vista (and to which Microsoft replied with Windows 7) also flamers? That is what is ridiculous.

sure, and perhaps its not your fault for not realising or considering that a LOT changes in 6 months in the AVC, and especially x264 Encoding circles.

x264 can do a Lot more than it did 6 months ago, and is only getting better and more quality options as time passes.., do you advocate Core and other vendors freeze their v2.0 decoders to Open AVC Encoder development options to what only existed 6 months ago ?

if so, how do you propose to play back todays more advanced x264 AVC encoded content using Encoder options that didnt exist 6 months ago?, buy a new version with the last 6 months x264 updates available to it sometime in the near future ?, and then buy again 6 months from now?....

or perhaps you want to ban the free x264 Encoder development from being first to add the missing parts of the AVC/H.264 spec for your open and free use today, as they Might provide things the commercial consumer deciders cant cope with yet....

[popper]

I'm not going to jump over that stick.

It's really very simple: In the past I have paid for five (5) licenses of CoreAVC. I have written in this thread and in the CoreCodec support forum (under a different name), as have countless other customers of CoreCodec, about issues and bugs that are not fixed until now. For several releases BetaBoy has promised that those will be addressed in the next release. He also repeatedly announced a new version 2.0 "around the corner" since summer 2009. It's now November, and still no 2.0.

If you want to strike me for not playing your games, fine.

If your point is simply that I should take customer support issues to CoreCodec's forum, please tell so. Otherwise I'd assume that a Doom9 thread with the name "CoreAVC", opened up by the boss of CoreCodec, is indeed for discussing shortcomings of CoreAVC.

what!, the question seems clear enough, tell him and the readers your perceaved "3 worst ones" as regards Your "longstanding bugs"...

perhaps if you actually state them right here ,right NOW and provide a small sample for download showing these perceaved bugs, then they may or not get fixed to your satisfaction ready for this release!

[squid_80]

put simply, your extensive API's talked directly with other 3rd partys closed proprietary API and Hardware... in some cases, in such a way as to forbid other non signing 3rd partys from using all your extensive API's as it stands now....

your legal team wont sign off that/your dual commercial API and so your looking to provide a subset of your extensive API's that does not in any way touch these closed [licenced for money] proprietary API's...
CoreAVC does not make use of any "closed proprietary" APIs.

[Guest]

If they offer an SDK for sale, how can there not be a closed API? I'm just trying to understand the situation, which BetaBoy cannot "go into".

[squid_80]

put simply, your extensive API's talked directly with other 3rd partys closed proprietary API and Hardware... in some cases, in such a way as to forbid other non signing 3rd partys from using all your extensive API's as it stands now....All I meant was that this assumption isn't true.

[popper]

i'm just a bit dismayed the weightp w/ dupes isn't going to be in the 1.x version series and that i'm going to have to pay for it. my HTPC currently is CUDA-able, but i'm not sure it's going to stay that way (i'll see once ATI releases budget 5000 series)... i'm using it without CUDA, currently.

why so ?, weightp w/ dupes didnt exist back then, so whats the problem ?

using ATI/AMD wont help you in the slightest, they wont release their "UVD ASIC" documentation API.

so only 'CUDA ASIC' is a viable option even after all this time and Hardware assisted OpenCL doesnt even run on ATI cards/GPUs today

and ATI/AMD or any 3rd party have not as yet even produced any of the other Gallium3D DRI Support parts for such Hardware decode assistance in the near future.

theres not even been any "Proof of concept" code been produced or seen in public, plus their talking of a full 12 months from now before that Gallium3D + HW asssisted code may or not be an option in the OSS land....

with talk of some potiential review of perhaps looking into releaseing some form of UVD ASIC API documentaion be it a sub set or something new into the open driver code base sometime after Gallium3D is stable.

then your far more likely to see a fully working and mass produced cheap brand new NVidia Fermi Gfx chip with its Unified memory space and related SIMD options API becoming available and someone actually producing some HW assisted Encoding/Decoding for that OpenCL, hell somone might even write a working and even good SAD and related optimised code for it,long before you get any REAL ATI H@L4.1 capable HW assisted API from AMD for general OSS use.

will Core be looking into and trying to use Fermi HW assisted capabilitys when the times right ?

as i understand it, although info's rather limited right now, their Unified memory space can look into and use the CPUs mapped memory too, and so save some cycles not moving small data sets and messages to the Gfx card....in some cases, but time will tell....

[popper]

All I meant was that this assumption isn't true.

i just mean that you can make a new (good?) API working with your HW partners to take full advantage of their low level HW etc,with the intent that you would provide your API to 3rd partys for free in some cases (non profit,personal etc).

then you later discover that your HW partners etc didnt realise you were going to allow both paying and non paying 3rd party devs/partys to use all the new APIs calls..rather than a subset of them.

you can end up in a position that you are allowing access to the HW vendors bits of their "black Box" that they dont want people outside the profit circle knowing about.....

it seems thats exactly what happened to ATI/AMD and their 'UVD ASIC' they cant let you have the documentation, because as it stands, they didnt see fit or think of the long term benefits to totally seperating out their DRM HW ASIC from the far more useful HW assisted decoding ASIC bits... its all inside the one generic ATI UVD ASIC.

and they dont have a subset of the API in all this time to give out and allow anyone access that doesnt sign the legal NDA papers....

even though there are masses of AMD/ATI UVD cards out there today, and lots of people wanting to use what they payed for to use the HW decoding UVD bits without ever touching the DRM bits..for their own non DRM encodes.

[Maccara]

I have only single question:

I paid for H.264 high profile support, and now you're saying the product paid for and advertised as such (still says so at corecodec pages) will not get that support, but instead I need to pay more for a new version which may have some additional features I may have no need for?

It does not matter one single bit if any encoder actually utilized all the high profile features - the specifications have been available all the time. The fact that some encoder now adds more _spec compliant_ features which break the decoder, I expect it to get fixed to deliver what was promised in the first place.

I don't know what additional improvements there are in 2.0, nor do I care - I just want the features I already paid for. Such bugfixes (I consider it a bug, if the decoder which was supposed to be compliant, isn't) should be backported.

Otherwise I have been happy with the product and it has been doing what I need it to do. I may even upgrade to the new version, if it has some real added value (I need to evaluate that), but I will not pay just for bugfixes (especially, since there are free alternatives).

[Hans Ohlo]

are there any speed comparisons between CoreAVC x86 and x64?

[Sharc]

i'm just a bit dismayed the weightp w/ dupes isn't going to be in the 1.x version series and that i'm going to have to pay for it.... .
I second this. The current 1.9.5 should come as a free bugfix for weightp compliancy (w/o depending on CUDA).

[plonk420]

why so ?, weightp w/ dupes didnt exist back then, so whats the problem ?

i guess i take for granted the speed at which FOSS moves. i'm guessing i won't get an 20 month old build of MPC HC to play it in hardware, but it plays it in software (unless the decoder is simply (somehow) skipping the weightp+dupes). i'd try it with a 14 month old CCCP Project/ffdshow, but it's wanting me to reboot to get it to work.

[hydra3333]

My goodness there's a lot of spleen on display from a poster or two. Jeepers anyone would think they've paid new car prices or something. Oh well, just pay a few pennies when it is released and be happy. Is there a consolidated changelog so I see what I'm getting for my money ?

[dimitrik]

Honestly all the complaining is just getting excessive. As far as I can tell CoreAVC is a nightmare for product management, what with the standard's specifications constantly evolving and customers' expectations of perfection.

I think clearly when a customer buys a product that product is supposed to do what it says on the box at the time of purchase. If the spec changes a month later that doesn't automatically guarantee it'll be supported but it seems as if CoreCodec have in fact done their best to keep up with the standard specs and I for one have not had to pay for a version upgrade from my initial purchase (I think 1.6).

Now enough of the defense. Let's look at the other side. I think a lot of the complaining stems from poor customer communication.

Of all the tech companies whose products I buy, I struggle to think of one with customer comms worse than CoreCodec.

It's important to understand that customer communication is powerful tool, so powerful you can chop your arm with it.
Customers are educated and trained in their expectations by this. It's great to help you sell a new product for which the market is immature. It's bad when you increase customer's expectations by promising things like features and release dates and consistently failing to meet them. Especially when you don't have to.

Remember the promised "hardware acceleration support" that turned out to be for nvidia only? Which few people use in HTPC's which has to be a good chunk of your consumer clientele. Now I personally think HA is totally unimportant with today's and even yesterday's processors, but you went and promised your customers, got them all excited and then delivered halfway.:rolleyes:

Same goes for v2.0. I've been hearing about an imminent release since forever (well months anyway) and even two weeks ago you said it would be the previous week. Honestly it's as if you don't learn. Just tell people it'll be a few months and then give them a nice surprise if you deliver early. It worked for MS with Win7. Do an interim beta release like DivX are doing to keep people interested if you want.

By setting expectations you are not ready to deliver, you are actually paving the way for competitors to come in and go after the customers you trained. Take it from someone who's been in market strategy for a long time, there is no benefit in advertising too long before you're ready to sell.

Please don't get defensive about this comment. I'm offering some constructive advice, because it's silly to have the top product in the market and always have some of your customers pi**ed off at you.

[Dark Shikari]

Honestly all the complaining is just getting excessive. As far as I can tell CoreAVC is a nightmare for product management, what with the standard's specifications constantly evolvingConstantly evolving? What?

CoreAVC doesn't (nor does basically anyone else) support any of the recent additions to the spec (SVC and MVC). With the exception of Predictive Lossless, everything in the spec that CoreAVC and libavcodec supports is identical to how it was in 2005.

[BetaBoy]

and the flames continue... In the end 2.0 will be out this week. Dark Shikari... Thx was gonna jump in and say something similar.

Popper... on the API's... I think you misunderstand and while I would love to be able to go into detail about it I think what I have said is about the limit we feel comfortable with.

On Pangea... it's the project name for CorePlayer as we have begun to break out many of the components and tools that we have created for it into separate products: CoreMAKE (already out), CoreUI, CoreOS, Codecs, Corenect UPNP (already out), CoreIO (network), CoreTheque (db), LibEBML2, LibMatroska2, etc.

Any mod want to delete 'ney2x' intentional flame?

[tal.aloni]

Constantly evolving? What?

I think dimitrik is confused because of this forum post:
http://forum.corecodec.com/viewtopic.php?f=3&t=69

BetaBoy, You may want to rephrase the last sentence there.

BetaBoy, Haali, Thanks for adding support for TrueHD / DD+ in m2ts, looking forward to the next version of the splitter.

[Guest]

Any mod want to delete 'ney2x' intentional flame? Deleted and struck.

[BetaBoy]

I can clarify it no problem. Thanx neuron2.

[Killerattacks]

I'm using a ATI HD4xxx and those obviously don't support nvidias proprietary CUDA-Framework. Now that both nvidia and ati (and other manufacturers) have both OpenCL implementations are there any plans for a CoreAVC version based on OpenCL? I don't understand all this nvidia exclusive support at all. It's not like they are paying you, you limit your possible customers by ~50% and it's not like there wasn't ATI's Stream gpgpu Framework around when OpenCL was still in development.

[Dark Shikari]

I'm using a ATI HD4xxx and those obviously don't support nvidias proprietary CUDA-Framework. Now that both nvidia and ati (and other manufacturers) have both OpenCL implementations are there any plans for a CoreAVC version based on OpenCL? I don't understand all this nvidia exclusive support at all. It's not like they are paying you, you limit your possible customers by ~50% and it's not like there wasn't ATI's Stream gpgpu Framework around when OpenCL was still in development.OpenCL doesn't expose the GPU video decoder hardware necessary for playback.

[khat17]

So - will there be ATI support later on or no? Any idea when? Recently purchased a 4870 for myself and gave my wife my 8800GTS - so I have both GPU's at my disposal. Am I gonna have to install CoreAVC on her machine to use the features if I so desire later on? Or will there be support? (redundant with the question I know......)

[ranpha]

From http://www.avsforum.com/avs-vb/showpost.php?p=17283441&postcount=38


Also on a side note for hardware acceleration... we will also be releasing OpenCL support sometime during the CoreAVC 2.x. which both ATI and NVIDIA supports.


There will be OpenCL support in the future, although how CoreCodec will do it is pretty much a mystery.

But knowing their schedule, you may wait at least another couple of years then.

[Killerattacks]

@Dark Shikari, ranpha

Thanks four your answers.
And seems like only time will tell then.

[popper]

DS said:OpenCL doesn't expose the GPU video decoder hardware necessary for playback.

So - will there be ATI support later on or no? Any idea when? Recently purchased a 4870 for myself and gave my wife my 8800GTS - so I have both GPU's at my disposal. Am I gonna have to install CoreAVC on her machine to use the features if I so desire later on? Or will there be support? (redundant with the question I know......)

theres the thing, no one can really know if, or when, not even BetaBoy not unless hes doing one of the below and im pritty sure he's not or something would have been seen by now.

i give you probably all the curent data and quotes needed as a one off, to see the patern ATI/AMD have followed to date and for the last 10 months:

all we can do is take what we know already and conclude most likely NO Never ATI HW UVD decode, and very unlikey anything else OpenCL/using conventional shaders, extending
-- VA-API
-- VDPAU
-- XvBA
-- XvMC
etc for ATI AVC/VC-1,Mkv HW assisted decode .

not unless some 3rd party OSS devs once again try and make the really hard effort to bring something realtime+ usable frame accurate decode and Encode for the most needed parts, sometime sooner than later (and im not talking yet another 12 months with nothing to speak of in the H@L4.1HW assisted Encode department).

as DS said OpenCL doesnt make it any easyer to attach to the 'ATI UVD ASIC' HW found in all current and last gen cards.

bridgman the AMD exec for Linux open and closed dev work and documentation again states 10-29-2009, 09:41 PM
"bridgman said:One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".

and again he stated 10-31-2009, 05:36 PM
"bridgman said: ... that UVD support is likely to come out in the closed driver before the open driver, and that is still our thinking.

In the meantime, the open source work is starting to shift focus to Gallium3D, which is a practical pre-requisite for decode acceleration *without* relying on UVD.

I think all the things you want are happening."


all this goes back to just before i asked him these direct UVD questions back in January 2009 (10 months ago) just after someone mentioned the CUDA ASIC...
in relation to OpenCL were RealNC asked "Hmm. So then OpenCL is not the answer here? Then what is?"


01-05-2009, 01:31 PM "bridgman said: ...
It depends on the question

The ideal solution is to have access to the dedicated hardware we all put in our chips to support BluRay playback. Unfortunately that hardware is also wrapped up in bad scary DRM stuff so making it available on Linux is a slow and painful process.

In the meantime, a lot of the computationally expensive work associated with H.264 decode and encode can be done with shaders, which is where OpenCL comes in. It doesn't *have* to be OpenCL, and the work doesn't have to wait for OpenCL, we're just saying that a year from now anyone writing that kind of code will probably start with OpenCL.

In the meantime, I believe there is enough info publicly available today to write a GPU-accelerated H.264 decoder for Linux on either Intel or ATI hardware using the 3D engine using conventional shaders. Another option for ATI and NVidia hardware would be to write the decoder using Stream or Cuda tools (but without that handy library).

One thing that tools like OpenCL will do is make it possible for more people to get into this kind of programming, without having to first take the plunge into driver development. The CUDA and Stream tools certainly help, but I think OpenCL will help more.

The other obvious benefit of OpenCL is the ability to run the same program on hardware from different vendors, which I guess you could say is "bad for the hardware vendors individually but good for them collectively"
Last edited by bridgman; 01-05-2009 at 02:17 PM.
"

as you can see theres a confusion there were he casually refers to the cuda tools but clearly makes a point of ruling out the library for ATI, then moves on to re-enforce the non UVD documentation hes put out there.

and to be fair, its not all his fault, as he has tryed to encurage 3rd party devs to take whats already available and extend each option as they see fit using the other data he released... such as extending XvMC or one of the others as it existed back then....before the OpenCL really get talked about.. perhaps some have tryed and failed , but it seems most didnt even want to try and write any Proof Of Concept code or extensions to the above API's etc...

"bridgman said:This thread is only debating the urgency of building XvMC (Motion Compensation and optionally IDCT) on top of Xv, to offload more CPU work to the GPU when decoding MPEG2 video streams. Our view is that time would be better spent working on an implementation which could also handle H.264/VC-1 as well as MPEG2, which will require either some extensions to the XvMC API or a different API completely.
"


then on "10-29-2009, 06:20 PM we start to see a shift away from the old options and on to the up and coming Gallium3D
were again it is/was hoped someoone/ANYONE will take the time to try and add the required video decode acceleration OpenCL on top of that sometime in the near future, but noones taken the first steps down that path so far, or at least publicly stated their willingness to try...
see Feature dependency tree
"bridgman said:This is one of those cases where desired priorities don't make much difference -- the development sequence is based on architectural hierarchy :

- dynamic power management will be built on top of kernel modesetting, and decode acceleration will be built on top of Gallium3D drivers.

- Gallium3D drivers, in turn, depend on DRI2 and can leverage most of the code (and nearly all of the painful lessons) from the 3D work done on the classic Mesa 3D drivers

- DRI2 depends on memory management, and the memory management work was driven primarily by kernel modesetting

Completion of new functionality pretty much *has* to follow that dependency tree, no matter what order the work is started. Resistance is futile.

I updated the chart at the end of the RadeonFeature page to make this a bit more clear :

http://www.x.org/wiki/RadeonFeature

Last edited by bridgman; 10-29-2009 at 06:24 PM"


this all goes all way back to January 2009 as replys to my UVD questions etc
"bridgman said: we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


"popper said:thats a shame, we are looking at months at the very least then!"

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

and bridgman does or at least did read this betaboy thread :waves: but doesnt seem to post here and thats a shame, as he could clarify any slight errors if any are made, but essentially this is the pubic information and statements available to date.

http://www.phoronix.com/forums/showpost.php?p=97961&postcount=30
http://www.phoronix.com/forums/showpost.php?p=97711&postcount=11

[khat17]

Long read - and I'll have to do some additional reading up to fully grasp everything.

I noticed in the listing you have there's no DXVA - - - why? Changing from nVidia to ATI using MPC-HC with DXVA I've gotten H264 streams to play through the GPU. A quick browse of what UVD is shows that it should work through DXVA, so why not tackle it from that angle?

[Dark Shikari]

Long read - and I'll have to do some additional reading up to fully grasp everything.

I noticed in the listing you have there's no DXVA - - - why? Changing from nVidia to ATI using MPC-HC with DXVA I've gotten H264 streams to play through the GPU. A quick browse of what UVD is shows that it should work through DXVA, so why not tackle it from that angle?IIRC, DXVA requires control of the output display device too, so a decoder can't do it alone (it requires support in the player).

[BetaBoy]

Ranpha.... I welcome your thoughts/flame. I stand by what I said, in fact OpenCL will come into play at some point but there are obvious things that need to occur first for us to be able to take advantage of what it has to offer as DS has stated is missing.

[popper]

Ranpha.... I welcome your thoughts/flame. I stand by what I said, in fact OpenCL will come into play at some point but there are obvious things that need to occur first for us to be able to take advantage of what it has to offer as DS has stated is missing.

for instance , ATI/AMD NEED to finally make their OpenCL codebase actually use their Gfx chips and not just use your CPU only, some time really soon at the very least OC...

its not even really clear if you could simply get your 3rd party OpenCL code working on say OSx and Nvidia for instance, then later just port it and compile it for a much improved ? future ATI Gfx OpenCL codebase in a simple way...

thats how bad ATI are right now and in the near future it seems... shame.

also, keep in mind that its been said by bridgeman that "decode acceleration will be built on top of Gallium3D drivers." for the OSS linux OS etc.

its also been said by others that although very basic alpha Gallium3D drivers have passed 11-09-2009, 09:30 PM first basic tests for the old ATI R300 only, its expected to take another 12 months from now before Gallium3D is considered stable and feature rich, as in most of the standard, and ALL its supporting code as per the Feature dependency tree is there and works reasonably OK...

so its reasonable to assume unless something changes, that only 12 months or later , will OpenCL open linux drivers will be good enough for your everyday use, i wound Not expect the stable windows side to be much sooner...., perhaps 9 months instead of 12months+ as they seem to run the windows and closed linux drivers together ,(remember BM says he expects the closed driver to get any UVD before open linux if and only if they pass a future review actually allowing access to some of its API) perhaps one revision behind wondows...

[lych_necross]

@BetaBoy,
I just wanted to say, I love CoreAVC and I am eagerly waiting for 2.0 to be released. Ignore the flamers and keep up the good work! :)

[djmasturbeat]

i have posted numerous times in coreavc's forums inquiring about this release. have not been back for awhile, and sorry if it has been touched on in this thread (but it is really long, so i will ask anyhow):
is x64 still going to be supported? as we were told it would when the new x64 haali was released beyond beta, and this was the last hold up, essentially of v2.

i do think there is some good advice to be had in not prematurely announcing things, then having customers getting angry over long waits. being upfront is better than spinnig us.

if hw accel can ever be had for ati cards, i know a lot of us would really appreciate it, but i won't pretend to have any current knowledge of how this is accomplished. it would be a nice addition to a great package.

i look forward to all the current audio formats being better supported as well, with stable releases of splitters and codecs coming out. so thanks to beta boy and the haali and corecodec crews for all of their hardwork.

[Przemek_Sperling]

I do wonder how the author of Mirillis Splash Player http://mirillis.com/splash.html made his software HW decode AVC? I use the software with combination with my Radeon 4550 and it works like a charm (both DVB-T and playing mkvs).

[nm]

I do wonder how the author of Mirillis Splash Player http://mirillis.com/splash.html made his software HW decode AVC?

According to its system requirements, it simply uses DXVA if possible. Like MPC-HC, for example.

[dimitrik]

Constantly evolving? What?

CoreAVC doesn't (nor does basically anyone else) support any of the recent additions to the spec (SVC and MVC). With the exception of Predictive Lossless, everything in the spec that CoreAVC and libavcodec supports is identical to how it was in 2005.

My mistake I must have misunderstood something I read. I was under the impression people were complaining about lack of support for new x264 features which I understand is not the case.

and the flames continue... In the end 2.0 will be out this week. Dark Shikari... Thx was gonna jump in and say something similar.


Betaboy if you're referring to my post...I'm really not sure what part you could possibly interpret as a flame? I was making a simple comment on facts and offering a friendly opinion as a customer. Maybe you could point out what I said that you felt was so negative?

[Dark Shikari]

My mistake I must have misunderstood something I read. I was under the impression people were complaining about lack of support for new x264 features which I understand is not the case.New x264 feature does not mean new H.264 feature.

[dimitrik]

Right, :thanks: for reminding me.

[Disabled]

My mistake I must have misunderstood something I read.
You might have just read Betaboys comment, stating that the AVC specs are changing, implying that weightp is a feature added to the specs and not to one encoder.

The AVC specs today are not the same spec they were 6 months ago no less 2-3 years ago.

@betaboy Youre waiting for OpenCL to expose the GPU decoder hardware right?

[BetaBoy]

Disabled, I've never said that about weightp... Please re-read the thread. On the specs if was stated "AVC specs/profiles changing", but that's not gonna stop the continued flaming is it?

[LoRd_MuldeR]

Youre waiting for OpenCL to expose the GPU decoder hardware right?

As far as I know, OpenCL doesn't expose the built-in hardware video decoder of the Graphics Card at all. It provides an interface to compute devices (this may be a GPU, a Cell Processor or even a "normal" CPU). So you could use OpenCL to implement your own H.264 decoder as an OpenCL kernel, which would run on any OpenCL-enabled device. But that's not what CoreAVC currently does, as far as I know. Instead they simply use the PureVideo-decoder chip, which is available on all recent Nvidia Graphics Cards and which already provides a highly efficient H.264 decoder in hardware. That decoder can be used through the CUDA Video API, but it's not a CUDA kernel and it's not something you could do with OpenCL in a similar way (at the moment). Last but not least writing your own H.264 decoder as a CUDA kernel or as an OpenCL kernel, which would be running on a (more or less) "general purpose" GPU, will never be as efficient as a dedicated decoder hardware, such as the PureVideo decoder chip...

[Disabled]

Disabled, I've never said that about weightp... Please re-read the thread. On the specs if was stated specs/profiles changing

Then tell me how to re-read that:
The harm is done, when you think you bought a decoder for high profile files, while you bought a decoder for files that use 'some' high profile features.
The AVC specs today are not the same spec they were 6 months ago no less 2-3 years ago. As far as changes... you are really talking about encoding...
Of course I was not talking about encoding, because the specs didn't change and you don't have full High profile support.

As far as I know, OpenCL doesn't expose the built-in hardware video decoder of the Graphics Card at all. It provides ....
Yeah, that has been said a thousand times now. I was connecting:

I stand by what I said, in fact OpenCL will come into play at some point but there are obvious things that need to occur first for us to be able to take advantage of what it has to offer as DS has stated is missing.
with the only post from DS about OpenCL (in the last few pages):
OpenCL doesn't expose the GPU video decoder hardware necessary for playback.
I read it like "if OpenCL offers GPU playback in a distant future, were gonna use that. If not, you don't get it." I'm probably wrong with that assumption, but betaboy doesn't tell us otherwise...

[BetaBoy]

I can only say so much with respect to others.... but with support for OpenCL by both ATI and NVIDIA now, its a safe guess that it's only a matter of time before something of value comes for decoding (as you are all touching on as well).

[Jeff Flowerday]

I'm going to wear this thread out checking it to see if the new splitter has been released...

[BetaBoy]

No as we found a few bugs in the splitter, but they are not show stoppers for the CoreAVC 2.0 release either.

[plonk420]

I think clearly when a customer buys a product that product is supposed to do what it says on the box at the time of purchase. If the spec changes a month later that doesn't automatically guarantee it'll be supported but it seems as if CoreCodec have in fact done their best to keep up with the standard specs and I for one have not had to pay for a version upgrade from my initial purchase (I think 1.6).

i don't recall hearing about "CoreAVC Knowledgebase and Feature Limitation" when i bought 1.0 or whatnot. (of course not knowing about its existence-even if it did-isn't really an excuse for end users). i can't even remember if CoreAVC claimed High Profile support (was pretty sure it did). anyone remember?

[Shinigami-Sama]

i don't recall hearing about "CoreAVC Knowledgebase and Feature Limitation" when i bought 1.0 or whatnot. (of course not knowing about its existence-even if it did-isn't really an excuse for end users). i can't even remember if CoreAVC claimed High Profile support (was pretty sure it did). anyone remember?

as I recall it they advertised as the fastest high profile decoder
back when LAVC was slow as sin

[plonk420]

i guess it's down to wording. i'm seeing "H.264 Baseline, Main, High profile support" back to 12/2006 and thru 12/2007. waybackmachine++ :)

[BetaBoy]

No as we found a few bugs in the splitter, but they are not show stoppers for the CoreAVC 2.0 release either.

To that..... I'm gonna sync with Haali now... As we think it might be a good idea to QA the splitter more outside of the small test group now, and ahead of the CoreAVC 2.0 release.

[Cyber-Mav]

wouldnt it be best to delay coreavc 2.0 till next year that way none of these bugs that keep getting found will make poor experience for the users?

[BetaBoy]

Not at all, as stated above this will not effect the release. But with a few more days before 2.0 is out, getting the splitter out earlier could not hurt.

[Cyber-Mav]

so will coreavc 2.0 still have lots of bugs in it when its released in few days? it seems as if your trying to rush coreavc 2.0 out of the door.

[BetaBoy]

No way, In months of testing we have only a handful of bugs in the 2.0 codebase, in fact we are only aware of one bug in 2.0 ATM. Also you need to distinguish the splitter from the filter, while we work with Haali on suggesting features and fixes, we do not directly work on it and as stated CoreAVC is designed to work with any splitter (but we prefer Haali and his splitter).

However that being said, this is a milestone release and does add support for a new OS, new SN/Customer Portal, so we do expect a few bumps... That's a give in.

[Hans Ohlo]

few days? the week has only like two of them left ;)

when using coreavc with windows media center it would be nice to limit the open instances of the decoder like ffdshow can. because in the background for creating thumbnails i get up to 20 open instances at times resulting in poor performance and sometimes crashes.

[BetaBoy]

few days? the week has only like two of them left ;)

when using coreavc with windows media center it would be nice to limit the open instances of the decoder like ffdshow can. because in the background for creating thumbnails i get up to 20 open instances at times resulting in poor performance and sometimes crashes.

Haali has removed all thumbnail support from the new splitter now... so you should not see that anymore. He has also mentioned the possibility to release it as an addon and or as a new app.

[THX-UltraII]

http://haali.su/mkv/ is down at the moment. Think it beeing updated to Haali Splitter 2.0!

[madshi]

@BetaBoy,

will CoreAVC 2.0 (software decoding) fix the artifacts that occur with some Blu-Rays (e.g. Chinese Ghost Story, Chocolate, Der Untergang, just to name a few)? It may be that those Blu-Rays are out of spec, but only CoreAVC shows artifacts with them. And of course it's not nice if I invite guests over to watch movies with me, and then artifacts show up. So in order to make CoreAVC a good choice for me, I'd have to rely on that it doesn't show artifacts even with funny Blu-Rays.

Thanks!

[BetaBoy]

If its related to out of spec Motion Vectors, as Dark Shikari already stated we did not increase the threshold and to do so would come at the cost of speed. We did however a few releases back increase the threshold, but only to the point where it started to slow down decoding.

BTW... I have not sen an recent Blu-Ray releases (past few months) that have MV issues. But that maybe due to my limited time to watch every BR release.

[sneaker_ger]

If its related to out of spec Motion Vectors, as Dark Shikari already stated we did not increase the threshold and to do so would come at the cost of speed. We did however a few releases back increase the threshold, but only to the point where it started to slow down decoding.

BTW... I have not sen an recent Blu-Ray releases (past few months) that have MV issues. But that maybe due to my limited time to watch every BR release.

Will 2.0 support out of spec MV's which could sometimes produce glitches?

All limitations on MV's have been removed in 2.0.

:confused:

[BetaBoy]

:confused:

Please continue... in the follow-up post was where I mentioned that we had not expanded the MV's. Its also not a limitation at all, but should be considered by Mastering Houses when doing the final production encodes. I had already pointed this out to Sony, Paramount and Fox through a third party all of which have since changed how they treat MV's.

[sneaker_ger]

I see. Which means that if people are getting artifacts because of out-of-spec MVs with 1.9.5 they'll also get them with 2.0.(?)

[Snowknight26]

No way, In months of testing we have only a handful of bugs in the 2.0 codebase, in fact we are only aware of one bug in 2.0 ATM.

Out of curiosity, which one is that?

[BetaBoy]

I'll hold off on any report of specifics till it is out with hope that it will be fixed by then.

[madshi]

If its related to out of spec Motion Vectors, as Dark Shikari already stated we did not increase the threshold and to do so would come at the cost of speed. We did however a few releases back increase the threshold, but only to the point where it started to slow down decoding.

BTW... I have not sen an recent Blu-Ray releases (past few months) that have MV issues. But that maybe due to my limited time to watch every BR release.
I've seen it in multiple rather recent Blu-Rays (a list of which you'll find in my previous post). I understand your stance on this. But please understand that from an end user point of view it doesn't matter much whose fault the artifacting is. Couldn't you add an option to CoreAVC to properly handle out of spec motion vectors? I wouldn't mind (at all) if that option came at a speed penalty! But I definitely can't live with artifacts.

[BetaBoy]

This was discussed about 90 pages back... but technically that would require two separate decoders as it not something that can be set dynamically like that.

[Jaja1]

I totally agree with Madshi's remarks on handling out-of-spec MV's. They are more common than you think. I have quite a few BRD's suffering from this. ATM I have to rely on ffdshow to playback the affected BRD's without artefacts, but I would prefer to use CoreAVC as my default decoder. So I hope you can come up with a solution Betaboy

[hakujin]

Fix on "--weightp 2" corrupted frames problem planned for soft decoding?

More info:

http://x264-bb.com/helpdesk/4333-coreavc-later-builds-x264-encoder.html

[BetaBoy]

hakujin... pls read the last few pages of this thread. Thx.

[THX-UltraII]

it s friday, the last day of the week so Haali time! :)

[Snowknight26]

A week includes the weekend...

[leeperry]

it s friday, the last day of the week so Haali time! :)
or else? :devil:

[Shinigami-Sama]

it s friday, the last day of the week so Haali time! :)

theres still two days left...

[BetaBoy]

It's ready when it's ready... weekend or not. Just pinged Haali now for any new changes to the splitter.

[Jeff Flowerday]

http://haali.su/mkv/ is down at the moment. Think it beeing updated to Haali Splitter 2.0!

Site is back. But nothing new...

[THX-UltraII]

yeah, saw this too :(

[Cyber-Mav]

is there a problem decoding out of spec Motion Vectors when gpu (cuda) decoding is used or is it still broken as the software decoder is?

[BetaBoy]

We are working on a x264 multi-dupe bug atm that came up yesterday.... On Haali, I've pinged him but I think at this point that you're likely to see the new splitter in CoreAVC before his website, we will see.

[Cyber-Mav]

if coreavc was free i can understand releasing a buggy version for users. but since coreavc is not free i dont understand why your rushing to get this 2.0 release out, in my opinion it would be wise to hold back release till next year since your finding out more bugs all the time.

again this is just my opinion on this. last thing you want is this thread going an extra 100 pages long with nothing but complaints.

[Keiyakusha]

In my opinion exactly because CoreAVC is not free (and because of weightp of course), they should release 2.0 as fast as possible. Check PM if you want to know more about my point of view.

[BetaBoy]

Keiyakusha that is the plan to get it out when its ready (minus my remark about 'this week' with this last minute bug), in fact as I've already stated that the only CORE changes has been to the add support for the multi-dupe additions to x264. But over the past few weeks/months it has been about the Windows 7 changes, 64bit additions, Installer, New SN/Customer Portal (for users to self-serve there own downloads/SN's), which are all ready to go.

Last was Haali's splitter changes to ensure directshow playback in WMP and MC and not MediaFoundation. We already know that with this first splitter release that its to ensure it works under Windows 7 properly and post forward, its going to be about playing nice with MediaFoundation to make Directshow the priority over it (without the DLL hacks that are out there).

Cyber-Mav... If you have a CUDA Enabled GPU.. out of spec MV's videos will play fine in CoreAVC.

[Cyber-Mav]

ahh nice to know cuda acceleration has the ability to play out of spec MV's. betaboy does coreavc 2.0 make any changes to cuda decoding? or is it kept the same as 1.9.5

[the_corona]

Wait, only core change is "multi-dupe additions"?

Isn't it also going to be faster, beating out the free competitors (divx/diavc) finally in all configurations? If not, why should I buy a new licence for 2.0? Divx supports the latest x264 stuff just fine.

I think I'll personally wait to see benchmarks, before deciding to renew my licence. Just saying. Not being able to use coreAVC lately due to the x264 blocky thingy, I find divx to be a viable alternative TBH. Waiting to be impressed by speed.

[BetaBoy]

ahh nice to know cuda acceleration has the ability to play out of spec MV's. betaboy does coreavc 2.0 make any changes to cuda decoding? or is it kept the same as 1.9.5
CUDA support in CoreAVC 2.0 has been devel'd against the latest SDK and there is several changes that affect it. The one that most ppl will want, is that it removes the need to have directshow as a requirement for native playback on Windows.

A great example of this is in 2.0 is that it now allows Windows Media Center to work with CUDA without it losing focus.

[THX-UltraII]

will Haali Splitter and Core 2.0 be released today?

[Astrophizz]

This is getting a little annoying (I'm sure even more so for others). Are you working on some time-sensitive project that requires these things within a short time frame? Are you going to ask if it's ready today every day?

[Cyber-Mav]

whoa if i can play mkv's in windows media center on my vista x64 machine using cuda then coreavc 2.0 will be worth the purchase just for that feature alone. would this also work on windows 7 media center 32 and 64bit versions?

[leeperry]

CUDA support in CoreAVC 2.0 has been devel'd against the latest SDK and there is several changes
shortening the CUDA initialization time sure would be fantastic.

[Cyber-Mav]

CUDA support in CoreAVC 2.0 has been devel'd against the latest SDK and there is several changes that affect it. The one that most ppl will want, is that it removes the need to have directshow as a requirement for native playback on Windows.

A great example of this is in 2.0 is that it now allows Windows Media Center to work with CUDA without it losing focus.

would this require a newer nvidia driver installed? i currently use the 186.18 driver but i think higher level cuda support was introduced in the 191.07 driver.

[G_M_C]

Hmmm, CUDA ... CUDA ... CUDA ....

Personnally i'm getting annoyed with this CUDA stuff. Is CoreAVC finally becoming vendor-neutral with V2.0, i.e. are the other 75% of computer-users finally getting H/W assistance too ?

(Yes, including all the Intel on-board IGP-users, more than 75% of users DON'T use Nv ! source (http://digital.venturebeat.com/2009/10/26/nvidia-sees-big-loss-of-market-share-in-third-quarter-as-graphics-chip-sales-boomed/)).

Relevant question, as an Ati-user; Other than the multi-dupe-p-refs or what not, is there any reason for me to get CoreAVC ? Cause ffdshow seems to be doing fine since i went back to the recent (non-experimental) version.

[Cyber-Mav]

i guess its because cuda can do things no other api can. cuda allows direct access to the video processor on nvidia cards, and for me and others its a brilliant solution. you can use media player classic home cinema with general dxva acceleration for all other cards but from my experience cuda seems to playback more video types that have higher ref frames etc.

why not just get a cheap cuda capable card these days they are real cheapo at around 20 quid for a 8 series.

[G_M_C]

i guess its because cuda can do things no other api can. cuda allows direct access to the video processor on nvidia cards, and for me and others its a brilliant solution. you can use media player classic home cinema with general dxva acceleration for all other cards but from my experience cuda seems to playback more video types that have higher ref frames etc.

why not just get a cheap cuda capable card these days they are real cheapo at around 20 quid for a 8 series.

Yup, like many of us are likely to downgrade from a HD5xxx series card, just for CUDA :rolleyes:

WE're at DX11 these days; DirectCompute, OpenCL etc. Why not switch to that. Nv will come to support that in the future too.

[BetaBoy]

leeperry... yes we have reported the initialization delay to NVIDIA.

Cyber-Mav.. anyone after 185 will work but I'd use the latest one (even Beta) as they do continue to address issues fast (The NVIDIA Team has been great about that!).

G_M_C.... Each user will be different. My rule of thumb on any device I have owned is to try almost everything first to see what works best on it... (noting that we first designed CoreAVC to work best on ARM/MIPS based Mobile devices with CorePlayer). On being 'neutral.... later 1.9.x releases and now the upcoming 2.0 release finally brings it into the desktop space with the CPU optimizations and will continue into 2.x for more of the 'neutral' stance you mentioned. Our belief is still that CUDA is a great technology and has only begun to scratch the surface of what's possible with it.... that being said, we will support DXVA as well, although I do not want to get into that now.

[Snake91]

Yup, like many of us are likely to downgrade from a HD5xxx series card, just for CUDA :rolleyes:

WE're at DX11 these days; DirectCompute, OpenCL etc. Why not switch to that. Nv will come to support that in the future too.
Let me understand, you have a hd5xxxx and not a 1080p-capable cpu? LOL

[G_M_C]

Let me understand, you have a hd5xxxx and not a 1080p-capable cpu? LOL

What's the argument you' re trying to make ? As a matter of fact; I have both (and even have a Asus Xonar HDAV Slim, that might become less useful when Ati/AMD finally gets HD-audio streaming right i.e. without PowerDVD, which i detest).

It's the argument that counts here. Supporting CUDA only, leaves out the vast majority of PC-owners that want GPU assisted decoding. All of these users are potential customers for CoreCodec.

It would be "good buissness" to be vendor-neutral, or to at least support DXVA. It is possible, look at MPC-HT; It supports DXVA for a long time now.

Furthermore; It is my opinion that DirectCompute/OpenCL gives CoreCodec possibilities. They could "stick with" their original concept of a software-decoder (without DXVA/CUDA, like the original CoreAVC's). DirectCompute/OpenCL opens up the shaders of a GPU for parallel computing by implementing C(++) libraries. It might be an idea to thy to adapt the software-CorecAVC with/using/implementing those libraries, and so getting GPU power implemented. This is a "vendor neutral" approach, but on the other hand it has disadvantages is. It is not the most energy-efficient idea (since the GPU's will "power up" when using shaders).

[Jeff Flowerday]

I'm a little confused about all the no ATI hardware support complaining. Is DXVA acceleration via MPC-HC's standalone filters not good enough?

[Cyber-Mav]

i dont understand why someone would go out and buy a graphics card these days that doesnt even support cuda?
i also dont understand why the said person would then come onto this forum and complain about the lack of support for thier graphics card in coreavc. if you had purchased a cuda capable card in the first place then you wont need to complain about this. and as mentioned above if you need gpu acceleration there are a number of alternatives for you such as media player classic home cinema or powerdvd and a few others. only one that is of no use to you is coreavc, for now.....

[shon3i]

Is DXVA acceleration via MPC-HC's standalone filters not good enough? DXVA have special limitations, stream must follow AVC specification for Level 4.1 and lower, while CUDA decode everything even "broken" streams.

[Cyber-Mav]

DXVA have special limitations, stream must follow AVC specification for Level 4.1 and lower, while CUDA decode everything even "broken" streams.

correct, also to mention ati's uvd hardware decoder is said to be limited to level 4.1 streams so it will not benefit over nvidia's video decoder implementation which decodes level 5.1 streams.

[G_M_C]

i dont understand why someone would go out and buy a graphics card these days that doesnt even support cuda?
i also dont understand why the said person would then come onto this forum and complain about the lack of support for thier graphics card in coreavc. if you had purchased a cuda capable card in the first place then you wont need to complain about this. and as mentioned above if you need gpu acceleration there are a number of alternatives for you such as media player classic home cinema or powerdvd and a few others. only one that is of no use to you is coreavc, for now.....

If I neutrally look at the graphics card market today, without knowing about CoreAVC or what not, i'd sooner get an Ati/AMD than i would get a Nv-card. All review sites agree, Ati/AMD cards give more features, more speed and are simply more bang for the buck. Almost all review sites agree. Nv is running behind, and they even seem to have problems keeping up production, even while loosing market share. CUDA isnt even a major selling point; Having DX11 is a much bigger argument. And Ati has that, Nv doesnt.

But as i said; From a business standpoint, i would be more profitable to "not chose sides" for CoreCodec. But thats my $ 0,02.

[ajp_anton]

and they even seem to have problems keeping up productionAnd AMD doesn't?

[G_M_C]

And AMD doesn't?

Yeah, getting hold a a 5xxx gpu isnt easy, but it gets delivered. Nv cards seem to be running "out of stock" fast lately, and some dont seem to be replaced. But this is based on "what i heard / read" on several tech-forums; I'm not in the market for Nv cards atm :p

EDIT: But this another subject for discussion. I made the argument that i'd hope to see that CC became more vendor-neutral i.e. not being CUDA only any more.

[pankov]

i dont understand why someone would go out and buy a graphics card these days that doesnt even support cuda?
The answer is very simple
DX11 and 8-channel LPCM, TrueHD & DTS-HD MA Bitstreaming

[BetaBoy]

EDIT: But this another subject for discussion. I made the argument that i'd hope to see that CC became more vendor-neutral i.e. not being CUDA only any more.
Sure... we've been saying that, but I also want to point out that we do have fundamental issues with DXVA as I've stated here a few times.

Long term, we see many advantages if CUDA combines its power with OpenCL, but when/if that happens, it will not stop us with DXVA (noting that we support more GPU's in CorePlayer then any other media platform and DXVA has always been a goal there).

[Mixer73]

EDIT: But this another subject for discussion. I made the argument that i'd hope to see that CC became more vendor-neutral i.e. not being CUDA only any more.

You don't seem to understand - its not the CoreCodec isn't supporting ATI, ATI do not provide access to their UVD hardware through their API, so DXVA is all you're going to get with ATI.

Unless eventually CoreCodec becomes code that actually runs on the GPU hardware, which I think is a bit of a stretch.

[jakor]

DXVA have special limitations, stream must follow AVC specification for Level 4.1 and lower, while CUDA decode everything even "broken" streams.
You are fundamentally wrong.
Speaking of h.264 decoding CUDA and DXVA are just interfaces to the same dedicated chip on a videocard.
The only difference in implementing them is that there is a code sample how to decode h.264 thru CUDA, and no such a sample for DXVA ;-))

[saint-francis]

From my understanding DXVA only works where there are no filters inline aside from the DXVA decoder. Which is why we aren't all using DSS2 with the stand alone MPC HC decoder for video encoding. How corecodec is planning on accomplishing this, I have no idea. But more power to them. And all of this bitterness about corecodec not supporting ATI because they have a CUDA implementation......? It's available..... Why not use it? They aren't siding with one hardware manufacturer because ATI doesn't have CUDA. They aren't siding with any manufacturer. Just taking what's given to them.

[G_M_C]

[...]
And all of this bitterness about corecodec not supporting ATI because they have a CUDA implementation......?
[...]

You seem to misread and/or misinterpret. I have no bitterness whatsoever, i just make an observation (CUDA only being for max 25% of all PC users worldwide, so 75% of potential CoreAVC customers dont have a use for CUDA support).

Personally, i dont give a damn about CUDA or Nv. Reading one of BetaBoy's previous post, i decided that i for myself dont need CoreAVC anymore. My QX9650 does fine without it.

I might have been tempted to try V2.x out if it had OpenCL or such, but alas it's not there yet. So it is (and frankly already was) unnecessary for me to upgrade. And there will probably be more people that weigh the same arguments i've used.

And so you read the reason why i posted the OpenCL -vendor-neutral- argument in the first place; Supporting CUDA only can prove to be "bad for business"; See it more as an observation/general idea and so forth.

[me7]

You seem to misread and/or misinterpret. I have no bitterness whatsoever, i just make an observation (CUDA only being for max 25% of all PC users worldwide, so 75% of potential CoreAVC customers dont have a use for CUDA support).

Personally, i dont give a damn about CUDA or Nv. Reading one of BetaBoy's previous post, i decided that i for myself dont need CoreAVC anymore. My QX9650 does fine without it.

I might have been tempted to try V2.x out if it had OpenCL or such, but alas it's not there yet. So it is (and frankly already was) unnecessary for me to upgrade. And there will probably be more people that weigh the same arguments i've used.

And so you read the reason why i posted the OpenCL -vendor-neutral- argument in the first place; Supporting CUDA only can prove to be "bad for business"; See it more as an observation/general idea and so forth.

You don't get it: CUDA is not a subset of OpenCL, both provide access to different components of the GPU. OpenCL can not be used to access the video decoder.

[G_M_C]

You don't get it: CUDA is not a subset of OpenCL, both provide access to different components of the GPU. OpenCL can not be used to access the video decoder.

Again: This is actually a seperate discussion. But I do want to answer this. Cause i'm noty the one that doesnt understand, you seem to be.

OpenCL is an cross-platform/cross-device open code-model. CUDA is NOT cross-device nor is it open. So developing for CUDA means developing for Nv-users only; Users of other vendor-devices are left out.

Nv claims that anything that runs CUDA will run OpenCL. That would also mean that if CC develops for OpenCL "(maybe "translates" their CUDA code to the equivalent OpenCL-code), they can support all HW vendors; Cause it'll support CUDA, but also Ati, Intel or S3 hardware (i.e. "vendor neutral") as long as the device has the abillity to run a certain version/level of OpenCL.

[Mixer73]

OpenCL is an cross-platform/cross-device open code-model. CUDA is NOT cross-device nor is it open. So developing for CUDA means developing for Nv-users only; Users of other vendor-devices are left out.

OpenCL does not provide the same functionality CoreAVC uses in CUDA. Its VERY simple. CUDA provides direct access to the decoding operations of the GPU and enables CoreAVC to use the hardware to decode the video while having less limitations than a native DXVA implementation.

OpenCL in its current state on ATI graphics cards is not suitable for a similar implementation to what is currently enjoyed by Nvidia owners. ATI could very simply provide access to the video processing but they have chosen not to.

Take your issue up with ATI for not providing access to the video decoding hardware through their API.

[nm]

That would also mean that if CC develops for OpenCL "(maybe "translates" their CUDA code to the equivalent OpenCL-code), they can support all HW vendors
As people told you, the current CoreAVC CUDA code can't be ported to OpenCL because OpenCL doesn't have the equivalent of NVCUVID interface that provides access to the hardware video decoder.

Developing a fully functional OpenCL decoder is a huge task -- about as large as getting the CoreAVC software decoder up to the point where it is today. There would also be several downsides to it when compared against a dedicated hardware decoder:

Part of the decoding (at least CABAC) would need to be done on the CPU, so it would cause a higher CPU load
A fast GPU would be required to decode HD video instead of a low-end card like GeForce G210 that can decode 1080p60 H.264 video on its dedicated chip.
Much higher energy consumption and more heat.

The positive features are hardware-independence (as long as the hardware supports OpenCL) and avoiding limitations set by the hardware decoder.

[Cyber-Mav]

OpenCL is an cross-platform/cross-device open code-model. CUDA is NOT cross-device nor is it open. So developing for CUDA means developing for Nv-users only; Users of other vendor-devices are left out.

as mentioned above opencl cant provide access to the video decoder on the graphics chip like CUDA can. the strange thing is that ati do have something like CUDA and they call it Ati STREAM, however even in ati's own api it still doesnt provide access to the video decoder. so this is a problem with ATi and not coreavc.

as long as opencl doesnt provide direct access to a gpu's video decoder i cant see opencl being of any use to us in the video decoding segment of the market.

[leeperry]

leeperry... yes we have reported the initialization delay to NVIDIA.
very nice! so CoreAVC 2.0 will include this improvement? :cool:

[G_M_C]

I already said that i dont really care myself. My QX9659 copes fine without C-AVC or CUDA. It is only a suggestion to CC/BetaBoy that OpenCL might be a way to significantly increase possible customer-base. The latter isnt even an argument for all of you, you mostly only focus on CUDA and what it can or cant do.

And the possible negative influence on power-consumption when using OpenCL? I already posted that too.

But enough of this; I don't need CC, so discuss for yourself what you want.

[Guest]

This discussion is getting boring, repetitive, inflammatory, and borderline OT. Let's drop it guys. You've all made your points (several times!).

[dimitrik]

Personally I think the most important things for v2.0 in terms of new features are (a) support for Windows 7 including Windows Media Foundation to enable CoreAVC to work inside Media Center and (b) support for x64 Windows 7/vista.

These two are significant stoppers right now for an increasing number of people Win7's adoption rate is very high, and x64 adoption is also growing extremely fast.

[Mixer73]

These two are significant stoppers right now for an increasing number of people Win7's adoption rate is very high, and x64 adoption is also growing extremely fast.

Well.... I disagree.

CoreAVC already works on x64 just fine, my desktop rig is such. Its not a 64bit component but then you have to have every filter in the chain being 64bit which complicates matters, even if you wanted to use 64bit MPC-HC with CoreAVC 64bit when its out, you can do that but I just don't see any real benefit. 64bit seems to me to be the revolution that never was.

If it wasn't for the large amounts of cheap RAM I'm not sure anybody would be rushing out to get x64 OS.

And CoreAVC isn't as critical to 7 as it was to Vista IMO, with 7 having a working default h.264 codec built in. Vista was much harder to get to play DXVA in MCE. CoreAVC 'may' be better on 7 but even as an owner of CoreAVC I'm not sure if I will install it on my 7 rig.

[BetaBoy]

While I have not talked a lot about it, we posted a video on YouTube showing CoreAVC 2.0 64bit w/Haali 64bit bypassing MediaFoundation in favor of Directshow (no hacking required) for any MKV files in Windows 7 64bit.

[Snowknight26]

Awfully strange file names you're testing in that video..

[BetaBoy]

Mixer73... Depending on which method used for DXVA, it will always use less CPU over CUDA. RAM usage in our testing is negligible outside of the GPU, but the wave in recent months has been an increasing number of apps going 64bit. Windows 7 (and cheap ram) imho is driving this and that's a good thing, although technically there are not many advantages for decoding.

[Stephen R. Savage]

http://img338.imageshack.us/img338/4155/rule6violation.png

I believe that BetaBoy's link should be removed due to rule 6 violation since it shows obviously stolen content.

[BetaBoy]

Said the person with 6 posts.... and pls with the accusations since we (CoreCodec) do have promotional rights for content through our partnerships. But if the link is in question, its been removed.

[BetaBoy]

And CoreAVC isn't as critical to 7 as it was to Vista IMO, with 7 having a working default h.264 codec built in. Vista was much harder to get to play DXVA in MCE. CoreAVC 'may' be better on 7 but even as an owner of CoreAVC I'm not sure if I will install it on my 7 rig.

The issue with Windows 7 is that I fear there will be a battle for codec and splitter priorities and you can only go back and blame MS for creating MediaFoundation which is really not needed (in our opinion) unless you want to push EVR/DXVA, DRM, or finite Codec/Splitter control (although some would argue this point). Does anyone see a compelling reason to switch after seeing this comp chart? http://msdn.microsoft.com/en-us/library/aa468614.aspx#appendix_feature_comparisons__zftb

DivX for example has chosen to go the MF compatible route while we are steadfast in sticking with Directshow for Matroska. As stated, CoreAVC 2.0 w/Haali splitter now makes MKV the default for directshow and I really see no work around that Microsoft can do to prevent this if the filter/splitter is installed unless they intentionally change, block our registry settings or for DivX unless they ask the user who is installing it if they want the current splitter/filter to be removed prior to having theirs installed.

This is gonna be fun.... MF or DS? It might have to come down to a tool to be able to switch/change defaults at will.

[Guest]

I believe that BetaBoy's link should be removed due to rule 6 violation since it shows obviously stolen content. Next time you have a concern report the post. Do not post about it per rule 17.

If it is a sample as indicated in the filename then it is OK under the fair use clause. Further discussion to PM.

[roytam1]

/me was heard that coreavc doesn't support x264 weightp parameter. will it be fixed in 2.0?

[Mixer73]

Mixer73... Depending on which method used for DXVA, it will always use less CPU over CUDA. RAM usage in our testing is negligible outside of the GPU, but the wave in recent months has been an increasing number of apps going 64bit. Windows 7 (and cheap ram) imho is driving this and that's a good thing, although technically there are not many advantages for decoding.

Clarify for me, CUDA will use less CPU than outright DXVA or the other way around.

I'm a fan of your product, seat of the pants tells me it worked better with CoreAVC than Win7's default codec, but I feel that I want to install as few third party things as possible on the machine.

[CiNcH]

Clarify for me, CUDA will use less CPU than outright DXVA or the other way around.
AFAIK, CUDA copies back the decompressed video into main memory, which takes some CPU time. The pro is that you can post process video in "software".

[Shii]

As stated, CoreAVC 2.0 w/Haali splitter now makes MKV the default for directshow

What about mp4? Will WMC and WMP use CoreAVC 2.0 for decoding mp4 h264 files?

[hydra3333]

... and you can only go back and blame MS for creating MediaFoundation which is really not needed (in our opinion) unless you want to push EVR/DXVA, DRM, or finite Codec/Splitter control (although some would argue this point). Does anyone see a compelling reason to switch after seeing this comp chart? http://msdn.microsoft.com/en-us/library/aa468614.aspx#appendix_feature_comparisons__zftb

Nope, M$ are only in it for the almighty US $ that they and their rich mates pray to... text from that M$ link says it all
The key feature of Media Foundation that supports protected content is the Protected Media Path (PMP), which provides a protected environment for running audio and video processing pipelines.
i.e. they want to suck the life out of your PC and stop you from doing things you want to on your own PC ... and you pay for the privilege of them sticking it to you.

cheeky so and so's, they've lost the plot about who their customer really is... unless big content is bribing them to do it.

[G_M_C]

Nope, M$ are only in it for the almighty US $ that they and their rich mates pray to... text from that M$ link says it all

i.e. they want to suck the life out of your PC and stop you from doing things you want to on your own PC ... and you pay for the privilege of them sticking it to you.

cheeky so and so's, they've lost the plot about who their customer really is... unless big content is bribing them to do it.

Hmm, your opinion of DRM is quite clear. But I think you overreact somewhat.

Most PC's dont even have a BD-drive or another component that requires PMP/PAP. Most people just want to use youtube or what not. And realistically speaking; Most people play MKV's or AVI (i.e the wellknown "x264-somegroup" type videos) too. And MS codecs makes it easy for clueless-n00bs (*) to do so without having to mess with codec-packs or worm-toolbar-spyware-infected-shit .

The bad thing is that they made it impossible for people that are NOT clueless n00bs (*) to choose their own software. Personally, i'd even consider buying a Win7-N (without windows media-player), cause i dont like MS mediaplayer. With my current Win XP I don't use it ever, and i've blocked it with my firewall atm. But I fear that i dont have freedom anymore in Win7, hence my idea of buying Win7-N. They should also have made a Win7/Stripped-edition, without mediaplayer or MS codecs; I would have bought that.

Anyway; Just wait a few months and there will probably a plethora of tools circumventing this Mediafoundation hinderence ;)

((*) clueless n00b => (C) Doom9 ;) )

[hydra3333]

Thanks for the label :p If you don't care what people do with your PC whilst making you pay for it, then that's up to you.

MS codecs and the stuff that goes with it don't work as well as say this codec here nor ffdshow... and witness media foundation whos primary purpose is to lock stuff down... agh, you're entitled to your view.

I too await tools and techniques built for the users to use as they choose not as enforced by the mates of big content.

[dimitrik]

Well.... I disagree.

CoreAVC already works on x64 just fine, my desktop rig is such. Its not a 64bit component but then you have to have every filter in the chain being 64bit which complicates matters, even if you wanted to use 64bit MPC-HC with CoreAVC 64bit when its out, you can do that but I just don't see any real benefit. 64bit seems to me to be the revolution that never was.

If it wasn't for the large amounts of cheap RAM I'm not sure anybody would be rushing out to get x64 OS.

And CoreAVC isn't as critical to 7 as it was to Vista IMO, with 7 having a working default h.264 codec built in. Vista was much harder to get to play DXVA in MCE. CoreAVC 'may' be better on 7 but even as an owner of CoreAVC I'm not sure if I will install it on my 7 rig.

Well, it's your right to disagree and I appreciate your points. However I don't think you are the whole of the market.

While x64 users might not be the biggest share of the market, they're growing fast and for valid reasons which makes us an important segment for CoreAVC to address - 32-bit will eventually disappear, just like 16-bit did. To take your points one by one:

1) It's good that you are happy with the 32-bit codecs, and so am I - on my desktop. But on my HTPC I want to run windows media center, which is only 64-bit on Win7 x64. So if I want to use CoreAVC, I'm stuck with 32-bit windows - not cool.

2) Why not cool? Well, for one thing x64 windows is significantly more robust, responsive and faster on newer systems. It can access all the physical memory, has better threading on multi-core CPUs, and fully utilizes the 64-bit CPU capabilities. In most tests, x64 systems beat x86 systems hands down. True it does little for decoding, but it does a lot for everything else.

3) About a year ago windows x64 adoption was tripling every 3 months. It has possibly accelerated since especially with win 7 coming out and MS encouraging adoption of the x64 platform.

4) As for your choice to stick with the MS codecs, that's fine if DXVA is all you care about. Speaking for both me and many other HTPC users, we want subtitles (not available with MS codecs and WMF, multiple-audio streams (also not possible - you need haali), more audio decoding and processing options (forget it, you're stuck with the MS audio decoder only - at least in MC) and lots of other things which the default codecs don't support or allow you to configure.

As for DXVA - seriously who cares? Most CPU's today handle 1080p in software just fine. I heat is a problem, you can buy a 2-core energy efficient CPU for less than $100. DXVA might be useful for a couple of years but just ask yourself who cares about hardware accelerated DVD decoding today?

[Virtual_ManPL]

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly
x264 - core 55 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:-6:-6 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=2pass bitrate=5299 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30 zones aq=1:0.3:15.0
file:
CoreAVC-large-motion-vectors-x264-b0rk.mkv (http://www.cccp-project.net/beta/test_files/CoreAVC-large-motion-vectors-x264-b0rk.mkv)
http://img101.imageshack.us/img101/9430/coreavc1.th.png (http://img101.imageshack.us/i/coreavc1.png/)



2 bug
frames are wrongly decoded in CUDA and soft mode, internal MPC-HC decoder decode this properly
OLS05lossless--avisource_82_92.mp4
x264 - core 55 svn-663C - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=7 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=32 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=1 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=2 wpredb=1 bime=1 keyint=240 keyint_min=25 scenecut=40 rc=2pass bitrate=1717 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30
file:
OLS05lossless--avisource_82_92.mp4 (http://www.cccp-project.net/beta/test_files/OLS05lossless--avisource_82_92.mp4)

CoreAVC
http://img192.imageshack.us/img192/4695/coreavc2.th.png (http://img192.imageshack.us/i/coreavc2.png/)
internal MPC-HC decoder
http://img192.imageshack.us/img192/6159/mpchc.th.png (http://img192.imageshack.us/i/mpchc.png/)



and you can also try other files on this FTP (http://www.cccp-project.net/beta/test_files/) to check that everything working properly with CoreAVC 2.0 before official release ;)

[hydra3333]

Latest new nvidia driver 195.62 says
"Adds support for OpenCL 1.0 (Open Computing Language) for all GeForce 8-series and later GPUs."
Does that change anything ?

[LoRd_MuldeR]

No, it doesn't. And it has been explained a dozen times why OpenCL isn't relevant for CoreAVC.

:search:

[roozhou]

No, it doesn't. And it has been explained a dozen times why OpenCL isn't relevant for CoreAVC.

:search:
It is not easy to explain to those who knows little about computer architecture. People see those words in NV's new drivers and believe GPU+OpenCL may help speed up everything.

[LoRd_MuldeR]

It is not easy to explain to those who knows little about computer architecture.

That's why it has been explained in this thread. More than one time ;)

[TheShadowRunner]

Please take as much time as you want to release 2.0, but by all means correct the "live resolution switching issue (http://forum.doom9.org/showthread.php?p=1282057#post1282057)" before release!

[mandarinka]

Oh, I also have an issue with resolution switching, this time with both software and hardware mode. Actually, I don't use coreAVC myself (although I admire how it's optimized for K7/K8!), a friend pointed out the error for me.

What happens: there are video corruptions or crashes if you encounter/seek through a resolution change in h.264 video - in my case they are two matroska segments linked together into one merged timeline. I used different pps/sps id for both segments when encoding to x264 (I also found out that I have to use raw output in x264, for those who are interested), which causes filter chain reconnection (?) and enables decoder to switch the resolution.

This works perfectly with most if not all renderes - if I use divx decoder or ffdshow-tryouts (in its case, it works with revision 3008 and lower, there is a regression after that, coincidentally). Obviously this is with haali splitter, else there would be no linking.
Now with coreavc (both software and hardware decoding), one gets video corruption when the resolution switches, and the decoding isn't corrected in further gops either, it even corrupts when you seek elsewhere - forward, or back to the previous segment. I checked if the decoder switches the resolution, and it apparently does so (else the video would be totally beyond recognition from my experience), mybe the parsing somehow seems to get glitched, resulting in the corruptions.

Because the affected video files (movie with changing AR) were too cumbersome, I made a couple of small samples with the same workflow, to replicate the issue.

------------------------------------------------------------
http://www.mediafire.com/?2z1ziktwlyj
http://www.mediafire.com/?tmvmjn2nemz

They are for demostration purposes only (pardon for disclaiming :eek:). Video was borrowed from import ntsc dvd of Osamu Tezuka's Cleopatra movie, audio is a random mp3 with some amateur performance (used just to simulate audio track, note that it's intentionally the same for both parts) and subtitle script muxed in is just a dummy (added for the same reason)...

x264 commandline:
--crf 19 --no-mbtree --tune grain --b-pyramid --keyint 48 --preset slow --sps-id 1 --output "cleoA.264"
--crf 19 --no-mbtree --tune grain --b-pyramid --keyint 48 --preset slow --sps-id 2 --output "cleoB.264"


sample mkvmerge 2.4.2 commandline (the same is used for segment A too, simple blocks not enabled):
-o cleoB.mkv --priority lower -s 0 -D -A sample.ssa -a 0 -D -S BABICKA.MP3 --default-duration 0:24000/1001fps -d 0 -A -S cleoB.264 --track-order 2:0,1:0,0:0
------------------------------------------------------------
So much for the report, thanks for your attention!

PS: Hello to forum members :)

[Edit:] PPS: I tried this (http://forum.doom9.org/showpost.php?p=1348169&postcount=211) version of Diavc; it doesn't show the corruptions I was experiencing with coreavc and links fine if width of video changes, while for some reason crashing on height change (so not a complete pass).

[Mixer73]

2) Why not cool? Well, for one thing x64 windows is significantly more robust, responsive and faster on newer systems. It can access all the physical memory, has better threading on multi-core CPUs, and fully utilizes the 64-bit CPU capabilities. In most tests, x64 systems beat x86 systems hands down. True it does little for decoding, but it does a lot for everything else.

Personally I've yet to see a single benchmark that actually shows this.

Potentially the adoption of a new 'lowest common denominator' instruction set optimisation could provide a speed boost but I'm yet to see any applications that can back this up.

You're right, unlike most here I don't use subs or any such thing so I don't have those requirements, but I still had CoreAVC on my Vista system because it was the simplest and most compatible solution. However, I see no point at all in running 64bit for a MCE platform - I fail to see any benefits at all for this usage, so I'm running 32bit.

I have no argument that its the right way to go, but the way I see it, right now, it costs a lot of development time and money, without providing any additional benefits to the consumer.

My POV on this is influenced by my employment position, which is in the video editing & video compression fields. Personally there have been better ways for our staff to spend their development time to give more features for our customers than to work on 64bit code which at this point in time doesn't deliver a tangible benefit across all relevant areas.

Indeed as you've stated its something that will need to be done, but there's more productive areas IMO.

[Guest]

Debate about x64 Windows is OT here. Please start a new thread in an appropriate forum.

[squid_80]

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly

file:
CoreAVC-large-motion-vectors-x264-b0rk.mkv (http://www.cccp-project.net/beta/test_files/CoreAVC-large-motion-vectors-x264-b0rk.mkv)
http://img101.imageshack.us/img101/9430/coreavc1.th.png (http://img101.imageshack.us/i/coreavc1.png/)
Looks like it was encoded with an old build of x264, which didn't restrict vertical motion vectors properly.


2 bug
frames are wrongly decoded in CUDA and soft mode, internal MPC-HC decoder decode this properly

file:
OLS05lossless--avisource_82_92.mp4 (http://www.cccp-project.net/beta/test_files/OLS05lossless--avisource_82_92.mp4)

CoreAVC
http://img192.imageshack.us/img192/4695/coreavc2.th.png (http://img192.imageshack.us/i/coreavc2.png/)
internal MPC-HC decoder
http://img192.imageshack.us/img192/6159/mpchc.th.png (http://img192.imageshack.us/i/mpchc.png/)

I tried the following decoders and none of them decoded the clip properly:
- DivX
- ArcSoft
- ffmpeg
- DiAVC
- MPC-HC DXVA

[Virtual_ManPL]

Looks like it was encoded with an old build of x264, which didn't restrict vertical motion vectors properly.
dunno, soft mode works good, CUDA not ;)


I tried the following decoders and none of them decoded the clip properly:
- DivX
- ArcSoft
- ffmpeg
- DiAVC
- MPC-HC DXVA
but MPC-HC can

[Astrophizz]

MPC-HC (internal) is ffmpeg...

[sneaker_ger]

Can someone enlighten me about the reference frame limit of CoreAVC in CUDA mode? On the CoreCodec site it says that 16 frames is the limit but on many pages it says that the limit is actually 15 frames. Or does this depend on the version of CoreAVC, the resolution, graphic card and frame rate?
And how does CoreAVC decide if it will decode a video with CUDA or in pure software mode? Does it only read the level or does it inspect the x264 info (if x264 was used and the info not stripped)?

[honai]

squid_80 answered this a while back:

http://forum.doom9.org/showthread.php?p=1262588#post1262588
http://forum.doom9.org/showthread.php?p=1192953#post1192953
http://forum.doom9.org/showthread.php?p=1262558#post1262558

[sneaker_ger]

That answers my first question, thank you! The formulation on the CoreAVC page (http://forum.corecodec.com/viewtopic.php?f=3&t=69) can lead to misunderstanding.
Still leaves me wondering about those "out-of-order frames" though. How does CoreAVC make sure those frames won't get corrupted e.g. by using pure software mode?

[schweinsz]

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly
The.Illusionist.2006.HDTV.720p.x264-iLL.mkv
x264 - core 55 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:-6:-6 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=2pass bitrate=5299 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30 zones aq=1:0.3:15.0
file:
CoreAVC-large-motion-vectors-x264-b0rk.mkv (http://www.cccp-project.net/beta/test_files/CoreAVC-large-motion-vectors-x264-b0rk.mkv)
http://img101.imageshack.us/img101/9430/coreavc1.th.png (http://img101.imageshack.us/i/coreavc1.png/)



2 bug
frames are wrongly decoded in CUDA and soft mode, internal MPC-HC decoder decode this properly
OLS05lossless--avisource_82_92.mp4
x264 - core 55 svn-663C - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=7 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=32 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=1 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=2 wpredb=1 bime=1 keyint=240 keyint_min=25 scenecut=40 rc=2pass bitrate=1717 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30
file:
OLS05lossless--avisource_82_92.mp4 (http://www.cccp-project.net/beta/test_files/OLS05lossless--avisource_82_92.mp4)

CoreAVC
http://img192.imageshack.us/img192/4695/coreavc2.th.png (http://img192.imageshack.us/i/coreavc2.png/)
internal MPC-HC decoder
http://img192.imageshack.us/img192/6159/mpchc.th.png (http://img192.imageshack.us/i/mpchc.png/)



and you can also try other files on this FTP (http://www.cccp-project.net/beta/test_files/) to check that everything working properly with CoreAVC 2.0 before official release ;)

I extracted the raw 264 bitstream in OLS05lossless--avisource_82_92.mp4 and decode it to locate the error and I found it is a corrupted bitstream. When MB with (mbx=26, mby=1)is decoded, the end_of_slice_flag=1 in the first P picture with POC=4, so I believe no decoder can get the "correct" result, the needed operation is error concealment.

[Virtual_ManPL]

@ schweinsz - yep, it's probably like you said, but look how decode this newest MPC-HC in soft mode vs your decoder, CoreAVC (CUDA & soft) and DivX (+ MPC DxVA decoding)
only with MPC decoder in soft mode I get not pixelated frame like you can see on attached SS, odd ;p

[Keiyakusha]

Maybe it works in MPC because of some bug ^_^

Anyway may I ask about status of this multi-something bug in CoreAVC 2.0? Its not that I'm asking about releasing it now, I just thought that bug was not so serious...

[schweinsz]

@ schweinsz - yep, it's probably like you said, but look how decode this newest MPC-HC in soft mode vs your decoder, CoreAVC (CUDA & soft) and DivX (+ MPC DxVA decoding)
only with MPC decoder in soft mode I get not pixelated frame like you can see on attached SS, odd ;p

The first P picture with poc=4 is almostly same with the preceding I picture with poc=0, if error concealment is done, the P picture will be recovered perfectly. the current DiAVC is without the error concealment and I will add it after beta version is released.

[bluebebe]

hi there, i thought it was another error with the encoder, but its coreavc, it produces in a few videos of mine errors like this:

http://i46.tinypic.com/23j692o.jpg

http://i46.tinypic.com/4kzq6w.jpg


It is a bug or what? when i try decoding a x264 thru ffdshow i dont have that artifacts. hope anyone can tell me what the problem is.

[JEEB]

You might want to read some of the last pages of this thread. I think it's pretty sure that it's just the decoding bug/feature that's present in the 1.X series of CoreAVC and that has been fixed/added for quite some time already, just that CoreCodec hasn't gotten to releasing their 2.X version yet (which contains the support for weightp). nvidia's VP2 decoding doesn't have problems with decoding such content, just to note it one more time (CoreAVC's CUDA feature uses the VP2 hardware on the GPU).

You might want to use another decoder until CoreAVC 2.X gets released, and then check if it contains enough reasons for you to upgrade :)

[squid_80]

It's virtually impossible to confirm the cause of a problem from screenshots, stream samples are needed.

[bluebebe]

no samples needed, with cuda the video is working fine. thanks for help :)

[pankov]

Well, I too have problems (very rare to be fair) with CoreAVC's decoding.
Here is a sample showing the problem captured in the picture bellow. The same file plays fine both with FFDShow and MPC-HC decoders.
[link removed]

http://img44.imageshack.us/img44/3894/samplemkv00000.th.jpg (http://img44.imageshack.us/i/samplemkv00000.jpg/)

I'm using ATI so I don't have a chance to test it with CUDA. Can someone confirm/deny that this is the same weightp problem?

[pankov]

no, it's a sample I've found on the net with complaints about bad quality and just wanted to check if the problem was present on my machine too.
As you can see - it does and I'm still not sure which is the problem the source or CoreAVC.

I read that it's not against the rules to post samples, but if I misread/misunderstood the rules I'll remove it.

[Stephen R. Savage]

If it was encoded with x264, you can look at the headers in a hex editor (search for ASCII string "x264"). Streams encoded with weight-p on will display either "wpredp=1" or "wpredp=2". If it was not encoded with x264, you probably have to use a stream analyser like Elecard StreamEye or something.

[LoRd_MuldeR]

If it was encoded with x264, you can look at the headers in a hex editor (search for ASCII string "x264").

Or more user-friendly, look at the x264 encoding parameters with a tool like MediaInfo or AVInaptic :)

[weasel_]

Well, I too have problems (very rare to be fair) with CoreAVC's decoding.
Here is a sample showing the problem captured in the picture bellow. The same file plays fine both with FFDShow and MPC-HC decoders.
[link removed]

http://img44.imageshack.us/img44/3894/samplemkv00000.th.jpg (http://img44.imageshack.us/i/samplemkv00000.jpg/)

I'm using ATI so I don't have a chance to test it with CUDA. Can someone confirm/deny that this is the same weightp problem?
put in mediainfo and see if weightp=2

[pankov]

Well, I did try this (with the latest version from sourceforge - GUI 0.7.25) and here is the result
Writing library : x264 core 79 r1342 e8501ef
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=esa / subme=10 / psy=1 / psy_rd=1.0:0.3 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=6 / nr=0 / decimate=0 / mbaff=0 / constrained_intra=0 / bframes=5 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / mbtree=0 / bitrate=14648 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=30 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.70

I have to admit I don't understand 90% of these parameters but I do see that there is no wieghtp or alike.

[kemuri-_9]

I have to admit I don't understand 90% of these parameters but I do see that there is no wieghtp or alike.

weightp is written as wpredp in the SEI,
see the wpredp=2 in your options there which indicates weightp 2 was used.

[pankov]

10x for the help
Now I'm officially a "victim" of the weightp bug/feature of CoreAVC
;)

[BetaBoy]

Well... a good thing now is that we are reworking how we handle MV's now (we now support non-spec compliant streams), which in-turn had a direct effect on our current weightp support.

[ajp_anton]

Will the 64-bit version be any faster? And if so, how much?

[BetaBoy]

Will the 64-bit version be any faster? And if so, how much?

We've discussed this several times here in this thread, but... you'll likely see negligible speed improvements for 64bit. I'll leave it for you all to tell us that after its released just how 'true' that to be, but I think many of you will be surprised.

[Snowknight26]

Any updates on that one bug you guys were aware of that hadn't been fixed at the time you mentioned it... whatever that bug was/is?

[BetaBoy]

iirc I did state its a weightp bug related to our support for the updated x264 and is a part of what we are working on now.

[hajj_3]

don't suppose you have a new eta?

[dead_screem]

Well... a good thing now is that we are reworking how we handle MV's now (we now support non-spec compliant streams), which in-turn had a direct effect on our current weightp support.

How is it supported? With two internal decoders? One with spec compliant MV limits and the other unlimited? (as mentioned a few times in this thread,). Or just one decoder with unlimited MV support?

[Hans Ohlo]

it is really disappointing as always with core. we get an eta for the avc decoder and haali with x64 support weeks ago and still nothing. really great as always. we should have known better.

[Shakey_Jake33]

In fairness, people have been fussing for support for out of spec MVs and the like for ages, and people critisised CoreCodec a few pages ago for not supporting it. I don't think it's necessarily fair to critisise them for doing what people have asked them to do.

[Snowknight26]

iirc I did state its a weightp bug related to our support for the updated x264 and is a part of what we are working on now.

My mistake - I thought there was only one bug in CoreAVC and HMS, not simply CoreAVC. You mentioned in one of your previous posts you were only aware of one bug in the 2.0 codebase, but I skipped over the part where you mentioned that you don't work in tandem with Haali. Bummer.

[hydra3333]

it is really disappointing as always with core. we get an eta for the avc decoder and haali with x64 support weeks ago and still nothing. really great as always. we should have known better.
Crikey, you're a bit on the down side ! Cheer up mate, when it arrives think how you'll enjoy it then.

[DigitalDeviant]

it is really disappointing as always with core. we get an eta for the avc decoder and haali with x64 support weeks ago and still nothing. really great as always. we should have known better.

LOL, when has Core ever met a release date they set? This has been a tradition going back to 1.0 back in April 2006, why break it now?

[squid_80]

LOL, when has Core ever met a release date they set? This has been a tradition going back to 1.0 back in April 2006, why break it now?

When was a definite release date given?

[BetaBoy]

My mistake - I thought there was only one bug in CoreAVC and HMS, not simply CoreAVC. You mentioned in one of your previous posts you were only aware of one bug in the 2.0 codebase, but I skipped over the part where you mentioned that you don't work in tandem with Haali. Bummer.
Well we found out that the Motion Vector limit we had has a direct effect on WeightP, so its a 2-for-1 bug fix and requires we rewrite a nice chunk of code. The good thing about this though is as I stated, a) It removes the MV limitation, and now b) Will take into account some future x264 WeightP changes, which we already know are coming sometime next year.

While its obvious we have a vested interest in Haali's work with the splitter, he works at his own pace but has always listened to what needs to be fixed/changed... and if you ask many of the testers (*cough*Jarod) the latest versions have fixed almost every known issue (outside of VC1), but I'm sure more needs to be done.

[betaking]

Well we found out that the Motion Vector limit we had has a direct effect on WeightP, so its a 2-for-1 bug fix and requires we rewrite a nice chunk of code. The good thing about this though is as I stated, a) It removes the MV limitation, and now b) Will take into account some future x264 WeightP changes, which we already know are coming sometime next year.

While its obvious we have a vested interest in Haali's work with the splitter, he works at his own pace but has always listened to what needs to be fixed/changed... and if you ask many of the testers (*cough*Jarod) the latest versions have fixed almost every known issue (outside of VC1), but I'm sure more needs to be done.

:)today i test Haali Media Splitter 1.9.355.21! on windows7 wmp12 can use haali play avi files but test ts/tp file not work! use mpc-hc use haali play some ts file encoder by vc1 not see video but sound is ok! and some vob files can see video but no sound! sound encoder by lpcm! can repot it to haali ?thanks!

[BetaBoy]

A big hurdle has been overcome. CoreAVC 2.0 now supports Non-Compliant Motion Vector's.... and it gets even better, WeightP is now fully supported ;-) (this also includes support for future x264 weightp changes coming in 2010). We are going through QA now and tweaking the code as we go. No timeline on the release, let's see how QA goes.... but current results puts us on top again, but there is still room for improvement ;-)

Thanx all for your patience.

[Mixer73]

Bring it on Dan!

[hydra3333]

Yep, do a good job in QA and then please release it as soon as you reasonably can !

[link2009]

When 2.0 gets released and I see a decent improvement for playback, I will re-purchase it to support the project.

[Romario]

BetaBoy,please, I have one question for you. :)

Can you, please, tell me from which site I can download latest Development version of Halli media splitter, which you will use in CoreAVC 2.0 ?

thanks. I want to test it on Windows 7.

[BetaBoy]

Technically its the same that's on Haali's site right now.... all we do is add our special sauce (non-hacking) to make it work on Windows 7.

[honai]

While its obvious we have a vested interest in Haali's work with the splitter, he works at his own pace but has always listened to what needs to be fixed/changed... and if you ask many of the testers (*cough*Jarod) the latest versions have fixed almost every known issue (outside of VC1), but I'm sure more needs to be done.

Can you, please, tell me from which site I can download latest Development version of Halli media splitter, which you will use in CoreAVC 2.0 ?

thanks. I want to test it on Windows 7.

Technically its the same that's on Haali's site right now.... all we do is add our special sauce (non-hacking) to make it work on Windows 7.

Now you got me really confused. So does the latest version at your hands realize bug-fixes not implemented in the latest downloadable splitter (dated 11/01/2009), or not?

[BetaBoy]

Now you got me really confused. So does the latest version at your hands realize bug-fixes not implemented in the latest downloadable splitter (dated 11/01/2009), or not?
Have you tested the new version Haali posted on his site for any bugs?

[ChronoCross]

Have you tested the new version Haali posted on his site for any bugs?

The one on Haali's site is from January.

[BetaBoy]

I thought Haali had posted the new version already. Pinging him now.

[ajp_anton]

A little offt, but a "11/01/2009" date can be either Nov 1st or Jan 11th, depending on which one of the weird formats you use.
2009/01/11 = no confusion.

[LoRd_MuldeR]

I'd prefer the ISO 8601 format. For example:
2009-12-16

And the latest version on Haali's site definitely dates back to 2009-01-11 ;)

[THX-UltraII]

great news that the new Haali Renderer will be up soon!

[Carpo]

http://haali.net/mkv/mkx.y.9.exe - thought that was the latest unofficial version about

[Keiyakusha]

THX-UltraII
Renderer? I guess you mean splitter? Or there is some changes to the renderer too?

[THX-UltraII]

THX-UltraII
Renderer? I guess you mean splitter? Or there is some changes to the renderer too?

sorry, mistyped

[hydra3333]

Technically its the same that's on Haali's site right now.... all we do is add our special sauce (non-hacking) to make it work on Windows 7.

Hmm, is this http://www.videohelp.com/tools/Preferred_Filter_Tweaker your work in getting codecs to work under Win7 ?

[Jeff Flowerday]

Hmm, is this http://www.videohelp.com/tools/Preferred_Filter_Tweaker your work in getting codecs to work under Win7 ?

:confused:

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

[hydra3333]

Ah, it's something different. Thanks.

[honai]

I thought Haali had posted the new version already. Pinging him now.

I understand you are on a busy schedule, but are there any followups on this?

[STaRGaZeR]

You can get the (lastest?) Haali beta with CCCP beta. Deselect everything but Haali and you're done. It supports TrueHD in MKV and detects Blu-ray stereo LPCM tracks ;)

[BetaBoy]

I understand you are on a busy schedule, but are there any followups on this?

Haali will post it on his site when we launch 2.0.

[tal.aloni]

You can get the (lastest?) Haali beta with CCCP beta.

the revision included is Haali 1.9.355.21 (2009-11-14)
you might as well grab it from his site (sorry):
-removed-

nice progress haali, thanks!
however, this release crash with the m2ts samples I posted earlier (TrueHD / EAC3), and also crash with another Blu-Ray I have (TrueHD).

Note:
I have not yet investigated the origin of the crash, there's a slight chance it's unrelated to the splitter.

Edit:
The crash is related to ffdshow, later build resolve the crash, but the playback is still very choppy with TrueHD, I'm not sure if it's a bug with the splitter or the decoder.

[BetaBoy]

tal.aloni.... Excuse me if I ask but, has Haali given you the ok to post that? As far as we are concerned we have respected Haali's work until we have the OK to distribute it or he posts a public link to it (which I do not think has occurred).

[tal.aloni]

I have removed the link, I don't want to offend anybody,
however, it's already embedded into many codec packs.
the file name was published already by a few codec-pack authors.

[BetaBoy]

tal.aloni... Thx it's appreciated. It seems some of the testers decided it was ok to give out the links ;-/ . . . there is a reason its only posted on Haali's site when its ready.

[Keiyakusha]

Not necessarily. It's not hard to guess that link using capabilities of any download manager with support downloading by mask.

[BetaBoy]

True.... but in this case I already have confirmation that the testers in fact did give out download links. No biggie now.... we just don't want reports coming back on versions that maybe old and fixed (or not ;-).

[Carpo]

so is there anything wrong with that build ;)

[BetaBoy]

It dosen't really matter at this point as Haali will be posting the update soon enough.

[BetaBoy]

Well the time has come... We are about to release CoreAVC 2.0 Professional Edition for Windows. Current customers will be notified first... Purchasers in the past 60 days get the upgrade included.... post 60 will get a unique code to upgrade. Emails are going out now for; 1) The new portal login account (all users get this), and 2) The upgrade email.

I'll post more details next.

[BetaBoy]

After 9 months of work, CoreCodec is proud to release CoreAVC 2.0 Professional Edition.

More details below.... but lets get to what's new:

CoreAVC H.264 Video Codec - Version 2.0.0.0 (20091218)
- ADD: Initial support for Windows 7
- ADD: Support for Windows Media Center (in .MKV)
- ADD: Custom fourcc to match the Haali splitter
- ADD: Support for Non-Compliant Motion Vectors (MV)
- ADD: mmx optimizations
- ADD: mmx2 optimizations
- ADD: sse optimizations
- ADD: sse2 optimizations
- ADD: sse3 optimizations
- ADD: ssse3 optimizations (almost 70)
- ADD: sse4 optimizations
- ADD: faster handling of pure-DC chroma blocks
- ADD: new x86 cpu caps
- ADD: Multi-dupe weightp (+Future x264 changes)
- ADD: 64bit support
- FIX: Fix potential failure in CABAC MVD decoding.
- FIX: Proper alignment intrinsics for MSVC and GCC.
- FIX: AVC SEI+userdata fix
- FIX: Focus bug in Windows Media Center that disabled CUDA
- FIX: Better frame re-ordering on difficult streams
- CHG: Supports 16 CPU Cores (was 4 cores max)
- CHG: Support for QuadHD resolutions(4096×4096)
- CHG: New dc_add
- CHG: Faster CAVLC
- CHG: Faster CABAC
- CHG: Faster Deblocking (Massive deblocking overhaul)
- CHG: SSSE3: Faster Motion Compensation (20% faster on Core 2 Conroe and more for Penryn)
- CHG: New CoreNumber for 2.0
- CHG: Initial support for CoreAccount. Linking purchase+account
- CHG: Integrated the Haali splitter into the installer
- CHG: New installer supports both 32/64 bit Operating Systems
- CHG: Filter compiled against ICC (2% speed increase for modern Intel Processors)
- CHG: Updated IDCT to support ARM NEON Cortex A8 Support
- CHG: Updated Blitter YUV/RGB for ARM NEON Cortex A8 Support
- OEM: Initial ARM NEON Cortex A8 Support (iPhone, Touch, Linux, Windows Mobile)
- OEM: SDK NVIDIA CUDA 2.3 support
- OEM: Removed the windows direct3d requirement for CUDA (it can now be native)
- OEM: Updated GStreamer plug-in


Haali Media Splitter (20091112)
- ADD: Official 64bit support
- ADD: Official support for Windows 7
- ADD: Custom fourcc option for windows 7
- ADD: Silent install flags for each install option
- CHG: Disabled explorer thumbnail support (off by default)

Haali Media Splitter supports the following command line options:
/S - silent install without any UI
/MKVONLY - register only Matroska components
/AVI=[yes|no] - register AVI support
/MP4=[yes|no] - register MP4 support
/OGG=[yes|no] - register OGG/OGM support
/TS=[yes|no] - register MPEG TS support
/PS=[yes|no] - register MPEG PS support
/WMP=[yes|no] - register WMP to play in Windows 7


Bulletpoints on CoreAVC 2.0
-------------------------------
- First on Windows 7..... Both CoreAVC and Haali's splitter now use a custom fourcc so that when you play an MKV video it uses Directshow instead of MediaFoundation in WMP and MC. No hacks and its a simple solution to gets ppl out of the pitfalls of MF. Note that this is ONLY for .mkv and does not affect any other container.
- You will also see CoreAVC now supports both 32/64bit, but like Haali we have opted to keep both .AX's in the same folder for simplicity's sake.
- We would also like to thank Clsid for his help with some of the changes we made to the installer for all OS's but mostly Win7.

[clsid]

Haali Media Splitter (20091112)Based on the date I assume this is version 1.9.355.21. What will happen with the bugs that have been reported for that version? Will there be another release in the near future?

[BetaBoy]

If I am not mistaken the date in the readme is wrong. The build # is: 1.9.355.21 that's what counts (as you mention). But otherwise yes, Haali said when he gets time (motivation) he will work on the additional bugs reported.

[Cyber-Mav]

criky thats a big changelog listing a lot of speed boosts, hopefully someone will post some test results here showing how coreavc 2.0 fairs against divx, diavc and against coreavc 1.9.5

[the_corona]

Awesome, lots of speed optimizations!

Any benchmarks you can share? Which proc generation saw the biggest speed bump (probably the latest which ironically needs it the least, lol)

[Disabled]

One Question: Do you sell a full featured High Profile* Decoder this time? Or is it again possible that in 2 years x264 will use a feature previously not used and everyone has to buy a new licence?
(This of course excludes new features that are added to the specs after the purchase, as you don't need to promise on those.)

*normal High profile, not High10 or with 4:4:4 support

[Dark Shikari]

Awesome, lots of speed optimizations!

Any benchmarks you can share? Which proc generation saw the biggest speed bump (probably the latest which ironically needs it the least, lol)
The speed bump is pretty big, though note that the following test was done on a Core i7 with HT, and CoreAVC 1.9.5 was capped to 4 threads max, so the real boost is not as large as the graph suggests. Obviously, CoreAVC 1.9.5 was still faster than ffdshow-mt on a per-core basis; it's just that 8 threads of ffdshow-mt beat out 4 threads of CoreAVC 1.9.5.

http://i50.tinypic.com/b7ett3.png

CoreAVC is now slightly faster than DivX on 1080p HD content. The weightp example is somewhat invalid, as DivX does not decode weightp bit-exact. The results of the 2160p test were a bit odd though: I'm going to guess that DivX is faster on really low bitrate content (the 2160p test case was 4 megabit).

Note "CoreAVC 2.0 Intel" is using ICC, so you can see the benefit of that.

[Cyber-Mav]

yikes looks like divx is still damn quick. would be good to see how diavc compares with the above. i guess coreavc is only good for those who want cuda support, cant see people paying good money for a decoder thats hardly any quicker and in half the cases above slower than a free alternative. ??

[Dark Shikari]

yikes looks like divx is still damn quick. would be good to see how diavc compares with the above. i guess coreavc is only good for those who want cuda support, cant see people paying good money for a decoder thats hardly any quicker and in half the cases above slower than a free alternative. ??Well DivX still doesn't handle weightp correctly, albeit the artifacts are generally not too noticeable. Also note that CoreAVC likely has a larger advantage on older CPUs, which is where you most need the speed of a fast decoder to begin with. I don't have an older CPU to test it on though; I'd be curious about the results.

Hopefully in 2.1 the speed will be even higher ;)

[Cyber-Mav]

need some tests done on older hardware such as athlon xp. wonder if there is some inprovements for atom cpu's too.

shikari any idea if divx will sort out the weight-p issues you mentioned in future divx updates?

[Dark Shikari]

shikari any idea if divx will sort out the weight-p issues you mentioned in future divx updates?Dunno. Slap them until they do. It's a trivial deblocking bug that's very common among decoders, and fortunately one whose effects are probably not noticeable in real situations. It still should get fixed though.

Do note that CoreAVC had to sacrifice a small amount of speed (not much, but measurable) to fix the MV range and weightp issues.

[the_corona]

yikes looks like divx is still damn quick. would be good to see how diavc compares with the above. i guess coreavc is only good for those who want cuda support, cant see people paying good money for a decoder thats hardly any quicker and in half the cases above slower than a free alternative. ??

I agree, that's kinda dissapointing.....hmmm

But from what I remember DivX did comparitably good on high core/thread counts (probably better multithreading), so I'm guessing the graphs would look different on a 2 core machine. At least I'm hoping.....

[Dark Shikari]

I agree, that's kinda dissapointing.....hmmm

But from what I remember DivX did comparitably good on high core/thread counts (probably better multithreading), so I'm guessing the graphs would look different on a 2 core machine. At least I'm hoping.....Likely true as well. We're probably going to look into some multithreading tweaking with lots of cores, though to be honest one hardly needs CoreAVC on a system as beefy as the one I benchmarked on.

[the_corona]

Likely true as well. We're probably going to look into some multithreading tweaking with lots of cores, though to be honest one hardly needs CoreAVC on a system as beefy as the one I benchmarked on.

Wait...."we're" as in "we" as in you and CoreAVC? Are you on their team now?

Does that mean CoreAVC got their optimizations from yours truly?

Edit: I guess you are since the ICC version indicates you have access to the source code.

[Dark Shikari]

Wait...."we're" as in "we" as in you and CoreAVC? Are you on their team now?

Does that mean CoreAVC got their optimizations from yours truly?Yes, all the x86 asm since 1.9.5 has been written by me, including some from x264 that I wrote as well ;)

A bit has gone in the other direction too; x264's cacheline-split chroma MC was originally written for CoreAVC.

[Snowknight26]

Any word on when we can expect HMS as a standalone download?

[Astrophizz]

Looking forward to trying out a trial version to compare with DiAVC which is even faster than DivX on my system. If Dark's chart is any indicator then I'd have to agree with Cyber-Mav that it doesn't look good. Maybe I'll see CoreAVC's "larger advantage on older cpus" since I have a Core Duo (not Core2). Exciting stuff either way.

[ranpha]

Nice new website, the same as my website provider support system. Is that affiliate feature really work? 20% off purchase price is really generous. :p

[dead_screem]

so what's the deal? the website still has 1.9.5 and I havn't gotten an email. for the record the last update email I got was for 1.6. 1.6.5 and up I had to use the resend form every time, comcast seems to be blocking your bulk emails. So how do I get my 2.0 update 20% off email now?

Edit: I found the new core account system, (unfortunately it doesn't use our old core account email/passwords). It used my paypal email as the account email. (I had originally used a different email for the old core account then the one I payed with paypal) I tried logging in to the new system with my paypal email and my old core acount pasword and that didn't work. I tried the forgot password link and it said validation email sent but I got nothing. My paypal email was with aol. can't submit a support ticket because I would need to access my account to even do that... so now what?

[lnatan25]

A small question, will the h264 decoding bugs also find their way into the CorePlayer Movile platform?

[dvy]

CoreAVC is definite fastest H.264 decoder in planet earth.



Note "CoreAVC 2.0 Intel" is using ICC, so you can see the benefit of that.

Dark Shikari，why don't compile CoreAVC of windows version in icl,icl is wondows version intel C++ compiler.I compile x264 in icl is faster than x264 compile in gcc.

[hippoth]

What about a CoreAVC version for Mac OS X ... is there anything in the pipe?

[blubberbirne]

When buyers get the email with the download link???

EDIT: I can't login in customer area. My eMail don't work!

[zn]

any news on linux version? or android market?

[BetaBoy]

When buyers get the email with the download link???

EDIT: I can't login in customer area. My eMail don't work!

We are doing exactly as I stated emailing current customers with the account login first, then releasing it to them. So users will start to see those emails over the next few hours as they go continue to go out. Then we will open purchasing to the public.

[BetaBoy]

Nice new website, the same as my website provider support system. Is that affiliate feature really work? 20% off purchase price is really generous. :p
Correct, we have an affiliate program in place. However the rate will be 15% for 2.0.

Also on price. Upgrades are $4.95 and the full version is $9.95 (discounted from $12.95 till xmas).

[BetaBoy]

Looking forward to trying out a trial version to compare with DiAVC which is even faster than DivX on my system. If Dark's chart is any indicator then I'd have to agree with Cyber-Mav that it doesn't look good. Maybe I'll see CoreAVC's "larger advantage on older cpus" since I have a Core Duo (not Core2). Exciting stuff either way.
I did state this a while back in this thread that we will not offer a trial version of 2.0 for the first couple of weeks. The trial is scheduled to be released January 7th as CES begins as it is expected to be included on Media and some press junket's (NVIDIA, etc.)

[BetaBoy]

A small question, will the h264 decoding bugs also find their way into the CorePlayer Movile platform?Its the same thing really... so all the current fixes are already in CorePlayer 2.0. That also includes CUDA which we added a few months ago, but CorePlayer 2.0 will not be released in the next couple of weeks as we are still working on UI elements and trying to integrate our 'Corenect' UPNP/DLNA client/server into it for CES.

[BetaBoy]

so what's the deal? the website still has 1.9.5 and I havn't gotten an email. for the record the last update email I got was for 1.6. 1.6.5 and up I had to use the resend form every time, comcast seems to be blocking your bulk emails. So how do I get my 2.0 update 20% off email now?

Edit: I found the new core account system, (unfortunately it doesn't use our old core account email/passwords). It used my paypal email as the account email. (I had originally used a different email for the old core account then the one I payed with paypal) I tried logging in to the new system with my paypal email and my old core acount pasword and that didn't work. I tried the forgot password link and it said validation email sent but I got nothing. My paypal email was with aol. can't submit a support ticket because I would need to access my account to even do that... so now what?
Accounts get added into the system as the emails go out. So, no email=no account. Account emails are still going out.

[schweinsz]

yikes looks like divx is still damn quick. would be good to see how diavc compares with the above. i guess coreavc is only good for those who want cuda support, cant see people paying good money for a decoder thats hardly any quicker and in half the cases above slower than a free alternative. ??
From the results given by Dark Shikari, I believe the DiAVC alpha is still faster than the DiVX and coreavc2.0. I believe it is especially true when the DiAVC beta is out.

[BetaBoy]

schweinsz... no offense, but pls post results and not speculations and keep that talk in your thread, not this one.

[schweinsz]

schweinsz... no offense but pls post results and not speculations.
There are some results about coreavc1.9.5, divx and DiAVC.
http://forum.doom9.org/showthread.php?p=1331966#post1331966
http://forum.doom9.org/showthread.php?p=1334702#post1334702
http://forum.doom9.org/showthread.php?p=1344770#post1344770
http://forum.doom9.org/showthread.php?p=1347162#post1347162
http://forum.doom9.org/showthread.php?p=1347187#post1347187

I have not a coreavc 2.0, but allrough Dark Shikari gives that coreavc2.0 is comparible to divx, I believe it is slower than DiAVC.

I will give more results after you release the coreavc 2.0 to public between coreavc2.0 and the upcoming DiAVC beta.

[STaRGaZeR]

Yes, all the x86 asm since 1.9.5 has been written by me, including some from x264 that I wrote as well ;)

A bit has gone in the other direction too; x264's cacheline-split chroma MC was originally written for CoreAVC.

So we can forget about you RE'ing CoreAVC and improving libavcodec/ffmpeg-mt with that, right?

[squid_80]

I will give more results after you release the coreavc 2.0 to public between coreavc2.0 and the upcoming DiAVC beta.

How about you wait until your filter can output to multiple colorspaces, perform image levels adjustment, handle anamorphic widths properly and deinterlace. Also don't forget to provide the source files used for the benchmarks so they can be verified.

[edison]

there is a sync glitch when playing TrueHD clip with the 09-12-19 version MatroskaSplitter .

[Cyber-Mav]

From the results given by Dark Shikari, I believe the DiAVC alpha is still faster than the DiVX and coreavc2.0. I believe it is especially true when the DiAVC beta is out.

this is why im hesitant on making the purchase for coreavc 2.0
i hate to say it but its just too little way too late.

diavc beta will be the decider for me.

shikari could you rerun those speed test by locking affinity to 1 or 2 cores and see how performance racks up?

[tal.aloni]

there is a sync glitch when playing TrueHD clip with the 09-12-19 version MatroskaSplitter .

I can confirm that,
1. TrueHD have issues with both m2ts and mkv files, including the sample I posted @ page 256,
I can post more samples if needed.
Haali, is this part of your "core parser library"? I'm willing to help. (sent you an email)

2. I have a Blu-Ray demo disc that have two audio tracks: 5.1 DTS-HD and 2-channel LPCM,
I enjoyed 5.1 with the previous version,
but with the new version, I can only select the 2-channel LPCM audio track.

3. DD+ now works great. (starting with the new release).

Thanks,
Tal

[JohnnyFu]

Correct, we have an affiliate program in place. However the rate will be 15% for 2.0.

Also on price. Upgrades are $4.95 and the full version is $9.95 (discounted from $12.95 till after xmas).

Betaboy, is this the xmas edition you announced in 2008 ? Sorry, couldn't resist :D

Btw, I'd like to upgrade my lincense but I can't seem to find an upgrade link, huh?

http://corecodec.com/products/coreavc2

[LoRd_MuldeR]

It was already told that CoreAVC 1.x customers will receive an email with a unique upgrade code...

[JohnnyFu]

Aight', didn't read the forum lately, I just stumbled upon the Coreavc2 link while looking for a solution on how to play MKV's in Win7 MCE.

[BetaBoy]

Betaboy, is this the xmas edition you announced in 2008 ? Sorry, couldn't resist :D

Btw, I'd like to upgrade my lincense but I can't seem to find an upgrade link, huh?

http://corecodec.com/products/coreavc2

That link is not live yet.... it will be in about an hour as we send the emails out to current customers and take down CoreAVC.com to redirect them to CoreCodec.com

[BetaBoy]

There are some results about coreavc1.9.5, divx and DiAVC.

I will give more results after you release the coreavc 2.0 to public between coreavc2.0 and the upcoming DiAVC beta.

I'm really not gonna say it again seeing that you are insisting to taking your Off-Topic discussion to new levels. IE; Stop sh*tting on the release, before its even out, got it?

Take 'your' comparison out of this thread. Mods notified.

[weasel_]

Problem with cuda nad high number of ref frame is fixed ?

[BetaBoy]

In case you all did not notice..... Haali has posted the new splitter now that is included in CoreAVC 2.0: http://haali.su/mkv/

[edison]

In case you all did not notice..... Haali has posted the new splitter now that is included in CoreAVC 2.0: http://haali.su/mkv/

http://forum.doom9.org/showpost.php?p=1354688&postcount=5370 :)

[sneaker_ger]

One Question: Do you sell a full featured High Profile* Decoder this time? Or is it again possible that in 2 years x264 will use a feature previously not used and everyone has to buy a new licence?
(This of course excludes new features that are added to the specs after the purchase, as you don't need to promise on those.)

*normal High profile, not High10 or with 4:4:4 support

The 1.x was already sold as featuring "High profile (http://web.archive.org/web/20071222072516/www.coreavc.com/index.php?option=com_content&task=view&id=30&Itemid=1)".

[lexor]

@http://corecodec.com/products/coreavc2 I see this (emphasis mine):
Get Matroska MKV and MKA support from the ppl here at CoreCodec that helped create Matroska in the first place!

Was that intentional? Seems oddly out of place. Also I think it would be a good idea to expand MF into its full name (possibly with a link to details). I doubt many people who do not visit this forum would know what MF is and why bypassing it is important.

[BetaBoy]

Intentional yes, but only to my auto-correct.

[Disabled]

The 1.x was already sold as featuring "High profile (http://web.archive.org/web/20071222072516/www.coreavc.com/index.php?option=com_content&task=view&id=30&Itemid=1)".

Thats why I asked for full High Profile support, so they can't give me the finger once again. Now that DarkShikari teamed up with them, theyre gonna win every speed comparison and I have to buy the upgrade... ;-)

[BetaBoy]

The 1.x was already sold as featuring "High profile (http://web.archive.org/web/20071222072516/www.coreavc.com/index.php?option=com_content&task=view&id=30&Itemid=1)".
With features subject to change. We do plan on releasing 4:2:2 and 4:4:4 at some point... but as I stated, we have aligned our efforts with that of x264's capabilities.

[sneaker_ger]

With features subject to change. We do plan on releasing 4:2:2 and 4:4:4 at some point... but as I stated, we have aligned our efforts with that of x264's capabilities.

There's no mention of that on the website I linked. We all know that "smart" weighted p prediction was already supported by the standard standard at that time.

P.S.: Your website still charges 12.95 $ in case you haven't noticed yet. (Yes, I know your site isn't online yet)

Thats why I asked for full High Profile support, so they can't give me the finger once again. Now that DarkShikari teamed up with them, theyre gonna win every speed comparison and I have to buy the upgrade... ;-)

A decoder that isn't able to correctly decode all compliant High profile videos can't claim to feature High profile support IMHO. But of course I'd like to hear the answer to your question as well. Just wanted to make sure that when they claim "High profile" support it doesn't necessarily answer your question.

[Dark Shikari]

There's no mention of that on the website I linked. We all know that "smart" weighted p prediction was already supported by the standard standard at that time.

A decoder that isn't able to correctly decode all compliant High profile videos can't claim to support High profile IMHO. But of course I'd like to hear the answer to your question as well. Just wanted to make sure that when they claim "High profile" support it doesn't probably won't answer your question.libavcodec, DivX, Mainconcept, Elecard, and DiAVC all have known bugs or limitations in decoding some valid High Profile streams. It's not as if CoreAVC is the only one; hell, the only decoder I know that has no known issues at all is JM. And that's probably just because I don't use it enough to notice the bugs.

FYI, a list:

libavcodec: There is at least one weird conformance vector it fails on, relating to MMCO + long term refs.
DivX: incorrect deblocking with duplicate refs
Mainconcept: incorrect motion compensation with duplicate refs
Elecard: broken direct mode with duplicate refs, incorrect handling of delta quants > 25
DiAVC: quite a few (but it's alpha, so it never claimed to be perfect yet, of course)

[Disabled]

A decoder that isn't able to correctly decode all compliant High profile videos can't claim to feature High profile support IMHO.
I totally agree with you, but they obviously don't. But what can you do, try to sue them about it? Because of 9.99$?

libavcodec, DivX, Mainconcept, Elecard, and DiAVC all have known bugs or limitations in decoding some valid High Profile streams. It's not as if CoreAVC is the only one;
Youre probably right, but CoreAVC are the only ones who got money from me, so they are the only ones I can complain to. And they are the ones with the most obvious artifacts (ie unplayable).
I wouldn't care if the not supported features werent in use, but they are now, so now I do care. I just don't want to shell out money again to a company that promises things, they don't want to keep.

[sneaker_ger]

Don't get me wrong. I'm no angry customer complaining about not getting fixed weight p. But I don't like the marketing which tries to make it look like it's x264 fault that CoreAVC is buggy. On the recent CoreAVC page there was a URL listing its limitations (good thing!) - but it wasn't even linked (bad thing!). If I sell a decoder and claim that it features High profile support I have to be prepared to be taken up on that. (But to be realistically: CoreAVC is no 2000$ product - it only costs as much as few packs of cigarettes so customers should not be too demanding)
In this case I just wanted to make clear that giving a "marketing friendly" answer, like "CoreAVC 2.0 supports High profile" would not be sufficient, as they already had claimed that in the past.

[Cyber-Mav]

we have aligned our efforts with that of x264's capabilities.

so playing videos that are not encoded with x264 will result in a negative impact on speed?

this is very insteresting indeed.

[sneaker_ger]

so playing videos that are not encoded with x264 will result in a negative impact on speed?

this is very insteresting indeed.

We all know that impact on decoding speed depends on the settings and not the software used for encoding.

[Dark Shikari]

We all know that impact on decoding speed depends on the settings and not the software used for encoding.It's quite possible for a decoder to take speed shortcuts based on things it knows about the encoder. I don't know any that do, but it could be done.

[sneaker_ger]

It's quite possible for a decoder to take speed shortcuts based on things it knows about the encoder. I don't know any that do, but it could be done.

Thanks for the clarification. I didn't think in that direction at all. I love how you make at least 10 people a day look stupid. :(

[BetaBoy]

sneaker_ger... your points had been discussed 100+ pages back and we have taken the steps in notify what is and is not. In fact we have done this since the first day it was sold as well as changed when we were notified on issues.

[BetaBoy]

We are sending out emails now for users who purchased it within the past 60 days for the free update. Then come the update emails with the $4.95 upgrade discount for current customers.

[BetaBoy]

For the $9.95 launch use the coupon code: 20LAUNCH or just click this link: https://customers.corecodec.com/cart.php?a=add&pid=1&promocode=20launch

[the_corona]

That's great, if only we had a trial to see if it was worth it......or at least a few benchmarks by people with different proc architectures. I'm guessing nehalem owners arent exactly impressed so far (not that they should care much in the first place). What about Atoms/Athlon 64/Core Duo/Core 2 Duos?

I will not make a blind purchase.

[BetaBoy]

Since its finally live... I would like to thank the staff here for their hard work on the release, Haali for his simple solution for bypassing MediaFoundation in MKV's, Dark Shikari for his input, Clsid for his help with the installer... and even though you don't see it because its in our CoreAVC SDK... Thx to Mans for his kick ass work on ARM NEON Cortex A8 which makes CorePlayer rock on the iPhone 3GS.

[Disabled]

https://customers.corecodec.com/cart.php?a=add&pid=1&promocode=20launch
That link still states "- SMP (supports 4 CPU Cores)". Wasn't 2.0 to support more cores like DS made me think (http://forum.doom9.org/showthread.php?p=1354537#post1354537)?

[BetaBoy]

That's great, if only we had a trial to see if it was worth it......or at least a few benchmarks by people with different proc architectures. I'm guessing nehalem owners arent exactly impressed so far (not that they should care much in the first place). What about Atoms/Athlon 64/Core Duo/Core 2 Duos?

I will not make a blind purchase.

Based on feedback you will see across the board improvements in overall speed with all processors. Noting however that the Motion Vector and WeightP changes did slowdown performance about 1%... this is why we switched to ICC to get that 2% gain in overall speed.

[BetaBoy]

That link still states "- SMP (supports 4 CPU Cores)". Wasn't 2.0 to support more cores like DS made me think (http://forum.doom9.org/showthread.php?p=1354537#post1354537)?
We are still in the middle of changes.... that one is next.

[Yoshiyuki Blade]

Thanks. Just ordered and installed the client. Everything appears to be working fine.

[BetaBoy]

Correct, we have an affiliate program in place. However the rate will be 15% for 2.0.

The Affiliate Program is now live at a 15% commission rate.
https://customers.corecodec.com

We have added the ability to directly link to the purchase page to maximize conversion. If you log in to your affiliate panel, at the bottom, you will now see a "Affiliate links" section. This will include a link you can use to directly add the purchase to cart. You can activate your account by logging into your account and clicking the top 'Affiliates' tab and then agree to the notification.

If you have any questions, or any specific issues, feel free to contact me.

[BetaBoy]

We are still in the middle of changes.... that one is next.

Done.... thx for the report.

[blubberbirne]

When will the eMail send to people who buy coreavc for more than one year???

[BetaBoy]

When will the eMail send to people who buy coreavc for more than one year???
For all users, yes.

[sneaker_ger]

sneaker_ger... your points had been discussed 100+ pages back and we have taken the steps in notify what is and is not. In fact we have done this since the first day it was sold.

I have linked a past version of your website above listing CoreAVCs features - and there's no asterisk or any mention of any limitations on High profile support. The same goes for your start post in this very thread.

Then we have this post by you:
1.x is also fully spec compliant against the features that are included.... there are many features not supported in both CoreAVC and x264 that are being added,

Yet your feature limitation page only lists "FMO" and "multi-dupe WeightP". (+ the profiles not supported)

That leads me to the conclusion that you just lied to me. Don't do that because you're now making me angry. I don't know if you are willing to clarify and/or apologize but I suggest you to at least answer Disabled's question.

[zn]

In case you all did not notice..... Haali has posted the new splitter now that is included in CoreAVC 2.0: http://haali.su/mkv/

1.9.355.21 correct? file is dated as 14th November, but website tells us 19th December

[clsid]

14th November is the production date. 19th December the official public release date.

[JohnnyFu]

Betaboy, are you guys still pushing the mails out? I have no mail until yet.

[hajj_3]

is there going to be a trial released of 2.0? Wouldn't mind trying it on my sisters older laptop to see if hers can handle 720p 4000bitrate x264 .mkv. Nice to see this out, a nice christmas suprise:)

[BetaBoy]

Betaboy, are you guys still pushing the mails out? I have no mail until yet.

Yes, they are trickling out... and I suspect they will be for the next 6-7 hours.

[BetaBoy]

is there going to be a trial released of 2.0? Wouldn't mind trying it on my sisters older laptop to see if hers can handle 720p 4000bitrate x264 .mkv. Nice to see this out, a nice christmas suprise:)

No trial till January 7th.

[hd1080]

.... Thx to Mans for his kick ass work on ARM NEON Cortex A8 which makes CorePlayer rock on the iPhone 3GS.
means this i can play 720p/1080p movies with my iPhone?

[blubberbirne]

I'm still waiting for the email with the download link :(

[JEEB]

I'm still waiting for the email with the download link :(
You should be able to download the app from the customer area after your payment has been checked. No need to wait for an e-mail :)

[BetaBoy]

means this i can play 720p/1080p movies with my iPhone?
Its not 'true' GPU hardware acceleration, but it does help (especially for mobile)

[JohnnyFu]

I'm still waiting for the email with the download link :(

http://corecodec.com/products/coreavc/retrieve

404

[BetaBoy]

You should be able to download the app from the customer area after your payment has been checked. No need to wait for an e-mail :)

You can now for both 2.0 and past customers for 1.9.5. Its just the upgrade emails and free email links that are still going out. As they go out they create/change the account to reflect the upgrade/discount.

[JEEB]

You can now for both 2.0 and past customers for 1.9.5. Its just the upgrade emails and free email links that are going out. As they go out they create/change the account to reflect the change.
Oh yes, forgot completely about the 60-day offer and so on.

[blubberbirne]

You should be able to download the app from the customer area after your payment has been checked. No need to wait for an e-mail :)

i buy coreavc in mid 2008 (i think) and can't do nothink at the moment. i wait for email, nothing happens. this really .....

[BetaBoy]

http://corecodec.com/products/coreavc/retrieve

404

No longer is valid... the customer portal now handles all of that: https://customers.corecodec.com

[JohnnyFu]

No longer is valid... the customer portal now handles all of that: https://customers.corecodec.com

"No client account was found with the email address you entered"

What the frak?

[ranpha]

timecodec tests with a couple of files.

A Blu-ray rip snippet, 1080p, no reencode, straight out from the disc:-


Divx 7.2 (latest available at their site)
User: 7s, kernel: 0s, total: 7s, real: 29s, fps: 295.4, dfps: 74.7
User: 8s, kernel: 0s, total: 8s, real: 30s, fps: 267.7, dfps: 72.1
User: 8s, kernel: 0s, total: 9s, real: 30s, fps: 241.4, dfps: 70.5

ffdshow-mt build 3099
User: 11s, kernel: 0s, total: 11s, real: 37s, fps: 189.2, dfps: 58.4
User: 11s, kernel: 0s, total: 11s, real: 36s, fps: 191.5, dfps: 59.1
User: 11s, kernel: 0s, total: 11s, real: 36s, fps: 191.0, dfps: 59.8

MPC-HC (DXVA) build 1249
User: 99s, kernel: 0s, total: 99s, real: 99s, fps: 22.0, dfps: 21.9
User: 99s, kernel: 0s, total: 99s, real: 100s, fps: 22.0, dfps: 21.8
User: 98s, kernel: 0s, total: 98s, real: 99s, fps: 22.1, dfps: 22.0

MPC-HC (no DXVA) build 1249
User: 10s, kernel: 0s, total: 11s, real: 94s, fps: 196.4, dfps: 23.0
User: 10s, kernel: 0s, total: 11s, real: 96s, fps: 189.4, dfps: 22.6
User: 10s, kernel: 0s, total: 10s, real: 96s, fps: 200.0, dfps: 22.6

CoreAVC 1.9.5 (no CUDA)
User: 6s, kernel: 0s, total: 6s, real: 27s, fps: 342.3, dfps: 78.9
User: 5s, kernel: 0s, total: 5s, real: 26s, fps: 368.4, dfps: 81.2
User: 6s, kernel: 0s, total: 6s, real: 27s, fps: 353.5, dfps: 80.7

CoreAVC 1.9.5 (CUDA)
User: 9s, kernel: 1s, total: 11s, real: 30s, fps: 191.5, dfps: 70.6
User: 9s, kernel: 2s, total: 11s, real: 30s, fps: 188.9, dfps: 70.6
User: 9s, kernel: 2s, total: 11s, real: 30s, fps: 188.4, dfps: 70.6

CoreAVC 2 (no CUDA)
User: 6s, kernel: 0s, total: 6s, real: 26s, fps: 344.8, dfps: 81.7
User: 5s, kernel: 0s, total: 5s, real: 26s, fps: 370.4, dfps: 81.3
User: 6s, kernel: 0s, total: 6s, real: 26s, fps: 328.6, dfps: 83.8

CoreAVC 2 (CUDA)
User: 7s, kernel: 1s, total: 8s, real: 29s, fps: 264.6, dfps: 74.2
User: 7s, kernel: 0s, total: 7s, real: 29s, fps: 277.2, dfps: 74.1
User: 7s, kernel: 0s, total: 8s, real: 29s, fps: 269.7, dfps: 74.1

Microsoft DTV-DVD Video Decoder (no DXVA)
User: 0s, kernel: 0s, total: 0s, real: 37s, fps: 13999.9, dfps: 57.9
User: 0s, kernel: 0s, total: 0s, real: 36s, fps: 15555.5, dfps: 59.1
User: 0s, kernel: 0s, total: 0s, real: 36s, fps: 17499.9, dfps: 59.1

DiAVC (latest version from website)
User: 7s, kernel: 0s, total: 7s, real: 25s, fps: 275.0, dfps: 86.6
User: 6s, kernel: 0s, total: 7s, real: 25s, fps: 309.7, dfps: 87.3
User: 7s, kernel: 0s, total: 7s, real: 25s, fps: 281.7, dfps: 86.5



A Blu-ray snippet reencode, 1080p, very high bitrate, Blu-ray DXVA-compatible:-


Divx 7.2 (latest available at their site)
User: 2s, kernel: 0s, total: 3s, real: 16s, fps: 212.3, dfps: 40.6
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 231.8, dfps: 41.5
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 230.6, dfps: 40.5

ffdshow-mt build 3099
User: 3s, kernel: 0s, total: 3s, real: 17s, fps: 178.7, dfps: 38.2
User: 3s, kernel: 0s, total: 3s, real: 17s, fps: 168.2, dfps: 38.4
User: 3s, kernel: 0s, total: 3s, real: 17s, fps: 182.5, dfps: 38.3

MPC-HC (DXVA) build 1249
User: 62s, kernel: 0s, total: 62s, real: 62s, fps: 10.7, dfps: 10.7
User: 62s, kernel: 0s, total: 62s, real: 62s, fps: 10.7, dfps: 10.6
User: 62s, kernel: 0s, total: 62s, real: 63s, fps: 10.7, dfps: 10.6

MPC-HC (no DXVA) build 1249
User: 3s, kernel: 0s, total: 3s, real: 53s, fps: 174.3, dfps: 12.6
User: 3s, kernel: 0s, total: 3s, real: 53s, fps: 177.9, dfps: 12.5
User: 3s, kernel: 0s, total: 3s, real: 53s, fps: 172.9, dfps: 12.6

CoreAVC 1.9.5 (no CUDA)
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 250.8, dfps: 40.6
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 250.8, dfps: 40.6
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 230.6, dfps: 40.0

CoreAVC 1.9.5 (CUDA)
User: 4s, kernel: 0s, total: 5s, real: 22s, fps: 131.5, dfps: 29.4
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 147.9, dfps: 29.4
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 142.9, dfps: 29.4

CoreAVC 2 (no CUDA)
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 268.0, dfps: 39.2
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 225.7, dfps: 40.1
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 238.2, dfps: 38.8

CoreAVC 2 (CUDA)
User: 2s, kernel: 0s, total: 3s, real: 22s, fps: 197.6, dfps: 29.6
User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 195.8, dfps: 29.6
User: 2s, kernel: 0s, total: 3s, real: 22s, fps: 214.4, dfps: 29.6

Microsoft DTV-DVD Video Decoder (no DXVA)
User: 0s, kernel: 0s, total: 0s, real: 20s, fps: 10721.1, dfps: 32.8
User: 0s, kernel: 0s, total: 0s, real: 21s, fps: 7147.4, dfps: 31.7
User: 0s, kernel: 0s, total: 0s, real: 20s, fps: 5360.5, dfps: 33.3

DiAVC (latest version from website)
User: 2s, kernel: 0s, total: 2s, real: 14s, fps: 236.9, dfps: 46.9
User: 2s, kernel: 0s, total: 2s, real: 14s, fps: 268.0, dfps: 46.7
User: 2s, kernel: 0s, total: 2s, real: 14s, fps: 261.5, dfps: 46.7


System: Windows 7 x64, Phenom X4 9500, 4GB RAM, nVidia GT220 1GB with 191.07 drivers.

[Mixer73]

- First on Windows 7..... Both CoreAVC and Haali's splitter now use a custom fourcc so that when you play an MKV video it uses Directshow instead of MediaFoundation in WMP and MC. No hacks and its a simple solution to gets ppl out of the pitfalls of MF. Note that this is ONLY for .mkv and does not affect any other container.

Awesome release, thanks for all the hard work.

Can I please clarify the above. I'm using Windows 7MCE and I archive all my content in PS3/DXVA compatible h.264, MP4 container, does the above mean I won't be able to use CoreAVC for my system at all? Or does it just mean I will have to do trickery to get the merit sorted?

Apologies for the newb question, as yet I have not changed anything on the 7MCE system.

[BetaBoy]

IF when you want... you can simply rename the .mp4 videos to .mkv and it will work with CoreAVC/Haali.

[JohnnyFu]

Betaboy, I have not received an email link and I can't logon to your customer system to access my download/serial.

"No client account was found with the email address you entered"

[blubberbirne]

"No client account was found with the email address you entered"

What the frak?

same here :devil:

[BetaBoy]

Emails are still going out.... this is why I mentioned earlier that your account is modified/activated when the email is sent. But we think we can go even one better by adding an 'addon' to each of those accounts. We are looking into it now.

[BetaBoy]

All.... I know I have a bunch of PM's in my account... I'll get to them once we get through tonight/tomorrow AM. Thanx for being patient.

[lych_necross]

Thanks BetaBoy and the rest of CoreCodec! I just bought my copy and it's working fine on my system. Ignore the haters and keep up the good work. :)

[puffpio]

i just bought a copy and installed it woohoo...
notices some slowdowns playing 1080p...and i think it may be my system is not fast enough?
mobile core2duo @ 2ghz
mpc-hc 64bit build 1424, haali media splitter, coreavc 2, haali renderer

thanks for any info

[Sharc]

With version 2.0 the former --weightp issues (blocks) of 1.9.5 are solved, according to my tests.

[Mixer73]

IF when you want... you can simply rename the .mp4 videos to .mkv and it will work with CoreAVC/Haali.

With perhaps thousands of files this isn't practical, is there a way I could do the same through the registry?

[DigitalDeviant]

I'm still waiting for my upgrade link.

[hippoth]

Same here. I have bought CoreAVC april 2006 and did not get any mail and I can´t login --> "No client account was found with the email address you entered"

[blubberbirne]

This is sad. People who buy CoreAVC at the beginning are still waiting. New buyer are still happy

[the_corona]

Hmm, so seems DiAVC > CoreAVC > Divx (and sometimes DivX/CoreAVC are reversed or very close).

Whats interesting is that DiAVC supposedly has alot more optimizations left which will come in the beta.

Can someone test on a dual core machine (or simply only give timecodec 2 cores)? My HTPC is a Yonah so personally such results would help me the most (hint CoreAVC just release the trial and people can test themselves....I don't get it)

[clsid]

With perhaps thousands of files this isn't practical, is there a way I could do the same through the registry?Next version of my Win7DSFilterTweaker tool should be able to assist you with bypassing the evil MS stuff ;)

[BetaBoy]

Hmm, so seems DiAVC > CoreAVC > Divx (and sometimes DivX/CoreAVC are reversed or very close).

Whats interesting is that DiAVC supposedly has alot more optimizations left which will come in the beta.

Please keep it on-topic... but to your point... remember this is our 'first' optimizations release. While DiAVC has been doing opts for months now... you can only tweak so much till as DS says you code to match a 'specific' encoder.

[BetaBoy]

Next version of my Win7DSFilterTweaker tool should be able to assist you with bypassing the evil MS stuff ;)

Yeah... we have been thinking about an option to treat other containers as .mkv but I think its out of the scope of what 'we' should do.

[the_corona]

Please keep it on-topic... but to your point... remember this is our 'first' optimizations release. While DiAVC has been doing opts for months now... you can only tweak so much till as DS says you code to match a 'specific' encoder.

Is simply everything thats not praising CoreAVC "off-topic"?

Seriously, how is it not on topic to talk about CoreAVC performance in the CoreAVC thread. I mean come on...

We only have very few benchmark results, and these are my impressions. Are they wrong?

<stupid rant>Yeah yeah, I'm sure your next "optimization release" will blow us all away....in 2014 ..... after buying yet another license.</stupid rant>

[Cyber-Mav]

DiAVC has been doing opts for months now...

if your not happy with that then maybe you can get a court injuction placed on diavc to stop them from doing these optimisations if its hurting your business?

seriously betaboy i was expecting you to be more mature about this. i can see now why dark shikari left out the diavc tests in his performance benchmarks since it would have a negative impact on coreavc sales, not surprising since dark shikari and corecodec have "teamed up" so to speak.

also its pointless saying that this is your first release with speed optimisations, by the time the second release is done everyone will be using quad core cpu;s even on laptops.

all this talk is on topic since it is about coreavc and its performance. no one is crapping on the release here, they are just voicing thier opinions and first hand experience of the new codec you have just released.

for me the key reason i purchased coreavc 1.9.0 is because of the CUDA support and that was money well spent in my eyes.

[Dark Shikari]

seriously betaboy i was expecting you to be more mature about this. i can see now why dark shikari left out the diavc tests in his performance benchmarks since it would have a negative impact on coreavc sales, not surprising since dark shikari and corecodec have "teamed up" so to speak.How am I supposed to bench a codec that doesn't work on my computer? I use Windows 7 64-bit and DiAVC doesn't support it yet. :rolleyes:

I explicitly went out of my way to try to include DiAVC but it didn't work, so obviously I couldn't include it in the results.

[honai]

I hope we can all agree that competition is a good thing. Without the pressure from past and prospective customers I don't think CoreAVC 2.0 would include that much bug fixes and improvements as it does know.

Having said that, without a freely downloadable trial I'm going to refrain from purchasing upgrades for my 5 licenses for the time being.

[BetaBoy]

I hope we can all agree that competition is a good thing. Without the pressure from past and prospective customers I don't think CoreAVC 2.0 would include that much bug fixes and improvements as it does know.
Without a doubt competition is great... always will be. There is tons of space in H.264 space and it's just a small part of what we are doing here overall, and we are very grateful for our customers and commercial partners.

[LoRd_MuldeR]

How am I supposed to bench a codec that doesn't work on my computer? I use Windows 7 64-bit and DiAVC doesn't support it yet. :rolleyes:

Does work here. Windows 7, 64-Bit, latest DiAVC Alpha. Also works with TimeCodec :confused:

Here are my results:
http://forum.doom9.org/showpost.php?p=1347162&postcount=179

(CoreAVC 2.0 is missing in that comparison, as I don't have access to the 2.0 release of CoreAVC)

[lnatan25]

Just to say, DiAVC works here too, on 64-bit Windows 7.

[LoRd_MuldeR]

Just to say, DiAVC works here too, on 64-bit Windows 7.

As older Alpha versions did not work and the developer has updated the Alpha several times without renaming the download, Dark Shikari may be using an old/broken version.

(It also may help to unregister and re-register the filter manually from an Admin console. That did the trick for me at least...)

[the_corona]

DiAVC works for me on Win7 x64 too with MPC-HC 32bit.

Though I have to say the output looks different from other decoders, I'll have to investigate this when I find some time.

[lnatan25]

As older Alpha versions did not work and the developer has updated the Alpha several times without renaming the download, Dark Shikari may be using an old/broken version.

(It also may help to unregister and re-register the filter manually from an Admin console. That did the trick for me at least...)
I just added it as an external codec in KMP. Works very good. It's an alpha, so some bugs here and there, but I was surprised how well it works for such an early release.

To go "off-topic" for a moment (:rolleyes:), I think everyone should wait and see how DiAVC progresses. Beta should be out soon. No point in purchasing one product and then having to purchase a better one later. Just wait a little longer to see where things are headed.

[LoRd_MuldeR]

DiAVC works for me on Win7 x64 too with MPC-HC 32bit.

Though I have to say the output looks different from other decoders, I'll have to investigate this when I find some time.

You are 100% sure that you aren't misinterpreting different Luma Levels as "different output" ???

[the_corona]

You are 100% sure that you aren't misinterpreting different Luma Levels as "different output" ???

No, I think actually 32bit MPC had different renderer settings than 64bit which I was used to seeing things as. I didn't really bother, just a quick install to see if it runs on Win7 x64. Disregard that remark for now.

[BetaBoy]

To go "off-topic" for a moment (:rolleyes:), .
No.. what I suggest is simple, take your OT discussion out of this thread.

[wayland]

maybe i misunderstand this "Current customer from the past 60 days are getting updates emailed to them now. Post 60 days users get the upgrade for $4.95 and those emails are going out now as well." but longterm customers have to pay $15 more for 2.0? (was originally $20 iirc not $10 plus $5 upgrade fee)

[LoRd_MuldeR]

maybe i misunderstand this "Current customer from the past 60 days are getting updates emailed to them now. Post 60 days users get the upgrade for $4.95 and those emails are going out now as well." but longterm customers have to pay $15 more for 2.0? (was originally $20 iirc not $10 plus $5 upgrade fee)

If you bought CoreAVC in the last 60 days, you get the 2.0 upgrade for free. If you bought it earlier, you can upgrade for $5. New users will have to pay $10 (after xmas it will be $13).

Please correct me, if I'm wrong...

[laserfan]

If you bought CoreAVC in the last 60 days, you get the 2.0 upgrade for free. If you bought it earlier, you can upgrade for $5. New users will have to pay $10 (after xmas it will be $13).

Please correct me, if I'm wrong...Where'd the $5 upgrade come from? I have 1.9.5 and just paid $9.95 to upgrade... :confused:

[wayland]

i think they are supposed to email you a code that gives a discount, i havnt had any email about it yet though. i dont really see a good reason for paying the upgrade fee, might as well just use a decoder without mv and weightp problems and save $5

[LoRd_MuldeR]

Where'd the $5 upgrade come from? I have 1.9.5 and just paid $9.95 to upgrade... :confused:

From this post:

Correct, we have an affiliate program in place. However the rate will be 15% for 2.0.

Also on price. Upgrades are $4.95 and the full version is $9.95 (discounted from $12.95 till xmas).

I think as a CoreAVC 1.9.x owner, you should have received an email with a unique code for reduced-price upgrade...

[laserfan]

I think as a CoreAVC 1.9.x owner, you should have received an email with a unique code for reduced-price upgrade...
Maybe I "jumped the gun" then. I did receive an email Subject: CoreAVC 1.9.5 Purchase Update
Dear <my registered name>,

Thank you for your purchasing CoreCodec products. We have recently upgraded our order processing system.

An account has automatically been generated for you in our new system.
To log on, use your email address (myregisteredemail), and your temporary
password of "secretpassword". This password is stored encrypted and can be reset, but not recovered, if lost.

In addition, we have imported your existing CoreAVC 1.9.5 purchases into this account.

The following CoreAVC 1.9.5 serial numbers have been associated with your account:
- XXXXXXXXXXXX -

You can log in to view your serial numbers and downloads at any time by visiting https://customers.corecodec.com/ .
So I went to the link, logged-in to my account, didn't see any "upgrade" link anywhere but clicked on "order" and completed the order w/20LAUNCH to get to $9.95.

Got this email 2 days ago and just bought the new version this a.m. (no further emails received).

So has anyone here gotten theirs for $5bucks? How? :confused:

[JEEB]

Maybe I "jumped the gun" then. I did receive an email Subject: CoreAVC 1.9.5 Purchase Update

So I went to the link, logged-in to my account, didn't see any "upgrade" link anywhere but clicked on "order" and completed the order w/20LAUNCH to get to $9.95.

Got this email 2 days ago and just bought the new version this a.m. (no further emails received).

So has anyone here gotten theirs for $5bucks? How? :confused:

I had the same thing, only mail I got was that purchase update one. Oh well...

[BetaBoy]

We are looking into the reports of users not getting the upgrade emails.

[Sharc]

Maybe I "jumped the gun" then. I did receive an email Subject: CoreAVC 1.9.5 Purchase Update

So I went to the link, logged-in to my account, didn't see any "upgrade" link anywhere but clicked on "order" and completed the order w/20LAUNCH to get to $9.95.

Got this email 2 days ago and just bought the new version ..
Same here....

[blubberbirne]

We are looking into the reports of users not getting the upgrade emails.

:thanks: i hope i get my email this year :mad:

[DigitalDeviant]

No upgrade link here either.

[BetaBoy]

We are looking into the reports of users not getting the upgrade emails.

For any people that did not get the discount code you can email me directly: info@corecodec.com and I will issue you a unique coupon. Please provide your original purchase email address as this will need to match your current CoreAVC order.

[ranpha]

For any people that did not get the discount code you can email me directly: info@corecodec.com and I will issue you a unique coupon. Please provide your original purchase email address as this will need to match your current CoreAVC order.

I haven't got the upgrade e-mail either, so I have sent you an e-mail for the coupon so that I can grab myself a second copy.

[BetaBoy]

Coupons sent to all those you sent in their purchase info to me so far.

[RiCON]

So I tried to install CoreAVC through Wine, to use it on Mplayer, like I used with 1.9.5. But something changed that broke that possibility.

As the development of coreavc-for-linux seems to be kinda dead, is there any way CoreCodec could explain to get it to work again?

It's essential that I get it to work as ffmpeg-mt is not fast enough to run on the netbook for which I especifically bought CoreAVC.

Everything from coreavc-for-linux compiled just fine. It's just a problem with the .ax not detecting the serial registered through registercodec. I tried registering the new serial and even the user, but it doesn't seem to work.

Any ideas?

[Mixer73]

Next version of my Win7DSFilterTweaker tool should be able to assist you with bypassing the evil MS stuff ;)

Awesome CLSID. With some time off work soon I feel I might be able to do "risky" stuff with my 7 box ;)

Btw I gotta say you're involved in all my favourite projects, :thanks:

Yeah... we have been thinking about an option to treat other containers as .mkv but I think its out of the scope of what 'we' should do.

I can understand this 100%, there's only so much you should be doing as part of a commercial installer.

Coupons sent to all those you sent in their purchase info to me so far.

Well done - whether its $10 or $5 CoreAVC is a great product and very affordable. Thanks for all your hard work.

[lnatan25]

No.. what I suggest is simple, take your OT discussion out of this thread.
I guess you didn't catch the sarcasm. :rolleyes:

Or you tuck your head in the sand on purpose?

[yesgrey]

Here are my test results using an Intel E2160@2.7GHz with 1080p material:
ffdshow
User: 0s, kernel: 0s, total: 0s, real: 4s, fps: 479.6, dfps: 41.2
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 479.6, dfps: 54.2
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 647.4, dfps: 52.4

ffdshow-mt
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 719.4, dfps: 66.8
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 563.0, dfps: 67.4
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 588.6, dfps: 64.4

CoreAVC 1.9.5
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 719.4, dfps: 71.2
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 588.6, dfps: 73.2
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 616.6, dfps: 72.7

DiAVC alpha
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 588.6, dfps: 81.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 681.5, dfps: 80.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 479.6, dfps: 82.5

CoreAVC 2.0.0
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 498.0, dfps: 81.4
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 404.6, dfps: 81.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 462.5, dfps: 80.9

[BetaBoy]

We keep seeing Timecodec reports again and again on Doom9 with multi-core systems. Everyone needs to understand that timecodec does not produce accurate results for multi-core systems (single core however does produce accurate results), and as such any reports are not correct. Both Haali and I both have stated this a few times here. I have pinged Haali to see if he can mod it to accurately represent true 'dfps', although I suspect that would require a lot of work to make it accurate against all the AMD and Intel CPU's.

[Keiyakusha]

But even if result is not accurate, it should be not accurate in the same way for all decoders. So we still should be able to say "this one is faster than that one".
Anyway maybe yesgrey3 or someone can do another comparison using graphstudio?

[BetaBoy]

But even if result is not accurate, it should be not accurate in the same way for all decoders. So we still should be able to say "this one is faster than that one".
Anyway maybe yesgrey3 or someone can do another comparison using graphstudio?
Not at all, as each decoder will likely handle threading priorities differently and throw off the 'dfps' count.

[laserfan]

Maybe I "jumped the gun" then. I did receive an email Subject: CoreAVC 1.9.5 Purchase Update

So I went to the link, logged-in to my account, didn't see any "upgrade" link anywhere but clicked on "order" and completed the order w/20LAUNCH to get to $9.95.

Got this email 2 days ago (Dec 18th)and just bought the new version this a.m. (no further emails received).
Subject: CoreAVC 1.9.5 Purchase Update
Date: Fri, 18 Dec 2009 17:06:11 -0800 (PST)
From: CoreCodec Inc. <noreply@corecodec.com>
To: <my email>
Dear <my registered name>,

Thank you for your purchasing CoreCodec products. We have recently upgraded our order processing system.

An account has automatically been generated for you in our new system.
To log on, use your email address (myregisteredemail), and your temporary
password of "secretpassword". This password is stored encrypted and can be reset, but not recovered, if lost.

In addition, we have imported your existing CoreAVC 1.9.5 purchases into this account.

The following CoreAVC 1.9.5 serial numbers have been associated with your account:
- XXXXXXXXXXXX -

You can log in to view your serial numbers and downloads at any time by visiting https://customers.corecodec.com/ .

So has anyone here gotten theirs for $5bucks? How? :confused:
What bonehead(s) in your company are responsible for this: after getting the above two days ago, I tonight received the following:
Subject: Upgrade to CoreAVC 2.0 for $4.95!
Date: Sun, 20 Dec 2009 18:56:26 -0800
From: CoreCodec, Inc. <support@corecodec.com>
To: <yours truly, removed to protect my innocence>

CoreCodec, Inc.

Dear <my name>,

You are receiving this email because you have purchased CoreAVC 1.X.

We are pleased to announce the immediate availablity of a discounted upgrade to CoreAVC 2.0.

To purchase, simply log into your client portal and access your licenses at

https://customers.corecodec.com/clientarea.php?action=products

then click the license you wish to upgrade, and click upgrade. This will generate an invoice for the upgrade.

Upon payment, your license will be automatically upgraded to CoreAVC 2.0.

Thank you.

A little late CoreCodec, Inc.! I know it's only $5 bucks, but what a way to make your customers feel like jerks for responding to your first "come on"! How'd you manage to mess this up??? :devil:

[BetaBoy]

Not boneheads at all, but we apologize for your inconvenience. We sent another round of emails for those that had already been sent, but bounced back to us. If you already paid for it send me an email: info@corecodec.com and we will make up the difference.

[G_M_C]

I've got one question; How is the 32-64 bit / new windows migration arranged with you guys ?

I'm on 32-bits Win XP right now, but plan to upgrade to Win 7 in Q1 2010. When I buy CoreAVC now, wich would be Win XP32, will my license give me the abillity to also migrate CoreAVC to Win7/64 bits when i upgrade ?

[tormento]

I have just bought coreavc2 and I have 2 questions:

1) Why is not possible to install it in a custom directory?

2) How (on hell) is possible to change codec priority? I have tried every single codec modding program out there and CoreAVC does take the decoding process.

Oh, yeah, on my PC even tagging the preferences does not show the tray icon..

[BetaBoy]

1 - will be an option in a future release.
2 - Uncheck the preference for 'codec' priority in the decoder properties page.

On the tray... what OS are you running?

[dimitrik]

I just got my upgrade email - can't wait to install and test the new decoder. It helps me run MC7 x64 on my HTPC, I will be one happy guy.

By the way for those interested in speed comparisons, there is a major thread on this, which is the ideal place for those questions.

MPEG-4 AVC/H.264 decoder comparison (http://forum.doom9.org/showthread.php?t=99402)

I think its more relevant to discuss the specific features of this release here, good or bad, which will ultimately help both old and new customers.

[JohnnyFu]

I can confirm MC7 recognizes MKV files without any modification with CoreAVC 2.0 installed. Thanks!

Looking forward for ATi GPU support!

[tormento]

2 - Uncheck the preference for 'codec' priority in the decoder properties page.

On the tray... what OS are you running?

2) Tried, not working.

Windows ult 7 x64.

[Disabled]

We keep seeing Timecodec reports again and again on Doom9 with multi-core systems. Everyone needs to understand that timecodec does not produce accurate results for multi-core systems...

I wonder, how do you benchmark your decoder? Does the graphstudio benchmark provide correct results? I tested all decoders (CoreAVC 1.9.5) with graphstudio and timecodec and while the absolute numbers varied a little, the results were absolutely comparable...

[LoRd_MuldeR]

Side-note: In all my tests the "dps" value seems to correlate perfectly with the "real" decoding time and also with the subjective decoding experience.

And I assume TimeCodec does measure the (real) decoding time correctly. That really shouldn't be too hard to do ;)

[tommy_vercetti]

I can confirm MC7 recognizes MKV files without any modification with CoreAVC 2.0 installed. Thanks!

Looking forward for ATi GPU support!

You can try with just the Haali Splitter, it works the same, just it gets rendered by the default codecs in Windows 7 x64

[BetaBoy]

I wonder, how do you benchmark your decoder? Does the graphstudio benchmark provide correct results? I tested all decoders (CoreAVC 1.9.5) with graphstudio and timecodec and while the absolute numbers varied a little, the results were absolutely comparable...
Timecodec is good for benchmarking devel diff's of before Vs. after to see if it has a positive/negative impact on performance. Also from what I was told graphstudio also has the same threading problem, which would explain why they numbers are close for both.

I'm trying to chat with Haali more on it to get more details on what is and is not, and what we can do to get more accurate benchmarks.

[BetaBoy]

2) Tried, not working.

Windows ult 7 x64.

This seems to be a bug with Shark's Codec tool based on the reports coming in. Removing it seems to resolve the issue till he releases a fix.

[Shark007]

This seems to be a bug with Shark's Codec tool based on the reports coming in. Removing it seems to resolve the issue till he releases a fix.

Since i have not had a chance to test 2.0 (until now) my x64 components use x64 ffdshow as an H264 default. You will need to open the x64 settings application on the Config TAB, use the center dropdown to choose 'FFDshow Video' and set H264/AVC to disabled. I will add provisions to my x64 release to accomodate x64 CoreAVC a.s.a.p.

EDIT: version 2.2.8 of the x64 Components (http://www.majorgeeks.com/VistaCodecs_x64Components_d5535.html) accommodates the use of CoreAVC x64.

[BetaBoy]

Shark007... thank you!

[Cyber-Mav]

ok i bit the bullet and upgraded to coreavc 2.0 here are my results:

q9650@3.6ghz vista ultimate x64


720x304 1mbit

coreavc 1.9.5
User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 4918.2, dfps: 1073.8

coreavc 2.0
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 6170.1, dfps: 1396.5
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 6284.4, dfps: 1396.5
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 5751.8, dfps: 1408.0

divx
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 7892.0, dfps: 1705.0
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 7069.9, dfps: 1705.0
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 8277.0, dfps: 1696.8

diavc alpha
User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 3393.6, dfps: 1814.9
User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 3201.5, dfps: 1814.9
User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 3232.0, dfps: 1805.0
---------------------------------------------------------------------

720p 2.5mbit

coreavc 1.9.5
User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 2177.1, dfps: 542.8

coreavc 2.0
User: 3s, kernel: 0s, total: 3s, real: 10s, fps: 1878.9, dfps: 606.9
User: 3s, kernel: 0s, total: 3s, real: 10s, fps: 1820.7, dfps: 605.1
User: 3s, kernel: 0s, total: 3s, real: 10s, fps: 2088.7, dfps: 604.2

divx
User: 4s, kernel: 0s, total: 4s, real: 11s, fps: 1480.1, dfps: 579.5
User: 4s, kernel: 0s, total: 4s, real: 11s, fps: 1480.1, dfps: 581.2
User: 4s, kernel: 0s, total: 4s, real: 11s, fps: 1418.9, dfps: 578.7

diavc alpha
User: 5s, kernel: 0s, total: 5s, real: 10s, fps: 1139.8, dfps: 604.2
User: 5s, kernel: 0s, total: 5s, real: 10s, fps: 1213.8, dfps: 606.9
User: 4s, kernel: 0s, total: 5s, real: 10s, fps: 1250.7, dfps: 606.0
---------------------------------------------------------------------

720p 5.7mbit

coreavc 1.9.5
User: 3s, kernel: 0s, total: 3s, real: 14s, fps: 1861.7, dfps: 473.0

coreavc 2.0
User: 3s, kernel: 0s, total: 3s, real: 14s, fps: 1815.3, dfps: 485.6
User: 4s, kernel: 0s, total: 4s, real: 13s, fps: 1602.6, dfps: 487.7
User: 3s, kernel: 0s, total: 3s, real: 14s, fps: 1822.9, dfps: 485.6

divx
User: 4s, kernel: 0s, total: 4s, real: 14s, fps: 1439.1, dfps: 480.8
User: 4s, kernel: 0s, total: 4s, real: 14s, fps: 1406.7, dfps: 481.3
User: 4s, kernel: 0s, total: 4s, real: 14s, fps: 1371.5, dfps: 481.8

diavc alpha
User: 4s, kernel: 0s, total: 5s, real: 13s, fps: 1271.8, dfps: 504.0
User: 4s, kernel: 0s, total: 5s, real: 13s, fps: 1317.8, dfps: 505.8
User: 4s, kernel: 0s, total: 5s, real: 13s, fps: 1337.9, dfps: 502.9
---------------------------------------------------------------------

1080p 4.5mbit

coreavc 1.9.5
User: 10s, kernel: 0s, total: 11s, real: 27s, fps: 741.5, dfps: 297.1

coreavc 2.0
User: 11s, kernel: 0s, total: 11s, real: 26s, fps: 685.2, dfps: 303.1
User: 11s, kernel: 0s, total: 11s, real: 26s, fps: 699.9, dfps: 303.1
User: 12s, kernel: 0s, total: 12s, real: 26s, fps: 631.5, dfps: 303.1

divx
User: 13s, kernel: 0s, total: 13s, real: 28s, fps: 588.2, dfps: 288.4
User: 14s, kernel: 0s, total: 14s, real: 28s, fps: 565.4, dfps: 287.7
User: 14s, kernel: 0s, total: 14s, real: 28s, fps: 572.2, dfps: 288.9

diavc alpha
User: 12s, kernel: 0s, total: 13s, real: 26s, fps: 605.9, dfps: 302.8
User: 14s, kernel: 0s, total: 15s, real: 27s, fps: 535.8, dfps: 301.7
User: 13s, kernel: 0s, total: 14s, real: 27s, fps: 574.7, dfps: 301.4

new coreavc 2.0 is deffo faster than 1.9.5 was. however on my laptop the pentium m740, coreavc 2.0 is around 1fps SLOWER than 1.9.5 is in all the timecodec benches i ran.

however im currently running benches on my opteron cpu and the results so far are very very interesting indeed. i will post results in few mins when testing is done.

//also how do i get my results embedded in a code box like others do?

[yesgrey]

//also how do i get my results embedded in a code box like others do?
select the results and click the "#" icon when creating/editing a message.

[Cyber-Mav]

select the results and click the "#" icon when creating/editing a message.

thankyou my good man.

[the_corona]

Well, it sure seems all those optimizations only made it faster than 1.9.5, but not really faster than the competition.

BetaBoy, if timecodec is as you claim not accurate at all and shouldn't be used to judge a codec's performance, then how can you claim CoreAVC to be the "world's fastest H264 software decoder"? How do you measure that? Or don't you and just put that up there for good marketing? Or was timecodec "good enough" while it showed CoreAVC to be the fastest in the past?

In either case, a bit questionable buiseness practice if I may say so.

[Cyber-Mav]

Well, it sure seems all those optimizations only made it faster than 1.9.5, but not really faster than the competition.

BetaBoy, if timecodec is as you claim not accurate at all and shouldn't be used to judge a codec's performance, then how can you claim CoreAVC to be the "world's fastest H264 software decoder"? How do you measure that? Or don't you and just put that up there for good marketing? Or was timecodec "good enough" while it showed CoreAVC to be the fastest in the past?

In either case, a bit questionable buiseness practice if I may say so.

wait till i get my opteron pc results up. its very interesting indeed.

[BetaBoy]

AMD opteron users have seen the great decrease in overall speed with CoreAVC 2.0 from the reports so far.

the_corona... take your continued attacks/flames elsewhere, its really getting old.

[JohnnyFu]

Opteron or AMD CPU's in general?

[Cyber-Mav]

opteron is just more cache memory than regular athlon64, so i would assume all athlon 64 users would get similar speed to opteron. i almost finished benching the codecs on my opteron pc, just a few more runs to go then i install coreavc 2.0 and bench that and i will post up the results. but as of now coreavc 1.9.5 is showing amazing results for me.

[BetaBoy]

Opteron or AMD CPU's in general?

typo.. decrease. But we still have a bunch of ppl testing and are getting mixed results. So I'll hold off on more reports till later this week.

[Dark Shikari]

I'm guessing that a good bit of the new SSE2 assembly code is slower on A64 and should probably be disabled there.

[Cyber-Mav]

and here are the results:
opteron 170 @ 2.6ghz win7 x64

720x304 1mbit

coreavc 1.9.5
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 2232.6, dfps: 519.7
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 2293.0, dfps: 518.9
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 2651.2, dfps: 519.7

divx
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 1895.8, dfps: 484.8
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 2203.6, dfps: 491.1
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 2356.6, dfps: 490.4

diavc alpha
User: 2s, kernel: 0s, total: 3s, real: 11s, fps: 1608.3, dfps: 460.5
User: 3s, kernel: 0s, total: 3s, real: 11s, fps: 1385.1, dfps: 460.5
User: 2s, kernel: 0s, total: 3s, real: 11s, fps: 1696.8, dfps: 462.4

microsoft dtv-dvd
User: 0s, kernel: 0s, total: 0s, real: 16s, fps: 42419.6, dfps: 323.2
User: 0s, kernel: 0s, total: 0s, real: 16s, fps: 48479.5, dfps: 323.5
User: 0s, kernel: 0s, total: 0s, real: 16s, fps: 56559.5, dfps: 321.1

coreavc 2.0
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 2293.0, dfps: 514.9
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 2389.8, dfps: 522.0
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 2651.2, dfps: 518.1
----------------------------------------------------------------------

720p 2.5mbit

coreavc 1.9.5
User: 9s, kernel: 0s, total: 9s, real: 39s, fps: 681.2, dfps: 164.5
User: 8s, kernel: 0s, total: 8s, real: 38s, fps: 727.0, dfps: 165.9
User: 8s, kernel: 0s, total: 8s, real: 38s, fps: 738.7, dfps: 164.9

divx
User: 12s, kernel: 0s, total: 12s, real: 44s, fps: 503.0, dfps: 144.9
User: 10s, kernel: 0s, total: 10s, real: 43s, fps: 608.7, dfps: 146.6
User: 10s, kernel: 0s, total: 10s, real: 43s, fps: 600.7, dfps: 146.3

diavc alpha
User: 11s, kernel: 0s, total: 11s, real: 40s, fps: 544.3, dfps: 158.4
User: 10s, kernel: 0s, total: 11s, real: 40s, fps: 577.1, dfps: 157.4
User: 10s, kernel: 0s, total: 11s, real: 40s, fps: 582.0, dfps: 157.3

microsoft dtv-dvd
User: 0s, kernel: 0s, total: 0s, real: 64s, fps: 29390.8, dfps: 99.0
User: 0s, kernel: 0s, total: 0s, real: 65s, fps: 37406.5, dfps: 98.5
User: 0s, kernel: 0s, total: 0s, real: 65s, fps: 29390.8, dfps: 98.7

coreavc 2.0
User: 8s, kernel: 0s, total: 8s, real: 38s, fps: 732.2, dfps: 166.2
User: 8s, kernel: 0s, total: 8s, real: 38s, fps: 724.4, dfps: 167.2
User: 8s, kernel: 0s, total: 9s, real: 38s, fps: 710.7, dfps: 166.7
---------------------------------------------------------------------

720p 5.7mbit

coreavc 1.9.5
User: 9s, kernel: 0s, total: 9s, real: 47s, fps: 693.3, dfps: 143.3
User: 9s, kernel: 0s, total: 9s, real: 47s, fps: 716.0, dfps: 143.4
User: 9s, kernel: 0s, total: 9s, real: 47s, fps: 696.7, dfps: 143.2

divx
User: 12s, kernel: 0s, total: 12s, real: 52s, fps: 526.5, dfps: 129.2
User: 10s, kernel: 0s, total: 11s, real: 52s, fps: 615.3, dfps: 130.2
User: 11s, kernel: 0s, total: 11s, real: 52s, fps: 590.4, dfps: 130.8

diavc alpha
User: 10s, kernel: 0s, total: 11s, real: 50s, fps: 588.0, dfps: 136.4
User: 10s, kernel: 0s, total: 11s, real: 50s, fps: 601.8, dfps: 136.3
User: 10s, kernel: 0s, total: 11s, real: 50s, fps: 587.2, dfps: 136.0

microsoft dtv-dvd
User: 0s, kernel: 0s, total: 0s, real: 76s, fps: 19021.6, dfps: 89.7
User: 0s, kernel: 0s, total: 0s, real: 75s, fps: 33653.6, dfps: 90.2
User: 0s, kernel: 0s, total: 0s, real: 75s, fps: 29166.5, dfps: 90.0

coreavc 2.0
User: 8s, kernel: 0s, total: 8s, real: 46s, fps: 771.6, dfps: 146.0
User: 9s, kernel: 0s, total: 9s, real: 46s, fps: 731.6, dfps: 145.6
User: 9s, kernel: 0s, total: 9s, real: 46s, fps: 718.4, dfps: 145.6
----------------------------------------------------------------------

1080p 4.5mbit

coreavc 1.9.5
User: 25s, kernel: 0s, total: 25s, real: 96s, fps: 318.4, dfps: 84.5
User: 25s, kernel: 0s, total: 25s, real: 96s, fps: 319.0, dfps: 84.4
User: 25s, kernel: 0s, total: 25s, real: 96s, fps: 316.5, dfps: 84.3

divx
User: 28s, kernel: 0s, total: 28s, real: 114s, fps: 285.6, dfps: 71.2
User: 27s, kernel: 0s, total: 28s, real: 114s, fps: 290.8, dfps: 71.2
User: 32s, kernel: 0s, total: 32s, real: 116s, fps: 253.5, dfps: 70.3

diavc alpha
User: 26s, kernel: 1s, total: 27s, real: 104s, fps: 296.3, dfps: 78.5
User: 26s, kernel: 1s, total: 28s, real: 104s, fps: 291.3, dfps: 78.3
User: 26s, kernel: 1s, total: 27s, real: 104s, fps: 297.5, dfps: 78.5

microsoft dtv-dvd
User: 0s, kernel: 0s, total: 0s, real: 175s, fps: 20135.5, dfps: 46.6
User: 0s, kernel: 0s, total: 0s, real: 175s, fps: 18697.2, dfps: 46.6
User: 0s, kernel: 0s, total: 0s, real: 174s, fps: 23796.5, dfps: 46.9

coreavc 2.0
User: 24s, kernel: 0s, total: 24s, real: 96s, fps: 332.8, dfps: 84.2
User: 25s, kernel: 0s, total: 25s, real: 96s, fps: 317.3, dfps: 84.3
User: 25s, kernel: 0s, total: 25s, real: 97s, fps: 317.7, dfps: 84.0


already coreavc 1.9.5 is the fastest decoder on the dual core opteron cpu i have. but the new coreavc 2.0 has left me well and truly disapointed.

[Dark Shikari]

already coreavc 1.9.5 is the fastest decoder on the dual core opteron cpu i have. but the new coreavc 2.0 has left me well and truly disapointed.That's not bad at all, though I suspect there may be some small improvements to be had.

Do remember: all the new assembly optimizations were SSE2 through SSSE3, which don't exist or are near-useless on Athlon 64s. Additionally, the weightp fix cost some speed.

I'm actually surprised it's still marginally faster.

[the_corona]

AMD opteron users have seen the great decrease in overall speed with CoreAVC 2.0 from the reports so far.

the_corona... take your continued attacks/flames elsewhere, its really getting old.

My question was regarding how you measure the speed of CoreAVC if timecodec cannot be trusted and can thus declare it the "world's fastest H264 Codec".

How is that flaming/attacking you? Do you not have an answer?

[Cyber-Mav]

My question was regarding how you measure the speed of CoreAVC if timecodec cannot be trusted and can thus declare it the "world's fastest H264 Codec".

How is that flaming/attacking you? Do you not have an answer?

timecodec does the job, i use longer video clips to try and get more accurate/consistant results.

[Cyber-Mav]

That's not bad at all, though I suspect there may be some small improvements to be had.

Do remember: all the new assembly optimizations were SSE2 through SSSE3, which don't exist or are near-useless on Athlon 64s. Additionally, the weightp fix cost some speed.

I'm actually surprised it's still marginally faster.

my opteron supports sse2 and sse3, supplimental sse3 is not supported on me opteron 170.

seeing as how the q9650 cpu shows bigger speed difference with coreavc 2.0 it supports your statement that ssse3 and sse4 optimisations are what boost speed.

[Dark Shikari]

my opteron supports sse2 and sse3, supplimental sse3 is not supported on me opteron 170."Support" doesn't mean it's useful. The Athlon 64's SSE unit is so slow that it's generally worse than MMX. Most operations are done by splitting the instruction in half and sending them off to the MMX unit, making the whole thing a complete waste of time.seeing as how the q9650 cpu shows bigger speed difference with coreavc 2.0 it supports your statement that ssse3 and sse4 optimisations are what boost speed.Not at all. I tested myself; the SSSE3 optimizations gave relatively little compared to the benefit of SSE2 over MMX on a Core 2.

[Cyber-Mav]

odd, how come my laptop, the pentium M740 cpu that has sse2 saw now speed increase, if anything it was a 1fps decrease over coreavc 1.9.5?

[Dark Shikari]

odd, how come my laptop, the pentium M740 cpu that has sse2 saw now speed increase, if anything it was a 1fps decrease over coreavc 1.9.5?The Pentium-M has the worst SSE unit ever created, far worse than the Athlon 64. It is so bad that in x264, we simply had the CPU detection routines pretend that it didn't even support it at all.

In the next CoreAVC version, we should probably make an equivalent to the x264 routines for this.

[Cyber-Mav]

so in essence coreavc is just optimised for the latest intel cpus, which are the processors that least need speed increases. i would have thought that the focus would have been to get more performance out of older hardware, and energy efficient hardware such as the intel atom cpu. odd.

[Dark Shikari]

so in essence coreavc is just optimised for the latest intel cpus, which are the processors that least need speed increases. i would have thought that the focus would have been to get more performance out of older hardware, and energy efficient hardware such as the intel atom cpu. odd.Not true either. CoreAVC currently follows the more naive strategy of simply loading whatever functions the CPU supports. It would benefit, as I mentioned, from a more complicated strategy like x264's.

The Atom supports all the way through SSSE3, so that point is moot. The assembly is not fully optimized for Atom though; there is currently work on making it better, though note coding for Atom is much more difficult than any out-of-order CPU.

[lnatan25]

so in essence coreavc is just optimised for the latest intel cpus, which are the processors that least need speed increases. i would have thought that the focus would have been to get more performance out of older hardware, and energy efficient hardware such as the intel atom cpu. odd.
Shush, you are talking "off-topic", and might hurt CoreAVC sales!!! :rolleyes:

[Cyber-Mav]

ahh thats understandable, do you believe it is possible to extract any more decoding speed from cpu's like athlon64/ athlonxp / opteron / pentium-m / pentium 4 ? or do you believe coreavc has done all it can for those old timers?

[Dark Shikari]

ahh thats understandable, do you believe it is possible to extract any more decoding speed from cpu's like athlon64/ athlonxp / opteron / pentium-m / pentium 4 ? or do you believe coreavc has done all it can for those old timers?Do note there is still some assembly code that CoreAVC is missing: there is no SSE version of the 8x8 idct or the deblocking code. This will open the door for significant speed boosts with all SSE-supporting CPUs except for the P-M/Core1 (x264's numbers show that these functions are faster than MMX on Athlon 64). All the notes below are about existing asm.

Pentium-M/Core 1 would benefit significantly from simply turning off all the SSE code.

Pentium 4 probably can't gain any more; in theory some of the assembly code could be munged all over the place to give slight benefits due to the Pentium 4's retardation, but it's not worth bothering and the benefit would be very slight.

Athlon 64 would benefit a bit from disabling whatever SSE code is slower on A64. Maybe a few percent.

Atom could benefit from both more manual asm reordering, and a special Atom version of the motion compensation functions. Specifically, SSSE3 motion compensation uses two tricks to improve performance: pmaddubsw and palignr. The former hurts a lot on Atom, but the latter helps a lot. Making a version that only used the latter trick would improve performance there.

Of course, if CoreCodec implemented all of the above ideas, the release would be 6 months later and everyone would be complaining ;)

[Cyber-Mav]

how come they didnt turn off the sse code for pentium-m if it would benefit speed? or is this something you have pointed out just recently to them shikari?

[Dark Shikari]

how come they didnt turn off the sse code for pentium-m if it would benefit speed? or is this something you have pointed out just recently to them shikari?I didn't get around to it. CoreAVC 2 was released during my school's final exam week. Blame me. ;)

[Cyber-Mav]

will coreavc remove sse support for pentium-m in the future? or is it something we will have to wait and see.

[Disabled]

What exactly is your relationship with CoreAVC Dark Shikari? How long will you stay on the team and what ASM optimizations will you implement in that time? (Ie will you implement everything you just told us was possible?)

[khat17]

I wanna know how long before ATI will be supported. My wife's machine has my old 8800GTS, and CoreAVC 2.0 looks nice with the whole CUDA support - so I can use that if I need to test - but when will red team get some support?

And could you give an idea of what's the lowest specs that you think CoreAVC would run on and still give decent results? How about say...........a DURON 1.6 with some board and onboard graphics?

[Dark Shikari]

What exactly is your relationship with CoreAVC Dark Shikari? How long will you stay on the team and what ASM optimizations will you implement in that time? (Ie will you implement everything you just told us was possible?)I periodically come in and work on things when I have time; I'm not really responsible for much of anything with a hard deadline. I'll try to get that done sometime this winter break though.

[Chumbo]

CoreCodec is proud to present ...More info here: http://corecodec.com/products/coreavc .

CoreAVC™ 2.0 Professional Edition Decoder
* Supports Windows 7
* 32/64 bit Support
* NVIDIA CUDA GPU support
* Supports up to 16 CPU Cores
* QuadHD Resolution Support
* Uses Directshow for MKV
* Includes the Haali Media Splitter
* Full Interlaced support
...
Would love to see ATI Stream support soon please. Thank you. I'm anxiously waiting for my upgrade email. :)

[Mixer73]

I wanna know how long before ATI will be supported. My wife's machine has my old 8800GTS, and CoreAVC 2.0 looks nice with the whole CUDA support - so I can use that if I need to test - but when will red team get some support?

Would love to see ATI Stream support soon please. Thank you. I'm anxiously waiting for my upgrade email. :)

The answer to your question is perhaps never. Read this post for more information:

http://forum.doom9.org/showthread.php?p=1347303&highlight=ati#post1347303

[dimitrik]

"Support" doesn't mean it's useful. The Athlon 64's SSE unit is so slow that it's generally worse than MMX. Most operations are done by splitting the instruction in half and sending them off to the MMX unit, making the whole thing a complete waste of time.Not at all. I tested myself; the SSSE3 optimizations gave relatively little compared to the benefit of SSE2 over MMX on a Core 2.

Pardon my ignorant question but what about SSE4?

I read recently that Intel's &AMD's SSE implementations were similar until SSE4, were they branched off to SSE4 (Intel) & SS4a (AMD). It was my understanding the differences were such that it was necessary to optimize for each one separately.

I recently tested some x264 decoders (CoreAVC 1.95, DivX, ffmpeg-mt) on an Intel Quad @ 2.26, 2.33, 2.5 & 3GHz and an AMD Phenom-II 945@3GHz and noted that the AMD@3GHz was slower than the Intel at all speeds above 2.33GHz.
My test were not scientific but I wonder if this could be due to different SSE4 versions?

[roozhou]

Pardon my ignorant question but what about SSE4?

I read recently that Intel's &AMD's SSE implementations were similar until SSE4, were they branched off to SSE4 (Intel) & SS4a (AMD). It was my understanding the differences were such that it was necessary to optimize for each one separately.

I recently tested some x264 decoders (CoreAVC 1.95, DivX, ffmpeg-mt) on an Intel Quad @ 2.26, 2.33, 2.5 & 3GHz and an AMD Phenom-II 945@3GHz and noted that the AMD@3GHz was slower than the Intel at all speeds above 2.33GHz.
My test were not scientific but I wonder if this could be due to different SSE4 versions?

More instruction set does not mean faster decoding. A good example is Intel Atom.

IMO speed boost brought by SSE4 is trivial. The performance of SSE2 instructions has a noticeable impact on decoders.

[dimitrik]

More instruction set does not mean faster decoding. A good example is Intel Atom.

IMO speed boost brought by SSE4 is trivial. The performance of SSE2 instructions has a noticeable impact on decoders.

So the difference I noted was due to different SSE2 units? That's very interesting, thanks.

[BetaBoy]

I know it was mentioned in this thread.... but I wanted to clarify it further.

If you want to disable both CoreAVC and Haali's splitter for AVC content and using Directshow in favor of MediaFoundation in Windows 7 (not that we want you to do that ;-), You will need to deactivate use of the "CCV1" mediatype that they both share.

To do this: Open Haali's Media Splitter properties: Go to Options-> Output-> Use custom media type for H.264, and set it to "No".

This then reverts WMP/MCE to use MF for AVC. To re-enable it, simply set it back to 'yes'.

I have just added this to our KB as well.

[Chumbo]

The answer to your question is perhaps never. Read this post for more information:

http://forum.doom9.org/showthread.php?p=1347303&highlight=ati#post1347303
Thanks for the info Mixer73. That really blows chunks. ATI needs to get their heads straight, but that's been said for a long time now unfortunately. They make a great product but shouldn't "lock it down" like that. Sigh...

[BetaBoy]

All, on a side note.... I am looking for a small group of ppl to test our upcoming CoreAAC and CoreASP directshow filters (CoreMVC is not till later next year). Email: betagroup@corecodec.com with your system specs, including specifics on the video and audio cards you are using. We will email acceptances in January. Thank you ahead of time!

[Tom-Cat]

Hi.

I have tested quite a few mkv's with the new 2.0 version and have found that some have problems with 2.0 that played perfectly fine on 1.9.5. These have problems only when CUDA is enabled, they play fine on 2.0 without CUDA (by "fine" I mean there aren't any artifacts, but the system needs HW accel for smooth playback)! And even when they have problems they are pretty much random, some parts of the movie would play perfectly fine one time, but have huge artifacts the next time.

System: Asrock ION 330 (Nvidia ION, 2Gb memory, Atom 330 @ 1.6Ghz, Windows 7 32bit, MPC-HC - also tested with Mplayer2 and BSPlay).

MKV Files (88 Mb zip) : http://pc.sux.org/tomcat/mkv.zip

ALL Screenshots: http://pc.sux.org/tomcat/jpg.zip

Just two smaller ones as attachments.

[squid_80]

I tried playing the clips multiple times with CUDA active and couldn't get any artifacts to happen. Which driver version do you have installed?

[Tom-Cat]

I tried playing the clips multiple times with CUDA active and couldn't get any artifacts to happen. Which driver version do you have installed?

Unless they have been "silently" installed in the background by Microsoft Update, then they are about 2 months old or there about. Will check in 10 hours or so.
Thanx for testing them !

[Grmpf]

Hello Betaboy,

i mailed you at the address you gave a few pages back on monday for the 2.0 upgrade notification, but its still missing (i have a coreavc licence from the beginning...). I would love to buy 2.0 with all the discounts while the x-mas offer is still running, but without the new password i can not log into your new site...

[THX-UltraII]

Just tried the new Haali Renderer with a .m2ts file. Only the secondary audio is played (directors comment) and the first audio cannot be selected when I right-click in MPC-HC and look at the filter.

What am I doing wrong here?

[JeffBDVS]

CoreAVC 2.0 (CUDA or not) crashes VirtualDub when the source video is an AviSynth script that uses the MT filter for multithreading. 1.9.5 did not.

Vista 64
GTX 280 with the 191.07 drivers

-Jeff

[Tom-Cat]

I tried playing the clips multiple times with CUDA active and couldn't get any artifacts to happen. Which driver version do you have installed?

Thank you very much! I had 190.xx and after installing the newest driver (195.xx) it works without any problems. :)

[BetaBoy]

Hello Betaboy,

i mailed you at the address you gave a few pages back on monday for the 2.0 upgrade notification, but its still missing (i have a coreavc licence from the beginning...). I would love to buy 2.0 with all the discounts while the x-mas offer is still running, but without the new password i can not log into your new site...

Send me a PM and I'll take care of it for you.

[JeffBDVS]

Updated to the 195 drivers and the crash is still an issue with AviSynth and MT.

Disabling MT had some interesting results. I have dual quad-core Xeons. I used CoreAVC to decode an HD MTS video clip for downscaling to SD. Lagarith was used as the output codec from VirtualDub. It turns out that CoreAVC runs faster (about 29 fps) without CUDA enabled. Using CUDA maxed out at about 24 fps during the conversion. Is this a reasonable result?

-Jeff

[Blue_MiSfit]

Yep! CUDA is going to always be capped to a reasonable speed, since the ASIC on the video card is handling it, and can only process so fast.

~MiSfit

[Asmodian]

Updated to the 195 drivers and the crash is still an issue with AviSynth and MT.

Disabling MT had some interesting results. I have dual quad-core Xeons. I used CoreAVC to decode an HD MTS video clip for downscaling to SD. Lagarith was used as the output codec from VirtualDub. It turns out that CoreAVC runs faster (about 29 fps) without CUDA enabled. Using CUDA maxed out at about 24 fps during the conversion. Is this a reasonable result?

-Jeff

That sounds reasonable to me, CUDA uses a chip on the video card to decode the video and with that fast of a computer the CPU decode could be faster. However I can get >45fps using the DGNV tools (which uses the same chip on the video card) doing blu-ray to 480p with any preset fast to slower for x264 but I was doing the resize on the video card in that case.

What is your CPU usage during the encode? Maybe there is a bandwidth issue to/from the video card on the dual Xeon motherboard (I assume it isn't optimized for graphics the way a single socket consumer board is?). i7 or core2 Xeons and is it a NUMA aware system?

[JeffBDVS]

I can get >45fps using the DGNV tools (which uses the same chip on the video card) doing blu-ray to 480p with any preset fast to slower for x264 but I was doing the resize on the video card in that case.
I tried DGNV tools b7, but it maxed out at 24 fps also. How did you set up the resize on the card? Is it an option when using x264?

What is your CPU usage during the encode? Maybe there is a bandwidth issue to/from the video card on the dual Xeon motherboard
35% to 40%, which I interpret as not quite maxing out 4 cores out of 8.

-Jeff

[Asmodian]

On card resize is a option when loading in avisynth (h_resize, v_resize - I think).

It would be interesting to see the %CPU usage per-core. (crtl-alt-esc can show this for windows)

[JeffBDVS]

Here's a screenshot of the Performance graphs near the end of the operation.

CPU Usage (http://bellunevideo.com/client1/CPU_Use.jpg)

-Jeff

[potatochobit]

hi guys
I have a quick question, didn't see anyone talking about it
but is coreavc 2.0 worth upgrading to?
I have 1.9.5 but i had to disable it in windows 7 due to the corruption issue with newer h264
I did get the email that I could upgrade for 5$, but does the new coreavc performance worth having at all over CCCp and MT enabled?

[Dark Shikari]

hi guys
I have a quick question, didn't see anyone talking about it
but is coreavc 2.0 worth upgrading to?
I have 1.9.5 but i had to disable it in windows 7 due to the corruption issue with newer h264
I did get the email that I could upgrade for 5$, but does the new coreavc performance worth having at all over CCCp and MT enabled?Is it fast enough for you to play the videos you want? Then CCCP+MT is fine. Is it not fast enough? Then CCCP+MT probably isn't fine ;)

[THX-UltraII]

Just tried the new Haali Renderer with a .m2ts file. Only the secondary audio is played (directors comment) and the first audio cannot be selected when I right-click in MPC-HC and look at the filter.

What am I doing wrong here?

[talen9]

I suppose you tried Haali's Splitter, not the renderer, else you wouldn't report the "problem" with the audio streams ... which, btw, is NOT a problem :)

Actually, you're not using MPC-HC correctly: when using an external splitter, you cannot select the audio stream anymore from the "Audio" submenu: you have to use the "Navigate" menu, from there you can select audio/subtitle stream and jump to a different chapter, if the feature is present in the file you're playing.

[THX-UltraII]

I suppose you tried Haali's Splitter, not the renderer, else you wouldn't report the "problem" with the audio streams ... which, btw, is NOT a problem :)

Actually, you're not using MPC-HC correctly: when using an external splitter, you cannot select the audio stream anymore from the "Audio" submenu: you have to use the "Navigate" menu, from there you can select audio/subtitle stream and jump to a different chapter, if the feature is present in the file you're playing.

I meant the Splitter of course, sorry.

Ill try your tip tonight. Is the Haali Splitter preferable above the internal MPEG PS/TS/PVA filter? If so, why?

[talen9]

Once Haali's one was less CPU-intensive if compared with MPC-HC's internal one; i don't know if this is still true, though.

[dZeus]

Do note there is still some assembly code that CoreAVC is missing: there is no SSE version of the 8x8 idct or the deblocking code. This will open the door for significant speed boosts with all SSE-supporting CPUs except for the P-M/Core1 (x264's numbers show that these functions are faster than MMX on Athlon 64). All the notes below are about existing asm.

-cut-

ok, so that might explain the results I get when I compare CoreAVC to DivX on my Pentium 3. CoreAVC shows a far greater difference in speed when enabling deblocking compared to the DivX AVC decoder (see the large speed increase when going from CoreAVC deblock to no deblock).

Other than the fact that CoreAVC 2.0 seems to be slightly slower than v1.8.5 on a P3, I wonder why there is such a difference in speed between rendering to 'null' or to 'overlay' with CoreAVC, where DivX doesn't seem to give much difference (CoreAVC performs about 10% less on Overlay/Null compared to DivX AVC).

Why would there be a difference at all between different decoders when they're all set to output the same colourspace to the renderer (in this case YUY2)?

Nevertheless, on a P3 CoreAVC 2.0 still is faster than DivX AVC decoder, though it's a bit slower than v1.8.5.

[blubberbirne]

New Haali sucks here like hell.


F:\test.mkv::Video

Media Type 0:
--------------------------
Video: CCV1 1920x1080

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31564343-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 158

Video: CCV1 1920x1080 <- what the hell, its AVC and not CCV1.

If i switch so internal MKV Splitter in MPC-HD all works finel.

MediaInfo says:

General
Complete name : F:\test_.mkv
Format : Matroska
File size : 300 MiB
Duration : 3mn 42s
Overall bit rate : 11.3 Mbps
Encoded date : UTC 2009-12-25 21:58:14
Writing application : mkvmerge v3.0.0 ('Hang up your Hang-Ups') gebaut am Dec 12 2009 15:20:35
Writing library : libebml v0.7.9 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@5.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 3mn 42s
Bit rate : 10.7 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : Component
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Interlaced
Bits/(Pixel*Frame) : 0.206
Stream size : 284 MiB (95%)
Title : PID 4113
Language : German
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
Codec ID : A_AC3
Duration : 3mn 42s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Video delay : 15ms
Stream size : 10.2 MiB (3%)
Title : PID 4352
Language : German

[LoRd_MuldeR]

New Haali sucks here like hell.


F:\test.mkv::Video

Media Type 0:
--------------------------
Video: CCV1 1920x1080

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31564343-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 158

Video: CCV1 1920x1080 <- what the hell, its AVC and not CCV1.

I think that's their "hack" to avoid the Microsoft decoders and allow CoreAVC 2.0 to be used inside WMP/WMC ;)

And you can turn it off in Haali's options :p

[BetaBoy]

blubberbirne.... How about reading this thread instead of posting in a manner that does nothing nothing to help you.

Now... Go to Haali's settings and select 'no' for custom mediatype.

[BetaBoy]

I think that's their "hack" to avoid the Microsoft decoders and allow CoreAVC 2.0 to be used inside WMP/WMC ;)

And you can turn it off in Haali's options :p

Hack? I'd not even compare that to that of renaming DLL's and the like . In fact we have had no less then a dozen companies that have emailed us since the CoreAVC 2.0 / Haali launch, asking for information on how they can do the same thing for their applications.

Almost each of the companies stated that the solution to add a custom mediatype to bypass mediafoundation is the easiest way to not fall into the pitfalls that they each have tried to work with, with little success.

Did I say that MF is evil? :-)

[LoRd_MuldeR]

I didn't want criticize your method. Instead it should be criticized that such workarounds (if you prefer that word) are needed. Oh, and I used the quotation marks for a reason ;)

BTW: I wonder how long it will take until M$ comes up with a way to block your method ^^

[avivahl]

So you guys simply "fake" the FOURCC code of the H.264 stream to be something else in order to avoid Microsoft's decoder from accepting it? What if I'll install Haali Media Splitter and want ffdshow to decode the video...? Would ffdshow accept this FOURCC code?

[LoRd_MuldeR]

So you guys simply "fake" the FOURCC code of the H.264 stream to be something else in order to avoid Microsoft's decoder from accepting it? What if I'll install Haali Media Splitter and want ffdshow to decode the video...? Would ffdshow accept this FOURCC code?

Did you read the last few posts in this thread? It appears you didn't, because the answer to your question was given twice already :p

Anyway, ffdshow does support Haali's new "custom" H.264 media type already:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=3169

[avivahl]

Did you read the last few posts in this thread? It appears you didn't, because the answer to your question was given twice already :pOh, i missed the line that says "you can turn it off in Haali's options"... So wait a minute... Is it the default value (faking FOURCC set to ON) when installing Haali as standalone?

[LoRd_MuldeR]

Oh, i missed the line that says "you can turn it off in Haali's options"... So wait a minute... Is it the default value (faking FOURCC set to ON) when installing Haali as standalone?

Yes, because otherwise people will complain that they can't use anything but Microsoft's H.264 decoder in WMP/WMC :rolleyes:

Remember that without the "custom media type" workaround we can't even use ffdshow in WMP/WMC, at least not without the help of clsid's tool.

And as ffdshow accepts Haali's workaround, you'd only need to turn off the custom media type for other H.264 decoders...

[avivahl]

Thank you for the clear information! :)

[squid_80]

Yes, because otherwise people will complain that they can't use anything but Microsoft's H.264 decoder in WMP/WMC :rolleyes:

Remember that without the "custom media type" workaround we can't even use ffdshow in WMP/WMC, at least not without the help of clsid's tool.

Hasn't anyone bothered to check what those registry entries are after installing CoreAVC?

[Ice =A=]

Congratulations on releasing CoreAVC 2.0!

And while we're at it I wanted to say again that ANY 720p AVC video file I ever tested did run flawlessly on an Intel Atom single core with CoreAVC 1.5 upwards! (On any other cpu out there 720p playback is fast enough anyway.)
Nevertheless I'd welcome any speed improvements on Atom cpus which might result in saving some energy and extending run time!

So for me bying CoreAVC 2 depends on speed improvements on Atom cpus and I'm really looking forward to some benchmarks! :)

[lnatan25]

I didn't want criticize your method. Instead it should be criticized that such workarounds (if you prefer that word) are needed. Oh, and I used the quotation marks for a reason ;)

BTW: I wonder how long it will take until M$ comes up with a way to block your method ^^
How about developing a Media Foundation codec, instead of resorting to hacks? No quotation marks are required, this is indeed a hack, even if it is a mild one.

[BetaBoy]

Why? Simple why should developers adopt a technology that provides no added value other then lock them into DRM restrictions?

[lnatan25]

The DRM facilities are there only if you want them.

You don't want to adopt, that's fine, just don't take offense when your bypass method is called what it is, a hack. MF evil or not, you made a hack around it. :)

[BetaBoy]

Please... if that were the case then everyone would be making MF codecs... but the truth is they are not. If 'you' want to call a custom mediatype a hack then so be it, in the end it bypasses MediaFoundation and that's all that counts to most of us.

[Ice =A=]

Just my opinion:
If I had to choose between DRM or any kind of proprietary solution on one side and a workaround or hack or whatever you call it on the other side I'd choose the latter without hesitation!

The DRM facilities are there only if you want them.It's just that I don't want them to be possibly there!!! :)

[lnatan25]

It's just that I don't want them to be possibly there!!! :)
May I ask what operating system you are using?

[BetaBoy]

lnatan25... I see where you are going? We could make it possible that the custom mediatype to only be used in Windows 7. I'll sync with guys on it.

[Disabled]

Isn't WMP the only app that uses MF? Wouldn't it even be more feasable to only use the new mediatype when a MF compatible app is used?

[lnatan25]

WMP and WMC, and possibly any future media application by Microsoft.

[squid_80]

How about developing a Media Foundation codec, instead of resorting to hacks? No quotation marks are required, this is indeed a hack, even if it is a mild one.
"Hey let's use this new framework from MS called activemovie."
"Hey let's use this new framework from MS called directshow."
"Hey let's use this new framework from MS called DMOs."
"Hey let's use this new framework from MS called Media Foundation."

I think you can see where I'm going here.

[BetaBoy]

lnatan25... I see where you are going? We could make it possible that the custom mediatype to only be used in Windows 7. I'll sync with guys on it.
I was reminded that's how it works now... Win 7 only.

[lnatan25]

BetaBoy, any news on when the CorePlayer Mobile platform will receive the H.264 decoding improvements?

[BetaBoy]

We are planning to release CorePlayer 2.0 in Q1 next year that will feature the current improvements as well as the ARM Cortex NEON A8 improvements for AVC (and AAC, MP3, ASP by then).

We will be demo'ing at CES and if anyone wants to see whats going on with it and our other products, pls email: info@corecodec.com with the blog, companies you are with and I'll give you a schedule of our planned CES events.

[lych_necross]

How about developing a Media Foundation codec, instead of resorting to hacks? No quotation marks are required, this is indeed a hack, even if it is a mild one.
The reason is simple. No offense intended, but I believe that programmers are inherently lazy and choose to implement "hacks" to fix problems instead of rewriting the offending code correctly.

[BetaBoy]

The reason is simple. No offense intended, but I believe that programmers are inherently lazy and choose to implement "hacks" to fix problems instead of rewriting the offending code correctly.
That's not the case here that's for sure. MF codecs are as simple to make as directshow ones.

[88keyz]

Did my own little tests to compare performance of CoreAVC 2.0 with MPC Video Decoder r.1448 and here are my results using the following MKV file:


General
Complete name : C:\Sample.720p.AC3.x264.mkv
Format : Matroska
File size : 78.5 MiB
Duration : 1mn 2s
Overall bit rate : 10.5 Mbps
Encoded date : UTC 2007-07-22 17:15:17
Writing application : mkvmerge v2.0.2 ('You're My Flame') built on Mar 5 2007 12:54:12
Writing library : libebml v0.7.7 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Muxing mode : Container profile=Unknown@5.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 2s
Bit rate : 9 698 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.439
Stream size : 72.1 MiB (92%)
Language : English

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 1mn 2s
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Video delay : 8ms
Stream size : 4.76 MiB (6%)


System:
Windows 7 Ultimate x64
Core i7 860
8 GB DDR3-1333
MPC-HC r.1448 - x64

CPU Software Decoding:
CoreAVC 2.0 - 5.94% Avg. CPU usage
MPC Video Decoder r.1448 - 8.17% Avg. CPU usage

GPU Accelerated Decoding:
CoreAVC 2.0 - 2.13% Avg. CPU usage
MPC Video Decoder r.1448 - 1.94% Avg. CPU usage

So as you can see CoreAVC is the faster software decoder (which I think we all knew) but DXVA is still quicker than CUDA when it comes to GPU acceleration. The difference is minimal but it is there.

Also, for those of you with Windows 7 there is a great little tool out there that will allow you to select the system default decoder for many of the most popular codecs. Works great and its something I would highly recommend.

Preferred Filter Tweaker for Windows 7 (http://www.codecguide.com/windows7_preferred_filter_tweaker.htm)

[lnatan25]

The reason is simple. No offense intended, but I believe that programmers are inherently lazy and choose to implement "hacks" to fix problems instead of rewriting the offending code correctly.
I really have no problem with this. The majority of their target audience is using DirectShow, so for now at least, they don't find reason in maintaining two different branches - one for DS and one for MF. What I was commenting on, was that BetaBoy took offense to the word "hack". :)

[me7]

So as you can see CoreAVC is the faster software decoder (which I think we all knew) but DXVA is still quicker than CUDA when it comes to GPU acceleration. The difference is minimal but it is there.

This is already well known. DXVA and CUDA use the same decoding hardware, but DXVA outputs the video directly after decoding while CoreAVC + CUDA copies each frame back into RAM first, which does take longer but allows other filters (like subtitle filters) to alter the frame.
It's not a disadvantage, it's a feature :)

[dimitrik]

I really have no problem with this. The majority of their target audience is using DirectShow, so for now at least, they don't find reason in maintaining two different branches - one for DS and one for MF. What I was commenting on, was that BetaBoy took offense to the word "hack". :)

And as part of that audience, I have an added reason for supporting this which is that ALL my codecs are directshow filters, not just CoreAVC. So bypassing MF is definitely something I want for all filetypes, hence I resort to this and other similar hacks to be able to set up my HTPC the way I want to. Or I stick with Vista (which for now is actually fine).

But if I have to use MF codecs which will restrict my ability to play each filetype with the best possible decoder, I might as well bite the bullet and switch to XMBC under linux or something, which will have a learning curve but finally free me from the MS cr*piness.

As for calling it a hack or not, to each his own. I'm fine with calling it anything, why should it matter as long as it gets me where I want to go today:p

[JeffBDVS]

Can anyone (Core-folk or not) confirm or deny a crash in VirtualDub when using CoreAVC as the DirectShowSource decoder in an AviSynth MT script that resizes HD video down to SD frame sizes? Setting MTMode to (2,0) causes the crash. If I set MTMode to (3,0), then the script runs at only 3 -4 fps on an 8-core machine.

Thanks,
-Jeff

[Blue_MiSfit]

But if I have to use MF codecs which will restrict my ability to play each filetype with the best possible decoder, I might as well bite the bullet and switch to XMBC under linux or something, which will have a learning curve but finally free me from the MS cr*piness.


Then forget about any DirectShow decoders :) You loose ffdshow and avisynth post processing in Linux.
~MiSfit

[ChronoCross]

/me prods BetaBoy for returning customer email.

ffdshow is just not doing it for me...

[lnatan25]

Can anyone (Core-folk or not) confirm or deny a crash in VirtualDub when using CoreAVC as the DirectShowSource decoder in an AviSynth MT script that resizes HD video down to SD frame sizes? Setting MTMode to (2,0) causes the crash. If I set MTMode to (3,0), then the script runs at only 3 -4 fps on an 8-core machine.

Thanks,
-Jeff
Confirmed.

And to stop CoreAVC being the DirectShow source used, you have to disable the input colorspace. :rolleyes: What is the point of having a "Preferred decoder" check box, when it has no effect whatsoever? :rolleyes:

[JeffBDVS]

Confirmed.

And to stop CoreAVC being the DirectShow source used, you have to disable the input colorspace. :rolleyes: What is the point of having a "Preferred decoder" check box, when it has no effect whatsoever? :rolleyes:
Thanks for confirming that.

CoreAVC may not be the sole guilty party here. I updated AC3 Filter to 1.63b, and I'm running some tests now where I set the MTMode to (3,0) before the DirectShowSource command, and then switch to MTMode(2) after it. With CUDA preferred in CoreAVC, I've gotten a couple of short conversion runs at frame rates of 30 - 50 fps without crashing.

I'm running a long test now. The short tests ended up with artifacts in the output files, but that may be an output codec issue. The short tests were done with UT 7.02, but the long test is being done with Lagarith.

-Jeff

[mandarinka]

post 5265 (http://forum.doom9.org/showpost.php?p=1348040&postcount=5265)

Sadly, it seems that the bug that caused coreavc 1.9.5 to crash or corrupt decoded video is still alive and well in version 2.0.
Are there any plans to look into this?

[JeffBDVS]

Thanks for confirming that.

CoreAVC may not be the sole guilty party here. I updated AC3 Filter to 1.63b, and I'm running some tests now where I set the MTMode to (3,0) before the DirectShowSource command, and then switch to MTMode(2) after it. With CUDA preferred in CoreAVC, I've gotten a couple of short conversion runs at frame rates of 30 - 50 fps without crashing.

I'm running a long test now. The short tests ended up with artifacts in the output files, but that may be an output codec issue. The short tests were done with UT 7.02, but the long test is being done with Lagarith.

-Jeff
MT in AviSynth with CoreAVC 2.0 is unusable. Even with the filter tweaks to prevent crashing VirtualDub, the final output is time-jumbled. Some frames appear whole seconds before they're supposed to, some frames are missing completely. Apparently the multi-threaded MT pipeline and CoreAVC's multi-threading are incompatible unless MT is slowed waaay down.

The artifacts I mentioned were eliminated by adjusting settings in the players I used to view the video, so CoreAVC isn't introducing any artifacts, even in the time-jumbled clips. Both UT and Lagarith produced high-quality output, which I was able to confirm after the settings adjustments.

So far, software decoding with CoreAVC (versus CUDA GPU decoding) seems to be the way to go for me.

-Jeff

[squid_80]

What is the point of having a "Preferred decoder" check box, when it has no effect whatsoever? :rolleyes:
The checkbox lowers the decoder's priority from preferred to normal. If it still gets used then your other decoder has the same/lower priority, or doesn't handle the required input/output formats.

[saint-francis]

Personally I have never been able to use DirectShowSource with SetMTMode (2,0) You have to start with (3,0) and switch to (2,0) after. This isn't a CoreAVC bug. It has to do with DSS.

[JeffBDVS]

Personally I have never been able to use DirectShowSource with SetMTMode (2,0) You have to start with (3,0) and switch to (2,0) after. This isn't a CoreAVC bug. It has to do with DSS.
Thanks!

The filter tweaks I mentioned in my last post? Your solution is exactly what I did to fix the crash when CUDA was enabled. I should have been more specific.

If software rendering in CoreAVC is used instead, the 3-then-2 solution results in conversion frame rates less than 10 fps. Bad juju.

The new, big problem is the converted output video and its jumbled frames when using MT. I *don't* have a solution for that other than to not use MT.

-Jeff

[Virtual_ManPL]

bump, not fixed in CoreAVC Professional 2.0.0

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly
x264 - core 55 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:-6:-6 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=2pass bitrate=5299 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30 zones aq=1:0.3:15.0
file:
CoreAVC-large-motion-vectors-x264-b0rk.mkv (http://www.cccp-project.net/beta/test_files/CoreAVC-large-motion-vectors-x264-b0rk.mkv)
http://img101.imageshack.us/img101/9430/coreavc1.th.png (http://img101.imageshack.us/i/coreavc1.png/)



2 bug
frames are wrongly decoded in CUDA and soft mode, internal MPC-HC decoder decode this properly
OLS05lossless--avisource_82_92.mp4
x264 - core 55 svn-663C - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=7 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=32 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=1 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=2 wpredb=1 bime=1 keyint=240 keyint_min=25 scenecut=40 rc=2pass bitrate=1717 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30
file:
OLS05lossless--avisource_82_92.mp4 (http://www.cccp-project.net/beta/test_files/OLS05lossless--avisource_82_92.mp4)

CoreAVC
http://img192.imageshack.us/img192/4695/coreavc2.th.png (http://img192.imageshack.us/i/coreavc2.png/)
internal MPC-HC decoder
http://img192.imageshack.us/img192/6159/mpchc.th.png (http://img192.imageshack.us/i/mpchc.png/)



and you can also try other files on this FTP (http://www.cccp-project.net/beta/test_files/) to check that everything working properly with CoreAVC 2.0 before official release ;)

[squid_80]

I told you, those streams are invalid.

[Virtual_ManPL]

and I told you too :p


first file is properly decoded in soft mode, not in CUDA

second file is decoded with less errors, look even on SS (better error resilnience?) in soft mode in MPC-HC (DiAVC in near future will decode this like MPC-HC decoder or better like I heard), CoreAVC have problems with it

[iSunrise]

@BetaBoy:
Thanks for the great release. I have a rather complex chain setup, and from now on I can use CoreAVC 2.0.0 (with CUDA enabled) as a decoder, together with ffdshow as a post-processor AND madVR or Haali as renderer, while CPU usage is extremely low on a Core i7. I also have a very demanding avisynth MT script running which works very well with it.

One _very annoying_ and related bug, however, is that Haali`s new splitter package, v1.9.355.21 (which also comes with CoreAVC 2.0.0) doesn´t recognize VC-1 streams in M2TS containers anymore, while v1.9.42.1 worked flawlessly. I hope this issue can be solved quickly.

Keep up the good work and a happy new year in advance.

[JeffBDVS]

One _very annoying_ and related bug, however, is that Haali`s new splitter package, v1.9.355.21 (which also comes with CoreAVC 2.0.0) doesn´t recognize VC-1 streams in M2TS containers anymore, while v1.9.42.1 worked flawlessly.
Concur.

-Jeff

[JohnnyFu]

v1.9.355.21 (which also comes with CoreAVC 2.0.0) doesn´t recognize VC-1 streams in M2TS containers anymore, while v1.9.42.1 worked flawlessly. I hope this issue can be solved quickly.

Keep up the good work and a happy new year in advance.

Oh my gosh... and I thought haali couldn't handle VC-1 in m2ts at all. I remuxed tons of VC-1 streams into matroska containers during christmas days haha....

However, I second your last comment!

[jj666]

and I told you too :p


first file is properly decoded in soft mode, not in CUDA

second file is decoded with less errors, look even on SS (better error resilnience?) in soft mode in MPC-HC (DiAVC in near future will decode this like MPC-HC decoder or better like I heard), CoreAVC have problems with it

File #1 is a rule 6 violation, so you shouldn't ask about it here.

Cheers,

-jj-

[Virtual_ManPL]

Who cares about stupid rules (I dunno even where is the topic about it...) :rolleyes:

IMO better is helping in bug reporting...
And thats is only SAMPLE, not full movie or sth ;)

[Guest]

Who cares about stupid rules (I dunno even where is the topic about it...) :rolleyes:
Your attitude has just bought you a rule 6 strike. You may not discuss warez here.

[rpm7200]

coreavc rgb32 is really bad but ffdshow's rgb32 is good. please download this youtube video's and force coreavc and ffdshow rgb32 output. they output are really different. it is very important. sample is here http://www.youtube.com/watch?v=LN5lF4dp3cs

[leeperry]

has there been any test w/ a wattmeter between CUDA and software decoding? apparently CUDA would consume far less electricity?

[JohnnyFu]

has there been any test w/ a wattmeter between CUDA and software decoding? apparently CUDA would consume far less electricity?

Not CUDA but DXVA....
Leistungsaufnahme (Power Consumption) - BluRay
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/22/#abschnitt_bluraymultimonitorverbrauch

Leistungsaufnahme (Power Consumption) - Idle / Last (Load)
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/21/#abschnitt_leistungsaufnahme

Sorry it's a german site...

[leeperry]

Not CUDA but DXVA.... [..]
Sorry it's a german site...
very nice, thanks! but they didn't try full software decoding to compare?

I see several other decoders fight to take CoreAVC's speed crown...but what matters to me is my electricity bill in the end. I'll try to find someone w/ a wattmeter to check, and I'll report back.

[turok]

I have problems playing a H.264 720p video on my comp like lagging and stuff: Would changing the deblock from standard to skip always fix the problem and allow me to play the 720p video without problems? My comp is old lol running an xp sp3 1.25gb ram pentiium 4 @ 2.4ghz and no its not dual core theres only one.

[Mixer73]

I see several other decoders fight to take CoreAVC's speed crown...but what matters to me is my electricity bill in the end. I'll try to find someone w/ a wattmeter to check, and I'll report back.

I concur, and where you will find electricity savings you'll also find lower heat and therefore less noise in a HTPC, which is a major criteria for me.

[AnonCrow]

Would changing the deblock from standard to skip always fix the problem and allow me to play the 720p video without problems?
It might, but it'd also introduce horrible artifacts, unless the video is very high quality - low quantizers.
I just skip B-frames alltogether.

Alternatives:
temporarily re-encode each video
either into x264 using ultrafast preset (or any other with --tune fastdecode if you don't mind it taking longer), with a relatively low CRF (14-20) to maintain some quality, or
into XVID or MPEG2 which should take even less power to decode; and might have better hardware decoding support on older videocards.

Overclock your P4 just a little; 10 to 15% overclock shouldn't need a voltage increase.

If spending some money isn't out of the question (double digit $/€) , an AGP ATI/AMD card should be able to decode lower resolution H.264 material , YMMV with 720P, not enough bandwidth for 1080P.

[turok]

Just tried it although it does bring artifacts I can do 720p just fine.i can decode anything not 720p just fine or more like as long as its not higher than 960x720 i can decode it just fine lol.

[dZeus]

-cut-
Overclock your P4 just a little; 10 to 15% overclock shouldn't need a voltage increase.

If spending some money isn't out of the question (double digit $/€) , an AGP ATI/AMD card should be able to decode lower resolution H.264 material , YMMV with 720P, not enough bandwidth for 1080P.

What do you mean, not enough bandwidth for 1080p? I haven't seen a sample that failed to play without framedrops on my HD3650 AGP in DXVA.

[puffpio]

I'm having a problem with CoreAVC 2 64 bit on my Core 2 Duo (T7300) laptop with Windows 7 64 bit decoding HD sized videos.
CPU usage will shoot up to 100% and the video will slow down for a minute or two..it will play so slowly that the audio will stutter so it doesn't get too far ahead of the video, then the video will play very fast to catch up to the audio..it will play at normal speed for a minute or two during which the CPU usage is not maxed out, and then it will repeat. This makes videos unwatchable.

I switched back to ffdshow and ffmpeg-mt and it plays my 720p content just fine...I bought CoreAVC because I thought I would be able to play back 1080p through my laptop..but this really sucks.

For a sample clip, please PM me and I'll provide a link.
..the first 2 minutes of this show, when the jungle scenes first come on.my cpu shoots to 100% and the playback slows to a crawl and audio stutters..whereas with ffmpeg-mt it plays fine

-----

well..i switched from using the haali renderer in media player classic home cinema to EVR custom and it appears to have fixed everything. curious why haali's renderer would cause those problems

[JohnnyFu]

I know you will strike me Betaboy but you have to take critisism in order to make a better product, right? No negative feelings!

I was recently asked for a good reason to buy CoreAVC when I was promoting the the 2.0 release on a german forum. To my own surprise I didn't know any.

Wait.... I just remembered the initial reason for me to buy CoreAVC three years ago. It was

GPU support (to be added**) ** GPU scheduled to be added at a later date

I guess it is just bad luck that I had just bought myself an ATi card when CUDA was implemented two years later.

However, I spend the last two weeks with my new Philips Flat, an HTPC and 7MC. My conclusion is that I have to uninstall both CoreAVC and Haali Renderer for now.

MPCVideoDec.ax is way faster on my ATI card then CoreAVC 2.0 thanks to DXVA. And Haali's Renderer caused a bit of pain to me. It registers itself for almost eveything by default even though it can't even handle VC-1/M2TS at all. So I figured MPC splitters are the better solution for now. Hopefully Haali fixes VC-1 soon.

[avivahl]

And Haali's Renderer caused a bit of pain to me. It registers itself for almost eveything by default even though it can't even handle VC-1/M2TS at all. So I figured MPC splitters are the better solution for now. Hopefully Haali fixes VC-1 soon.Couldn't you simply uncheck everything (but "MKV") in the installation? or is there a bug?

[ForceX]

If I recall correctly, if you choose to install the embedded Haali splitter in CoreAVC installation, it does a silent installation without showing the dialogue box, so no way to modify it. One way to fix this after installation is to regsvr32 /u the individual DLLs for the problematic file types.

[avivahl]

Well, then one could probably install Haali manually (unchecking the boxes he doesn't want), and then install CoreAVC w/o Haali. Isn't that possible?

[squid_80]

MPCVideoDec.ax is way faster on my ATI card then CoreAVC 2.0 thanks to DXVA.
I'd like to see some benchmarks to back that up... or what you really meant to say is that it's just lighter on the cpu when playing in realtime.

[STaRGaZeR]

I'd like to see some benchmarks to back that up... or what you really meant to say is that it's just lighter on the cpu when playing in realtime.

It means that you can actually play stuff without perfomance issues. And you know that. A benchmark like TimeCodec is useless, it doesn't show when the decoder can't work in realtime at some points.

[wOxxOm]

biXPelsPerMeter, biYPelsPerMeter confusion...

CoreAVC decoder (as well as ffmpeg's libav/h264) seems to mistreat haali splitter's OUT-pin properties biXPelsPerMeter/biYPelsPerMeter (used for SAR correction numerator/denominator in mp4/mkv header)

e.g. I have a 1440x800 mkv with 16:9 AR set in mkv header. It should play at 1440x810, but when haali splitter is used in MPCHC (which sets biX/YPelsPerMeter unlike the standard Gabest's splitter), the video stream is decoded to a strange resolution (1536x800) with strange AR (4551:2560) then gets rescaled by renderer (any of them) to the correct AR & size. And though the result video size is correct but I'm afraid that 1) the quality degrades due to intermediate resizing 2) performance-wise it's not optimal.

These picture properties in haali splitter's output video pin entangle the CoreAVC h264 decoder:
biXPelsPerMeter: 81 (Haali - AR correction numerator, 81 in my case)
biYPelsPerMeter: 80 (Haali - AR correction denominator, 80 in my case)

* since 1440x800 @ 16:9 = 1440x810, so AR correction is 800/810 = 80/81
** biXPelsPerMeter, biYPelsPerMeter = 0 in the [standard] Gabest's mkv splitter.

[squid_80]

It means that you can actually play stuff without perfomance issues. And you know that.
That's not what he said at all, and I don't know it because it's not true - CoreAVC running on any average pc bought within the past 3 years (excluding atom, which are far below average) will give much better performance than a hardware decoder running on the same machine.

[STaRGaZeR]

Why the 3 year limit? Core2 launch? What about the huge number of slow P4s and the like out there? :rolleyes:

If better perfomance means higher TimeCodec numbers, then probably yes depending on the case, but if better perfomance means playing 1080i60 Blu-ray streams with high quality deinterlacing on insert-whatever-old-CPU-name-here (way older than 3 years), most likely not, because your "average" 3 year-old CPU running CoreAVC won't be able to do it.

[squid_80]

Why the 3 year limit? Core2 launch? What about the huge number of slow P4s and the like out there? :rolleyes:

If better perfomance means higher TimeCodec numbers, then probably yes depending on the case, but if better perfomance means playing 1080i60 Blu-ray streams with high quality deinterlacing on insert-whatever-old-CPU-name-here (way older than 3 years), most likely not, because your "average" 3 year-old CPU running CoreAVC won't be able to do it.
Are you the original poster that I was talking to? Or did you even bother to read his post before you jumped in and started derailing the conversation?

Wait.... I just remembered the initial reason for me to buy CoreAVC three years ago.
[..]
However, I spend the last two weeks with my new Philips Flat, an HTPC and 7MC.

[JohnnyFu]

I'd like to see some benchmarks to back that up... or what you really meant to say is that it's just lighter on the cpu when playing in realtime.

Yes, what I really meant is that it doesn't need much CPU at all.

CoreAVC running on any average pc bought within the past 3 years (excluding atom, which are far below average) will give much better performance than a hardware decoder running on the same machine.

People will not take you seriuos if you post things like that.

I remember three years ago, november 2006, I did some very extensive benchmarks here on doom9 between CoreAVC and Cyberlink, unfortunately the screenshot results are lost. Even back then Cyberlink was way faster (lighter on the cpu) then CoreAVC and was the only way for me to actually watch some BBC (Planet Earth) videos on my Athlon CPU. I bought back then CoreAVC because they announced hardware support for their decoder as well. Well, we all know how that ended up...

Today, three years later, there at least two more decoders with hardware support out there. And they are all WAY much faster then CoreAVC. Yes you know what I mean squid_80, they don't break my system during video playback. Even today I can't watch all my h264 videos using CoreAVC on my HTPC (AMD X2 235e). Ok, I have to admit CoreAVC performs well on my workstation (Intel Quad Core) though.... :mad:

[Blue_MiSfit]

If you're having issues with your CPU not being quite fast enough (even with CoreAVC), then you should experiment with different renderers. My Quadro NVS130 (basically a GeForce 8400M) is pretty slow, so I can't use EVR or haali for 1080p stuff, even with CoreAVC decoding. So, I often use VMR7, which is quite fast, though not quite as pretty (running Windows 7 x64 btw).

On XP, you could also try overlay mixer.

EVR CP is awesome, but is verrry sloooww on older systems :)

Also, you should be running 32 bit builds of everything. 64 bit MPC-HC / ffdshow is actually slower and more buggy than the 32 bit versions, due to lots of missing ASM.

~MiSfit

[STaRGaZeR]

Are you the original poster that I was talking to? Or did you even bother to read his post before you jumped in and started derailing the conversation?

No and yes. Now you start with derailments instead of admiting things, just like BetaBoy. The main point of CoreAVC is being able to play stuff you can't play with free decoders on slow systems. Surprise, most of the time it won't be fast enough either, and will eat your CPU alive. When it's not fast enough, you "complain" and what you get for your money is forum vitriol and excuses. Just read this thread. You guys at CoreCodec should read a book or two about how to run a business.

[clsid]

Use case 1: real-time playback

The "fastest" decoder is the one with the best playback performance, being the lowest CPU usage. Both the average and the peak usage is relevant.

Use case 2: non real-time decoding (e.g. generating input for an encoder)

Here the highest fps decoding rate is what matters.

Just my $0.02

[hydra3333]

The main point of CoreAVC is being able to play stuff you can't play with free decoders on slow systems. Why only "on slow systems" ? Are there free decoders which do the job as reasonably as coreavc/haali ?

[LoRd_MuldeR]

Why only "on slow systems" ? Are there free decoders which do the job as reasonably as coreavc/haali ?

There are free H.264 decoders available, such as ffmpeg/libavcodec (e.g. ffdshow) and the DivX H.264 Decoder.

If those are fast enough for smooth "real time" playback on your system, there's not much reason to invest your money into a payware H.264 decoder ;)


So if at all, you would buy a "fast" H.264 decoder for a "slow" system. And even that only if the payware decoder enables smooth playback, while the freeware decoder doesn't.

But in case you have a decent CPU, the free decoders will allow smooth playback, even for high-bitrate 1080p content. Why would you buy another decoder then?


Being 5% faster or slower doesn't matter for a decoder, at least not for "real time" playback. There are only two possibilities: It's fast enough for smooth playback or it isn't!

For the purpose of encoding (that is: non-realtime decoding) it may matter, but even then it only matters if your encoder is bottlenecked by the input/decoder.

[STaRGaZeR]

Why only "on slow systems" ? Are there free decoders which do the job as reasonably as coreavc/haali ?

As stated by LM, when watching videos, there are two situations: the decoder is fast enough for realtime playback or it isn't. You should only consider a payware decoder when the available free decoders aren't fast enough. CoreAVC is barely faster than other free decoders, so even if your system is slow CoreAVC will probably only help in cases where you're in the limit of being playable/unplayable with the free decoders, of course not in cases where it's completely unplayable.

This is the logical way, people can spend their money in whatever they want.

[Mixer73]

I bought back then CoreAVC because they announced hardware support for their decoder as well. Well, we all know how that ended up... Today, three years later, there at least two more decoders with hardware support out there.

It is NOT CoreAVC's fault that ATI chose not to implement UVD controls in their SDK.

There are free H.264 decoders available, such as ffmpeg/libavcodec (e.g. ffdshow) and the DivX H.264 Decoder.

My opinion & experience only:
CoreAVC is the best solution for pre-Windows 7 to get DXVA playback for Media Centre, I found it much more reliable. Trying to get Cyberlink codecs priority right just didn't deliver a result for me. CoreAVC on the other hand seemed to work instantly, and when CUDA was bought out the system performed even better. Haali has its issues (I had the crashing on thumbnail creation) but they are solvable.

My MCE box is Win7 so the jury is out for me on whether I will install CoreAVC on that or not. I'm not sure I see the benefit atm. Plus for stability I like having less stuff installed. Personally I found just FFDShow is the #1 cause of crashes/memory leaks/lack of responsiveness on my MCE rig.

Now on my other system, 64bit Vista/Q6600 CPU, primarily using MPC-HC and recently had to go back to a 7950GTX with no DXVA support, I found libavcodec/ffmpeg codecs woefully inadequate, very soft picture and stuttery playback. CoreAVC 1.9.5 played OK but with some artefacting; so I upgraded to 2.0 and playback is perfect on my system now.

I never tested the DIVX decoder, perhaps I should have; but CoreAVC for me was a known quantity and it was only a fiver ;)

[leeperry]

The main point of CoreAVC is being able to play stuff you can't play with free decoders on slow systems.I think the main point of CoreAVC *nowadays* is to use CUDA and save on your electricity bill, as a VP2 GPU is far more efficient than a CPU for decoding h264.

[IgorC]

I think the main point of CoreAVC *nowadays* is to use CUDA and save on your electricity bill, as a VP2 GPU is far more efficient than a CPU for decoding h264.
Can you provide tested results?

[lych_necross]

I think leeperry already posted some links about power consumption in CPUs vs GPUs a while back. I'm too lazy atm to post any, but a quick google search will point to articles from Anandtech, HardOCP, and Tomshardware showing that GPUs are often more energy efficient.

[roozhou]

I think leeperry already posted some links about power consumption in CPUs vs GPUs a while back. I'm too lazy atm to post any, but a quick google search will point to articles from Anandtech, HardOCP, and Tomshardware showing that GPUs are often more energy efficient.

Modern dual-core CPU consumes ~40W more at fully loaded compared to idle. Suppose your CPU are nearly fully loaded when decoding by software and you watch HD movies on your PC for 2 hours each day, so that's 365x2x0.04 = 29.2 kWh more power each year.

I know that price of electricity varies in different countries. In my country it's ~$0.1 during daytime and ~$0.05 during night. I don't care about saving $1.5~$3 each year.

[IgorC]

I think leeperry already posted some links about power consumption in CPUs vs GPUs a while back. I'm too lazy atm to post any, but a quick google search will point to articles from Anandtech, HardOCP, and Tomshardware showing that GPUs are often more energy efficient.
GPU aceleration can be more power efficient but the question if it's far more efficient like leeperry said.

I found this http://www.anandtech.com/printarticle.aspx?i=2977.
The difference is ~9-10 watts? That's all?
It's an old article but CPU( with software decoders) and GPU increased its efficiencies at the same time.

All GPU's power efficiency will vanish if take into account that CPU+GPU consume more than CPU+integrated graphics.

Main advantage of GPU acceleration isn't efficiency but almost complete offload of CPU during video playback.

[Mixer73]

Main advantage of GPU acceleration isn't efficiency but almost complete offload of CPU during video playback.

I can't tell you power usage wise but my MCE rig has a passively cooled 8400GS card and with CUDA running I noticed significantly lower fan noise from the rig, and that was enough for me to spend the $20!

I suspect with less heat comes less electricity usage but I can't quantify it.

[leeperry]

Can you provide tested results?
I will! a friend of mine has a wattmeter, I will visit him anytime soon. and I'm surprised CoreCodec didn't boast about it, as this is the major selling point for CoreAVC at this point IMHO.

Well the CPU load falls to 4% on my Q9450 w/ 1080p AVC, and my GF9600 temperature/load hardly moves as well...CoreAVC connects to VP2, and from what I'm seeing it doesn't need much power at all, but I'll come back w/ hard proofs ;)

[BetaBoy]

I will! a friend of mine has a wattmeter, I will visit him anytime soon. and I'm surprised CoreCodec didn't boast about it, as this is the major selling point for CoreAVC at this point IMHO.

Well the CPU load falls to 4% on my Q9450 w/ 1080p AVC, and my GF9600 temperature/load hardly moves as well...CoreAVC connects to VP2, and from what I'm seeing it doesn't need much power at all, but I'll come back w/ hard proofs ;)

We just started to push power savings with 2.0 with the help of NVIDIA, especially with Netbooks. In fact now that we have added ARM NEON Cortex A8 support to the CoreAVC SDK it helps there as well (for the platforms that support it).

STaRGaZeR..... while we thank you for your opinion. Please add value to this thread, jumping in like you have is more like a flame to most of us. Squid is very passionate and proud of our work here. True he also represents CC, but he has nothing to do with business, of which we are doing quite well, thank you very much.

Lets keep the discussion focused on the product.

[CruNcher]

BetaBoy still no go for CorePlayer for Android ? ;) though i guess with all the Hardware functions on most mobiles it makes less sense but for those ones that havent any it seems a option currently i only see the Korean company of Mobilesoft doing work here with their Yxflash it's not that bad for ASP but they seem to lack H.264 experience ;) Porting mplayer to it with neon support for sure will come sooner then later also same for Maemo.
Also i did power consumption tests between CoreAVC (on AMD Athlon 64 Toledo Dualcore @ 3 Ghz) efficiency and the 8800 GT and it's VP2 Core Decoder the result wasn't that mayor difference i mean sure the Decoder Core alone is very efficient it was around 1 Watt and CoreAVC around 3 Watt for the same result and that on this old CPU, but if you add the overall power from the card itself to this then the difference becomes less in overall consumption of the system as the GFX board itself eats major amounts in idle. :) ( if i dont remember wrong i even posted the results on doom9 search for it)

[BetaBoy]

BetaBoy still no go for CorePlayer for Android ? ;) though i guess with all the Hardware functions on most mobiles it makes less sense but for those ones that havent any it seems a option currently i only see the Korean company of Mobilesoft doing work here with their Yxflash it's not that bad for ASP but they seem to lack H.264 experience ;) Porting mplayer to it with neon support for sure will come sooner then later also same for Maemo.

The Android SDK and NDK still need a lot of work to be able to run an app in 'true' native space. The advantage we have now with CorePlayer is that everything is API driven. So once they get the *DK's up to speed, we are ready to go.

FYI.. there are other issues as well (renderering, audio input, etc.), but if they fix the native space issues we can at least move forward.

We are on ASP, AAC and MP3 for ARM NEON next.

[leeperry]

We just started to push power savings with 2.0 with the help of NVIDIA, especially with Netbooks.
got any benchmarks made w/ a wattmeter on say a Q6600/GF9600? software Vs CUDA...every watt counts, and electricity bill saving might be on your best thing to boast about...as the other decoders start climbing up your leg software decoding speed-wise :devil:

[Cyber-Mav]

i have to say that for nvidia users with a cuda capable vpu2+ card coreavc is a must have piece of software. on my older machines with cuda cards i can watch full 1080p videos and surf the net etc with plenty power left for multi-tasking. these days i encode everything into h.264 just so that i can use hardware accelerated playback thanks to coreavc's cuda implementation,

i know i can use media player classic home cinema do get free dxva decoding done but coreavc's cuda playback is far more robust and so far only 1 video refused to playback with cuda because it had like 17 reference frames.

for me the money has been well worth it for coreavc, sure there are couple of other hardware based video decoders out there now but none do as good a job as coreavc;s cuda implementation does.


also let me add to this, i replaced the graphics card in a DJ's video server, the card he used as a x1900xt and i replaced it with a nvidia GT240, with coreavc he now had cuda acceleration available even inside his Video Jockey software, i believe he uses something arkaos grand vj. multiple h264 files bring up multible coreavc gree icons in the system tray and this frees up cpu power for additional effects and processing. the DJ is elite-syndicate http://www.elite-s.co.uk/

we are highly impressed with coreavc's cuda support and i recommend it to everyone who uses a cuda capable card and wants to free up cpu cycles for other stuff.

[pankov]

I too support Cyber-Mav's opinion.
For non-english native speakers subtitles are very important and the only way to get them in DirectShow player and still have hardware acceleration is through Cuda. It's also the case with non DX capable renderer like madVR, which is still in beta/alpha stages but still gives the best picture quality out there.
On one of my PCs I use NVidia and really like the way that everything plays. Sadly on my main HTPC I'm with ATI and I really miss Cuda.
I hope ATI will do something in the near future so the Core team and many users can benefit from their hardware too.

[roozhou]

Ithe only way to get them in DirectShow player and still have hardware acceleration is through Cuda.

Try KMPlayer and PotPlayer.

[pankov]

roozhou,
I'm using ZoomPlayer and all the family is familiar with it - that's the reason I'd prefer not to change player.

[88keyz]

The biggest downfall of the CUDA support for an HTPC is nVidia's appalling Sleep/Hibernate/Hybrid Sleep support. I love my nVidia GPU's but I had to switch to ATI on my HTPC to solve my sleep resume problems. Went from a 8600 GT to a ATI 2600 PRO and all problems with sleep were solved.

Thankfully due to CoreAVC also being the best and fastest software h.264 decoder I have noticed almost no performance difference when playing back either 720p or 1080p MKV files on my HTPC with a Q6700.

Here's hoping that someday ATI allows access to the core in the same way nVidia does so that we can have ATI Stream accelerated content the same as we do CUDA accelerated content now.

[Shakey_Jake33]

Daft question - for someone who only intends to use GPU acceleration, what are the advantages of CoreAVC 2.0 over 1.9.5? It's essentially just accessing capabilities that exist on the GPU anyway right?

[weasel_]

in 2.0 NO more bug with 16 ref frame ...

[an3k]

If you don't have GPU support (no CUDA), CyberLink PowerDVD 7 codec is much faster than CoreAVC 2.0 Professional.
If you have GPU support, CoreAVC is a bit faster, a bit.

[Blue_MiSfit]

I doubt very much that Cyberlink's PowerDVD 7 H.264 decoder is faster than CoreAVC. This would be big news to everyone here...

AFAIK, the fastest software only decoders are CoreAVC, DiAVC, and DivX H.264, followed by ffmpeg-mt (and not necessarily in that order).

~MiSfit

[LoRd_MuldeR]

AFAIK, the fastest software only decoders are CoreAVC, DiAVC, and DivX H.264, followed by ffmpeg-mt (and not necessarily in that order).

This agrees with my personal tests and all I have read. However an specific CPU's the results may be different...

[roozhou]

I doubt very much that Cyberlink's PowerDVD 7 H.264 decoder is faster than CoreAVC. This would be big news to everyone here...

PDVD 7 decoder supports DXVA, including partial acceleration. It will give you hardware acceleration on ATI cards and NV 6/7 series, while CoreAVC does that only on NV 8+ series.

[Blue_MiSfit]

Partial acceleration is interesting for some folks indeed. I wonder if my Quadro NVS 110M (basically a Go 7300) would get any benefit from this? As it is, I have to use VMR7 and CoreAVC on Windows 7 (not sure why this is actually faster than native EVR) to get reasonable performance on <10mbps 1080p content, and even so there are some dropped frames. A 1.8 GHz Core 2 Duo is pretty slow when it comes down to it - at least, compared to my overclocked 3.4 GHz Q6600 in my desktop!

Do any other decoders offer partial decode acceleration? Maybe the Microsoft decoders in Windows 7?

Is it possible to use the PowerDVD filters if you have only the trial installed?

~MiSfit

[an3k]

PDVD 7 decoder supports DXVA, including partial acceleration. It will give you hardware acceleration on ATI cards and NV 6/7 series, while CoreAVC does that only on NV 8+ series.

I tested CoreAVC 2.0 Pro and CyberLink PDVD7.3 H.264 codec on a P4 3,73GHz Extreme Edition with GeForce 7800GTX (VP1).

I cannot watch a 1080p with CoreAVC (slideshow). I can watch the same file with CyberLink codec (not 100% smooth but nbot a slideshow anymore).

On my GTX295 CoreAVC is faster, a bit.

As i said :)

Is it possible to use the PowerDVD filters if you have only the trial installed?They blocked other applications from using the codec since PDVD7.3 but PDVD7.0 codec is usable.

[Blue_MiSfit]

Interesting.

Your setup is quite unusual among BluRay watchers, AFAIK. A high clock but still slow by modern standards (and single core, at that) P4, and a VP1 7800GTX! You had one mean machine back in '05 huh? ;)

I'll have to try Cyberlink on my laptop! Partial DXVA may very well be a lifesaver!

[an3k]

Interesting.

Your setup is quite unusual among BluRay watchers, AFAIK. A high clock but still slow by modern standards (and single core, at that) P4, and a VP1 7800GTX! You had one mean machine back in '05 huh? ;)

I'll have to try Cyberlink on my laptop! Partial DXVA may very well be a lifesaver!

Hehe, yeah. Was a great machine years ago ;) In meantime i replaced the motherboard, PSU, RAM, etc. except CPU and GFX. Its my "not fully upgraded" computer. Tomorrow i get my GT240 with VP4.1, CPU gets upgraded next month. It has a BluRay drive but i only use it to rip these, not to watch. Using my PS3 for that, best BD/DVD-Player afaik (BD-Live, great SD-upscaling).
This computer here has a Q9650 and a GTX295 :)

[Weirdo]

Thanks for the excellent 2.0 version. :)
Was wondering if you still have plans for CoreWMV?

[JohnnyFu]

I wonder when Haali is going to fix the .m2ts/VC-1 issue on his splitter?

[leeperry]

Was wondering if you still have plans for CoreWMV?
yeah, that'd be cool! w/ CUDA and stuff possibly? not sure VP2 does VC1, though.
I wonder when Haali is going to fix the .m2ts/VC-1 issue on his splitter?
"when" or "if"? ;)

[BetaBoy]

What a great CES, the best in years. Thank you to all those who met with us and we got to preview many of our technologies and upcoming releases. We are just as excited to share with you what we have been working on for the past few years.

So... I guess many of you guessed this day was coming.... We will shortly begin to test DXVA in CoreAVC (and CorePlayer). Anyone intrested in helping us test, pls send an email to: info@corecodec.com with your system configuration. We will only email back those who's configurations meet our needs for testing.

TIA

[roozhou]

So... I guess many of you guessed this day was coming.... We will shortly begin to test DXVA in CoreAVC (and CorePlayer). Anyone intrested in helping us test, pls send an email to: info@corecodec.com with your system configuration. We will only email back those who's configurations meet our needs for testing.
TIA

Great news, Betaboy!
Will CoreAVC support partial acceleration? Since we have plenty of free DXVA solutions(mpc-hc, ffdshow), I will not be interested in CoreAVC DXVA if it only supports vld level acceleration.

[an3k]

yeah, that'd be cool! w/ CUDA and stuff possibly? not sure VP2 does VC1, though.

"when" or "if"? ;)

VP2 cannot handle VC-1 completely! It is GPU accelerated but depends on the source.
If you want full GPU support, get a Gainward GT240 Golden Sample (1GB GDDR5 RAM). This card costs around 80 euro and supports VP5 which supports full MPEG2, MPEG4 ASP, MPEG4 AVC, MPEG4 AVC-MVP and VC-1.

[BetaBoy]

Great news, Betaboy!
Will CoreAVC support partial acceleration? Since we have plenty of free DXVA solutions(mpc-hc, ffdshow), I will not be interested in CoreAVC DXVA if it only supports vld level acceleration.

I'll save any comments for now on how we are adding DXVA as we will have some suprises to announce related to it when the time us right.

[Guest]

VP2 cannot handle VC-1 completely! Please explain further and cite your source for this claim.

I have no problems with any VC1 using my VP2 engine cards.

[an3k]

Please explain further and cite your source for this claim.

I have no problems with any VC1 using my VP2 engine cards.

http://en.wikipedia.org/wiki/Nvidia_PureVideo#The_Second_Generation_PureVideo_HD and http://www.nvidia.com/docs/CP/11036/PureVideo_Product_Comparison.pdf

[nm]

Please explain further and cite your source for this claim.

I have no problems with any VC1 using my VP2 engine cards.
Perhaps an3k meant that VP2 doesn't support full decoding of VC-1 and MPEG-2 on hardware. Bitstream decoding is done on CPU (within the driver or NVCUVID). It works, but will cause a bit higher CPU load than complete offloading.

AFAIK, the most accurate official documentation on decoding capabilities of all NVIDIA GPUs is in the Linux/Unix driver manual:
http://http.download.nvidia.com/XFree86/Linux-x86_64/195.30/README/vdpausupport.html#vdpau-implementation-limits-decoder

[me7]

So... I guess many of you guessed this day was coming.... We will shortly begin to test DXVA in CoreAVC (and CorePlayer).

Does/Will your implementation support additional filters after the decoder, like subtitle filters (if this is even possible)?

[Keiyakusha]

Perhaps an3k meant that VP2 doesn't support full decoding of VC-1
I don't know how exactly things works, but maybe its DXVA not supports VC-1 with VP2 engine (some limitations or something)? Because with CUDA VP2 can decode VC-1. Or you saying that it falls back to CPU decoding without notifying?

[nm]

I don't know how exactly things works, but maybe its DXVA not supports VC-1 with VP2 engine (some limitations or something)?

DXVA does support partial decoding (IDCT and motion compensation) that VP2 provides for VC-1. However, in this case the DXVA codec must do bitstream decoding by itself, and this is not currently supported by the open-source filters in MPC-HC and ffdshow:

http://mpc-hc.sourceforge.net/DXVASupport.html
Unfortunately the MPC-HC decoder only supports the "bitstream mode" at this stage, which means that only the most recent graphic cards are supported :

nVidia series 8(9)xxx for H.264 only (*)
ATI Radeon HD series for H.264 and VC-1 decoding

"Motion compensation" mode might be added in the future to increase compatibility with older graphic cards, but I cannot promise anything. Mpeg2 and WMV accelerations are not supported either.

(*) Except for VP3 GPUs in this series that do support full VC-1 offloading

NVCUVID and VDPAU take care of bitstream decoding internally, so the application doesn't need to do it.

[Weirdo]

It is safe to assume then, that VP3-5 Nvidia cards can also provide VC-1 DXVA acceleration (mpc-only, at the moment)?

[LoRd_MuldeR]

Please explain further and cite your source for this claim.

I have no problems with any VC1 using my VP2 engine cards.

According to Wiki:

The Second Generation PureVideo HD
VC-1 acceleration was also improved, with PureVideo HD now able to offload more of VC-1-decoding pipeline's backend (inverse discrete cosine transform (iDCT) and motion compensation stages). The frontend (bitstream) pipeline is still decoded by the host CPU. [...] The second generation PureVideo HD is sometimes called "PureVideo HD 2" or VP2, although this is not an official NVIDIA designation.

The Third Generation PureVideo HD
This implementation of PureVideo HD, VP3 added entropy hardware to offload VC-1 bitstream decoding with the G98 GPU (sold as GeForce 8400GS), as well as additional minor enhancements for the MPEG-2 decoding block. The functionality of the H.264-decoding pipeline was left unchanged. In essence, VP3 offers complete hardware-decoding for all 3 video codecs of the Bluray-Disc format: MPEG-2, VC-1, and H264.

The Fourth Generation PureVideo HD
This implementation of PureVideo HD, VP4 added hardware to offload MPEG-4 (Advanced) Simple Profile bitstream decoding with the GT216 & GT218 GPUs (sold as GeForce GT 220 & GeForce 210/G210) & GT215 GPU (sold as the GeForce GT 240) in addition to formats supported in previous VP3 implementation, as well as an additional high quality scaler. The functionality of the H.264-decoding pipeline was left mostly unchanged but no longer have the limitations of the VP3 implementation.

[BetaBoy]

Does/Will your implementation support additional filters after the decoder, like subtitle filters (if this is even possible)?

No, in fact when DXVA is enabled, it disables the CoreAVC options in the configuration panel that are not available via DXVA.

[tormento]

Is it possible to use CoreAVC to hw accelerate playing of .mts files created from Sony HD camcorders? They use an AVC1 encoding and they are currently well supported by ffdshow.

P.S: I have tried win7dsfiltertweaker_2.7 and Coreavc is listed under h.264 codecs only.

[an3k]

Is it possible to use CoreAVC to hw accelerate playing of .mts files created from Sony HD camcorders? They use an AVC1 encoding and they are currently well supported by ffdshow.

P.S: I have tried win7dsfiltertweaker_2.7 and Coreavc is listed under h.264 codecs only.

Can you open such a file in GSpot (or if this app doesn't show any or enough information in other information tools like DGIndexNV). It really depends on the codec used if CoreAVC can handle your files.

CoreAVC 2.0.0 can handle the FourCCs listed on the left side.
http://img200.imageshack.us/img200/1549/coreavc200.png

You can send me a short file and i'll try if it works.

[tormento]

[QUOTE=an3k;1362986You can send me a short file and i'll try if it works.[/QUOTE]

The file is a .mts sony cam one ;)

The preview in DGIndex gives:

http://img689.imageshack.us/img689/6665/catturaad.png (http://img689.imageshack.us/i/catturaad.png/)

[an3k]

The file is a .mts sony cam one ;)

The preview in DGIndex gives:

http://img689.imageshack.us/img689/6665/catturaad.png (http://img689.imageshack.us/i/catturaad.png/)

Yes, CoreAVC can handle that but since the Haali Splitter has many problems you should NOT demux the file!!

I have two files here. One video.264 (rip from BluRay) and one audio.dts (rip from the same BluRay). If i try to play the video.264 it doesn't work. If i try to play the audio.dts it doesnt work.
If i mux both files to m2ts (same format as your files) i can play the files.

@ Haali: Fix your software please!

[an3k]

The following shows file information of video.264 which cannot played back cause of haali:
http://img694.imageshack.us/img694/7272/haalicannot.png

The following shows file information of video.264.m2ts which can played back cause of haali:

http://img94.imageshack.us/img94/3659/haalican.png

[sneaker_ger]

Since when did Haali claim to support elementary streams? It's a splitter for the following containers: Matroska, MP4, AVI, OGG/OGM, MPEG TS/PS. It's not a bug that you can't open your demuxed streams using Haali's splitter.

[an3k]

Since when did Haali claim to support elementary streams? It's a splitter for the following containers: Matroska, MP4, AVI, OGG/OGM, MPEG TS/PS. It's not a bug that you can't open your demuxed streams using Haali's splitter.

So Haali only splits the source and ignores eveything else even if its less work?

Can then someone please build a splitter which is useful? Its kinda annoying to install 20 splitters just because everyone is only supporting a small range.
Isn't playing back an elementary stream easier than a muxed file? Can't the splitter just forward the elementary stream to the decoder without splitting?!

[sneaker_ger]

Yes, it only splits the listed containers. And opening and seeking within raw h.264 files isn't trivial - that's why you are indexing them with DGIndex before loading them into AviSynth.

[an3k]

Yes, it only splits the listed containers. And opening and seeking within raw h.264 files isn't trivial - that's why you are indexing them with DGIndex before loading them into AviSynth.

I understand that but why isn't it a problem opening and seeking an elementary MPEG2?
I also can do that with MPEG2 HD content!

[tormento]

So, any idea about having CoreAVC read AVC transport files?

[sneaker_ger]

I understand that but why isn't it a problem opening and seeking an elementary MPEG2?
I also can do that with MPEG2 HD content!

Open an elementary stream with MPC/VLC or whatever your using, seek to a scene in the middle and note the timing and the total length of the stream. Now open the same stream muxed or indexed and try to seek to the same timing. You will see a different scene and the total stream duration will also be displayed totally different.

[clsid]

Is it possible to use CoreAVC to hw accelerate playing of .mts files created from Sony HD camcorders? They use an AVC1 encoding and they are currently well supported by ffdshow.

P.S: I have tried win7dsfiltertweaker_2.7 and Coreavc is listed under h.264 codecs only.
The H.264 option in the tool sets the preferred decoder for both H264 and AVC1 mediatype.

[an3k]

Open an elementary stream with MPC/VLC or whatever your using, seek to a scene in the middle and note the timing and the total length of the stream. Now open the same stream muxed or indexed and try to seek to the same timing. You will see a different scene and the total stream duration will also be displayed totally different.

Yeah but i can playback the file and that's what i want. If i buy a decoder i want to be able to playback every source the decoder can handle and not only the containers a free 3rd party splitter is able to.

@CoreCodec: nVIDIA sells "nVIDIA PureVideo Decoder" which is a "Windows Media Player Plugin" to playback DVDs on PC. CyberLink sells the same type of software.
How about a "BluRay/HD-DVD Plugin"? Currently there is no company selling such software.

The "Plugins" are intended for the use in Windows Media Center (but also works in Windows Media Player).

[tormento]

The H.264 option in the tool sets the preferred decoder for both H264 and AVC1 mediatype.

So, why isnt'it working to decode avc?

[JohnnyFu]

How about a "BluRay/HD-DVD Plugin"? Currently there is no company selling such software.

Arcsoft sells a BluRay plugin for 7MC/WMP (Total Media Theatre 3 Platinum). Works fine for me on 7MC + MediaBrowser.

[me7]

Yeah but i can playback the file and that's what i want. If i buy a decoder i want to be able to playback every source the decoder can handle and not only the containers a free 3rd party splitter is able to.

The definition of a decoder is that it decodes files. Period.
You seem to demand an all-in-one solution like VLC player but CoreCodec never claimed CoreAVC to be anything like that. Fact is that CoreAVC can perfectly decode that stream as long as it gets the stream passed to it. Doing that is not its responsability.

[clsid]

So, why isnt'it working to decode avc?Possibly because the player isn't using DirectShow.

[tormento]

Possibly because the player isn't using DirectShow.

Media player classic hc? ;) Sure?

[clsid]

MPC ignores the preferred filter settings of Windows 7 because it uses its own graph builder. It will simply use the decoder with the highest merit. Add CoreAVC as a preferred external filter in MPC settings. Then it will be given the highest possible merit.

But I suspect that CoreAVC isn't used because you have the internal H.264 decoders enabled in MPC.

[tormento]

MPC ignores the preferred filter settings of Windows 7 because it uses its own graph builder. It will simply use the decoder with the highest merit. Add CoreAVC as a preferred external filter in MPC settings. Then it will be given the highest possible merit.

But I suspect that CoreAVC isn't used because you have the internal H.264 decoders enabled in MPC.

Everything is disabled in mpc, both source and decoder.

I use it as a dumb media player, feeding it with ffdshow+haali+coreavc.

[XadoX]

Somehow CoreAVC does not active CUDA in Media Portal. While playing my FullHD-MKVs with Microsoft Media Player CUDA is activated.

[7oby]

I just recognized that the CoreAVC Professional 2.0.0.0 Codec is on sale for US$ 9.95 instead of US$ 12.95 till 1/17 (= today).

Although I don't really require that codec, I really like the way CoreAVC provides support for its product in this community forum. And that's why I just bought it.

I would appreciate if other companies would follow this way of supporting their products.

:thanks:

[BetaBoy]

I just recognized that the CoreAVC Professional 2.0.0.0 Codec is on sale for US$ 9.95 instead of US$ 12.95 till 1/17 (= today).

Although I don't really require that codec, I really like the way CoreAVC provides support for its product in this community forum. And that's why I just bought it.

I would appreciate if other companies would follow this way of supporting their products.

:thanks:
Thank you for the support. Starting with CoreAVC 2.0 the new customer portal is the first step for us to better help our customers help themselves.

The same will be said for CorePlayer 2.x and its various other related products (CorePlayer API, CorePlayer Embedded, CorePlayer TV, etc.) as 2.0 is more like a hybrid of Pandora Vs. Boxee Vs. iTunes with its login and back end systems.

[imk]

BetaBoy, is it possible for you to detect 1080p60 content and disable CUDA automatically?

I have some 1080p60 video game clips I record and they play perfectly with software decoding, but with CUDA enabled it plays for a couple seconds, then pauses for 3 seconds, then plays a couple seconds, repeat, etc.

It would just be nice if CUDA would automatically be used for everything else, and just automatically deactivate if it detects 1080p60 (and probably anything else it can't handle).

[CruNcher]

BetaBoy, is it possible for you to detect 1080p60 content and disable CUDA automatically?

I have some 1080p60 video game clips I record and they play perfectly with software decoding, but with CUDA enabled it plays for a couple seconds, then pauses for 3 seconds, then plays a couple seconds, repeat, etc.

It would just be nice if CUDA would automatically be used for everything else, and just automatically deactivate if it detects 1080p60 (and probably anything else it can't handle).

Try direct DXVA decoding CoreAVC CUDA needs a lot of Power the higher the resolution and fps when copying back the frames into memory on slow systems you might not gain the same FPS as the source anymore :(
Betaboy wouldn't it be possible to implement 2 CUDA modes one with the copy back to system memory for manipulation and one without you could call them advanced/fastest ;) ?

[CruNcher]

@BetaBoy
i looked more closely into these CoreAVC 2.0 CUDA(VP2) performance issues this time with the new WHQL Driver from today and i found out that you can higher the Performance @ Decoding by using a different Output color space though to my surprise the Performance of NV12 lowers even more compared to YV12 and I420/UYVY/RGB32/YUY2 also RGB32 seems to be faster then NV12 :)
And this opens the question shouldn't be NV12 give much better Performance and not the worst with CUDA(VP2) or is it just that the Conversion in CoreAVC 2.0 isn't optimized for Athlon 64 like I420 ?

CUDA(VP2): (VMR7)

UYVY = 47 FPS
I420 = 47 FPS
YUY2 = 46 FPS
RGB32 = 41 FPS
YV12 = 38 FPS
NV12 = 20 FPS

Very strange somehow ?

Without CUDA(VP2) and I420/UYVY/RGB32/YUY2 i can reach Realtime now @ Playback :) for this 1080p 60 FPS Level 4.1 PS3 Encode same as with VP2 directly via DXVA MPC-HC (no memory copy)

[BetaBoy]

CruNcher... something does not look right there. We are looking into it.

[tormento]

So, BetaBoy, how should I obtain AVC decoding?

[DigitalDeviant]

Is there a trial version yet?

[squid_80]

So, BetaBoy, how should I obtain AVC decoding?

Have you posted a sample of the files you can't play?

[BetaBoy]

tormento... maybe you are trying to play a non mkv based AVC file? If so try renaming the .mp4, .avi, etc. to .mkv and see if it plays.

[BetaBoy]

Is there a trial version yet?

We are still working on our trial module in the customer portal that will handle all our trial software. Its turned into a bigger project then expected as we are also doing work for our upcoming CorePlayer 2.0 and TV platform releases.

[puffpio]

BetaBoy..
I experience a bug where the video decode jumps to 100% CPU and frame rates drop to single digits..its not skipping frames to the audio desyncs and sometimes even starts stuttereing..eventually it clears up and the video plays faster than realtime to catch up to the audio.

I want to solve this issue, is it the codec? the renderer? the video card?
i'm on a core2duo 2ghz laptop w/ integrated video (intel G45) driving a 1920x1200 external display.
windows 7 64 bit, but using 32 bit mpc-hc (latest builds from xvidvideo.ru), 32 bit coreavc and haali media splitter..mpc-hc is set to use the haali renderer.

if i play a video using ffdshow/ffmpeg-mt as the codec, it wont do this behavior....granted it uses more cpu than coreavc..but it doesn't have these slowdown/stuttering moments..

how can i help to debug and isolate the cause of this so that your developers can fix it in a future release?

[squid_80]

Is it reliably reproduceable (happens at the same place every time in the same streams) or does it happen at random?
Can you make it happen when the laptop is connected to AC power or does it only happen on battery?
Does it happen with other renderers?

[ChronoCross]

The only weird thing I've noticed as of late is in regards to seeking. Sometimes when I seek forward or backward it emits a black screen for 5-6 seconds before restoring video. This may well be my POS machine but I wanted to see if anyone else is having anything similar.

[Abradoks]

CoreAVC doesn't respect AR when it's specified only in MKV header, but not in the stream. With Haali splitter it works fine, because afaik it overwrites stream AR with one from the header. But it doesn't work with Gabest's splitter. Other decoders (ffdshow, DiAVC) treat this flag correctly.
I've looked for workaround, but haven't found even description of such problem. So, is it known?

[puffpio]

Is it reliably reproduceable (happens at the same place every time in the same streams) or does it happen at random?
Can you make it happen when the laptop is connected to AC power or does it only happen on battery?
Does it happen with other renderers?

It is not reliably reproducible..it repeatedly happens, but in different spots if i replay the video.

I am on AC power when it happens, I have not tried on battery.

It also happens with the EVR custom renderer..but I don't really use that one since it is very slow for me (since it uses shaders and I don't really have a 3d graphics card)

[horvathd]

Hi!

I'm trying to encoding a video which has a dark/gray background and dimming lights using x264. When I play back the result with CoreCodec (2.0.0) it is blocky around the lights, but no problem with ffdshow.

Because of rules I don't want to post the video, so I made a small Avisynth script which also produces this bug. You can download the source avs, images, and the encoded video from here: http://www.mediafire.com/?zywom5j0dmk

I used for the encoding of ccbug_wp2 the x264-s default settings. For ccbug_wp0 I disabled the weighted p frames, but it didn't fixed the problem.

Please look into it. Thanks.

[squid_80]

I can't really see anything wrong when playing the clips in ccbug.zip. Could you post a screenshot of the problem?

[horvathd]

I got this:
http://i524.photobucket.com/albums/cc329/davhorv112/Misc/th_ccbug_wp2mkv_snapshot_0005_20100204.jpg (http://s524.photobucket.com/albums/cc329/davhorv112/Misc/?action=view&current=ccbug_wp2mkv_snapshot_0005_20100204.jpg)

[squid_80]

I think you have deblocking disabled. Make sure it is set to "Standard" in CoreAVC's settings.

[horvathd]

You're right. It was disabled.
I only use CoreCodec when ffdshow can't play the video because of it's resolution, and for the smoother playback I disabled it.

Thanks.

[Jiffy]

Hi,

Can we have a fix for the weightp problem for CoreAVC 1.x please? It doesn't seem reasonable that people must buy a new version to get the fix.

Thanks.

[LoRd_MuldeR]

Can we have a fix for the weightp problem for CoreAVC 1.x please? It doesn't seem reasonable that people must buy a new version to get the fix.

Very unlikely. Their answer to the "Weight-P" bug always was that it will be fixed in the upcoming 2.0 version. And 2.0 is out now ;)

[Jiffy]

Their answer to the "Weight-P" bug always was that it will be fixed in the upcoming 2.0 version. And 2.0 is out now ;)

Yes but if you sell something it has to be fit for purpose, which means that showstopper bugs are supposed to be fixed on your dime.

[LoRd_MuldeR]

Yes but if you sell something it has to be fit for purpose, which means that showstopper bugs are supposed to be fixed on your dime.

Sorry to disappoint you, but the licenses under which software products are sold generally contain a clause like "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE". So if their lawyers didn't fail miserably, they aren't obligated to fix anything! Furthermore commercial software developers have a complex release cycle. They usually invest a lot of manpower into QA (quality assurance) before they release a product. But once the product has passed QA and is released to market, it won't be developed actively anymore. In particular they won't waste resources (money) for adding new features into a "legacy" product. Instead they move on and put their efforts into the next major release. Maybe for you the lack of Weight-P support is a showstopper, but for them Weight-P support simply was never on the feature list for the 1.9.x release. It has been announced for version 2.0 and there it is. Mission completed...

Anyway, if you aren't willing to buy CoreAVC 2.0 for proper Weight-P support, there are various alternatives. Both, FFmpeg-MT and DivX H.264 Decoder, are available for free ;)

[Disabled]

the licenses under which software products are sold generally
I remember CoreAVC 1.x not being sold under ANY specific license, because they thought licenses are useless anyway.
That being said, they sold a "High Profile decoder", but didn't sell a decoder that support the full high profile. Everybody has their way to trick the customers... Just go with Divx, ffdshow or wait for DiAVC (or use the free beta), unless you need cuda support, then youre out of luck.

[LoRd_MuldeR]

...unless you need cuda support, then youre out of luck.

As soon as "CUDA decoding" is enabled, CoreAVC 1.9.5 will handle Weight-P perfectly fine. That's because the VP2 chip on your graphics board will take over the decoding in that case.

[Keiyakusha]

There is no trial version yet?

[Fadeout]

It only means there's space for competition.

Support for Weight-P is basically the only noticeable feature of CoreAVC 2.0

[Disabled]

Support for Weight-P is basically the only noticeable feature of CoreAVC 2.0
And of course closing the gap to the competition speed wise in software mode.

[Jiffy]

I remember CoreAVC 1.x not being sold under ANY specific license, because they thought licenses are useless anyway.
That being said, they sold a "High Profile decoder", but didn't sell a decoder that support the full high profile. Everybody has their way to trick the customers... Just go with Divx, ffdshow or wait for DiAVC (or use the free beta), unless you need cuda support, then youre out of luck.

Thanks, that's good information.

[Jiffy]

Sorry to disappoint you, but the licenses under which software products are sold generally contain a clause...

Did this one? It sounds like it didn't.

Furthermore commercial software developers have a complex release cycle. They usually invest a lot of manpower into QA (quality assurance) before they release a product. But once the product has passed QA and is released to market, it won't be developed actively anymore. In particular they won't waste resources (money) for adding new features into a "legacy" product. Instead they move on and put their efforts into the next major release.

Yes I'm a developer myself. Most comanpies have a disclaimer but they still make every effort to ensure that the software does work to a reasonable level, and provide bug fixes when it doesn't.

Anyway they don't need to put resources into the old branch. 1.9.6 could be a build of 2.0 with the new features disabled.

Maybe for you the lack of Weight-P support is a showstopper, but for them Weight-P support simply was never on the feature list for the 1.9.x release. It has been announced for version 2.0 and there it is. Mission completed...

It's not an optional feature. There wasn't any way to know in advance that this hadn't been implemented and a lot of people wouldn't have bought it if they had known.

Anyway, if you aren't willing to buy CoreAVC 2.0 for proper Weight-P support, there are various alternatives. Both, FFmpeg-MT and DivX H.264 Decoder, are available for free ;)

Hopefully they'll decide they've made a mistake and put things right.

[ChronoCross]

Did this one? It sounds like it didn't.


They do.



Yes I'm a developer myself. Most comanpies have a disclaimer but they still make every effort to ensure that the software does work to a reasonable level, and provide bug fixes when it doesn't.

Anyway they don't need to put resources into the old branch. 1.9.6 could be a build of 2.0 with the new features disabled.


Wasted time and effort. It's not as simple as "turning off features" as corecodec improved the primary design of the entire codec.


It's not an optional feature. There wasn't any way to know in advance that this hadn't been implemented and a lot of people wouldn't have bought it if they had known.


I doubt you knew that weight-p existed when you bought it. Sorry but it's highly unlikely that this feature that only x264 supports was even a glimmer in your mind when you purchased coreavc.


Hopefully they'll decide they've made a mistake and put things right.

They haven't made a mistake so there isn't really anything to correct. Just spend the $10 to upgrade or use a free codec and stop polluting this thread with useless drivel.

[Disabled]

I doubt you knew that weight-p existed when you bought it.
All I know is I bought a high profile decoder... do I have to know what features are in high profile?

But youre right, they won't implement it, lesson learned.

[Jiffy]

I doubt you knew that weight-p existed when you bought it.
Yes that was the point: "never on the feature list" huh? who knew they needed it?

Just spend the $10 to upgrade
And then again, and again. Forget it, I'd much rather work on making a faster open source codec.


stop polluting this thread with useless drivel.
whatever.

[ChronoCross]

All I know is I bought a high profile decoder... do I have to know what features are in high profile?

But youre right, they won't implement it, lesson learned.

Weighted prediction is not a requirement for high profile support.

Yes that was the point: "never on the feature list" huh? who knew they needed it?


Correct. Nowhere did you read "supports every feature of the h264 spec".


And then again, and again. Forget it, I'd much rather work on making a faster open source codec.
whatever.

Most people who say this are all talk. I have a feeling your exactly the same.

[sneaker_ger]

Weighted prediction is not a requirement for high profile support.

Not? Can you back that up?

[ChronoCross]

Not? Can you back that up?

Yes. It's usable in main profile or higher. Additionally it is not a requirement to claim support for either main or high profiles as x264 has supported both profiles for encoding for years while weight-p has only been around since last summer. Basically disabling weight-p does not take away the fact that a stream is either main or high profile.

[sneaker_ger]

Yes. It's usable in main profile or higher. Additionally it is not a requirement to claim support for either main or high profiles as x264 has supported both profiles for encoding for years while weight-p has only been around since last summer. Basically disabling weight-p does not take away the fact that a stream is either main or high profile.

Ah, ok, I agree. You're looking from an encoder side of view, while I was thinking about the decoder side of view (i.e. decoders claiming to feature h.264 high profile should be able to decode all high profile streams IMHO. Although this way of saying it could still lead to different interpretations.)

[Stephen R. Savage]

ChronoCross' statement is revisionist ***. By that logic, I could sell a decoder as having "FULL HIGH PROFILE SUPPORT" when it can only play streams of 320x240 with 1 reference frame, 0 bframes, and a VBV constraint of 400 kbps. After all, such a stream would still be High Profile!

[ChronoCross]

ChronoCross' statement is revisionist ****. By that logic, I could sell a decoder as having "FULL HIGH PROFILE SUPPORT" when it can only play streams of 320x240 with 1 reference frame, 0 bframes, and a VBV constraint of 400 kbps. After all, such a stream would still be High Profile!

Show me where their site says "Full High Profile Support" and your example might be valid. However you won't be able to cause it never said this.

Additionally the following link (which is linked to from the main page ): http://forum.corecodec.com/viewtopic.php?f=3&t=69 Indicates very clearly that it doesn't support all features and is dated "25 Feb 2007".

[plonk420]

Yes that was the point: "never on the feature list" huh? who knew they needed it?

seconded, but i still unhappily upgraded :/

at least i have a 1.x AND a 2.x license :P

Show me where their site says "Full High Profile Support" and your example might be valid. However you won't be able to cause it never said this.

lame example. that's like saying "you should have expected this since CoreAVC didn't list every h.264 feature it supports somewhere..."

edit: http://web.archive.org/web/20071210023944/http://www.corecodec.com/products/coreavc.html

from feb to december+, it says it supports "H.264 Baseline, Main, High profile support". i disagree that it's our fault for not reading that that wasn't "FULL High Profile Support"... but then again from a nitpicker's viewpoint, it DOESN'T say "full". but what decoder DOES? WinDVD says nothing. PowerDVD says it supports "MPEG-4 AVC (H.264)" and plays it just fine...

i'm with DS in that the h.264 spec has included x264's weightp since before CoreAVC.

all i can say is "fool me twice..."

[Disabled]

Imo one had to assume they support the full profile, because even under limitations they didn't write something about missing features: (*edit* They did, but only two who got fixed)
Limitations :
- Only output to YV12 and I420
- No dynamic output mediatype change
- No flushing for buffered frame at end of file
- Linked with some unnecessary code from TCPMP
- no cqm, lossless or interlacing support
link (http://web.archive.org/web/20060404210113/coreavc.corecodec.org/changelog.html)
But then again one could have guessed they don't really care because they also listed the standard edition as High profile support, but that one clearly lacked interlacing...

[LoRd_MuldeR]

Imo one had to assume they support the full profile, because even under limitations they didn't write something about missing features: (*edit* They did, but only two who got fixed)

link (http://web.archive.org/web/20060404210113/coreavc.corecodec.org/changelog.html)
But then again one could have guessed they don't really care because they also listed the standard edition as High profile support, but that one clearly lacked interlacing...

Back at the time when CoreAVC 1.9 was released, support for Weight-P was irrelevant because nobody needed it. That's a fact we should not forget in this discussion. It was even left out intentionally. Why make your code messier/slower for something that nobody needs? In fact 99,9% of all users didn't known what "Weighted P-Prediction" is, until it popped up on the x264 changelog a few months ago. Other H.264 decoder, such a Adobe's Flash or Apple TV didn't support it either (the latter still doesn't). Therefore it's obvious why they didn't mention the lack of support for something that nobody needed (back at that time) and that wasn't supported by the competitors either. Now, several years later, the situation has changed, indeed. But adding Weight-P support to CoreAVC 1.9 now would probably mean rewriting a lot of code - which not only requires a lot of time (money) for coding, but also for re-testing everything after those fundamental changes. Releasing a "crippled" CoreAVC 2.0 as v1.9.6 (as Jiffy suggested) probably isn't an option either, because one of the major improvements in CoreAVC 2.0 is the increased decoding performance, which they probably can't "undo" easily and won't give away for free...

[Disabled]

Back in the days I didn't care about weightp either, but today that its used I care about not knowing what I bought. And that makes me not buy the upgrade, because I will not know what I get for my money and if they feel like it they stop supporting new x264 features next month and I have to buy another decoder.

[LoRd_MuldeR]

Back in the days I didn't care about weightp either, but today that its used I care about not knowing what I bought. And that makes me not buy the upgrade, because I will not know what I get for my money and if they feel like it they stop supporting new x264 features next month and I have to buy another decoder.

Well, that applies to any product. And especially in the IT world things are outdated very soon. That's a matter of fact. We may not like it, but we have to live with it :rolleyes:

For example: If I buy a "high-end" graphic's card for 300$ today that runs all games with maximum details, I can be sure that this won't last very long. In 1 or 2 maybe 3 years it will be hopelessly outdated!

The same way you can't expect that a software, which is "state-of-the-art" today, will remain so until forever. And we talk about a 15$ software here, not some "enterprise" solution...

[avivahl]

If you ask me, the proper thing to do is to give 1.9.5's customers a free upgrade to 2.0.0. With every second person downloading pirated CoreAVC illegally, the company might wanna rethink before stabbing their customers in the back. And yes, not supporting weight-p, which has now become a basic feature in the world's most widely used H.264 encoder, is what I consider "stabbing the customers". I mean, it basically renders CoreAVC useless for customers who relayed on it as a software decoder. And between us, most people buy CoreAVC for its fast software decoding (not for CUDA). And I say all this as a person who uses Windows 7's internal DXVA H.264 decoder.

[Disabled]

Lord Mulder: Totally different thing. H264 hasn't moved since a long time - at least weightp is there since about a decade. I expect every DX11 graphics card to support every DX11 feature and every DX10 card to support every DX10 feature. And if one feature is not used today but is used tomorrow, I consider it false advertisement to advertise a DX11 card like that who does not support said feature. If the card is fast enough to run a game using that feature is a completely different story.
You know, ATI supports tesselation since its 2xxx series. Are they DX11 cards now? Or were they advertised as such?

[Maccara]

So when we got an order to manufacture a defibrillator according to specs (addressing some issues mentioned here (http://www.ncbi.nlm.nih.gov/pubmed/9259059)), you say it is ok for us to skip something in those specs? And when customer notices this (admittedtly, consequences are a little worse than just a failing codec) we can just say that no-one else uses that function either and we would like more money, despite we failed to provide what we got paid for the first time?

Great! I'll go tell my manager right away I found a great way to save money and ensure further revenue.

I'm glad at least some engineers have some ethics still...

And no, it's not about the money, it's about the principle. And for me personally, it's not even about the fact I'm paying for bugfixes (hell, I have software which I pay annually for just that reason), but about the ass-backwards way of handling the issue when it was found out, trying to blame it on "changing specs" (which is not true) and calling customers, who dared to complain, "ranters" and whatnot, instead of just being forthcoming about the issue in the first place.

[CiNcH]

Hey guys,

if I remember correctly, CoreAVC 2.0 removes the CUDA D3D dependency. Is the maximum reference frame count now 16 for 1080p?

Since you are also working on DXVA support.. guess it will have the Level 4.1 check?

[ChronoCross]

Did I just read a comparison between a codec and defibrillator?

The simple fact is you guys are complaining because you weren't paying attention to the fact that CoreAVC didn't claim to support the entire h264 spec.

You didn't properly evaluate the product before you purchased it and now you are upset. How many of us bought this because it allowed us to watch H264 without having to invest a grand or two into a new computer? The least you could do is be a bit great-full instead of bitching and moaning every time you get upset.

There are plenty of alternatives

1) ffdshow and ffmpeg
2) DivX
3) DiAVC (whenever it stops being a horrible piece of software)

[Fadeout]

3) DiAVC (whenever it stops being a horrible piece of software)
Right now it works best here. Problem is that the guy is missing.

The correct way to look at CoreAVC is that it's THANKS to the weight-P issue that it has now a reason to sell. Without it there would be absolutely no reason to buy the new version, so they were lucky that the issue came up.

I remember in June where on Twitter they said that the product was complete and they were working just on optimization (up to 20% better). Well, in November we got none of that performance both on new and old CPUs.

[Maccara]

Just a clarification. In general, I'm happy with CoreAVC and it gets the job done on my system, and I even bought the update as it also had other benefits for me.

Does not mean I can't criticize their marketing & their attitude to spec conformance (in the past, at least).

Did I just read a comparison between a codec and defibrillator?

Nope, just a comparison of following specs. And people defending that "it's ok not to follow specs". Just driving the point in. Of course, consequences of not following specs are an order of magnitude different between these examples, but it still does not make it right in either case.

The simple fact is you guys are complaining because you weren't paying attention to the fact that CoreAVC didn't claim to support the entire h264 spec.
Wrong. I WAS paying attention: I bought a H.264 High Profile decoder, as advertised. 1.x series never was that, and never will be. I suspect it never will be fully, and CoreCoded now has even aknowledged (somewhere in this thread) that they try to match what x264 produces featurewise and have listed what they do not support. This is ok as longs as they're forthcoming about it. This was not so in the past.

You didn't properly evaluate the product before you purchased it and now you are upset.
Sure I did. You don't expect us to write our own encoders to test every aspect of the decoder, do you? I just expect they follow the specs they claim to follow.

The least you could do is be a bit great-full instead of bitching and moaning every time you get upset.
I am as grateful as for any profit making company providing products which get the job done. It's the claims and handling discrepancies I'm criticizing.

This would be a bit different if we were talking about a free product - I'd be grateful for anything useful I get.

When I have to pay, I expect a bit more disclosure and some respect towards customers (not the other way around).

All-in-all. This IS a good product, and I'm happy it exists at all. I'm just not too happy about how they've handled business. At least now it seems they're more forthcoming about shortcomings.

[Keiyakusha]

Some peoples telling me that for lossless streams encoded with x264 --crf 0 --preset ultrafast, ffmpeg-mt is up to 35% faster than CoreAVC 2.0. Does anyone have any benchmarks for lossless?

[ChronoCross]

Some peoples telling me that for lossless streams encoded with x264 --crf 0 --preset ultrafast, ffmpeg-mt is up to 35% faster than CoreAVC 2.0. Does anyone have any benchmarks for lossless?

This is entirely possible however I haven't seen any benchmarks as almost no one uses lossless. I would imagine primarily that CoreAVC is more optimized for situations where higher compression is used whereas --ultrafast disables a good majority of the H264 specs in exchange for encoding speed. If your interested in running tests I would compare ---ultrafast vs. --placebo to test the two sides of the spectrum to see how each decoder fares.

[twazerty]

I am the developer of AVCHDCoder and found a very big problem when I use CoreAVC. (found the problem 3-4 weeks ago) This is the problem:

When the encoding pass 1 starts in AVCHDCoder the encoder and CoreAVC will be started. After it is started and I open a window or do something with setVisible(true) (Java GUI) AVCHDCoder will hang (Not responing). On this point AVCHDCoder's GUI is not responding. But when Pass 1 is complete CoreAVC is ready and my GUI is working again. So while CoreAVC is running by a process launched with AVCHDCoder the GUI will hang. Same problem with second pass. But it is even stranger, not only AVCHDCoder will hang but most times my IDE (Netbeans 6.8) is not responding too !!! the same problem as my app. Gets back to normal when CoreAVC is done.

This is what AVCHDCoder does when it starts the encoding process:

create avisynth script
create bat file with x264 commandline instructions
run batfile with ProcessBuilder (Java lib)


23:12:03 Creating AVS file: DirectShowsource("input.m2ts",fps=25.000,audio=false).ConvertToYV12().addborders(0,0,0,0)
23:12:03 Encoding Pass 1: "C:\Program Files (x86)\AVCHDCoder\Tools\X264\32bit\x264.exe"
--pass 1 --vbv-bufsize 18000 --vbv-maxrate 18000 --bitrate 17808 --level 4.1
--stats "K:\AVCHDCoder Temp\Test - item 1\Test.stats" --keyint 24 --min-keyint 2
--ipratio 1.1 --pbratio 1.1 --fps 25.000 --sar 1:1 --weightp 0 --nal-hrd --interlaced --aud
--output NUL "K:\AVCHDCoder Temp\Test - item 1\Test.avs"
23:12:39 Encoding Pass 2: "C:\Program Files (x86)\AVCHDCoder\Tools\X264\32bit\x264.exe"
--pass 2 --vbv-bufsize 18000 --vbv-maxrate 18000 --bitrate 17808 --level 4.1
--stats "K:\AVCHDCoder Temp\Test - item 1\Test.stats" --keyint 24 --min-keyint 2 --me umh
--direct auto --psy-rd 1.0:0.25 --ipratio 1.1 --pbratio 1.1 --fps 25.000
--sar 1:1 --weightp 0 --nal-hrd --aud --interlaced
--output "K:\AVCHDCoder Temp\Test - item 1\Test.264" "K:\AVCHDCoder Temp\Test - item 1\Test.avs"


This is my code to run the bat file and parse the output (Java):


FileWriter fw = new FileWriter(bat);
BufferedWriter bw = new BufferedWriter(fw);

bw.write(commandLine);
bw.close();

ProcessBuilder processBuilder = new ProcessBuilder(bat.getAbsolutePath());
processBuilder.redirectErrorStream(true);

process = processBuilder.start();

InputStream is = process.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
br = new BufferedReader(isr);

while ((line = br.readLine()) != null) {
//Write output to model.
}
br.close();


My app is multiThreaded (offcource) my GUI runs in it's own Thread. It works perfectly when I use ffdshow. In some strange way CoreAVC is messing with Java. I tracked down the problem as far as I could do. Every time I came back to standard java library. To be more specific the setVisible method of a Swing element like a JDialog. (For example opening the Settings window)

Also tried different versions of x264 and ffdshow and I have the same problem on my other computer. Both Windows 7 64 bit. Are you known with this problem???

[Blue_MiSfit]

Please parse that x264 command line so that it doesn't extend several pages to the right. Quite illegible :)

Thanks!

~MiSfit

[roozhou]

I am the developer of AVCHDCoder and found a very big problem when I use CoreAVC. (found the problem 3-4 weeks ago) This is the problem:

When the encoding pass 1 starts in AVCHDCoder the encoder and CoreAVC will be started. After it is started and I open a window or do something with setVisible(true) (Java GUI) AVCHDCoder will hang (Not responing).

Did you disable CoreAVC's trayicon?

[twazerty]

Did you disable CoreAVC's trayicon?

I think I didn't disable the icon. (always enable icons for testing) Could that really be the problem?? sounds strange. Anyway I will going to test it

[lych_necross]

Betaboy hasn't been on in a while... I wonder if all of the fighting in this thread has scared him off. :confused:

[lnatan25]

Betaboy hasn't been on in a while... I wonder if all of the fighting in this thread has scared him off. :confused:
If we've learned anything about BetaBoy, it's that he has learned to ignore any piece of criticism that doesn't paint his software in the best possible way, and call it off topic, trolling, etc. :devil:

[ChronoCross]

If we've learned anything about BetaBoy, it's that he has learned to ignore any piece of criticism that doesn't paint his software in the best possible way, and call it off topic, trolling, etc. :devil:

More likely is he's tired of answering the same questions/criticism 5000 times in the same thread.

He of course loves if you find a technical problem.....however none have come up in this thread in quite some time.

[pankov]

More likely is he's tired of answering the same questions/criticism 5000 times in the same thread.

He of course loves if you find a technical problem.....however none have come up in this thread in quite some time.

Here is one problem that isn't address till now. I'm still hoping it'll be soon since I've opened a ticket in my Core account ... though it's more than a couple of weeks now and I haven't received any feedback from them :(

[ChronoCross]

Here is one problem that isn't address till now. I'm still hoping it'll be soon since I've opened a ticket in my Core account ... though it's more than a couple of weeks now and I haven't received any feedback from them :(


Care to share what the problem is?

[pankov]

oooh,
I forgot the link
http://forum.doom9.org/showthread.php?p=1329406#post1329406

[pankov]

today I tried using the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) to quickly re-calibrate my projector and I found that CoreAVC doesn't recognize the correct Input/Output levels. Both FFDShow and MPC Video Decoder show the flashing black (17-25) and white (230-234) lines in "Brightness & Contrast.mp4". In CoreAVC I have to manually set the input to "PC" or output "to TV". When they are set to "Auto"/"Auto" none of the lines are flashing. If it was for all videos it wouldn't be such a problem but sadly this happens only to a few, one of which is this calibration pattern.
Am I doing something wrong or is there a bug in CoraAVC's level detection algorithm?

[BetaBoy]

If we've learned anything about BetaBoy, it's that he has learned to ignore any piece of criticism that doesn't paint his software in the best possible way, and call it off topic, trolling, etc. :devil:
I've been staying away from obvious troll postings and instead concentrating on what matters for our customers.

We are working on CoreAVC 2.1 at the moment with many enhanced features I've discussed here and some I have not.

[BetaBoy]

Here is one problem that isn't address till now. I'm still hoping it'll be soon since I've opened a ticket in my Core account ... though it's more than a couple of weeks now and I haven't received any feedback from them :(

PM me with the ticket # and I'll get the team on it here this morning to see what the hold up is.

[BetaBoy]

today I tried using the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) to quickly re-calibrate my projector and I found that CoreAVC doesn't recognize the correct Input/Output levels. Both FFDShow and MPC Video Decoder show the flashing black (17-25) and white (230-234) lines in "Brightness & Contrast.mp4". In CoreAVC I have to manually set the input to "PC" or output "to TV". When they are set to "Auto"/"Auto" none of the lines are flashing. If it was for all videos it wouldn't be such a problem but sadly this happens only to a few, one of which is this calibration pattern.
Am I doing something wrong or is there a bug in CoraAVC's level detection algorithm?
We are looking into it...

[squid_80]

today I tried using the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) to quickly re-calibrate my projector and I found that CoreAVC doesn't recognize the correct Input/Output levels. Both FFDShow and MPC Video Decoder show the flashing black (17-25) and white (230-234) lines in "Brightness & Contrast.mp4". In CoreAVC I have to manually set the input to "PC" or output "to TV". When they are set to "Auto"/"Auto" none of the lines are flashing. If it was for all videos it wouldn't be such a problem but sadly this happens only to a few, one of which is this calibration pattern.
Am I doing something wrong or is there a bug in CoraAVC's level detection algorithm?

The fullrange flag isn't set, so setting Input levels to Auto will use TV. If the Output levels is set to Auto, it will use PC levels for VMR9 or else TV levels. Sounds like you're using VMR9 and your video driver assumes TV levels are being used.

[hajj_3]

What features can you confirm for us for v2.1?

[pankov]

PM me with the ticket # and I'll get the team on it here this morning to see what the hold up is.
I've already done this on couple of days ago (19th February 2010, 21:49)

[pankov]

The fullrange flag isn't set, so setting Input levels to Auto will use TV. If the Output levels is set to Auto, it will use PC levels for VMR9 or else TV levels. Sounds like you're using VMR9 and your video driver assumes TV levels are being used.
Well, I tried other renderers and it seems you are correct. The strange thing is that FFDShow and MPC's video decoder recognize the correct levels with all renders and don't clip blacks/whites even with VMR9 - they show the same picture with all renderers.

[Cyber-Mav]

What features can you confirm for us for v2.1?

id like to know how much it will cost to upgrade from 2.0 to 2.1 :confused:

[hajj_3]

i think updates are free except for major numbers eg v1.0, 2.0 etc.

[BetaBoy]

correct...

[BetaBoy]

What features can you confirm for us for v2.1?

- Full DXVA Support
- Low latency Option
- Various bug fixes and speed enhancements

We are working on the report of a subtitles issue atm as well.

[ajp_anton]

- Full DXVA SupportMeaning ATI support?
- Low latency OptionAt what cost?

[Disabled]

- Full DXVA Support
Does it mean you can use DXVA to reencode Videos? Ie DXVA decodes the video and pipes it to another program? Like this guy is suggesting:
http://forum.doom9.org/showthread.php?p=1375061#post1375061

[BetaBoy]

Well to define Full = Anything but old cards that don't support bitstream mode.

[Keiyakusha]

Well to define Full = Anything but old cards that don't support bitstream mode.

So If I understand right, the answer is "yes", it will be possible to do whatever you want with decoded frames, the whole thing won't be limited to direct decoder-renderer connection like with all currently available solutions?

[BetaBoy]

To early to comment more on DXVA atm as we are just now testing Alpha builds.

As far as the low latency option... it is mostly for very specialized use cases (CCTV, IPTV, etc.) when speed is very important.
----
When a stream is properly muxed into a MP4 format, it has the advantage of storing the NALU lengths at the beginning of each frame. When the Byte stream format is used instead, the size of the NALU can only be determined when the next startcode is seen... this adds one frame of latency, plus the existing one frame delay.

Additionally you will need to use FORMAT_MPEG2Video for the input connection format type, with dwFlags set to the length of the size field (commonly 2 or 4 bytes) and the sps and pps NALUs should be passed in dwSequenceHeader. Also note that you should not use MEDIASUBTYPE_MAINCONECPT_H264 ({0x8D2D71CB, 0x243F, 0x45E3, 0xB2, 0xD8, 0x5F, 0xD7, 0x96, 0x7E, 0xC0, 0x9B}) for the subtype, as it is not meant for this format. Use one of the other regular H264 subtypes made by using either "avc1" or "h264" as the fourcc.

All of the above will be in the "CoreAVC Guide" and in the filter properties box.

[CiNcH]

As far as the low latency option... it is mostly for very specialized use cases (CCTV, IPTV, etc.) when speed is very important.
----
When a stream is properly muxed into a MP4 format, it has the advantage of storing the NALU lengths at the beginning of each frame. When the Byte stream format is used instead, the size of the NALU can only be determined when the next startcode is seen... this adds one frame of latency, plus the existing one frame delay.

So were are talking about 20-40ms faster zapping or what?

[Stephen R. Savage]

Are there any plans to include a 64-bit version of avss.dll? It is the only file from HMS that has no 64-bit equivalent.

[BetaBoy]

I've asked Haali to comment.

[Snowknight26]

Hope you also ask him to comment on his broken splitter. D:

[Gleb Egorych]

BetaBoy, so no improvements in interlaced content support?

[jj666]

We now have two "world's fastest H264 software decoders" according to webpages - which one is now the fastest?

Cheers,

-jj-

[Disabled]

It depends on the hardware you have. The other one was faster in some tests, others had CoreAVC run faster on their computer. I guess the tendency is, that CoreAVC performs better on older hardware while the other one performs faster on newer ones. CoreAVC is much more stable and feature complete and has no hardware tied activation scheme. The other one is still under heavy development, meaning there are some speed boosts to expect and features are promised to be added too. Theres always the free third option and the open source fourth, so if you can, wait for further development of both codecs.

[lych_necross]

I've got a question about CoreAVC 2.0 being used with ffdshow. I have configured CoreAVC to prefer CUDA acceleration and when I watch h.264 movies, I sometimes like to use ffdshow's raw video filter alter the movie in realtime. My question is, if I use CoreAVC (w/CUDA enabled) and ffdshow together, will CoreAVC revert to software mode like DXVA decoders do when used with ffdshow?

[roozhou]

will CoreAVC revert to software mode like DXVA decoders do when used with ffdshow?
No, CUDA is not DXVA. The frame will be fetched back to main memory no matter what you connect the decoder to.

[me7]

I've got a question about CoreAVC 2.0 being used with ffdshow. I have configured CoreAVC to prefer CUDA acceleration and when I watch h.264 movies, I sometimes like to use ffdshow's raw video filter alter the movie in realtime. My question is, if I use CoreAVC (w/CUDA enabled) and ffdshow together, will CoreAVC revert to software mode like DXVA decoders do when used with ffdshow?

I do exactly this and it works. As roozhou said each frame is copied back to RAM and can be altered by any filter you like.

[lych_necross]

Thanks roozhou and me7. That's what I thought, but I wanted to be sure. How is DXVA support going to change things? Lets say I have the latest and greatest Geforce card from Nvidia. Is the new CoreAVC going to prefer CUDA or DXVA? Using both at the same time is impossible I'm assuming.

[Keiyakusha]

It doesn't really matters since the same chip will be used as for CUDA. If cuda is fine for you now, then there will be no improvements for you.

By the way the only point for DXVA in CoreAVC I see is... if there will be some custom renderer and we will be able to retrieve decoded frames then Ati users will be happy. Otherwise this is waste of time IMHO... There is already DXVA in MPC-HC and ffdshow and its free.

[lych_necross]

It never occurred to me that the same chip is used for both. Hopefully, when the next update of coreavc comes out there will be a new haali splitter (unless Haali sees his shadow, then we'll have to wait six more months ;)

[me7]

Thanks roozhou and me7. That's what I thought, but I wanted to be sure. How is DXVA support going to change things? Lets say I have the latest and greatest Geforce card from Nvidia. Is the new CoreAVC going to prefer CUDA or DXVA? Using both at the same time is impossible I'm assuming.

The DXVA option could be slightly faster since the frames don't need to be copied to RAM while CUDA has the advantage of being compatible with other filters.

[clsid]

Is there a way for us to motivate Haali to fix some of the remaining bugs in his excellent splitter? Perhaps he could add a donation page to his website? Or the Matroska foundation could do it, and forward the revenue to Mike.

I could help send a lot of traffic to such a donation page, if that would result in further improvement of the splitter.

BetaBoy, are there still plans to open an official bugtracker for HMS and CoreAVC?

[Keiyakusha]

It will be also good to see in HMS support for compliant AC3 in mp4.

[Midzuki]

It will be also good to see in HMS support for compliant AC3 in mp4.

Besides AC3: DTS and VC-1.

[Jeff Flowerday]

Is there a way for us to motivate Haali to fix some of the remaining bugs in his excellent splitter? Perhaps he could add a donation page to his website? Or the Matroska foundation could do it, and forward the revenue to Mike.

I could help send a lot of traffic to such a donation page, if that would result in further improvement of the splitter.

BetaBoy, are there still plans to open an official bugtracker for HMS and CoreAVC?

+1, I'd be up for donating!

I'd even be up up to purchasing a splitter that was maintained with regular updates.

[BetaBoy]

We do share the source for HMS. But Haali has been resistant to outside devel other then us here at CoreCodec. Haali has a full time job and his splitter and third party work takes a back seat to his time availability. I'll ping him more on it.

On a CoreAVC bug tracker... we do have our internal wiki that we keep going but atm 2.0 has very little known bugs and those that are known have already been fixed for our upcoming 2.1 release.

[lych_necross]

Is there a way for us to motivate Haali to fix some of the remaining bugs in his excellent splitter? Perhaps he could add a donation page to his website? Or the Matroska foundation could do it, and forward the revenue to Mike.

You could try kidnapping his dog and holding it for ransom :devil:

Seriously, maybe Corecodec could buy haali's splitter outright and handover development to another person/team (someone who is more approachable and willing to work with others).

[hajj_3]

or they could buy it and make it open source:)

[ExSport]

Does it mean you can use DXVA to reencode Videos? Ie DXVA decodes the video and pipes it to another program? Like this guy is suggesting:
http://forum.doom9.org/showthread.php?p=1375061#post1375061
If it will be possible to use DXVA for decoding part in encoding process, like in Sherpya MEncoder, I suppose every will benefit from this, not only CoreCodec in sale ratings :)
And also new "benefit" in comparison with DiAVC: http://forum.doom9.org/showthread.php?p=1379225#post1379225 (Sherpya post and codec matrix supported in MEncoder right now)
I like free market, it leads to better products for end user so good luck FFDSHOW, DiAVC and Corecodec. Keep up good work all!!! Sorry for OT.

[leeperry]

You could try kidnapping his dog and holding it for ransom :devil:

Seriously, maybe Corecodec could buy haali's splitter outright and handover development to another person/team (someone who is more approachable and willing to work with others).
he's always idling on the MPC-HC IRC channel, bribe him :p

[dimitrik]

There is already DXVA in MPC-HC and ffdshow and its free.

OT: I know about DXVA in MPC-HC, but my understanding is ffdshow is a pure software decoder. Are you sure it can support DXVA?

EDIT: Checked, no it can't and won't. See this post here. (http://forum.doom9.org/showthread.php?p=1145712#post1145712)

Franky if it did there would be no reason whatsoever to use coreavc or other commercial decoders. As it is, they have at least that advantage, especially when hardware acceleration exists.

[nm]

OT: I know about DXVA in MPC-HC, but my understanding is ffdshow is a pure software decoder. Are you sure it can support DXVA?

EDIT: Checked, no it can't and won't. See this post here. (http://forum.doom9.org/showthread.php?p=1145712#post1145712)

That's old information. ffdshow tryouts (http://ffdshow-tryout.sourceforge.net/) SVN has DXVA support, including subtitle renderering in any DirectShow media player. Search the development thread (http://forum.doom9.org/showthread.php?t=120465) for more information.

[weasel_]

OT: I know about DXVA in MPC-HC, but my understanding is ffdshow is a pure software decoder. Are you sure it can support DXVA?

EDIT: Checked, no it can't and won't. See this post here. (http://forum.doom9.org/showthread.php?p=1145712#post1145712)


you check to old info ...

now it can ...

read ffdshow tryout project topic

[popper]

and OC theres the beta http://www.splitted-desktop.com/~gbeauchesne/xvba-video/ for AMD HD cards on linux use now OC,
its not clear if Core will or can make use of this (limited right now) UVD codebase patches etc in some way on linux for AMD HD cards HW assisted AVC decode!

Overview:
XvBA backend for VA API supporting the following codecs:

MPEG-4 AVC (H.264)
Windows Media Video 9 Advanced (VC-1 Advanced profile)
Requirements

This version requires AMD fglrx driver version >= 8.66. In particular, you'd need either fglrx 8.66.x (Catalyst 9.10) or fglrx 8.68.2 (9.12-HotFix)....

http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/
these patches add VA API support to FFmpeg and MPlayer.

HW video decode capabilities depend on the actual VA API implementation. Besides, from an MPlayer perspective, only full-offload (VLD) of the video is supported for the following codecs:....

http://www.splitted-desktop.com/~gbeauchesne/libva/
These patches extend VA API with data needed for VDPAU and XvBA backends. Other changes include packaging improvements.

http://www.phoronix.com/forums/showthread.php?p=113271#post113271
AMD's UVD2-based XvBA Finally Does Something On Linux

it might be werth helping out and asking questions on freenode #radeon too If your a developer looking to help make something usable for AMD/ATI end users there any time soon as he and several in house ATI/AMD devs hand out there.

[nitrous]

For some reason when I'm playing H264 movies on KMPlayer + CoreAVC, the picture randomly freezes, but the audio keeps running. The solution is going 5 seconds back, then it plays normally. What's the issue?


Edit: Nevermind this. Fixed it (I think) by changing video renderer from EVR to VMR9.

[BetaBoy]

CoreAVC 2.1 devel update... DVXA 1 done... working on finishing up DXVA 2 atm.

[BetaBoy]

On a side note we are also working on finalizing our CoreASP (DivX) directshow filter (and OEM SDK) for a QA release internally... the initial public release will be afterwards. No CUDA on the initial release, but it is planned.

[Disabled]

Any answer yet to the question if you will be able to use DXVA to reencode files like with Cuda?

[BetaBoy]

No... just decoding.

[Cyber-Mav]

On a side note we are also working on finalizing our CoreASP (DivX) directshow filter (and OEM SDK) for a QA release internally... the initial public release will be afterwards. No CUDA on the initial release, but it is planned.

i once asked if corecodec would expand the cuda support to cover the functions of the new nvidia VP4 processor (it has hardware mpeg4-asp (divx xvid) decoding support) and you betaboy said that you wont be going down that route since you want to stick to a pure AVC platform.

now your going back on your stance?

[eddman]

i once asked if corecodec would expand the cuda support to cover the functions of the new nvidia VP4 processor (it has hardware mpeg4-asp (divx xvid) decoding support) and you betaboy said that you wont be going down that route since you want to stick to a pure AVC platform.

now your going back on your stance?

You do know that coreavc and coreasp are two different products, right? Betaboy said that coreavc would remain an avc only codec, that's all.

[Mixer73]

Dumb question I know but is there any way to hack iTunes to use CoreAVC as a codec? Playback of h264 in iTunes SUCKS!!!

[laserfan]

iTunes SUCKS!!!
I completely agree!!! ;)

[Blue_MiSfit]

That's because iTunes uses QuickTime, and QuickTime in windows (in general) is epic lulz.

I can't imagine there's a way to make iTunes use DirectShow or something like libavcodec.

~MiSfit

[ChronoCross]

HAs anyone had trouble with CoreAVC where deeking takes forever? I just tried DivX's new codec and seeking is instant while CoreAVC is delayed by 1-2 seconds.

[Dark Shikari]

HAs anyone had trouble with CoreAVC where deeking takes forever? I just tried DivX's new codec and seeking is instant while CoreAVC is delayed by 1-2 seconds.Do they both do frame-accurate seeks?

It might be that CoreAVC is seeking to the frame, while DivX is rounding to the nearest keyframe.

[ChronoCross]

Do they both do frame-accurate seeks?

It might be that CoreAVC is seeking to the frame, while DivX is rounding to the nearest keyframe.

Could be, it was more of a casual observer notice than a in depth analysis.

[hydra3333]

Over at http://forum.doom9.org/showthread.php?p=1386569#post1386569 it looks like new haali coming up soon. Will updated version of coreavc be released with it inside when it is released ?

[roozhou]

@BetaBoy:
Found a new bug in CUDA decoding.

OS: WinXP SP3
CPU: Single-core Sempron 2500+(754)
Video Card: 8500GT 128M

When decoding 1920x1080 AVC videos, it shows distorted image after the first GOP. It plays OK with MPC-HC DXVA and ffdshow DXVA, and all SW decoders including CoreAVC

With old nVidia drivers, 8500GT card with 128M on-board vram cannot decode 1920x1080 AVC video with HW acceleration. I got this information from the video card vender one years ago. With some tests I found that neither DXVA nor CUDA could decode AVC w/ width>=1856. e.g. 1920x800 doesn't work but 1440x1080 works.

It seems this issue was fixed in 196.21 driver though not mentioned in driver's changelog. DXVA works perfectly on 1920x1080 video with 196.21 and latest 197.13, but still no luck for CoreAVC CUDA. Could you investigate on this problem?

[Cyber-Mav]

i believe you need a graphics card with 256mb memory onboard to do the cuda decoding properly.

[Keiyakusha]

On a side note we are also working on finalizing our CoreASP (DivX) directshow filter (and OEM SDK) for a QA release internally... the initial public release will be afterwards. No CUDA on the initial release, but it is planned.

Can we expect that in software mode CoreASP will be faster than ffdshow?

[eddman]

On a side note we are also working on finalizing our CoreASP (DivX) directshow filter (and OEM SDK) for a QA release internally... the initial public release will be afterwards. No CUDA on the initial release, but it is planned.

How much would CoreASP cost? Also, any chance on seeing a new CoreAAC and CoreVorbis? I don't really like ffdshow. It's been in beta for too long.

[me7]

i believe you need a graphics card with 256mb memory onboard to do the cuda decoding properly.

I can do it on my 128mb 8400M GS but only with "Overlay Mixer" as renderer.

[roozhou]

I can do it on my 128mb 8400M GS but only with "Overlay Mixer" as renderer.
I am also using Overlay Mixer.

@Cyber-Mav
CUDA decoding does not use stream processor but uses the PureVideo unit which is also used by DXVA.

[eddman]

CUDA has nothing to do with purevideo.

[LoRd_MuldeR]

CUDA has nothing to do with purevideo.

That is right. However CoreAVC doesn't use CUDA. They did not implement a custom H.264 decoder as CUDA kernel. Instead they use the "hardwired" PureVideo decoder chip.

And they access the decoder chip through the CUDA Video API (CUVID), instead of through DXVA. That's why they call it "CUDA", although CUDA isn't involved in fact.

The advantage of accessing the PurVideo decoder chip though the CUVID API is that you can get the decoded frames back to host memory, something which DXVA can't do easily.

Also implementing your own H.264 decoder as CUDA kernel would be pointless with PureVideo available, because nothing beats a dedicated decoder chip efficiency-wise.

[LoRd_MuldeR]

This is a wierd way to use the purevideo engine. Why they didn't use DXVA in the first place?

It's not wierd at all. DXVA is a playback-only technology. It only works in combination with a suitable renderer (e.g. EVR) and the renderer won't return the decoded frames to the software.

If you want to process the decoded frames in a software (e.g. Avisynth) instead of presenting them on the screen, then DXVA isn't suitable. But CUVID does it easily.

Furthermore DXVA has some harsh restrictions on which H.264 levels/profiles are supported. AFAIK these restrictions don't exist for CUVID, so it allows using the full capabilities of the decoder chip.

BTW: Somebody claimed you can get back the frames from DXVA by implementing a custom renderer, but that's certainly more work and potentially less stable than simply using CUVID.

[kieranrk]

It's not wierd at all. DXVA is a playback-only technology. It only works in combination with a suitable renderer (e.g. EVR) and the renderer won't return the decoded frames to the software.


The newer version of DXVA for Vista upwards is not playback-only. This is why ffmpeg can use it for input and ffdshow can run full post-processing on it.

[nm]

The newer version of DXVA for Vista upwards is not playback-only. This is why ffmpeg can use it for input and ffdshow can run full post-processing on it.
I followed the ffdshow development thread back then and they seemed to have problems getting the decoded video back to main memory fast enough (http://forum.doom9.org/showthread.php?p=1367471#post1367471), so they had to disable this feature. CUVID seems to make this much easier.

FFmpeg's DXVA2 input support is news to me (I thought it was output-only, like the VDPAU implementation). Is it fast?

[turbojet]

While doing some benchmarks I ran into surprising results from graphstudio decoder performance of CoreAVC 2.0 with null renderer.

32 bit: 00:00:02.775 work time, 500.3729 fps
64 bit: 00:00:02.917 work time, 472.7088 fps

While libav, ffmpeg-mt, wmv9 (from wmp12) and libmpeg2 64 bit is running about 5% faster then 32 bit with the same benchmark.

Does anyone have any idea why 64 bit coreavc is slower than 32 bit? Are there plans to improve the performance of coreavc 64 bit?

[archy141]

I intend to use CoreAVC 2.0 as the decoder with HDConvertToX to rip my Blu-Ray collection onto a media server as X264 MKV files.

Can someone tell me what settings the Input & Output Levels on the configuration page of CoreAVC should be set to. The video files are to be streamed using a PS3 & viewed on a 50" Pioneer Plasma TV (36bit deep colour supported). I do not want to get colours crushed etc. Please offer guidance.

[BetaBoy]

While doing some benchmarks I ran into surprising results from graphstudio decoder performance of CoreAVC 2.0 with null renderer.

32 bit: 00:00:02.775 work time, 500.3729 fps
64 bit: 00:00:02.917 work time, 472.7088 fps

While libav, ffmpeg-mt, wmv9 (from wmp12) and libmpeg2 64 bit is running about 5% faster then 32 bit with the same benchmark.

Does anyone have any idea why 64 bit coreavc is slower than 32 bit? Are there plans to improve the performance of coreavc 64 bit?
You will see 64bit improvements in the next 2-3 releases as we optimize both the Blitter and ASM for 64bit.

[CruNcher]

BetaBoy is this reproduceable on your side ? Win XP
http://forum.doom9.org/showthread.php?p=1393211#post1393211

[BetaBoy]

That has been fixed as well.

[Keiyakusha]

Any chance for better support for h264 streams with variable resolution?
With different scenarios CoreAVC shows corruption or crashes. ffdshow seems to handle them right. Tested in graphstudio.

[BetaBoy]

Any chance for better support for h264 streams with variable resolution?
With different scenarios CoreAVC shows corruption or crashes. ffdshow seems to handle them right. Tested in graphstudio.

It's been fixed and will be in the next release.

[hajj_3]

I don't suppose you are able to give an ETA on the next version?

[7ekno]

Next version being 2.1?!?

Sorry, haven't seen a download in the "support" section of the login site for a while, so was just checking !

7ek

[archy141]

Someone please..

What settings should the Input & Output Levels on the configuration page of CoreAVC be for playback on a Plasma TV to avoid colours crushing etc..? Auto/PC/TV ?

[Keiyakusha]

archy141
If you have some particular problem with levels - give more info about what you using for playback.
If there is no problems - leave everything at defaults.
Also you can try to set Input as TV and output to "whatever works for you"

[BetaBoy]

We are looking for a few 'well rounded' testers with multiple OS's config's to test CoreAVC's new support for both DXVA 1 and DXVA 2. Email: info AT corecodec DOT com with your system config (OS, Video card, etc.) and what apps you use now with DXVA support. Thx in advance!!

[merlinmage]

I have one question about the usage of CoreAVC:

Currently I use the CCCP codec pack with ffdshow as the default decoder. Now I installed CoreAVC 2.0 and want every H264 video source to be encoded with it. It is enough to change only the default decoder to CoreAVC in the CCCP settings to make the codec work?

Like this:

http://www.abload.de/img/unbenanntno4g.png

[Virtual_ManPL]

How about fixing these bugs in v2.1 ?
At last this first one, cause IMO is very important...

1. http://forum.doom9.org/showthread.php?p=1390600#post1390600
2. http://forum.doom9.org/showthread.php?p=1347803#post1347803

[squid_80]

How about fixing these bugs in v2.1 ?
At last this first one, cause IMO is very important...

1. http://forum.doom9.org/showthread.php?p=1390600#post1390600
2. http://forum.doom9.org/showthread.php?p=1347803#post1347803

The second report is not a bug, the streams are invalid so there is nothing to fix.

[Virtual_ManPL]

Maybe... so how about improving CoreAVC to not show this "bad frames" like MPC-HC or DiAVC decoder ? ;)

[pankov]

PM me with the ticket # and I'll get the team on it here this morning to see what the hold up is.
Betaboy,
this bug is still not addressed. It's more than 4 months now and I still haven't receive any answer from you or the core team.
Recently I upgraded my main PC which uses ATI Video card to Windows 7 and I get the same wrong field order problem with it.
How is anybody else using hardware deinterlacing in Win7 and Zoomplayer?
What could be wrong in my setup??

[BetaBoy]

FYI... a new Haali Splitter has been released that addresses the VC-1 and TS issues as well as it now adds support for 'WebM' content. See: http://haali.su/mkv/

[clsid]

Great news!

Is CoreAVC 2.1 following soon?

[shon3i]

Thanks for new Splitter, still have issues with VC-1 and DTS-MA audio (audio is not recognized at all), while is completly normaly working H264 + DTS-MA combination.

i confirm that Mp4 synch is fixed
and TrueHD tracks are recognized fine.

[BetaBoy]

Great news!

Is CoreAVC 2.1 following soon?

Technically we are done with DXVA 1 and DXVA 2... but are working on specific 'flavors' of DXVA 2 now that are causing QA to take longer then anticipated.... well that and with us working with Google on WebM has taken away our focus a bit.

[hajj_3]

strange, just tried playing a .webm file with WMP on win7 x64 after installing the new haali splitter, unfortunately it won't play :(

[Astrophizz]

You have to have a decoder in addition to the splitter ;)

[hubblec4]

FYI... a new Haali Splitter has been released that addresses the VC-1 and TS issues as well as it now adds support for 'WebM' content. See: http://haali.su/mkv/

yeah, but new issues were in this build. the DTS-MA were not regonzied corectly.

[BetaBoy]

Its a step is a step..... I have pinged Haali on the issue.

[Virtual_ManPL]

BetaBoy any chances that these bugs which I mentioned (even on PM) will be fixed in next version ?
Or at least only first one, because it's serous problem...

[BetaBoy]

BetaBoy any chances that these bugs which I mentioned (even on PM) will be fixed in next version ?
Or at least only first one, because it's serous problem...

Squid has already stated that your streams are invalid.

[pankov]

BetaBoy,
what about my problem?
It's more than half an year now and the problem is still present. The worst part is that I don't get any answers neither here nor through PMs nor at the CoreCodec ticket system.
What's going on?

HI
I've been using CoreAVC since it's first version and was pretty pleased with it's performance and quality. Recently I noticed that I have problems with the Hardware Deinterlacing when used with VMR9 or EVR. I thought the problem was either with my hardware or windows installation since it was more than 3 years old XP Professional. Recently I did reinstall my XP (SP3) with all updates and most recent drivers and DirectX and .NET 3.5 and sadly the problem is still there.
With EVR I don't get any deinteralacing ... which I suppose is normal since I use it in WinXP ... can somebody confirm/deny this?
With VMR9 it seams like there is problem with the field order - I don't see any jaggies but there is no fluid motion but total jerkiness.
With Overlay Mixer or Halli everything is butter smooth.
On this PC I use Gigabyte P35 mobo + Intel Quad Q9400 + ATI 4670.
To isolate the hardware as the source of the problem I build a totally different PC with NVidia GF9400 chipset and I decided to put Windows 7 on it.
The problem is still there and sadly in Win7 Overlay Mixer doesn't work (which I think I read somewhere that is normal) so I'm very frustrated now.

What can I do to get smooth playback of interlaced H264 content (50Hz 1080i - EurosportHD / BBC HD)?
What do you guys/gals use?

If needed I can provide samples but I doubt the files are the problem.

[Virtual_ManPL]

Squid has already stated that your streams are invalid.
Maybe, but MPC-HC and DiAVC decoders didn't show any signs of this, like I said many times before...
So implanting some better error handling will be good (like not better) also like getting faster and faster with each release :)

And how about my first bug ? It's not about invalid streams, but ignoring any AR set in the container by CoreAVC decoder like I can see...
http://forum.doom9.org/showthread.php?p=1390600#post1390600

[Keiyakusha]

And how about my first bug ? It's not about invalid streams, but ignoring any AR set in the container by CoreAVC decoder like I can see...
http://forum.doom9.org/showthread.php?p=1390600#post1390600

Your sample doesn't have SAR info on stream level (which is wrong since in current example it absolutely should be there), only info on container level is present. It seems more like bug/missing feature in gabest splitter.
Stream that have SAR on stream level plays nice.
As for divx, I believe there is a switch that makes it read aspect ratio from container, but imho decoder really should pay attention to the stream only. So if this is the case, this is not a bug in CoreAVC but more likely you asking for some extra functionality.

Also I believe MPC-HC devs planning to replace splitters with something else from ffmpeg project so "tomorrow" everything can be different again...

[squid_80]

Maybe, but MPC-HC and DiAVC decoders didn't show any signs of this, like I said many times before...
Yes they do.

[Audionut]

well that and with us working with Google on WebM has taken away our focus a bit.

So we'll also wait even longer for coreplayer mobile 2. It's a shame that his is becoming duke nukem forever.

This is the app that symbian S60 V5 phones desperately needs.

[Virtual_ManPL]

@ Keiyakusha - are you sure ? in MediaInfo I can see ratio (16:9) and even second one (3:2)
but odd, I tested many codecs like MPC-HC, DivX, CyberLink, ArcSoft, Elecard, Nero and only CoreAVC shows signs of this (as far I remember)

If its not CoreAVC bug than sorry...
And will be very nive when this feature will be also in CoreAVC



Yes they do.
No, they dont :p
At last on my side, like you can see on screenshots...

[Keiyakusha]

MediaInfo I can see ratio (16:9) and even second one (3:2)

I checked the stream itself, but if mediainfo shows that, it just confirms what I say. "Second one" is a stream level info. Since SAR is absent 720/480 = 3/2. And this is what used with gabest splitter. Normally you shouldn't see "original display aspect ratio" field. If stream meant to be anamorphic, it should be encoded as anamorphic - with appropriate SAR values.
Actually some workaround may be nice feature, I just say you shouldn't blame decoder for current behavior. Note that decoder by itself doesn't do scaling. This info forwarded to player. Isn't the splitter is the one, who should work with container-level info?

By the way. How it works with another splitters (other than haali and gabest)?

[Abradoks]

I just say you shouldn't blame decoder for current behavior.
Why not to blame decoder, if it overwrites correct dwPictAspectRatioX/Y values even when SAR information is not present in stream? Oh, and even if splitter workarounds this bug by writing biXPelsPerMeter/biYPelsPerMeter, CoreAVC will still change all these parameters to something weirdly calculated (like 7219/3072 and 2048/2625 instead of 1128/480 and 110/141).
BTW, divx decoder has an option to choose which AR to prefer, bitstream or container.

[madshi]

Since the first 3D Blu-Ray is out now, let me ask:

Do you plan to add support for 3D (h264 MVC) decoding?

[asarian]

I'm back to letting libavcodec (ffdshow) do the H264 decoding. First I got all sorts of nasty artifacts; and today the RipBot264 process froze up when using CoreAVC 2.0 (repeated attempts). It's unusable this way; sorry.

[BetaBoy]

asarian... Please provide more detail to what you are referring to when you say RipBot264 froze? You have a sample or profile details to what you encoded? Also, we have no reports of such issues.

[asarian]

asarian... Please provide more detail to what you are referring to when you say RipBot264 froze? You have a sample or profile details to what you encoded? Also, we have no reports of such issues.

Well, the RipBot264 process would freeze after a few seconds into the encoding (re-encoding a H264 anime to add subs). x264 itself would keep running, but the RipBot264 shell just stops responding, time and again (after killing everything and starting it up again). The moment I set ffdshow to let H264 decoding be handled by libavcodec again, RipBot264 kept running normally. And I have the latest ffdshow and haali media splitter.

My guess is, that it's CUDA related somehow. Not really sure how, as just running a preview avs script (which naturally also uses CoreAVC) seems to work just fine. After the current encoding job finishes, I'll do some more tests.

[pankov]

Betaboy,
are you intentionally ignoring my question/bug report?
It's kind of rude to answer other problems and skip mine 4 times ... and 3 PMs too
:(

[Stockpile]

Dan, has it fixed the 'crashing windows with explorer thumbnail integration' bug?Yes, that's fixed.

Not here tho. Perhaps it's because I'm on a 64-bit Vista.

EDIT: clsid's post below shows a similar registry entry to what I used to make Windows Explorer show try thumbnails on *.m2ts files.

[clsid]

If 'fixing' the thumbnail crash simply means removing Haali's shell extension, then it definitely has not been fixed. Thumbnails can be generated through Microsoft's shell extension as well. At least v2.0 still crashes with that afaik. Also when using a different splitter.

Here is an example of using MS shell extension:Windows Registry Editor Version 5.00

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

[Stockpile]

I may also add that XnView crashes when trying to create thumbnails of videos decoded by CoreAVC, as well as Pinnacle Studio 12 keeps refreshing the browsing feature, in order to create thumbnails of the videos. Related to Xnview, I contacted them and Pierre said he might send me a test version to see where the problem (I hope we can find a reason to the crashes then).

Other than that, nice codec it's definitely worth the money in my opinion.

[Mixer73]

If 'fixing' the thumbnail crash simply means removing Haali's shell extension, then it definitely has not been fixed. Thumbnails can be generated through Microsoft's shell extension as well. At least v2.0 still crashes with that afaik. Also when using a different splitter.

This is reason enough alone I just refuse to have Haali splitter in my system, and remux all MKV back to MP4. Just a joke something so old can be around for so long.

[Stockpile]

After testing several XnView exes, Pierre could conclude from the XnView console window, that the crash was because of the codec crashing. I might be able to pull more information out of him, I just need to hear if that's needed then. =)

EDIT: XnView (and probably other software as well) uses IMediaDet::GetBitmapBits to get a frame from each video. Perhaps AVC CoreCodec doesn't support that?

[goofee]

Does a upgrade offer still exist from 1.9.5 to 2.0? I don't have any account on this new portal though, how do i proceed? I tried PM'ing betaboy and emailing support but no go. Any tips?

[hajj_3]

what kind of support will you be adding for VP8 if any?

[BetaBoy]

Betaboy,
are you intentionally ignoring my question/bug report?
:(
Not at all... I think we have addressed your report.

[BetaBoy]

If 'fixing' the thumbnail crash simply means removing Haali's shell extension, then it definitely has not been fixed. Thumbnails can be generated through Microsoft's shell extension as well. At least v2.0 still crashes with that afaik. Also when using a different splitter.

Here is an example of using MS shell extension:

We are looking into it some more. Thx for the report.

[BetaBoy]

what kind of support will you be adding for VP8 if any?

Not to get OT... but we are going to be releasing a CoreVP8 at a later date as an alternative directshow filter to the current WebM Project's filter.

On a related note... We have added WebM support into CorePlayer 2.0 as well as migrated to our official code for Matroska 2.0 via the 'core' parser library with the updated libMatroska2 and libEBML2.

But on deck atm is us releasing CoreAAC 2.0 as a directshow filter. We are in final QA for it now.

[Keiyakusha]

Did I miss something? CoreAAC2.0? Is it any faster than faad, ffmpeg? (I don't need any comparisons, your word it enough for me atm.)
Multichannel, LC, HE support all is there?
What about Cuda-based aac decoder? not possible/not worth the trouble?

[BetaBoy]

Did I miss something? CoreAAC2.0? Is it any faster than faad, ffmpeg? (I don't need any compartions, your word it enough for me atm.)
Multichannel, LC, HE support all is there?
What about Cuda-based aac decoder? not possible/not worth the trouble?
CoreAAC 2.0 is what we have been using in CorePlayer 1.x and is written by us from scratch compared to our open source 1.x version that was based on faad2. The initial directshow filter will support 32/64bit, 2 channel and SBR+PS = LC / Main Profiles (ie; LC-AAC, HE-AAC and HE-AAC v2).

CUDA is planned (yes its worth it) but we wanted to get the initial release out to fix any potential bugs before moving on. Is there is a performance improvement over FFmpeg? Simply put, yes... but like I have said for CoreAVC, that's for you all to tell us.

Additionally CoreAAC has many more options available for our OEM licensee's that also includes support for AAC features like: LOAS/LATM Container, ARM NEON support and like our other decoders, supports all modern operating systems and CPU's.

OT off.

[Stockpile]

Sounds good, perhaps worth to test out when I get the time. How advanced will the decoder be when it comes to user-controlled options?

[Cyber-Mav]

will coreaac be a replacement for ac3filter?

[nm]

will coreaac be a replacement for ac3filter?

AAC is not AC-3 (Dolby Digital)

[pankov]

Not at all... I think we have addressed your report.
What does this mean? That you've found the problem and you've already fixed it or that you don't see a problem and there is nothing you can do about it?
If it's the first, which I hope, when should I expect the fix?

[me7]

I think there is a problem with open-gop, committed to x264 a few days ago. Sometimes after seeking, the picture looks like this:

http://img685.imageshack.us/img685/9421/error1ju.png (http://img685.imageshack.us/i/error1ju.png/)

http://img34.imageshack.us/img34/2615/error2e.png (http://img34.imageshack.us/i/error2e.png/)

http://img404.imageshack.us/img404/737/error3y.png (http://img404.imageshack.us/i/error3y.png/)

Skipping a few seconds back and rewatching the same scene is fine though, seems to be related to seeking. Happens with and without CUDA.
Encoded with "--open-gop display".

[Guest]

Seeking properly with open GOPs requires the decoder to go back an extra GOP. I don't know if CoreAVC has implemented that. Can you post a sample so that I can check if something else is going on?

[me7]

Sure: http://www.mediafire.com/?sharekey=811bbb2860d2a452e62ea590dc5e5dbb77213321e971ea7aea4ac78345cbe4ce
I was able to reproduce the error in that sample by seeking back and forth.

[Guest]

Thanks. Seeking is fine with that sample in DGDecNV, so it appears that CoreAVC did not implement the "back by one GOP" move when decoding open GOP streams (or did not do it correctly).

They could also skip leading B frames instead of using the "back by one GOP" move if accurate random access is not a requirement.

[CruNcher]

I think there is a problem with open-gop, committed to x264 a few days ago. Sometimes after seeking, the picture looks like this:

http://img685.imageshack.us/img685/9421/error1ju.png (http://img685.imageshack.us/i/error1ju.png/)

http://img34.imageshack.us/img34/2615/error2e.png (http://img34.imageshack.us/i/error2e.png/)

http://img404.imageshack.us/img404/737/error3y.png (http://img404.imageshack.us/i/error3y.png/)

Skipping a few seconds back and rewatching the same scene is fine though, seems to be related to seeking. Happens with and without CUDA.
Encoded with "--open-gop display".

Doesn't happen with DivX Demuxer and your sample, i guess it's more a Haali splitter issue.
Ok it does happen though it seems to be a very random problem, doesn't happen on every seek.
It definitely doesn't happen with DivX H.264 Decoder so indeed it seems to be as neuron2 said that Decoder issue :)

[bob0r]

LOL CoreAVC has this error for so long... (or in this case maybe haali) The same happens with BBC-HD. it always recovers and video is there to watch :p

[ChronoCross]

I've pretty much given up on all CoreCodec projects.

CoreAVC was great when it came out, but with updates/bug fixes taking 7 or more months it becomes less and less competitive as open-sourced decoders performance are rapidly increasing with each passing week.

CorePlayer 2 has been worked on for over 2 years now with the initial forum announcement stating this in August 2009. Now at nearly a year since that post CorePlayer 2 is no closer to being available.

CoreASP - 2 or 3 years since it was announced. Treading on Duke Nukem Forever Territory.

CoreAAC - announced around a year ago, got it's forum placeholder yesterday which means it's 1-2 years away from release.

This may seem harsh but I've always been a stanch supporter of CoreCodec and it's been nothing but disappointment for awhile now and the last 20 pages of this thread is supporting evidence of that fact.

[fenomeno83]

I've pretty much given up on all CoreCodec projects.

CoreAVC was great when it came out, but with updates/bug fixes taking 7 or more months it becomes less and less competitive as open-sourced decoders performance are rapidly increasing with each passing week.

CorePlayer 2 has been worked on for over 2 years now with the initial forum announcement stating this in August 2009. Now at nearly a year since that post CorePlayer 2 is no closer to being available.

CoreASP - 2 or 3 years since it was announced. Treading on Duke Nukem Forever Territory.

CoreAAC - announced around a year ago, got it's forum placeholder yesterday which means it's 1-2 years away from release.

This may seem harsh but I've always been a stanch supporter of CoreCodec and it's been nothing but disappointment for awhile now and the last 20 pages of this thread is supporting evidence of that fact.
can you say what decoder that in your opinion works better than coreavc for h264?because I didn't find them

[ChronoCross]

can you say what decoder that in your opinion works better than coreavc for h264?because I didn't find them

DivX, DiAVC, libavcodec are all contenders who either come close or surpass CoreAVC in common situations.

libavcodec has the most bugfixes for problematic streams. I haven't really tested multi-threaded as I have a single core machine.

[Audionut]

CoreAAC - announced around a year ago, got it's forum placeholder yesterday which means it's 1-2 years away from release.

Funny you say that.

Hello,

***** , we want to thank you for your past purchase of CoreAVC 2.0.0 .
Since you are a valued customer we are now offering you the ability to be one of the first to purchase the long awaited release of our CoreAAC Audio Decoder. The CoreAAC Directshow Plug-in for Windows Media Player is the culmination of over 2 years of work and fully supports AAC on any 32/64bit Windows OS.

We would like to pass on a $2.00 off discount code below ($5.95 purchase price). This discount code can be given to friends, family or maybe you just need CoreAAC 2.0 for another computer.

Discount code: *****
Purchase here: https://customers.corecodec.com/cart.php?a=add&pid=8

You can share and use the code above as many times as needed until August 30th, 2010.

Thank you.

Regards,

Dan Marlin
CEO/CoreCodec, Inc.
http://corecodec.com
http://twitter.com/corecodec

Lets hope that this is the start of many releases overdue.
I for one, am desperately waiting for coreplayer 2 for symbian.

[BetaBoy]

This may seem harsh but I've always been a stanch supporter of CoreCodec and it's been nothing but disappointment for awhile now and the last 20 pages of this thread is supporting evidence of that fact.

- We have been listening to the feedback here while we are working on DXVA support for CoreAVC 2.1, and have been reviewing the feedback/bug reports being posted.... we may not respond here to every D9 post but we do read what is being said and thank those for all the great feedback.

- While that is going on we just released CoreAAC 2.0 tonight, see: http://forum.corecodec.com/viewtopic.php?f=30&t=3908&p=14872#p14872

- CoreASP 2.0 is under 'reconstruction' as we felt it was best to rework the code some more (since its like 3 codec code bases in one... and I am sure of you code junkies know what I mean about ASP)... this also includes ARM NEON (for our SDK Licensees).

- CorePlayer 2.0 is still a work in progress, but we are getting closer everyday now with just a few bullet points to go before we release it... including Android.

[BetaBoy]

LOL CoreAVC has this error for so long... (or in this case maybe haali) The same happens with BBC-HD. it always recovers and video is there to watch :p
Is this really an error? filters are not meant to seek backwards, as they only decode what they're given.

To be more precise... As far as "back by one GOP".... we can't "go back by one GOP" because the filter can't seek, it just receives data... ie; it shouldn't be showing frames until it is sure they're not incomplete.

[Audionut]

- While that is going on we just released CoreAAC 2.0 tonight.

We have officially launched CoreAAC 2.0 for you to purchase

http://forum.corecodec.com/viewtopic.php?f=30&t=3908

[ChronoCross]

Funny you say that.

Lets hope that this is the start of many releases overdue.
I for one, am desperately waiting for coreplayer 2 for symbian.

Indeed, pretty funny indeed. I've been waiting for CorePlayer 2 for Windows and Linux for quite some time now.

- We have been listening to the feedback here while we are working on DXVA support for CoreAVC 2.1, and have been reviewing the feedback/bug reports being posted.... we may not respond here to every D9 post but we do read what is being said and thank those for all the great feedback.


Just do a quarterly release for product updates. You don't even have to respond on any forums. All any of us care about is results, but 6-12 month release cycles don't exactly inspire confidence.


- While that is going on we just released CoreAAC 2.0 tonight, see: http://forum.corecodec.com/viewtopic.php?f=30&t=3908&p=14872#p14872


Interesting timing.


- CoreASP 2.0 is under 'reconstruction' as we felt it was best to rework the code some more (since its like 3 codec code bases in one... and I am sure of you code junkies know what I mean about ASP)... this also includes ARM NEON (for our SDK Licensees).


Duke Nukem Forever has been redeveloped 3 or 4 times. I got a good laugh when I read this one. Thanks.


- CorePlayer 2.0 is still a work in progress, but we are getting closer everyday now with just a few bullet points to go before we release it... including Android.

Non-vague release date?

[madshi]

@BetaBoy, two questions:

(1) Will CoreAVC get support for h264 MVC (3D) decoding?
(2) Will CoreAVC get support for h264 High 10 Profile (10bit) decoding?

Thanks!

[BetaBoy]

CC..... Is D9 the reason you state we 'don't reply'? We do our best to reply although your not likely going to see a reply on every forum to every post.... But we do our best.

CorePlayer on Linux is a challenge for distributions as many of you may know. Many of our OEM customers have been using it on Linux for years now... But this is a controlled distribution and much easier for us to manage. We have discussed a public release for a while.... Let's see what we can do about it in CP2.

Madshi.... No that is CoreMVC... And something you'll likely see later this year. On 10bit.... It's been discussed and once we get past DXVA, we will go there.

[madshi]

Madshi.... No that is CoreMVC... And something you'll likely see later this year. On 10bit.... It's been discussed and once we get past DXVA, we will go there.
Good to hear, thanks. For 10bit, which FOURCC are you planning to use? If I may suggest, the FOURCC values on this page seem like good choices:

http://msdn.microsoft.com/en-us/library/bb970578%28VS.85%29.aspx#fourcc_codes

There are also FOURCC values for 4:2:2 and 4:4:4 listed there, in case you plan to support native 4:2:2 and 4:4:4 h264 streams, too. In any case it would be great, if you could offer an option with which your decoder always outputs the *native* format without any conversion. So basically for 8bit 4:2:0 you would use YV12 or NV12, for 10bit 4:2:0 you would switch to FOURCC P010, and for 10bit 4:2:2 you would automatically use P210 etc. That would be the ideal solution.

[ChronoCross]

CC..... Is D9 the reason you state we 'don't reply'? We do our best to reply although your not likely going to see a reply on every forum to every post.... But we do our best.

As I stated in my last reply I could care less about replies on any forum.....I'm more concerned when it takes six months to a year for any bugfixes on a product. I simply used doom9's 20-40 pages of bug/product discussion since your last release as an example of why you should release bugfix versions more often.

[BetaBoy]

As I stated in my last reply I could care less about replies on any forum.....I'm more concerned when it takes six months to a year for any bugfixes on a product. I simply used doom9's 20-40 pages of bug/product discussion since your last release as an example of why you should release bugfix versions more often.

What bugs are outstanding in CoreAVC 2.0 in the last 20-40 pages that we have not addressed??? If anything was a show stopper we would have released a new version, but as I've stated we have taken this time to concentrate on the 5+ flavors of DXVA 1/2 done as it is no small undertaking, and is one of the major features we wanted to get into it now before we move that code over to working on adding higher AVC profile support and then MVC.

[BetaBoy]

Good to hear, thanks. For 10bit, which FOURCC are you planning to use? If I may suggest, the FOURCC values on this page seem like good choices:

http://msdn.microsoft.com/en-us/library/bb970578%28VS.85%29.aspx#fourcc_codes

There are also FOURCC values for 4:2:2 and 4:4:4 listed there, in case you plan to support native 4:2:2 and 4:4:4 h264 streams, too. In any case it would be great, if you could offer an option with which your decoder always outputs the *native* format without any conversion. So basically for 8bit 4:2:0 you would use YV12 or NV12, for 10bit 4:2:0 you would switch to FOURCC P010, and for 10bit 4:2:2 you would automatically use P210 etc. That would be the ideal solution.

Noted... Thx for the input.

[ChronoCross]

What bugs are outstanding in CoreAVC 2.0 in the last 20-40 pages that we have not addressed??? If anything was a show stopper we would have released a new version, but as I've stated we have taken this time to concentrate on the 5+ flavors of DXVA 1/2 done as it is no small undertaking, and is one of the major features we wanted to get into it now before we move that code over to working on adding higher AVC profile support and then MVC.

I wonder if you would say this to one of your corporate clients if they were complaining about these "non-showstoppers".

Anyway I'm tired of trying to convince you that you shouldn't release only major revisions once a year and that smaller minor bug fix releases would be helpful to customer satisfaction.

I've decided as a result of your reply to never purchase or recommend your products to anyone ever again. I know you won't find losing a single persons business all that harmful but oh well.

[BetaBoy]

and answering with a statement rather then answering what bugs we have not addressed and or replied too helps who? As far as releases... We think we have been good in the quality of the last few 1.9.x and 2.0 releases and making them as bug free as possible. I attribute that to 1) Our devs doing QA, 2) The amazing job the beta test group does 3) Sites like here at D9 and, 4) The feedback we get from our OEM customers... and to that... you are right, if there were any major bugs in 2.0 as it stands right now we would be aware of it, and we are not.

[Frank K Abbott]

The major bug I see is when seeking through mkv files. It is a problem that needs to be fixed. Seeking properly with open GOPs requires the decoder to go back an extra GOP. Also I have a small feature request. Can you add a width/height black border setting in pixels somewhere? When I stream to my tv it cuts off a bit from the sides and i have to end up zooming out a little bit through MPC-HC's zoom feature. unfortunately that zoom has big increments and i never get the picture perfectly showing. ffdshow has a pixel-based border setting which works out perfectly.

[Keiyakusha]

Can you add a width/height black border setting in pixels somewhere? When I stream to my tv it cuts off a bit from the sides and i have to end up zooming out a little bit through MPC-HC's zoom feature. unfortunately that zoom has big increments and i never get the picture perfectly showing. ffdshow has a pixel-based border setting which works out perfectly.
Why not put ffdshow postprocessor after coreavc and do any kind of processing you want? Way better than anything you can expect from single decoder.

[ChronoCross]

and answering with a statement rather then answering what bugs we have not addressed and or replied too helps who? As far as releases... We think we have been good in the quality of the last few 1.9.x and 2.0 releases and making them as bug free as possible. I attribute that to 1) Our devs doing QA, 2) The amazing job the beta test group does 3) Sites like here at D9 and, 4) The feedback we get from our OEM customers... and to that... you are right, if there were any major bugs in 2.0 as it stands right now we would be aware of it, and we are not.

Addressing complaints involves fixing them and providing that fix to your client base, responding with "noted" or "this is not a showstopper" doesn't constitute it being addressed. If it's fixed internally it means nothing if one has to wait 6 months to a year for a major release fix.

One of the issues that comes directly to mind (without me wasting time going through this thread) is seeking in CoreAVC takes 3-5 seconds while ffdshow, and Divx seeking is instant. If the other two weren't instant I would say it's my computer.

[Frank K Abbott]

Why not put ffdshow postprocessor after coreavc and do any kind of processing you want? Way better than anything you can expect from single decoder.

Wouldn't that mean that ffdshow would re-process the output coming from CoreAVC? My setup right now is MPC-HC, Haali Renderer, [CoreAVC auto in levels, auto out levels, output RGB32 (rest unchecked)], [ffdshow set to HQ YV12 -> RGB32, TV levels in, Computer levels out]. So it would be like RGB32 coming from CoreAVC being reprocessed to RGB32 again with ffdshow and with level conversions based on the tv in/comp out settings?

One of the issues that comes directly to mind (without me wasting time going through this thread) is seeking in CoreAVC takes 3-5 seconds while ffdshow, and Divx seeking is instant. If the other two weren't instant I would say it's my computer.

I have the same exact issue with CoreAVC. I think two people and more saynig the same exact thing without any agenda for their own product advertisement constitutes a problem with the decoder and not with the users or their computers.

[Keiyakusha]

Frank K Abbott
re-process? the only "processing" by CoreAVC is a converting to RGB. Turn that off by outputting yv12 and ffdshow will do conversion if you need RGB. Also ffdshow's conversion can give higher quality, depending on settings.
EDIT: well if you only need to add borders, you can leave RGB output in CoreAVC. Thats up to you.

[Frank K Abbott]

Frank K Abbott
re-process? the only "processing" by CoreAVC is a converting to RGB. Turn that off by outputting yv12 and ffdshow will do conversion if you need RGB. Also ffdshow's conversion can give higher quality, depending on settings.
EDIT: well if you only need to add borders, you can leave RGB output in CoreAVC. Thats up to you.

How do I adjust the filter chain in order to have CoreAVC decoding and ffdshow just post processing as you have said?

[Keiyakusha]

Add raw filter to MPC-HC external filters, set merit to preferred if it doesn't loaded, and configure as you like. It should be set to process colorspace that came from CoreAVC. Postprocessor (raw filter) now has separate settings from ffdshow decoder.
Adding to external filters is needed because due to some bug MPC-HC doesn't wants to load any filters between decoder and renderer. At least on Win7.

[Frank K Abbott]

Wow, I absolutely love this! Now I can post-process everything with AviSynth on-the-fly :D Thanks so much!

[BetaBoy]

I have the same exact issue with CoreAVC.
We are looking into what we can do to work around any open GOP.... but as even Haali just noted to me "how do you detect an open gop in the first place".

[squid_80]

Which splitter is being used by the people seeing corruption after seeking?

[kemuri-_9]

You can get it right for the vast majority of cases by saying it is open if the first frame in display order is a B frame.

that logic fails for open gop streams generated by x264.

[hajj_3]

What filetypes and codecs will Coreplayer for Android be able to play? Will it be powerful enough to play 720p via HDMI out with the 1GHZ snapdragon cpu's ?

[CruNcher]

Hehe on the Cortex A8 with Neon i guess possible though don't expect extreme profile support and bitrates for example 30 fps Realtime playback :D

[hajj_3]

i was hoping 3000 bitrate x264 1280x720 L4.1 might play on a snapdragon 1ghz cpu, would be cool to play 720p tv/movies on your tv from your phone, alot less power required compared to a laptop and silent.

[CruNcher]

Hajj_3 sure these solutions already exist (via HDMI out 1080p HP L4.1 Low Power no problem, as MIPS and ARM solutions with special Decoding IP) though not in Phone factors yet, will still take some time before they come to market and also what you can see currently they will be again limited according to rumors for example about the Nvidia Tegra2 and it's based Boxxe box (might disappoint many) also Omap4 in general seems to be limited.

[hajj_3]

yeah i know there's standalone devices that can play them like WD HD media player etc was just hoping that the snapdragon cpu's might be powerful enough to handle 720p. There's 1.2/1.3ghz dual core snapdragons coming in a few months too.

[Guest]

that logic fails for open gop streams generated by x264. They are not really open. I revised and extended my remark here:

http://forum.doom9.org/showthread.php?p=1416044#post1416044

[Frank K Abbott]

@ Keiyakusha
I just want to make sure I'm doing this right. I have CoreAVC set to output only YV12 and ffdshow set to output only RGB32 with high quality conversion and dithering enabled. ffdshow input levels are standard and output is computer. However I don't understand what CoreAVC is doing with the "Input Levels", "Output Levels", and "Input colorspace (set to auto)" if ffdshow is already doing those conversions and settings. Does CoreAVC only decode the stream and send it to ffdshow as is with no levels conversions or colorspace changes? I just want to make sure that CoreAVC isn't sending out video that is already "processed" in these terms and then ffdshow is reprocessing the levels through the RGB conversion section.

[Keiyakusha]

However I don't understand what CoreAVC is doing with the "Input Levels", "Output Levels", and "Input colorspace (set to auto)"
If you outputting yv12, with this settings CoreAVC should do nothing. Output should be "auto" too. The result should be the same as when you set input and output levels to TV in coreAVC, since DVDs, BDs etc. uses TV levels.

[p0w3rh0u5e]

Madshi.... No that is CoreMVC... And something you'll likely see later this year. On 10bit.... It's been discussed and once we get past DXVA, we will go there.
Thats great. :)

And while we're talking about future plans, i want to make a wish. As a future owner of one of those RED cameras, i would like to see something like CoreRED.

They offer a SDK and there is already a vdub-input-plugin, but being able to play those RED-files directly in MPC-HC & co would be great.

[Guest]

Seeking properly with open GOPs requires the decoder to go back an extra GOP. I should also mention that seeking requires that the required SPS and PPS be available. One needs some heuristics to find and inject them on a seek.

[Frank K Abbott]

If you outputting yv12, with this settings CoreAVC should do nothing. Output should be "auto" too. The result should be the same as when you set input and output levels to TV in coreAVC, since DVDs, BDs etc. uses TV levels.

Exactly what I was hoping for. BTW HQ YV12 -> RGB32 and dithering makes a beautiful output. The conversion is so much more superior to CoreAVC. :D It's awesome. Thanks again! :)

[cyberbeing]

Trying to playback one of the new 4K Youtube videos (4096x2304 x264) with CoreAVC 2.0 (software mode, CUDA disabled) produces a black screen with all renderers. FFDshow plays them just fine, so it seems CoreAVC's 4K support is broken. Since this is a somewhat major bug, I assume it will be fixed in CoreAVC 2.1?

[squid_80]

I should also mention that seeking requires that the required SPS and PPS be available. One needs some heuristics to find and inject them on a seek.

CoreAVC is a decoder, not a splitter. It cannot seek, its job is to decode what it is given (which is why I am asking what splitter people are using because gabest's splitter treats I frames as IDR frames).

[Galnospoke]

Trying to playback one of the new 4K Youtube videos (4096x2304 x264) with CoreAVC 2.0 (software mode, CUDA disabled) produces a black screen with all renderers. FFDshow plays them just fine, so it seems CoreAVC's 4K support is broken. Since this is a somewhat major bug, I assume it will be fixed in CoreAVC 2.1?


Confirm. The same problem.

[Frank K Abbott]

Trying to playback one of the new 4K Youtube videos (4096x2304 x264) with CoreAVC 2.0 (software mode, CUDA disabled) produces a black screen with all renderers. FFDshow plays them just fine, so it seems CoreAVC's 4K support is broken. Since this is a somewhat major bug, I assume it will be fixed in CoreAVC 2.1?

I can confirm the same.

@ squid_80

I don't know about others but I'm using Haali Media Splitter for nearly everything except for m2ts files. I use MPC-HC's "MPEG PS/TS/PVA" splitter for that so that I can properly see the audio/subtitle/video stream types and switch between them. Haali's Media Splitter has some issues with that.

[BetaBoy]

Thx for the reports... We are looking into the YT 4k problem.

[BetaBoy]

Can anyone post 'legal' examples that breaks 4k support in CoreAVC?

[lnatan25]

This is one of the 4K videos:
http://www.mediafire.com/?ugnenwm00mzfxum

It is taken from here:
http://www.youtube.com/watch?v=N0m1XmvBey8

[Stockpile]

Using Inatan25's download link, I was able to produce the same bug as mentioned previousley. A whole black screen, actually WMP doesn't even wanna play it.

[THX-UltraII]

I don't know about others but I'm using Haali Media Splitter for nearly everything except for m2ts files. I use MPC-HC's "MPEG PS/TS/PVA" splitter for that so that I can properly see the audio/subtitle/video stream types and switch between them. Haali's Media Splitter has some issues with that.


I ve also noticed that Haali has a problem with subtitles with .m2ts files. I ve uninstalled Haali and only checked MPEG PS/TS/PVA in the internal filters of MPC-HC. Everything seems to work fine this way. What are the benefits of using Haali instead of the internal MPEG PS filter in MPC-HC?

[rahzel]

I think there's issues again with the newer versions of x264. I'm experiencing the same glitchy video that v1.9.5.0 had with newer versions of x264 with v2.0 recently. It's not as severe as it was with 1.9.5.0, it happens sometimes when I skip forward and sometimes when a video is played a second time without closing (I use MPC HC).

[hajj_3]

any eta on the new version of coreavc betaboy?

[BetaBoy]

We are trying to finish up on DXVA1 DXVA2 to stay focused... but we have addressed some of the issues reported here on D9 for 2.1 as well. TBD on the release date.

[Cyber-Mav]

dxva1 is older hardware like nvidia 6800?

[Mangix]

DXVA1 = DXVA on Windows XP
DXVA2 = DXVA on Vista and up

[hajj_3]

no news?

[JohnnyFu]

Patience young padawan. I bet they are already preparing for the Christmas edition. Aren't you Betaboy?

[BetaBoy]

JF... I love your continued persistence at interjecting OT wisdom ;-)

hajj_3... we are continuing to work on DXVA2 atm no ETA.

[STaRGaZeR]

I bet they are already preparing for the Christmas edition

Yeah, 2011 :D

[ChronoCross]

Yeah, 2011 :D

Post here on Doom9 indicate the next release of CoreAVC with DXVA and DXVA2 has been in QC/Final dev since may. So your statement probably isn't too far off.

[hajj_3]

if DXVA2 is taking so long wouldn't it be better to include that in the version after the upcoming release as its been over 9 months since coreavc 2.0 was released. Thats why we don't wait for 9 months for new firefox releases, its better to have more frequent releases.

[STaRGaZeR]

Maybe they'll release a new version in Christmas 2011 without DXVA2, and the one with DXVA2 in Christmas 2012.

DXVA2, version 2.2, 2012. Sounds good to me :p

[JohnnyFu]

Now... look what I've done. Sorry Betaboy :)

@hajj_3
9 months? It's more like 5 years since GPU support was announced for the first time :)

[me7]

if DXVA2 is taking so long wouldn't it be better to include that in the version after the upcoming release as its been over 9 months since coreavc 2.0 was released. Thats why we don't wait for 9 months for new firefox releases, its better to have more frequent releases.

Firefox is open source and has new nightly builds each day, that's a completely different beast.

[hajj_3]

my analogy wasn't to compare the applications or that its closed source its that features are often dropped in order to make deadlines of a new firefox version every few months, thats what CoreAVC needs to do. Much better to release more frequently with a few new features and bug fixes each time.

[dwrbudr]

IMHO they are more focused on the mobile market right now.

[oddball]

CoreAVC is sorely in need of VC1 support. Heck even ffdshow supports VC1 in DXVA and that's freeware.

[me7]

Yes, a software that is called CoreAVC definitely needs VC-1 decoding :rolleyes:

There are real issues at hand, like the buggy decoding of open-gop AVC.

[Audionut]

Patience young padawan.

Patience is something that doesn't last forever.

http://img409.imageshack.us/img409/6393/coreplayer.png

[BetaBoy]

Audionut... Stop the OT interjection on something that has nothing to do with CoreAVC. We have discussed this openly on our forums why we have not release CP on Symbian and have for long time.

[Audionut]

Audionut... Stop the OT interjection


JF... I love your continued persistence at interjecting OT wisdom ;-)

Really, so others can OT in this thread when you agree with them, but I may not when I post something you don't like.

Pffft.

[BetaBoy]

Lets just keep it OT. Thank you.

[Thunderbolt8]

Yes, a software that is called CoreAVC definitely needs VC-1 decoding :rolleyes:
nevertheless, it would be nice to have the ability of multi core vc-1 decoding within the same software ;)

[NikosD]

@Betaboy
Hello. Since you are working on the DXVA version of CoreAVC, you could take a look at this:
http://forum.doom9.org/showpost.php?p=1432980&postcount=1
It includes a procedure to benchmark your DXVA implementation and some carefully chosen H.264 and other clips,that stress hardware decoders and codecs.

[Cyber-Mav]

when cuda is in use on nvidia cards the blue coreavc icon in the system tray turns green. when dxva is in use for ati cards will the icon turn red?

[BetaBoy]

@Betaboy
Hello. Since you are working on the DXVA version of CoreAVC, you could take a look at this:
http://forum.doom9.org/showpost.php?p=1432980&postcount=1
It includes a procedure to benchmark your DXVA implementation and some carefully chosen H.264 and other clips,that stress hardware decoders and codecs.
I have been following that thread and already noted it internally.

Red sounds good.. I'll throw it at the guys.

[Virtual_ManPL]

Any chances for fixing this bug in next CoreAVC release ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600
because using CoreAVC with other splitters (except bugged Haali) is not possible because of this...

[ney2x]

new forware 261.00 developer driver refers to CUDA.. i hope its good news to CoreAVC

http://forums.guru3d.com/showthread.php?t=331483

[mkanet]

I'm curious, how this would affect CoreAVC? I would think this would be better news for ffmpeg CUDA support for video encoding. As far as I know, CoreAVC already has CUDA support; unless the new Nvidia drivers would somehow improve CUDA performance in CoreAVC. I actually prefer to offload H.264 decoding to my GPU and leave my CPU for other tasks that my display adapter cant do.

new forware 261.00 developer driver refers to CUDA.. i hope its good news to CoreAVC

http://forums.guru3d.com/showthread.php?t=331483

[LigH]

Is it really a CUDA decoder program, or just the PureVideo decoder chip used by CoreAVC (like in DGDecNV)? They are not the same...

[nm]

Is it really a CUDA decoder program, or just the PureVideo decoder chip used by CoreAVC (like in DGDecNV)? They are not the same...

Yep. The only change I see there is that they moved the NVCUVID library (which CoreAVC and other "CUDA" H.264 decoders use) to the CUDA Toolkit. That library is an interface to the PureVideo hardware decoder. There are no functionality changes as far as I can tell.

[lych_necross]

Will the next version of CoreAVC include a workaround/fix for the open-gop seeking issue?

[Octo-puss]

next version of CoreAVC
Excuse me? I thougt yetti was an urban legend :P

[hajj_3]

we said it would be christmas before a new version of coreavc would be out, we might be right :P

[Octo-puss]

This year or the next? Oh wait it was the one before :P

[ChronoCross]

This year or the next? Oh wait it was the one before :P

I'm going with 2012. The same time earth comes to an end.

[weasel_]

Is it really a CUDA decoder program, or just the PureVideo decoder chip used by CoreAVC (like in DGDecNV)? They are not the same...
Just api for PureVideo chip..

[hajj_3]

Dear Father Christmas,

I have been a very good boy this christmas, please could i have CoreAVC 2.1, it would make me very happy indeed.

Thankyou!

Love hajj_3

[madshi]

Just received this email from Core:

Thank you for your support of a CoreCodec Technology. With CES about to launch, 2011 looks like it will be our biggest year to date with upcoming releases for:

- CoreMVC 3D MVC Video Decoder (directshow/windows)
- CoreMVC OEM SDK for Android, iOS, Windows, Linux, OS X

- CoreAVC 2.5 with improved performance and new support for DXVA 1, DXVA 2 in Windows
- CoreAVC 2.5 SDK with support for Android, ARM NEON, and faster 64bit performance

- CorePlayer 2.0 Platform Release for Android, iPhone and iPad

We will be demoing all the above products at CES this year (email: info@corecodec.com for info)
@BetaBoy, do you have anything interesting to add? :)

Three questions, if you don't mind:

(1) Do you have an estimated release date for the MVC decoder?
(2) Will Haali update his m2ts splitter to add support for 3D splitting?
(3) Which media type do you plan to use for 3D? Maybe we should finalize the work-in-progress new media type we've been working on... ;)

Thanks!

[popper]

"CoreAVC 2.5 SDK with support for Android, ARM NEON"

BTW betaboy, if your doing Neon then why dont you have a x264 NEON mentor available for the GSOC code in before it closes ? and so greatly improve the ARM speed ready for the end of CES

BTW theres also a new Freescale i.MX 6 quad ARM Cortex™A9, 1.2GHz, 1MB of L2 cache out
http://www.freescale.com/webapp/sps/site/overview.jsp?code=IMX6X_SERIES&tid=FSHBNR_20110103
http://www.linuxfordevices.com/c/a/News/Freescale-iMX-6/
"..the i.MX 6 series is Freescale's first ARM-based multicore SoC and first Cortex-A9 model. The processor advances the i.MX family with dual-stream 1080p video playback at 60 frames per second (fps), 3D video playback at 50Mbps, desktop-quality gaming, augmented reality applications, and novel content creation capabilities, says Freescale.

The SoC is also touted for being one of the first applications processors to offer hardware support for the open source VP8 codec. VP8 drives the related WebM open container format, both of which are supported in the most recent Android 2.3 release...."
but dont know if any product will be really ready for CES showing it as yet, you might look for it.

[Mixer73]

Wow wonder why I didn't get the email, I'm a registered user of CoreAVC?

[boiled_sugar]

AMD finally opened OpenVideo Decode, an API to use their decoder on Radeon GPUs via OpenCL.
Any plan to support it?

[7oby]

- CoreAVC 2.5 with improved performance and new support for DXVA 1, DXVA 2 in Windows
Is it a free update for purchasers of CoreAVC 2.0?

[popper]

AMD finally opened OpenVideo Decode, an API to use their decoder on Radeon GPUs via OpenCL.
Any plan to support it?


are you referring to the OVDecode.lib and its h.264 and related video header file as found in the The ATI Stream SDK v2.3 with OpenCL™ 1.1 support Christmas release
http://developer.amd.com/gpu/ATIStreamSDK/downloads/Pages/default.aspx

? if so it may be ok for windows use ,just one more option to decode your video in windows , but it does nothing for linux use as AMD in their usual half assed linux video fashion did include the header files, But Did Not Include the required OVDecode.so in their v2.3-lnx32 package, and No date as to if and when they may add it there.

[CiNcH]

Let me guess... 1.x and 2.0 licensees have to pay again for 2.5?

[iolaus]

Let me guess... 1.x and 2.0 licensees have to pay again for 2.5?

In my opinion, the upgrades have been a steal.

[ChronoCross]

Wow wonder why I didn't get the email, I'm a registered user of CoreAVC?

Wish they had a way to turn off their promo emails. I only want to receive free update emails instead of emails stroking their ego's in a masturbatory manner.

Is it a free update for purchasers of CoreAVC 2.0?

It'll probably cost money since it adds "so many" features.

Let me guess... 1.x and 2.0 licensees have to pay again for 2.5?

see above..... probably.

In my opinion, the upgrades have been a steal.

Not really. It's a peice of software that does one thing. Aside from the mobile platoform it's losing it's significance each day as the processors being included with newer machines can generally handle 1080p content.

[Shevek]

Not really. It's a peice of software that does one thing. Aside from the mobile platoform it's losing it's significance each day as the processors being included with newer machines can generally handle 1080p content.

My thoughts exactly. I used to use it all the time, but since upgrading to a newer HTPC which has a Radeon HD3200 GPU and AMD dual core CPU I've stopped using it.

It was causing all sorts of stutter and sync problems with 1080p and even 720p content. Uninstalled it and now all my HD content plays in DXVA perfectly

[yesgrey]

Let me guess... 1.x and 2.0 licensees have to pay again for 2.5?
Yes. With a discount, though.

[Mixer73]

Yes. With a discount, though.

While I grant that CoreAVC is cheap, I think charging for a dot release when there has not been a single intervening release is a bit crass.

[Virtual_ManPL]

Any chances for fixing finally this bug in next CoreAVC release ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600
because using CoreAVC with other splitters (except bugged Haali) is not possible because of this...

[me7]

Any news on the open-gop bug? I stopped using CoreAVC and reading this thread because of it.

[sneaker_ger]

The issue won't ever by fixed in the 1.x series, but was fixed in v2.0 long ago. If you own 1.x you have to pay again for 2.0 though.

(While I think CoreAVC is a solid product worth the money, you should also consider the free alternatives)

open gop != multi dupe weighted p prediction. Did you perhaps confuse those two?

[LoRd_MuldeR]

open gop != multi dupe weighted p prediction. Did you perhaps confuse those two?

Yes, I did. My mistake :o

(Removed the misleading post)

[IgorC]

Aside from the mobile platoform it's losing it's significance each day as the processors being included with newer machines can generally handle 1080p content.
That is. Mobile devices overcome the desktop ones.
The evolution is more like: desktop -> mobile -> ultra mobile, thin.
Now phones can do 720p and will be able to do 1080p.

It's huge market for CoreCodec. Even bigger than desktop.

[CruNcher]

Yep especially for the endless low price devices (out of Shenzen) that don't come with Powerfull DSPs (but that don't just want to provide the default PacketVideo stuff in Android) though even on the Software Codec side their is competition and provider from other parts of the World that do very efficient Codec Design like CoreCodec does, but for the Higher Price Platforms you can see that we finally in the Move to high Efficient 1080p DSP solutions, especially in the Tablet World and im not talking only about Tegra 2 btw which most of doom9 users wouldn't like anyway to use ;)

2011 will be a exciting year in terms of High Efficient Low Power Mobile Video :) not all Devices though will provide the bang for the buck and Tegra 2 definitely failed it (where most of doom9ers set the highest expectations into, Tegra 1 failed it last year in the 720p move and now Tegra 2 goes the same way in the 1080p move).

[ChronoCross]

That is. Mobile devices overcome the desktop ones.
The evolution is more like: desktop -> mobile -> ultra mobile, thin.
Now phones can do 720p and will be able to do 1080p.

It's huge market for CoreCodec. Even bigger than desktop.

It may be a bigger market, however it's a market that will also get far more pissed off if they don't see fixes/releases/enhancements more than once a year.

If they manage their mobile business like they've managed their desktop offering, they are going to become a quick joke in the mobile market.

[Barlow]

Uhm Betaboy was talking about a TRIAL version afaik.

[ranpha]

Let me guess... 1.x and 2.0 licensees have to pay again for 2.5?

Just have a confirmation, v2.5 will be free for those with v2.0 licenses.

[Mixer73]

Just have a confirmation, v2.5 will be free for those with v2.0 licenses.

OK cool, well I retract my prior statement....

[ChronoCross]

Just have a confirmation, v2.5 will be free for those with v2.0 licenses.

Confirmation from what? The make believe fairy? Hopefully core will send out a email or something to indicate a release date that isn't when I'm old enough to cash in my 401k.

[ranpha]

Confirmation from what? The make believe fairy? Hopefully core will send out a email or something to indicate a release date that isn't when I'm old enough to cash in my 401k.

http://imgf.tw/926102916.jpg

Also confirmed on their forums BTW.

[ChronoCross]

http://imgf.tw/926102916.jpg

Also confirmed on their forums BTW.

Will believe it when it actually happens. If you've known corecodec for any length of time (which I have), you know they tend to exaggerate.

For example it's been 1 year since CoreAVC 2.0. The last bugfix release was supposed to come out 6 months ago. That has come and gone without so much as a word. Betaboy is a talker without any real idea of what is going on behind the scenes.

[ranpha]

Will believe it when it actually happens. If you've known corecodec for any length of time (which I have), you know they tend to exaggerate.

For example it's been 1 year since CoreAVC 2.0. The last bugfix release was supposed to come out 6 months ago. That has come and gone without so much as a word. Betaboy is a talker without any real idea of what is going on behind the scenes.

So, do you think that the upgrade will not be free? This has nothing to do with their release schedule, but only whether the upgrade is free or not.

[dead_screem]

Will believe it when it actually happens. If you've known corecodec for any length of time (which I have), you know they tend to exaggerate.

For example it's been 1 year since CoreAVC 2.0. The last bugfix release was supposed to come out 6 months ago. That has come and gone without so much as a word. Betaboy is a talker without any real idea of what is going on behind the scenes.Release schedule has nothing to do with it. The way it's worked in the past was 1.x customers get free updates to all 1.x releases, but will have to pay an upgrade (discount) fee to to get 2.0.
Current 2.x customers will get free updates to all 2.x releases. And it hasn't been stated, but past paractices indicate that 2.x users will have to pay an upgrade fee to get 3.0 whenever that is released.

[ChronoCross]

So, do you think that the upgrade will not be free? This has nothing to do with their release schedule, but only whether the upgrade is free or not.

That's exactly what I'm saying. I think that they will find something to justify charging everyone.

[DigitalDeviant]

That's exactly what I'm saying. I think that they will find something to justify charging everyone.

Betaboy has already stated on the CoreCodec forums that there will be no charge for 2.0 customers.

http://forum.corecodec.com/viewtopic.php?f=3&t=4167#p15693

[Fadeout]

Eta?

...

[ChronoCross]

Betaboy has already stated on the CoreCodec forums that there will be no charge for 2.0 customers.

http://forum.corecodec.com/viewtopic.php?f=3&t=4167#p15693

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.