CoreCodec/H.264 Codec "CoreAVC"

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