Talk:CoreAVC

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.

Abandoned?

The link on the CoreAVC website to the page where you can buy the program is broken. I can't log in to my account anymore to download the software, too. I used http://www.corecodec.com/contact-us and asked if I could get a download link because I'm a customer who lost the setup file. I have waited weeks now and got no reply.

Merging sections

The last two sections on the page, "NVIDIA CUDA Support" and "ATI DXVA Support", hardly seem important or comprehensive enough to be given their own sections. I therefore suggest that a new section named something like "Features" or "Capabilities" is created and that the information of the two aforementioned sections is moved there, possibly along with the section "Multi-Platform support". This would seem to be in accordance with articles on media players and other codecs (x264, Media Player Classic, Windows Media Player). Being fairly new to editing on Wikipedia, however, I hesitate to implement these suggestions myself. --Khhlevir (talk) 15:21, 9 April 2011 (UTC)[reply]

Implemented suggested changes due to an underwhelming lack of feedback. Khhlevir (talk) 16:23, 19 June 2011 (UTC)[reply]

13 September 2010

Why is CoreAVC continually referred to as a codec? It's a decoder, not a codec (coder/decoder). 78.8.249.23 (talk) 15:12, 13 September 2010 (UTC)[reply]

25 April 2006

I'm one of the CoreCodec guys; however, I'm also a wikipedian, and this reads too much like ad copy. I've got too much of an interest to write a truly NPOV version of this.

Some of the big issues I had with this: "H.264 is the next-generation standard for video" - According to whom? "CoreAVC™ is being recognized as being one of the worlds most efficient H.264 software decoders." - There are benchmarks that support this statement, but it needs citing and attribution.

"The efficiency of CoreAVC™ in 'software' is often compared to be faster than other solutions that try to rely on hardware to increase playback performance of H.264 video." - Weasel words, attacking competors, avoiding specifics, and a run-on sentence to boot. We have benchmarks done by other parties that show CoreAVC is more efficient than other decoders most of the time, even with hardware support. It still needs to be cited.

"CoreAVC™ Standard Edition: Good for everyday users" - Ad copy, not NPOV

"CoreCodec has also indicated that they will have a matching video encoder finalized in Q3 2006 with beta testing running during the summer 2006." - Press releases aren't facts, so should they get quoted in an encyclopedia?

"CoreAVC is also included as a part of CoreCodec's mobile/desktop media efforts called CorePlayer. It will feature all of CoreCodec's developed decoders; CoreMP3, CoreAC3, CoreAAC+ v2.0, CoreAVC, CoreASP, CorePIX and for the desktop version will feature CoreDVD and CoreDTS." - NPOV, Ad Copy, Press Releases, and forward-Looking statements presented as current fact.

In short, the only parts of the article I have no problem with are the infobox, and the statement "AVC/H.264 can be stored in Matroska, MOV, MPEG-4, TS, and PS video files.", although I question the relevency of the latter to CoreAVC.

Cyt0plas 17:43, 25 April 2006 (UTC)[reply]

I tried fixing it. bruce89 11:50, 1 May 2006 (UTC)[reply]

"At december" Shouldn't it be "In December"? 24.168.117.235 21:39, 25 March 2007 (UTC)[reply]

CoreAVC Quality

User:Nil Einne decided to remove the mention of CoreAVC's quality issues, and suggested it is false. I haven't found any great sources, but there are a few to at least show there are problems.

The CCCP project's (uncited) wiki article.

A comparison between ffh264 and CoreAVC showed: "every frame was different." It would be almost trivial for someone to losslessly encode H.264 video, and use MPlayer to decode the original and H.264 versions with both codecs to conclusively determine if CoreAVC is in fact not accurate (and make a website out of it) but it seems no one has yet.

Since these aren't great sources, I didn't revert, but I think CoreAVC's quality issues are significant, important, and belong in the Wikipedia article. Rcooley (talk) 20:07, 6 April 2008 (UTC)[reply]

Er. One of those sources refers to bugs from versions which appear to be at least 1 year old [1], which may have been fixed by now. The other one is almost 1.5 years old and says that the frames are different, but also says the output still looks excellent. And the fact that the results are different doesn't prove that CoreAVC has quality issues since ffmpeg is NOT a/the reference codec and therefore it is easily possible ffmpeg is wrong (or both are wrong). (Even a reference codec could be wrong of course although in theory it's a lot less likely.) Indeed even if CoreAVC is wrong, it only means the codec is not frame accurate, it's not generally a quality issue unless you can see it. BTW, it is not possible to 'losslessly encode H.264 video'. H.264 is a lossly codec. (period) If you are talking about losslessly encoding H.264 video, I suggest you read up on Lossy compression and H.264. (Hint, if you recode a H.264 video with H.264 you get more loss, it's called Generation loss.) Note that even if(edit:though) H.264 ~~did~~(edit:does) have a lossless mode, any issues CoreAVC (or other codecs) have on it wouldn't prove that the they were right with the lossy mode since AFAIK these modes are likely to be different enough that one could be wrong one one, and one wrong on the other (edit:although obviously if CoreAVC is wrong with loseless, that would be pause for thought). BTW, in case you're wondering why I'm doubtful of the claims, I myself once thought it was possible to use estimations and do other tricks to produce a faster but lower quality output but when I suggested this on doom9.org, people who knew a lot more then video encoding then me said it doesn't work like that. Perhaps they were mistaken but the fact that CoreAVC is a highly popular commercial codec, and no reliable source has noticed anything like you claim (as I mentioned, neither of your sources support your claim that CoreAVC has quality issues), heck it doesn't even appear to be a common suggestion in non-reliable sources, suggests to me you are mistaken. It seems to me that with so many competitors, one of them would have noticed if H.264 was really totally borked. In any case, anything without a reliable source doesn't belong in a wikipedia article because nothing is significant or important from wikipedia's POV without a reliable source. Nil Einne (talk) 14:26, 1 May 2008 (UTC) Apparently I was mistaken and H264 does have a lossless mode, serves me right for not doing my research properly (I did actually do some research but got confused and thought the lossless mode wasn't able to encode a full video stream.) before I shoot of my mouth, so I've struck off my irrelevant points. However the rest of my points still stand so I haven't struck them. BTW, CoreAVC posslby doesn't currently support lossless mode, so the whole thing may be moot anyway [2] (their changelog is pretty crap, they don't seem to have updated their list of features not supported but they don't mention adding lossless mode anyway). If I understand [3] and H264 correctly, Enterprise will support lossless but none of the current versions doNil Einne (talk) 14:17, 13 May 2008 (UTC)[reply]

Benchmark

As someone pointed out in the article, the evidence/benchmarks are getting rather old now. It would be interesting to see if CoreAVC is still holding the lead, and if they are, how they compared to the older hardware solutions (AVIVO and PureVideo) with the latest generation of codecs and to the new hardware solutions (PureVideo 2 and Unified Video Decoder, they are surely going to lose here) Nil Einne (talk) 14:58, 1 May 2008 (UTC)[reply]

Page cleanup idea

Cleanup advertising style (fastest & greatest...)
- Replace with: it is xx times faster/better as others (ffh264 or so with a footnote link to mplayer.devel and others). Can somebody with a deeper insight do this? There is stuff on mailing lists but I don't know the value of this stuff. Around 20% faster is written in one mail. But I don't want to change this without more knowledge. Maybe it is better to drop the whole "faster" as stuff? And just say there is multithreading and this is missing in other codecs? (tried, delete the rest?)
What is it, what is the linux project, what can the codec do different to other codecs and how is it done? (tried it, is it okay?)
- Clear up the goal of the wrapper project, show what it is not. (done?)

The DMCA History
- What was done & why. (done, but could be better)

Okay? Please add comments.

—Preceding unsigned comment added by 78.94.55.211 (talk) 21:28, 5 May 2008 (UTC)[reply]

Just to clarify the DMCA history based on a Slashdot post by "karmatic" and CoreCodec forum's thread posts (and a small amount of my own speculation as glue):

The CEO downloaded the program and noticed that it had registry entries for a specific Windows product ID and a specific corresponding CoreAVC serial number/license key, hereinafter called the pair. See also RegisterCoreAVC.
The CEO thought that publishing the pair was an infringement of copyright, or that the pair or distribution containing the pair was a device that circumvented a technical measure (CoreAVC requiring a pair) that controlled access (whether or not CoreAVC ran) to a copyrighted work (the CoreAVC program) -- see DMCA 1201(a)(1)(A).
The attorney thought that issuing a DMCA takedown was a necessary step required by the DMCA. There was some concern that "failure to protect your IP can make it difficult to enforce in other cases", most likely conflating trademarks (which can be lost to inaction) and copyrights (which cannot be lost as easily), but perhaps considering other caselaw.
The DMCA takedown complaint was sent.
The CEO (or others) attempted to contact the author to resolve the serial number problem. Perhaps successfully.
Google took down the site.
People noticed the site was down.
Site outage reported, in blogosphere and elsewhere.
Chilling Effects citation is made available.
Forum discussion reveals that, even if copyright or 1201(a)(1)(A) was upheld for the pair, it is trumped by DMCA's reverse-engineering for interoperability section 1201(f)(2).
CEO apologizes.
Apology reported, in blogosphere and elsewhere.
Site is restored.
(Forward-looking speculation) CoreAVC-For-Linux gains ability to "grow a pair" as needed.

I hope this helps. Unfortunately, Slashdot postings are not necessarily WP:RS so I'm reluctant to add this to the main page. If better sources can be found then this could be added. Oh, and if the 4AM call could be placed, that'd be good too. --Goldfndr (talk) 02:31, 8 May 2008 (UTC) (Edited 02:53)[reply]

Hmm, I think this is getting too long for a wiki overview article. Can you sum this up and find sources (Mailinglist/svn log?) from the CoreAVC-For-Linux author and the CoreAVC people? All this /. postings can be just stuff to cover things up. If a product key was misused (or just accidentally posted) we can write this and clean things up. But we need verifiable confirmation. It could be possible that both the wrapper-writers and codec-writers don't really like to talk about this openly. Do you have a valid source that the snr/license key pair was exposed on the google code site? —Preceding unsigned comment added by 78.94.54.178 (talk) 12:29, 27 May 2008 (UTC)[reply]

I removed the "encoder part" it's 2008 now and nothing new about it is on the web, so at the moment it is more or less just marketing stuff, okay? —Preceding unsigned comment added by 78.94.227.122 (talk) 11:52, 19 August 2008 (UTC)[reply]

I am "Karmatic" on Slashdot; again, I'm avoiding making edits due to difficulty staying NPOV. If you need a more reliable source, I can throw something on a corporate blog, etc. Cyt0plas (talk) 15:28, 17 February 2009 (UTC)[reply]

NPOV Marketing again

I have the feeling we are getting into the marketing lane again. Please cite technical details/data or remove things like "Part of the performance advantage...". If noting more of value is cited, we should remove a few things. What do you think? It is hard to write about proprietary software, but it should be easier to get some data/facts or else we should remove the fluffy stuff. —Preceding unsigned comment added by 78.94.227.122 (talk) 14:28, 19 October 2008 (UTC)[reply]

Since no one was able to find a better formulation and SOURCES for the claim (since anon user above asked for them), i took it out.

"Part of the performance advantage comes from more effective use of multiple threads than most other decoders, as well as :optimization for SIMD-Extensions such as SSE or Altivec."

Please cite sources for above claim ("performance advantage" and causes of it).

--- 88.117.86.252 (talk) 07:09, 28 December 2008 (UTC)[reply]

I am looking around for some reliable third-party stuff, and I may try my hand at a cleanup here. I'm trying to avoid Wikipedia:No Original Research, as well as NPOV. Cyt0plas (talk) 15:31, 17 February 2009 (UTC)[reply]

CoreAVC usability

The article states the following: "The decoder is currently (as of 2010) one of the fastest software decoders, and even matches some hardware-based ones. This may allow computers with less processing power to play back lower-resolution AVC video content, and computers with more processing power to play high-definition video."

While the first sentence is undoubtedly correct, the second one is not just unproven, but also a tautology. It is incidental that a better performing decoder allows weaker computers a wider range of playback regarding video complexity. The next thing is that there is no clear definition of "computers with less processing power", making the whole argumentation pretty much unrelatable from any point of view. To me, this line has "marketing slogan" written all over it. Last but not least the statement is also inaccurate. It's not so much the resolution that limits video playback on less powerful computers, but the bitrate. Even pretty weak computers can play back HD-content if the bitrate is just low enough. I used CoreAVC on a 5 year old budget notebook (1.8GHz Celeron, 1.5GB RAM, Windows 7) and was able to play back 1080p content, granted that the bitrate wasn't too high. On the other hand, even 720p content could not be played back smoothly if the bitrate wasn't low enough, so while resolution is a factor when it comes to necessary decoding power, it still is of lesser importance compared to bitrate. 188.106.156.86 (talk) 22:12, 5 March 2011 (UTC)[reply]

OEM for Linux

The OEM edition of CoreAVC isn't necessarily the only edition available for Linux; there is a workaround for Linux known as "coreavc-for-linux" which can be used with MPlayer [4] [5], and is mentioned on the CoreAVC website within its corporate blog. However, since all mentions are from forums and blogs, how would WP:RS work in this case? Having the article claim that the only CoreAVC for Linux is OEM isn't accurate, but WP:RS is a bit of a hurdle that I'm unsure on. -- 李博杰 | —Talk contribs email 10:22, 14 July 2011 (UTC)[reply]

Development

Updated dev. status to discontinued as the site no longer points to anything other than just an apache page. — Preceding unsigned comment added by 79.79.63.181 (talk) 11:38, 18 January 2017 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on CoreAVC. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:10, 13 August 2017 (UTC)[reply]