Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
30th November 2006, 19:57 | #2381 | Link |
Registered User
Join Date: Dec 2005
Location: Qetchua mountains in Peru, and Klingon battlecruiser D'Mar
Posts: 393
|
Who cares! 1.1.0.5 is an "old" version, so CoreCodec don't offer it anymore.
__________________
Live long and prosperLive long and prosperLive long and prosper |
30th November 2006, 20:12 | #2382 | Link |
Registered User
Join Date: Mar 2006
Posts: 567
|
Ican also give the name of a player that is sold commercially and that bundles coreavc as well as some open source decoders like coreaac, gabest's mpeg2 decoder and others while being payware and closed source. And some people wonder why a small company that makes its money from selling a decoder and a player had to go the "let's implement activation" way...
|
30th November 2006, 21:59 | #2383 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
@KoD
What's the name?
__________________
Detritus Software |
30th November 2006, 22:06 | #2384 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Free-codecs is full of illegal and shady codec packs, they've hosted ones that bundle nero, elecard, on2, divx pro (before it was free), and others over the years. So no big surprise there. More to the point, full of system-killer codec packs. (The worst part was that it was usually the commercial codecs that are the buggiest, ripping up your system's directshow capability, not the free ones.)
|
1st December 2006, 13:00 | #2386 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
__________________
Detritus Software |
1st December 2006, 14:13 | #2387 | Link |
Registered User
Join Date: Mar 2006
Posts: 567
|
Yes, that's the one. Be careful if you plan on installing it... look in your Windows/system32 for a folder where it places all its bundled filters and make a backup of that folder. Upon uninstallation it deletes that folder but does not unregister the filters there, so you'll have to go back to your backup and unregister them manually. At least that's the painful memory I have of it. There's also the nice media files extensions hijack it does that's not reverted upon uninstall.
|
2nd December 2006, 18:25 | #2388 | Link | |
Registered User
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
|
Quote:
I still haven't received the e-mail with the updated version Should I contact you again? and how? |
|
2nd December 2006, 21:36 | #2389 | Link | |
Registered User
Join Date: Oct 2006
Posts: 1
|
pankov: i'm guessing you don't check CoreCodec's actual forums, which you probably should do
Quote:
|
|
4th December 2006, 21:01 | #2394 | Link |
Registered User
Join Date: Mar 2005
Posts: 468
|
The true secret of CoreAVC is not its unusually efficient AVC decoding code - which will someday be equalled and perhaps even bested by ffdshow - but a little-noticed capability which has slipped quietly under the radar of most everyone but myself...
The story begins long ago in the misty veils of ancient times, but to make it shorter, I'll summarize its most important points. The VMR9 renderer, for sure, and probably also VMR7, both have a strange behaviour regarding YUV data presented to their input pins. In particular, if any YUV format is presented, values outside the range of 16-235 (TV levels) are clamped; RGB inputs are not clamped. After uncountably extensive tests by yours truly using every filter combination imaginable, it has been determined that the clamping behaviour holds true for every case, and in no case is there an exception but one. Avery Lee, the creator of VirtualDub, has been investigating the strange quirks of luma levels in the VMR renderers here. You may be asking yourself right now, "why oh why would I want PC level range when most video is coded in TV range?". Some good reasons come to mind: your video output device is probably a PC monitor or LCD, which expects PC levels. Feeding TV levels to such a device results in washed-out blacks (compounding the backlight leakage already present on LCDs) and dim whites. During encoding or re-encoding, the AviSynth command: ColorYUV(levels="TV->PC") can be used to stretch the TV levels to fit your device, or alternately, ffdshow's 'levels' filter can do it in realtime. But if ffdshow is sending any YUV format to the renderer, this will be utterly useless due to clamping. Knowing this, it is time to shift the focus of our examination to CoreAVC. This nice little filter has a checkbox labelled "Fix VMR9 color range". When checked, the output of VMR9 is observed to be full PC range, using a full-range source and with any YUV format selected as output (and no, it's not secretly sending RGB; the input pin of the VMR9 renderer was checked to make sure). Never, ever in the history of VMR9 has any piece of software been able to make this impossible event occur. Somewhere in the VMR9 or elsewhere in the system, exists a method to force the VMR9 to pass full PC range without clamping, from a YUV input. It is also observed, that if CoreAVC is set to output any YUV format, and ffdshow is set to accept that format and output any YUV format (no RGB formats checked), then the renderer will observe the usual clamping behavior. Thus, the CoreAVC filter must be directly connected to the VMR9 renderer's input pin in order for the fix to work. The hope is now to find out how they did it. If the information can be obtained, developers of all other filters may also incorporate the fix into their software. The fix has many advantages; most importantly it means that ffdshow can output YV12 without the heavy CPU burden of conversion to RGB, yet still maintain PC range. To wrap up, a request is now issued to CoreCodec to provide this small tidbit of information, which would both provide the video community with a much-needed fix, yet still maintain the advantage CoreAVC enjoys by means of its efficient decoding architecture. Note: Verification The behavior as stated above can be verified by running three instances of MPC. Your should have two source materials, one encoded in TV range, the other PC range, output in either VMR9 or VMR9 Renderless. Drivers newer than 84.21 on Nvidia cards may cause unpredictable results. Finally, make sure ffdshow is NOT set to accept any raw video inputs, to avoid having it get in between CoreAVC and the VMR9 renderer. MPC #1: CoreAVC filter set to RGB32 output ("Fix VMR9 levels" checkbox state shouldn't matter) MPC #2: CoreAVC filter set to any YUV ouput, checkbox checked (should cause unclamped passthrough) MPC #3: CoreAVC filter set to any YUV output, checkbox unchecked (should cause clamping to TV range) If your source is TV range, #1-3 should appear identical and show TV range If your source is PC range, #1,2 should appear identical and show PC range, while #3 shows TV range. Last edited by Isochroma; 4th December 2006 at 22:37. |
4th December 2006, 22:17 | #2395 | Link | |
Registered User
Join Date: Mar 2002
Location: France
Posts: 85
|
For those interested.
What i have found on this matter is that there's a fix for vmr to force output PC levels, at least with nvidia drivers. This is it: Quote:
|
|
5th December 2006, 13:56 | #2396 | Link | |
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
Solution from DW helped the issue (and he told me a while ago before posted here on the forums :P) |
|
5th December 2006, 19:35 | #2397 | Link |
Registered User
Join Date: Mar 2005
Posts: 468
|
84.21 may clips VMR9 outside 16-235 over DVI, Latest Nvidia driver clips
Quote from the 84.21 driver release notes: "Video color-space range for DVI-only1 outputs is erroneously set to standard mode (16-235) instead of extended mode (0-255). A new detection feature to apply Standard CSC mode to TV outputs (including NTSC, PAL, 480i, and 576i), included DVI-only outputs by mistake. Note: The driver correctly applies extended mode to analog outputs, and standard mode to TV outputs (including NTSC, PAL, 480i, and 576i). A future driver release will correct this and apply the extended-mode color space to DVI-only outputs." 1. “DVI-only” means only one display is connected, and it is to the DVI output. Last edited by Isochroma; 5th December 2006 at 19:39. |
8th December 2006, 01:25 | #2398 | Link | ||
Registered User
Join Date: Jul 2003
Location: somewhere north
Posts: 260
|
Quote:
i have the problem to it says : Quote:
my little story/timeline (and am proud of it to!) 1. I downloaded the alpha codecs that was here in the forum 2: I got CoreAVC 1.1.0.5 of a friend (illegal) 3. I Bought CoreAVC 1.1.0.5 (Legal!) 4. I upgraded to 1.2.0.0(Legal!) 5. I have no clue but i cant use 1.2 as it says its already activated 6. I reverted to my friends one (illegal), but i payd for 1.1.0.5, but i cant download it anymore 7. Now i use 1.1.0.5 (illegal!) i think many people has my dilemma :/
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview) "Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat Last edited by wiak; 8th December 2006 at 01:35. |
||
8th December 2006, 03:07 | #2399 | Link |
Registered User
Join Date: Mar 2005
Posts: 433
|
I haven't installed 1.2 yet - I have a dual-boot system (two OSes on the same PC) and I NEED to have CoreAVC Pro working on both (one OS for video editing and previewing, the other for HTPC-only use). From what I read this isn't possible.
Or is it? Has someone tried it? |
8th December 2006, 03:10 | #2400 | Link | |
Registered User
Join Date: Jul 2003
Location: somewhere north
Posts: 260
|
Quote:
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview) "Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat |
|
Tags |
codec, coreavc, corecodec, coremvc, cuda, decoder, dxva, h.264, mvc, scam |
Thread Tools | Search this Thread |
Display Modes | |
|
|