View Full Version : CoreCodec/H.264 Codec "CoreAVC"
BetaBoy
17th April 2008, 19:35
coreavc.com/dl
dfrailey
18th April 2008, 04:25
Will there ever be a CoreAVC encoder?
Seems like there was talk of an impending release -- several years ago?
BetaBoy
18th April 2008, 09:46
Will there ever be a CoreAVC encoder?
Seems like there was talk of an impending release -- several years ago?
1 posting Phishing... i'll bite... Use :search: in this thread you'll find about a dozen pages back I mentioned our encoders will be out later this year...
What I would like to tell you all is that because of the D9 Elite asking for it, that we will soon be releasing a CoreAVC 64 Professional Edition. Don't ask how soon but it is on the short term roadmap here to get it QA'd and out.
deets
18th April 2008, 18:57
does 64bit give any speed advantages? not that it wont be handy just to have a proper suite of 64 video tools :)
BetaBoy
18th April 2008, 19:15
does 64bit give any speed advantages? not that it wont be handy just to have a proper suite of 64 video tools :)
Simply put, if it didn't increase speed we wouldn't do it.
Episodio1
18th April 2008, 19:43
betaboy, could u post encoding speed for a 720p encoding with "typical" settings? *^_^*
ACrowley
19th April 2008, 08:11
coreavc.com/dl
We are sorry but we could not find your email in our records. ?
BetaBoy
19th April 2008, 13:41
We are sorry but we could not find your email in our records. ?
PM me the email address you used and i'll look into it.
BlackSun
21st April 2008, 08:47
We are sorry but we could not find your email in our records. ?
You need to use your paypal email that you originally used to purchase CoreAVC.
ACrowley
21st April 2008, 16:31
You need to use your paypal email that you originally used to purchase CoreAVC.
Really ?:rolleyes:
Ofcourse i use the same Email !
qyqgpower
22nd April 2008, 14:16
thanks for the update. but 1.7 is still producing blockiness in blu-ray source while other decoders(mainconcept/libavc/cyberlink) work perfectly.
following captures are from this (http://www.kumonomukou.com/goods.htm) blu-ray disc.
blockiness seems only to appear in fade out or pure black scenes
http://img183.imageshack.us/img183/293/snapshot20080422204948fb6.th.png (http://img183.imageshack.us/my.php?image=snapshot20080422204948fb6.png)
42:13 fade out scene
http://img373.imageshack.us/img373/130/snapshot20080422203736da0.th.png (http://img373.imageshack.us/my.php?image=snapshot20080422203736da0.png)
1:25:10 pure black scene
do you need sample file again? :D
BetaBoy
22nd April 2008, 14:31
Yes... anytime you run into issues.... pls send us a sample to determine what the issue is... thanx!
qyqgpower
22nd April 2008, 16:05
trimmed by tsremux 0.0.20
first sample
http://www.mediafire.com/?0btmodbmzl0
second sample
http://www.mediafire.com/?odq32maojbw
Jay Bee
22nd April 2008, 17:29
Sounds like wrong field order. Does it go away when you set deinterlace to bob?
Beta Boy: Here's a Blu Ray sample: http://rapidshare.com/files/108034632/sample.ts.html
Inerestingly the stuttering begins after about 19 seconds of continuous play, even if I start playing at two different places! Another interesting thing is that it happens in both ZP and MPC.
I understand that EVR isn't officially supported under XP but maybe it's an easy fix as it works with v1.5, which uses YUY2 instead of YV12?
And about the field order problem. It's only with HW deinterlacing (not with bob) and my card is an ATI x1950 pro. v1.5 works correctly. Since x264.nl seems to be down, here is a sample file:
http://rapidshare.com/files/108028549/hd.forum.tf1.hd_1080i50.ts.html
Can anyone confirm these problems?
BetaBoy
22nd April 2008, 19:26
Jay bee and qyqgpower... We have identified that we will need to work on the issues with those samples as it looks like its related to these Blu-Ray's encodes of H.264 Motion Vectors. IE... (and here we go again) out of range, non AVC spec compliant Motion Vectors.
Last time we did a MV fix for this it was a 'simple' matter of expanding the range. But these examples... well they are something new ;-) We will have a meeting to see what can be done about it.... but i'd really like to find out what app they used to master these videos so we can notify them of the potential issue.
Thanx for the samples.
bobbert
23rd April 2008, 02:12
I'm trying the CoreAVC trial with 1080i AVCHD files from my camcorder (Canon HF10). I've tried the different deinterlacing modes, but I still see lots of interlacing artifacts. Also, the framerate seems to be 30FPS instead of 60FPS. The camcorder came with the Pixela decoder which gives me 60FPS and no interlacing artifacts, but I'd prefer to use something that will be supported and updated like CoreAVC.
Anything I can try to improve the motion and deinterlacing? System specs:
Vista Home Premium 32-bit w/ SP1
Intel Core2Duo e6550
nVidia 8800GT w/ 512MB
4GB RAM
Dethis
23rd April 2008, 07:15
I'm trying the CoreAVC trial with 1080i AVCHD files from my camcorder (Canon HF10). I've tried the different deinterlacing modes, but I still see lots of interlacing artifacts. Also, the framerate seems to be 30FPS instead of 60FPS. The camcorder came with the Pixela decoder which gives me 60FPS and no interlacing artifacts, but I'd prefer to use something that will be supported and updated like CoreAVC.
Anything I can try to improve the motion and deinterlacing? System specs:
Vista Home Premium 32-bit w/ SP1
Intel Core2Duo e6550
nVidia 8800GT w/ 512MB
4GB RAM
Try Haalli renderer instead of VMR9 renderless
bob0r
23rd April 2008, 11:08
...... and provide a sample.
bobbert
23rd April 2008, 18:03
Try Haalli renderer instead of VMR9 renderless
Can you explain how to do this?
bobbert
23rd April 2008, 18:04
...... and provide a sample.
Not from me, but this sample from the HF10 shows the interlacing problem when the cars drive by about 14 seconds in.
http://www.megaupload.com/?d=3AS3UJEZ
ADude
23rd April 2008, 22:03
Try Haalli renderer instead of VMR9 renderless
Where do you read that he is using VMR9 renderless ??
He doesn't even say what program he is using to playback the files, and he doesn't say how he knows that CoreAVC is even in use by that program.
bobbert
23rd April 2008, 22:27
Where do you read that he is using VMR9 renderless ??
He doesn't even say what program he is using to playback the files, and he doesn't say how he knows that CoreAVC is even in use by that program.
Sorry, using WMP11 and CoreAVC is listed as the video codec being used.
ADude
24th April 2008, 19:58
WMP11 uses EVR, and under Vista, that is the preferrable renderer, and is not the problem.
When you say "CoreAVC is listed" --- where ??
bobbert
24th April 2008, 22:20
WMP11 uses EVR, and under Vista, that is the preferrable renderer, and is not the problem.
When you say "CoreAVC is listed" --- where ??
Bringing up the properties of the video in WMP when it's playing. Video codec is CoreAVC Video Decoder.
Jay Bee
25th April 2008, 00:35
Jay bee and qyqgpower... We have identified that we will need to work on the issues with those samples as it looks like its related to these Blu-Ray's encodes of H.264 Motion Vectors. IE... (and here we go again) out of range, non AVC spec compliant Motion Vectors.
Last time we did a MV fix for this it was a 'simple' matter of expanding the range. But these examples... well they are something new ;-) We will have a meeting to see what can be done about it.... but i'd really like to find out what app they used to master these videos so we can notify them of the potential issue.
Thanx for the samples.
Thx. Did you also have a look at the field order problem?
Here's the link to the sample again: http://rapidshare.com/files/108028549/hd.forum.tf1.hd_1080i50.ts.html
And some more data for you (all tests with x1950 pro):
WMP11 default settings: wrong method (25 fps)
WMP11 high quality mode: wrong field order
Zoom Player Overlay: correct field order
Zoom Player VMR7: wrong field order
Zoom Player VMR9: wrong method (25 fps)
Zoom Player EVR: wrong field order
MPC Overlay: correct field order
MPC VMR7 windowed: correct field order
MPC VMR7 renderless: no deinterlacing
MPC VMR9 windowed: wrong method (25 fps)
MPC VMR9 renderless: no deinterlacing
MPC EVR: wrong field order
Personally I only care about the red modes, which work fine in CoreAVC 1.5, making 1.7 useless to me.
bobbert: I tried your sample with CoreAVC 1.5 and can't see any problems, 60 fps, no artifacts.
bobbert
25th April 2008, 01:48
Thx. Did you also have a look at the field order problem?
Here's the link to the sample again: http://rapidshare.com/files/108028549/hd.forum.tf1.hd_1080i50.ts.html
And some more data for you (all tests with x1950 pro):
WMP11 default settings: wrong method (25 fps)
WMP11 high quality mode: wrong field order
Zoom Player Overlay: correct field order
Zoom Player VMR7: wrong field order
Zoom Player VMR9: wrong method (25 fps)
Zoom Player EVR: wrong field order
MPC Overlay: correct field order
MPC VMR7 windowed: correct field order
MPC VMR7 renderless: no deinterlacing
MPC VMR9 windowed: wrong method (25 fps)
MPC VMR9 renderless: no deinterlacing
MPC EVR: wrong field order
Personally I only care about the red modes, which work fine in CoreAVC 1.5, making 1.7 useless to me.
bobbert: I tried your sample with CoreAVC 1.5 and can't see any problems, 60 fps, no artifacts.
Could it be that I am using an nvidia card? I've tried on 2 different Vista machines with nvidia cards (8800GT and 7600GT) and the result is the same.
Also I'm using the trial version of CoreAVC 1.7
Jay Bee
25th April 2008, 01:53
You could try Zoom Player and MPC and go through the different modes like I did above. Could be that Nvidia + Vista reacts quite differently than ATI + XP. These things even change from driver version to driver version.
ADude
26th April 2008, 02:28
Doesn't the 8800GT do hardware deinterlacing ?
bobbert
29th April 2008, 00:17
Doesn't the 8800GT do hardware deinterlacing ?
When I choose hardware deinterlacing in CoreAVC, it appears to be using the wrong field order.
BetaBoy
4th May 2008, 14:19
All... a quick question I would like to throw out at the D9 crowd as it does related to CoreAVC... Some of you know that we have already support FLV playback within our internal version of CorePlayer for a while. But with the recent announcement by Adobe we have now taken our FLV Container decoder library and created CoreFLV.
The question is since AVC video is the future of FLV usage... do we include the CoreFLV DS Decoder as a part of the current CoreAVC installer as an 'added' value or leave it out... as a stand alone product or other bundled product.
Well I suppose that depends on how you handle the pricing on it. If it's included in the price of CoreAVC, and would cost extra on it's own, then bundle it :) If it's free, leave it separate.
But I have a bigger question, don't all those videos load in the Flash player? That doesn't support DS filters, so why would we want such a filter? Unless CP plugs into the browser to replace Flash... which would be awesome!
This may sound stupid, but doesn't Flash use the MP4 container for AVC video?
Inventive Software
4th May 2008, 16:06
It's a slightly modified MP4 container, I think.
By all means include it, but also have it as a standalone installer.
No, FLV is a whole different container than MP4. Hence my question.
AFAIK,
http://www.adobe.com/devnet/flashplayer/articles/hd_video_flash_player_02.html
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb402866&sliceId=1
regards
BetaBoy
5th May 2008, 02:04
I should have stated that its more about splitting and the FLV container (like we do with the matroska directshow filter) and using CoreAVC.
Thanks a lot :)
i got it.
http://en.wikipedia.org/wiki/Flash_Video#File_Formats
BetaBoy
5th May 2008, 04:06
Also before the Slashdot crowd jumps in here.... Last week we received a complaint noting a DMCA violation on the Google Code project for "CoreAVC for Linux' (MPlayer). Under the terms of the DMCA we 'had' to act on that complaint and asked Google to take the project down.
Now... did we 'want' to do it? No and I am working with Alan (the project creator) now on what the complaint addressed so we can have Google restore the project.
ChronoCross
5th May 2008, 05:28
Also before the Slashdot crowd jumps in here.... Last week we received a complaint noting a DMCA violation on the Google Code project for "CoreAVC for Linux' (MPlayer). Under the terms of the DMCA we 'had' to act on that complaint and asked Google to take the project down.
Now... did we 'want' to do it? No and I am working with Alan (the project creator) now on what the complaint addressed so we can have Google restore the project.
i thought I was a slashdot whore lol.
I'm interested in what the reasoning behind it is. DMCA is such a complex thing
You received a complaint? From who and why? You aren't the carriers of the software. Does the DMCA require you to send DMCA notices for other people who send them to the wrong party? (Kinda doubt it.) As for DMCA violation? It,s not about copyright then? Are you trying to say in a sideways manner you used the DMCA for a trademark violation? (Not really meant for that ...)
You know we will eventually get to see the complaint and see why exactly you said it should be taken down right? :) There is really no reason to be so obtuse.
PS. just because you felt you had to act doesn't mean you should come in shooting and then start negotiating IMO. Why get lawyers involved straight away?
Reimar
5th May 2008, 14:11
You know we will eventually get to see the complaint and see why exactly you said it should be taken down right? :) There is really no reason to be so obtuse.
The complaint itself (http://www.chillingeffects.org/notice.cgi?sID=6324) is as well completely and entirely devoid of information.
And this is something I have a problem with. From the review some of the patches have received (on the MPlayer development list), at least some of that code is either mine or suggested by me, and while probably not in a legal sense, in a personal sense this is really close to slander.
I do hope there will be more information because otherwise I will take this personal (though you may have no reason to care).
Now... did we 'want' to do it? No
Then don't next time ... a private negotiation a few days before a take down notice is not going to lose you anything, except lots of free publicity at the cost of looking like *****. If that was the aim job well done I guess :/
CruNcher
6th May 2008, 01:56
Also before the Slashdot crowd jumps in here.... Last week we received a complaint noting a DMCA violation on the Google Code project for "CoreAVC for Linux' (MPlayer). Under the terms of the DMCA we 'had' to act on that complaint and asked Google to take the project down.
That sounds indeed on the first read as MfA said strange, without knowing the background story, i mean you "had" to react why ? isn't it fully @ your side to react or not i mean sure if someone pressured you to react (buisness customer, license administration) i could personaly understand this action :)
Infringing Materials Hosted on and/or Linked To From the Site. The Site hosts and/or contains one or more links to CoreAVC, which contains CoreCodec's copyrighted Software. We have directly verified by downloading the file from the Site provided by Google Inc. that the file does include CoreCodec's copyrighted Software.
I don't see a Problem here it's absolutely CoreCodecs right to forbid the distribution of their binaries also if many might think that the old 0.0.0.6 Alpha (i think was the one distributed by Dan here on Doom9 as tech Preview) is free it isn't. (Also who in the Hell would still use that i mean ffmpegs decoder should allready reached that Single Threaded Performance and with alot less bugs :D)
The same constitutes an infringement of CoreCodec's copyright in the Software. I request that you immediately remove or cause to be removed from the Site or any other site owned, operated or under the control of Google Inc., all access to and/or links to the Software. Failure to do so may subject Google Inc. to legal liability.
Hmm sounds like: "We don't want that you link (code) to our binaries and make usage of it via Mplayer" ????
Tough im a little out of date on that topic wasn't it Designed so that it only works with the original Serial Number??? and CoreCodec did aproved that back then ???
Or does CoreCodec now fears that someone could start reverse engineering (or has ?) the core of it to find out it's speed optimizations??? (But actually that sounds stupid sooner or later ffmpegs h.264 decoder is gonna reaching CoreAVCs Performance anyways without RE anything)
But yeah CoreCodec is in a problematic situation now with the whole CorePlayer/Betaplayer/Mplayer thing and i hope all this can be resolved peacefully (for the customers and OSS guys alike), seeing such actions is allways a bad sign that one (whoever that is maybe also this strange 3rd entity) doesn't seem to be happy with the current situation.
PS: This is in no way affiliated with the view of CoreCodec Inc. and just represents my own view of things here.
I don't see a Problem here it's absolutely CoreCodecs right to forbid the distribution of their binaries also if many might think that the old 0.0.0.6 Alpha (i think was the one distributed by Dan here on Doom9 as tech Preview) is free it isn't. (Also who in the Hell would still use that i mean ffmpegs decoder should allready reached that Single Threaded Performance and with alot less bugs :D)
However, in this case no binaries or other infringing material whatsoever were distributed, only instructions and patches to MPlayer, Xine and MythTV. The user could then use a legally obtained codec binary and corresponding keys. Copy protection was not circumvented because the codec binaries were used as-is and keys were supplied through a registry, just like on Windows.
Apparently the reason for the DMCA takedown request was that someone suspected that the CoreAVC for Linux project was based on reverse engineered information. However, DMCA does not forbid reverse engineering, so it was just a misunderstanding and we can all be friends again. See: http://www.corecodec.com/forums/index.php?topic=981.msg5780
Reimar
6th May 2008, 10:33
so it was just a misunderstanding and we can all be friends again. See: http://www.corecodec.com/forums/index.php?topic=981.msg5780
After reading this: Please learn a lesson and do not sign things you have not read properly.
Because this part: "We have directly verified by downloading the file from the Site provided by Google Inc. that the file does include CoreCodec's copyrighted Software." in the letter says _nothing_ about reverse engineering. If you can not be bothered to verify that what you are signing is true, then let whoever wrote it sign it.
CruNcher
6th May 2008, 18:03
@nm
Thx for the Link major mistake here (the 3rd party involved here seem to have been laywers).
But the reaction of the CEO is very Diplomatic he even acknowledged that he made a big mistake here, apologized and made a deal (whatever that includes) with the guys to continue, and yeah we are all Humans and no Machines.
But you know i personaly would find it much better if this was a major mistake (that's human behaviour) instead if it was planned and executed (especialy against OSS guys) to reach some goal (every action follows a reaction) (that is machine behaviour).
JonRead
7th May 2008, 21:59
Sorry if this is not the right place to ask (I am a total newbie with HDTV), but I have CoreAVC decoder installed and for some reason unless I have FFDShow installed I can't open h.264 videos in MainConcept Reference for encoding. Is there any way I can make it so that Reference uses CoreAVC to open the video files instead of FFDShow ? Reason being I get visible video glitches when encoding with FFDShow installed.
BetaBoy
8th May 2008, 00:52
Goto 'Start > Programs > CoreCodec > CoreAVC Professional > Configure CoreAVC' then check the 'Preferred decoder' to make sure it has the highest priority.
JonRead
8th May 2008, 01:17
Hi BetaBoy, cheers for that, there is good news and bad news. It seems to of allowed me to open h.264 files, but it wont encode, I get a "msvcr71.dll" error (it crashes) when I click "start encode" in Main Concept Reference. Any ideas ? It may not be your software at fault.
BetaBoy
15th May 2008, 07:54
Anyone want to have a shot at comparing to see if the DivX H.264 claims of speed to their new decoder are correct on their page? ATM they are boasting they beat CoreAVC. My initial tests in a small comparision says otherwise (but it is a welcome sight seeing a new product from DivX).
See: http://labs.divx.com/ProjectRemoulade
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.