Talk:CoreAVC

From Wikipedia, the free encyclopedia

Contents


[edit] 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)

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

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

[edit] 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)

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)

[edit] 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)

[edit] 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)

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):
  1. 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.
  2. 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).
  3. 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.
  4. The DMCA takedown complaint was sent.
  5. The CEO (or others) attempted to contact the author to resolve the serial number problem. Perhaps successfully.
  6. Google took down the site.
  7. People noticed the site was down.
  8. Site outage reported, in blogosphere and elsewhere.
  9. Chilling Effects citation is made available.
  10. 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).
  11. CEO apologizes.
  12. Apology reported, in blogosphere and elsewhere.
  13. Site is restored.
  14. (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)
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)