View Full Version : CoreCodec/H.264 Codec "CoreAVC"


Pages : 1 2 3 [4] 5 6 7 8

ChronoCross
7th August 2007, 18:41
For Windows OS you mean...because what about mplayer's patch (http://code.google.com/p/coreavc-for-linux/) to work on Linux ? :p

Currently, I'm able to use CoreAVC on my XP *and* on my Debian.

well it's supposed to be for a single OS.

CiNcH
7th August 2007, 23:07
Demo didn't make it till tuesday, did it?

BetaBoy
8th August 2007, 07:06
We are working on sales as we speak now and will have it out within a few hours.... demo to follow after that.

BetaBoy
8th August 2007, 07:34
On Linux.... I have discussed this a few times in this thread... We have juggled the idea of releasing our stand alone decoder library for Linux for a few months now. But there is a larger momentum internally to go the larger route (not just one decoder) that would allow third parties to take advantage of all the CorePlayer Platform decoders including ones not released to the public in stand alone form (CoreASP, CoreSVC, CoreAAC, CoreMP3, CoreDVD, CoreAC3, CoreWMA, CoreWMV, CoreVC1 as well as all our other decoders; 3GP, AMR, etc.)... We will talk more about it as devel moves closer.

Also on Linux... you will see by the end of the year that we have a bunch of CE licensees that are using CoreAVC Linux for various uses; DVR, PMP, MP, Set top box, etc. and yes some take advantage of onboard GPU.

CruNcher
8th August 2007, 12:41
@Betaboy

it's cool to see that CoreCodec optimized Decoders are gonna be used so widely in CE Devices :) a massive attack this is indeed, so it should be in the future possible to free CoreAVC from it's commercial chain for the average joye shouldn't it ;)

But the most important question of all what is up with the CoreAVC Encoder and How about DVD, HD-DVD and or Blu-Ray licenses for CorePlayer and how will the Speed and Energy usage of Coreplayer look like compared vs PowerDVD with Hardware accelleration on Windows Vista/XP ? (People shouldn't forget that the PV1/PV2 and UVD core also need Energy also if CPU usage is lower that says nothing about how high the GPU usage is and how much energy it needs to achive those framerates and for playback you only need to achive the framerates of the movie (+ overhead for Parseing/and Audio Decoding and maybe decryption) and not some benchmark results of 1xx frames hehe but people seem to forget this another thing ofcourse for (Hardware Encoding) ;)

PS: It would be cool if CoreCodec would design the XboX 360 Dashboard Multithreaded Decoder (AVC,VC1,ASP) next as Microsofts Engineers seem to have problems there to get it more performant even i would by a Xbox 360 then (i think this would be a real adventure for Picard) ;)

Selur
8th August 2007, 13:14
btw. any news about Windows version of CorePlayer?

deets
8th August 2007, 15:41
come on im sitting here waiting to give you my money for my new system :P

BetaBoy
8th August 2007, 18:20
A small delay as we have gone beyond what we wanted to do, but its all good.... the installer will now also support X64 Vista (not native x64). If we have a few volunteers that have already purchased CoreAVC and have x64 that want to test it, email me betaboy@corecodec.com

comrinec
8th August 2007, 20:10
How much does the coreavc decoder cost? I can't seem to find pricing or a place to buy it on the offical website and forum registration doesn't seem to be working there either.

Is it still faster at decoding than ffdshow? I get around 90% cpu usage using ffdshow on my athlon 3500 when I play the 1080p apple trailers.

Pomyk
8th August 2007, 20:23
Are there any plans to fix the motion vector issue?

ChronoCross
8th August 2007, 21:42
Are there any plans to fix the motion vector issue?

what issue? The motion vector thing is something in the specs of h264 and was corrected in the latest x264 revisions. Coreavc shouldn't have to handle things that the spec doesn't particularly support.

Else they will have to support every random quirk.

Pomyk
8th August 2007, 21:55
It is a bit out of spec but it doesnt mean it can't be implemented. Should be trivial even.

deets
8th August 2007, 22:32
A small delay as we have gone beyond what we wanted to do, but its all good.... the installer will now also support X64 Vista (not native x64). If we have a few volunteers that have already purchased CoreAVC and have x64 that want to test it, email me betaboy@corecodec.com

i will when i can buy it :)

Revgen
8th August 2007, 23:34
Well I didn't have the original source for the 5000kbps encode I told you about earlier, so I made a new one by bob-deinterlacing (with mvbob) some ATSC 1080i basketball footage.

Unfortunately, this 5000kbps 1080p 60fps encode didn't play at 59.94fps. The earlier one was encoded about a year ago or more.

All tests below are done by watcing the "statistics" while playing in WMP. I don't trust Haali's tester because sometimes it plays vids slower or faster than I can play them in WMP. I haven't figured out why though.

CPU: Athlon X2 Dual-Core 4600+
CoreAVC Version 1.5

Settings for all encodes: --keyint 600 --ref 5 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --analyse all --8x8dct --threads auto --thread-input --progress --no-psnr --no-ssim

Title: Basketball 1080p 60fps
Bitrate: 10000
Results:
Deblocking ON: 45fps
Deblocking OFF: 54fps <- Speed really improves here. Just a tad slower than the 5000kbps one. Even though it's only 2fps slower, it was a noticeable slowdown. The high bitrate keeps the lack of deblocking from looking too ugly.

Title: Basketball 1080p 60fps
Bitrate: 5000kbps
Results:
Deblocking ON: 51FPS
Deblocking OFF: 56FPS <- Looks pretty smooth even though it's not full speed. Quality is awful though.

Title: Basketball 720p 60fps
Bitrate: 10000
Results:
Deblocking ON: 59.94fps
Deblocking OFF: N/A

Title: Basketball 720p 60fps
Bitrate: 5000
Results:
Deblocking ON: 59.94fps
Deblocking OFF: N/A

Conclusion: Well aparrently I shouldn't need Quad-Core to get full speed at 5000kbps quality. I should only have to upgrade to Core Duo from my older Athlon X2. 51fps @ 1080p isn't bad for a 1st gen dual-core though. I wonder if Core Duo would be able to push the 45fps for the 10000kbps encode to 60fps or if a Quad is required to do so.

So, if any of you have Core Duo's or Quads and want to try these vids, I have the encodes below. I'm going to upload the 1080's for now, but if any of you want the 720's I can upload those too if you're interested.

Please tell me your results!

Basketball 1080p 60fps 10000kpbs

http://www.mediafire.com/?9y2xdhwwwdc

Basketball 1080p 60fps 5000kbps

http://www.mediafire.com/?cxsgwssnwz2

bmnot
9th August 2007, 01:07
what issue? The motion vector thing is something in the specs of h264 and was corrected in the latest x264 revisions. Coreavc shouldn't have to handle things that the spec doesn't particularly support.

Else they will have to support every random quirk.

Well could they add some option to hide the glitches or something, like cyberlink filters and vlc do?

pookguy88
9th August 2007, 01:19
I want to start using CoreAVC but I can't seem to get it to work. Right now I'm using Vista and ffdshow (CCCP). After I install CoreAVC (1.5) and uncheck the h264 decoding in CCCP; I goto play a h264 file in MPC and it says it can't find a codec. When I switch it back to use ffdshow it works just fine.

Any help is greatly appreciated, thanks!

BetaBoy
9th August 2007, 01:46
We have about 20 ppl testing Vista x64 and XP x64 now (thanx to all who emailed me!). It should only take a few hours for feedback so we can make any last minute adjustments (if needed) and release it.

ChronoCross
9th August 2007, 01:48
It is a bit out of spec but it doesnt mean it can't be implemented. Should be trivial even.

You should fix the streams rather than trying to alter the codec.

Dark Shikari
9th August 2007, 02:30
You should fix the streams rather than trying to alter the codec.
That's like saying you should fix the highway rather than make the car work on the road. People can't change the streams they receive (nor can CoreCodec), but the customers can go and decide to use libvacodec instead of CoreAVC.

oddball
9th August 2007, 02:48
BetaBoy any word on if you will do anything about those out of spec motion vectors? A simple 'Yes we will fix it' or 'No we won't because it's out of spec' will suffice.

pookguy88
9th August 2007, 02:54
We have about 20 ppl testing Vista x64 and XP x64 now (thanx to all who emailed me!). It should only take a few hours for feedback so we can make any last minute adjustments (if needed) and release it.

how about Vista x86?

BetaBoy
9th August 2007, 03:20
@Betaboy

it's cool to see that CoreCodec optimized Decoders are gonna be used so widely in CE Devices :) a massive attack this is indeed, so it should be in the future possible to free CoreAVC from it's commercial chain for the average joye shouldn't it ;)

But the most important question of all what is up with the CoreAVC Encoder and How about DVD, HD-DVD and or Blu-Ray licenses for CorePlayer and how will the Speed and Energy usage of Coreplayer look like compared vs PowerDVD with Hardware accelleration on Windows Vista/XP ? (People shouldn't forget that the PV1/PV2 and UVD core also need Energy also if CPU usage is lower that says nothing about how high the GPU usage is and how much energy it needs to achive those framerates and for playback you only need to achive the framerates of the movie (+ overhead for Parseing/and Audio Decoding and maybe decryption) and not some benchmark results of 1xx frames hehe but people seem to forget this another thing ofcourse for (Hardware Encoding) ;)

PS: It would be cool if CoreCodec would design the XboX 360 Dashboard Multithreaded Decoder (AVC,VC1,ASP) next as Microsofts Engineers seem to have problems there to get it more performant even i would by a Xbox 360 then (i think this would be a real adventure for Picard) ;)

CruNcher.... don't forget about Matroska adoption as well!!! We will have millions of hardware devices supporting it by the end of the year ;-)

On the CoreAVC encoder... while it would be great to put it out there publically, we think our efforts are better spent on CoreSVC since it is the future. We can always back track at that point and release CoreAVC as a standalone encoder.

On GPU.... our beliefs are the reliance in DXVA is a mistake by GPU vendors as a short cut and unnecessarily locks third party vendors into restraints right from the get go. While DXVA is more than just for decoding, its also for video processing and capturing (amung other things), we feel its outright overkill.

Although I am sure zambelli would disagree... Simple i/o hooks and a K.I.S.S. approach is needed.... don't believe all the other talk about what is required for GPU, and I am not going to comment on specific functions as they are pretty well known on these forums. Simply put, something needs to be done for the future of GPU and marketing must be fixed in order to move forward and garner mass adoption (Linux comes to mind first when thinking about this).

BetaBoy
9th August 2007, 03:21
how about Vista x86?

Thats done...

bob0r
9th August 2007, 03:32
@comrinec
CoreAVC 1.5 is much much faster than ffdshow, also still a lot faster than Cyberlink H.264 decoder.
Even with GPU support (and deblocking disable < voiding spec) Cyberlink is slower.

Ateme is running another test on Satellite too: HD5 on DVB-S2 Astra 1D (23 east)
Cyberink crashes, ffdshow cant show the video.... and guess what? CoreAVC can decode this stream just fine.

CoreAVC Professional will cost you 15 dollar or 15 euro i believe, if you can pay with dollars thats the best option :P



@pookguy88
CoreAVC 1.5 works on Vista 32bit Ultimate.



@oddball
I don't think the motion vector issue will be fixed.
CoreAVC has proven to uphold the specs in almost all cases were "bugs" were reported.
Some were indeed typ0 bugs, but the motion vector and "color issues" all turned out to be streams not upholding specs.
ffdshow/cyberlink/mainconcept all use the color output it seems, while CoreAVC detects the color input and even lets you decide to change it.
(BBC-HD has PC level colors.... but when you set it to TV level, the same video (kill bill 2) will look the same on SKY HD)

foxyshadis
9th August 2007, 04:31
Still, I'd argue that broken streams should have a form of error resilience, the same thing lavc has. Regardless of whether you consider too-long vectors broken or not - is it really that vital to enforce it? - slightly broken captures or spontaneous corruption are rare but normal, especially if you deal with a lot of files for a lot of people. Then again, I've seen professional DVDs with mastering errors that lavc mostly eliminates. I know cabac makes corruption more of of a pain, but don't you want to be known as the best-looking player, and not the fastest-with-occasional-dropouts? Look how many people get upset already at the minor decoding bugs 1.1 had.

pookguy88
9th August 2007, 05:55
@pookguy88
CoreAVC 1.5 works on Vista 32bit Ultimate.




how did you get it to work? it's not working for me

ChronoCross
9th August 2007, 05:59
That's like saying you should fix the highway rather than make the car work on the road. People can't change the streams they receive (nor can CoreCodec), but the customers can go and decide to use libvacodec instead of CoreAVC.

So that means you have to fix the car to drive a road made of spikes, or perhaps it should be invulnerable to flame. Where do you draw the line?

To be honest someone is always going to find a way to screw up their stream. So rather than adjusting the codec each time one of these happens it should stick to the pre-defined rules.

It's the failure to follow standards that has caused problems in website coding and now when you make a website you have to code it for 7 different browsers and use all kinds of workarounds. If people would follow the standard it would save tons of time and produce quality output on all browsers.

BetaBoy
9th August 2007, 06:55
how did you get it to work? it's not working for me

Its a matter of rights... MS released a Vista update that had hardened perms even more then the initial Vista release and is why some ppl can run it while others cannot (stock vs. updated os).

This is what I had said was fixed.

pookguy88
9th August 2007, 06:57
Its a matter of rights... MS released a Vista update that had hardened perms even more then the initial Vista release and is why some ppl can run it while others cannot (stock vs. updated os).

This is what I had said was fixed.

where can i get this update?

BetaBoy
9th August 2007, 07:10
As I had said earlier as soon as we get confirmation that the x64 installer alterations are fixed.

BetaBoy
9th August 2007, 09:05
ok... thx for the great feedback all!! CoreAVC Professional 1.5 is now officially launched and is ready for purchase @ www.coreavc.com . On tap next is the release of Standard Edition and the 14 day Trial version.

ACrowley
9th August 2007, 10:18
ok... thx for the great feedback all!! CoreAVC Professional 1.5 is now officially launched and is ready for purchase @ www.coreavc.com . On tap next is the release of Standard Edition and the 14 day Trial version.

nice


Problem :
I downlaod the installer again now, and i cant use 1.5.0.0 anymore...The 1.5 installer from Tuesday was working.
Now the graph cant connect and i cant acces CoreAVCDecoder.ax anymore...
I there anything new in the "off" 1.5.0.0 installer compared with the 1.5 from last Days ?

Question:
i still cant reset the Serial or somewhat when i have to make a new Xp Install( import it to another OS ?
Not nice, evertime whem i make a fresh Xp install i cant use my legal Coreavc anymore

BetaBoy
9th August 2007, 10:32
ACrowley sure you can.... simply submit a ticket @ http://support.corecodec.com

ACrowley
9th August 2007, 10:41
ACrowley sure you can.... simply submit a ticket @ http://support.corecodec.com

Ah Ok..thanks ..when i build a new System i will transfer the License

But whats with my Problem ? I should create a Ticket for it too ?..Holy

As i say i redownloaded 1.5.0.0. from CoreAccount .
After installtion the Files are located on C:\....correctly, but the .ax Decoder is not "registered"
I cant use it anymore on my Xp 32bit, cant reregister it manually ,nothing. Whats up ?

1.5.0.0 installer/Decoder from Monday was working.

PS
Top be honest , i can understand when people prefer to use a pirated .ax without Problmes
I simply want to use my legal CoreAVC and i cant...it takes more effort as a few 100$ Program

Ice =A=
9th August 2007, 12:17
Well, I've just downloaded 1.5 and first thing I got was an error message. When trying to configure it I get an "error loading CoreAVCDecoder.ax - DLL could not be initialised", and the codec won't work either.
I've been buying and using older versions of CoreAVC with no problems as well as your great CorePlayer for PocketPCs and really liked those! But recently all I've heared of the "core team" were (futile) measures against piracy (which don't make CoreAVC better for paying customers, they actually make it worse!) and endless delays. Sorry, I'm just wondering...
It would be great if you could give a statement about the way the core team is heading, BetaBoy!

Edit:
GREAT! Now I can't even install an older version, your online activation won't let me!
What should I do? Use pirated software instead?!

ACrowley
9th August 2007, 12:29
Well, I've just downloaded 1.5 and first thing I got was an error message. When trying to configure it I get an "error loading CoreAVCDecoder.ax - DLL could not be initialised", and the codec won't work either.

Edit:
GREAT! Now I can't even install an older version, your online activation won't let me!
What should I do? Use pirated software instead?!

LOL..same Problem here

When i try to reg the .ax manually i get the same Error Message

1st Installer from Monday "was" working, the new not

foxyshadis
9th August 2007, 12:39
Someone accidentally linked against the debug libraries, maybe?

Ice =A=
9th August 2007, 12:45
@ACrowley:
Ups, I just saw that you allready had written about the same as me... Well, maybe that will get someones attention... :) :(

ACrowley
9th August 2007, 13:34
@ACrowley:
Ups, I just saw that you allready had written about the same as me... Well, maybe that will get someones attention... :) :(

Hopefully....

@Betaboy..hello ??!:)

Inventive Software
9th August 2007, 13:40
He'll be asleep (West Coast America). Try again in a few hours. ;)

Jay Bee
9th August 2007, 13:41
Well I didn't have the original source for the 5000kbps encode I told you about earlier, so I made a new one by bob-deinterlacing (with mvbob) some ATSC 1080i basketball footage.



Why don't you just encode it as interlaced and let the GPU deal with deinterlacing on playback? I think it should be better for your CPU (and encoding time).

BetaBoy
9th August 2007, 16:32
We are looking into the issue. Thx for the reports.

BetaBoy
9th August 2007, 16:55
OK... thx to a few of our users it looks like a DLL dependancy issue for some XP users... this is why it works for some and not others. We are working on a fix.

Ice =A=
9th August 2007, 16:56
@BetaBoy: Sorry to tell you that I'm using Windows XP, not Vista...

BetaBoy
9th August 2007, 17:39
Good catch... I mis-spoke... it was XP. Post edited.

Viper Zx
9th August 2007, 17:42
Well, I've just downloaded 1.5 and first thing I got was an error message. When trying to configure it I get an "error loading CoreAVCDecoder.ax - DLL could not be initialised", and the codec won't work either.
I've been buying and using older versions of CoreAVC with no problems as well as your great CorePlayer for PocketPCs and really liked those! But recently all I've heared of the "core team" were (futile) measures against piracy (which don't make CoreAVC better for paying customers, they actually make it worse!) and endless delays. Sorry, I'm just wondering...
It would be great if you could give a statement about the way the core team is heading, BetaBoy!

Edit:
GREAT! Now I can't even install an older version, your online activation won't let me!
What should I do? Use pirated software instead?!



Same here!

Vista (x86)


Bye
Viper Zx

deets
9th August 2007, 17:46
let us know when as im holding off until its done for sure :)

Revgen
9th August 2007, 18:50
Why don't you just encode it as interlaced and let the GPU deal with deinterlacing on playback? I think it should be better for your CPU (and encoding time).

1) First of all. Interlacing should be illegal. ;)

2) I don't have a GPU that decodes AVC.

3) I was testing the decoder to see how it can go. If a software decoder can decode 1080p video at 60fps at a good bitrate, then it'll be great since nobody would need any fancy hardware.

Jay Bee
9th August 2007, 19:31
1) First of all. Interlacing should be illegal. ;)

2) I don't have a GPU that decodes AVC.

3) I was testing the decoder to see how it can go. If a software decoder can decode 1080p video at 60fps at a good bitrate, then it'll be great since nobody would need any fancy hardware.

1) Would be nice, yeah. But if the source is already interlaced it's too late.

2) You don't need one. Just set CoreAVC to directshow deinterlacing and it should work with anything from GeForce 6600 onwards. Even if your card is older you should get some kind of deinterlacing, although perhaps only at 30 fps.

3) Is it to be expected that any content will ever be made available in 1080p60?

BetaBoy
9th August 2007, 20:50
PPl that are having the issue with running the AX and can help us test... pls email me betaboy@corecodec.com so we can have you run past a few test installs. Thx!!

Revgen
9th August 2007, 21:08
1) Would be nice, yeah. But if the source is already interlaced it's too late.

2) You don't need one. Just set CoreAVC to directshow deinterlacing and it should work with anything from GeForce 6600 onwards. Even if your card is older you should get some kind of deinterlacing, although perhaps only at 30 fps.

3) Is it to be expected that any content will ever be made available in 1080p60?

1) It's not too late. MVBOB and MCBob do a pretty good job at deinterlacing. Better than anything playback deinterlacers can do.

2) The deinterlacing done by CoreAVC or GeForce don't match MVBob or MCBob. They aren't even close. And there is no way I'm watching sports at 30fps.

3) It won't be unless there are decoders that can decode it. I'm hoping that CoreAVC can pave the way. Once interlacing is gone, the better off editing and watching video will be.

Jay Bee
9th August 2007, 22:01
1) It's not too late. MVBOB and MCBob do a pretty good job at deinterlacing. Better than anything playback deinterlacers can do.

2) The deinterlacing done by CoreAVC or GeForce don't match MVBob or MCBob. They aren't even close. And there is no way I'm watching sports at 30fps.

3) It won't be unless there are decoders that can decode it. I'm hoping that CoreAVC can pave the way. Once interlacing is gone, the better off editing and watching video will be.

GPU deinterlacing may not quite match MVBob but they are pretty damn good nowadays. You should give it a try. And it's about 2000x more efficient i.e. realtime. And you don't need to double the amount of data before encoding if you leave it interlaced.

But we can agree that sports at 30 fps is unbearable and anyone who dares applying a 30 fps deinterlacer to sports content should be shot without trial. :)

EDIT: if you can upload a short sample of your basketball clip I'd gladly make a couple of comparison screenshots.

BetaBoy
9th August 2007, 23:41
OK... I now have a ton of Vista testers.... Now I need XP PPl that are having the issue with running the AX and can help us test... pls email me betaboy@corecodec.com so we can have you run past a few test installs. Thx!!

Guest
9th August 2007, 23:50
I clicked on your Buy Now link and I get a Paypal screen that just says "This session contains invalid data.".

How do I purchase CoreAVC?

ChronoCross
10th August 2007, 00:12
I clicked on your Buy Now link and I get a Paypal screen that just says "This session contains invalid data.".

How do I purchase CoreAVC?

Are you using a proxy that strips referrers or a browser that does? I've seen that take out paypal payment scripts. It's working fine for me.

Guest
10th August 2007, 00:31
Nope. No proxy and IE 6. This is beyond ridiculous now.

BetaBoy
10th August 2007, 00:38
Checked in IE 6, IE 7, FF, Mozilla, Opera, Netscape under Win98, 2000, XP and Vista and all works fine here as well as XP/IE7/FF from a third party location using a proxy.

Here try the E-Junkie direct link: LINK OMITED

Guest
10th August 2007, 00:55
Checked in IE 6, IE 7, FF, Mozilla, Opera, Netscape under Win98, 2000, XP and Vista and all works fine here as well as XP/IE7/FF from a third party location using a proxy.

Here try the E-Junkie direct link: https://www.e-junkie.com/ecom/gb.php?i=39353&c=single&cl=3582 Exact same result. Any more ideas beyond "works fine here"? I'd be happy to mail you a check.

I have all cookies, including seesion cookies, enabled.

BetaBoy
10th August 2007, 01:37
sure... adblocker? Is Javascript enabled? btw... I have omited that link as it needs to be parsed on our side from that PHP script. IE; http://www.coreavc.com/purchase_pro.php

However the error you received "This session contains invalid data." might be caused by e-junkie. We are testing the purchasing now.

JimmyZ
10th August 2007, 03:13
still not working on Vista x64?

Guest
10th August 2007, 04:35
sure... adblocker? Is Javascript enabled? btw... I have omited that link as it needs to be parsed on our side from that PHP script. IE; http://www.coreavc.com/purchase_pro.php

However the error you received "This session contains invalid data." might be caused by e-junkie. We are testing the purchasing now. No adblocker and Active Scripting is enabled.

CruNcher
10th August 2007, 08:28
@ bobor


Even with GPU support (and deblocking disable < voiding spec) Cyberlink is slower.

Hmm is this result based on a DualCore Cpu ?
For Singlecore i can definately say this isn't true Cyberlinks PV1 Decoder (i can only test PV1 Geforce 7600 GS) is still a tad faster (in terms of raw fps) then CoreAVC without deblocking (dunno about DualCore yet ;) ) Results based on Windows XP Sp2 Low Latency Driver optimized ), but as i said all the Benchmarks @ the moment on the net about PV1/PV2 and UVD say nothing about it's Energy Efficiency compared vs CPU useing CoreAVC (they only test raw fps or most only CPU usage on every site, but not GPU usage and the resulting Energy consumption) :P, but ok if you gonna build a CE Device as Betaboy allready said you would go the K.I.S.S way so Broadcom AVC/VC1 DSP and you good to go and for sure with less Energy loss, but for all the HTPC builders i think this should be compared anyways CoreAVC + current low voltage CPU vs GPU based decoding + low voltage cpu and then measure the power of both systems and take this into account in the benchmarks (in times of raising energy prices) energy efficiency of Codecs (for a given purpose you wan't to reach) should be tested too. (Exactly in this terms Microsoft tweaked VC-1 over H.264)

BetaBoy
10th August 2007, 09:08
ok.... all ppl that have had an issue pls login to the core account and download the new installer and give it a shot. If you run into an issue we have setup a debug installer to see whats breaking for some users.

Guest
10th August 2007, 09:19
ok.... all ppl that have had an issue pls login to the core account and download the new installer and give it a shot. If you run into an issue we have setup a debug installer to see whats breaking for some users.
Don't I have to complete my purchase first? What's up with that?

ACrowley
10th August 2007, 09:27
@Bobor

ep..i can confirm it. On my A64 X2 4800 ,CyberlinkH264Decoder without DXVA is slower compared to CoreAVC!
Where Cyberlink has ~90% CPU Load, CoreAVC has 70-80%

Same on my Single Core AMD

@BetaBoy
No..new installer wont work on my Xp. Same Problems .

But why was the 1.5.0.0 installer from Monday working , any new Protection ?
1st .ax was 181kb, new ax is 184kb. Its only a installer/Activation change ,right ? Caused by the pirated Version ?

Maybe you should go back to the 1st installer until youve fixed your Reg Problems ,so that People can use the Product for the payed Money ?

bob0r
10th August 2007, 09:46
coreavc.com > "Buy now $19.95"
buy now button (paypal) > CoreAVC Professional Total: $14.95USD http://x264.nl/unsure.gif

Viper Zx
10th August 2007, 10:27
ok.... all ppl that have had an issue pls login to the core account and download the new installer and give it a shot. If you run into an issue we have setup a debug installer to see whats breaking for some users.

New installer OLD Problem! Does NOT work!

.AX not registered.



Vista (x86)

Bye
Viper Zx

CruNcher
10th August 2007, 10:47
@Bobor

ep..i can confirm it. On my A64 X2 4800 ,CyberlinkH264Decoder without DXVA is slower compared to CoreAVC!
Where Cyberlink has ~90% CPU Load, CoreAVC has 70-80%

Same on my Single Core AMD


He talked about with GPU support


Even with GPU support (and deblocking disable < voiding spec) Cyberlink is slower.

Ice =A=
10th August 2007, 14:42
I just downloaded the new version and in my case it seem so work now! (I wouldn't bet that it would work if I had to e.g. reinstall windows, but for now it's ok. :)) Thanks!

Guest
10th August 2007, 15:11
My bad. PayPal.com was on my blocked sites list. :eek:

So I am able to get to the purchase page now. Next step: purchase it and try to activate it.

Sorry for the distraction.

BetaBoy
10th August 2007, 18:10
It looks good so far... we are still tracking 1-2 more issues related to installers getting "Installer has been tampered with" or 'Installer is out of date"

KoD
10th August 2007, 18:37
No adblocker and Active Scripting is enabled.

No adblocker, huh ? ^^

BetaBoy
10th August 2007, 20:38
We have found only 8 ppl with issue with the "Installer has been tampered with" or 'Installer is out of date" and have reset their downloads. As of right now all the ppl that had reported installer bugs have been fixed. However there still maybe a few adjustments that will be required to the installer that is OS specific that we might have to. Thanx again to all the testers and patience by everyone while we worked on the issues.

We will see how it goes over the weekend and if all is well, we will then release Standard Edition and the Trial version.

Viper Zx
10th August 2007, 22:14
Output folder: C:\Program Files\CoreCodec\CoreAVC Professional
Extract: CoreAVCDecoder.ax... 100%
Extract: CoreAVCReadme.txt... 100%
Could not load: C:\Program Files\CoreCodec\CoreAVC Professional\CoreAVCDecoder.ax
Could not load: C:\Program Files\CoreCodec\CoreAVC Professional\CoreAVCDecoder.ax
Created uninstaller: C:\Program Files\CoreCodec\CoreAVC Professional\CoreAVC Professional-uninstall.exe
Completed



I have new downloaded the installer now.
Does not work!



Bye
Viper Zx

andybno1
10th August 2007, 22:30
just grabbed new installer and wahey I have it installed :D wateva was causing the installer to not detect productID has been fixed :D

just one question though how do I get coreavc associated with mkv? since installin new version mkv is opening with the cyberlink h.264 codec with terrible playback with batman returns

ToS_Maverick
10th August 2007, 22:42
coreavc has a lower merit as cyberlink h264. you have to use gspot to set it higher.

andybno1
10th August 2007, 22:47
I set coreavc as prefer in mpc but its using cyberlink still

EDIT: and now when I blocked cyberlink it has nothing to playback mkv

ChronoCross
10th August 2007, 23:27
I set coreavc as prefer in mpc but its using cyberlink still

EDIT: and now when I blocked cyberlink it has nothing to playback mkv

what type of file class is it returning for the filter it's looking for?

bob0r
11th August 2007, 00:26
@andybno1
Check if you can open CoreAVC properties, via MPC (double click in external filters)

or

start/program/CoreCodec/CoreAVC Professional/Configure CoreAVC

If that opens, you know at least that its registered with windows, and thus activated.

andybno1
11th August 2007, 02:04
well I think we have found the problem, I get the following if I re-register or un-register

http://img483.imageshack.us/img483/9301/corecodecgr5.jpg

DigitalDeviant
11th August 2007, 02:46
well I think we have found the problem, I get the following if I re-register or un-register

http://img483.imageshack.us/img483/9301/corecodecgr5.jpg

This was the same error I had from the install log to the dll initialization error. The problem was on the account side (iirc they had the wrong serial in my account). Have you opened a ticket through Core?

Delerue
11th August 2007, 03:15
So, if any of you have Core Duo's or Quads and want to try these vids, I have the encodes below. I'm going to upload the 1080's for now, but if any of you want the 720's I can upload those too if you're interested.

Please tell me your results!

Basketball 1080p 60fps 10000kpbs

http://www.mediafire.com/?9y2xdhwwwdc

Basketball 1080p 60fps 5000kbps

http://www.mediafire.com/?cxsgwssnwz2

I want to try, but unfortunately these links are broken. Can you re-upload them, please?

BTW, when you run these videos you get CPU full load all the time?

Cheers.

Dark Shikari
11th August 2007, 03:37
I want to try, but unfortunately these links are broken. Can you re-upload them, please?

BTW, when you run these videos you get CPU full load all the time?

Cheers.
Both of the downloads work fine for me...

Delerue
11th August 2007, 03:53
Both of the downloads work fine for me...

Yeah. I tried now and worked. Maybe it was a Mediafire server bug. I'll bench my Allendale right now with these videos. :)

EDITED: man, these videos are REALLY heavy. Althought they run well here, the CPU usage with the 10000kpbs one was around 60%, with a maximum of 72%. But, hey, I'm talking about a Core 2 Duo running at 3 GHz! I think that I found the heaviest video. Thanks to CoreAVC it can be decoded perfectly. :)

ACrowley
11th August 2007, 08:50
well I think we have found the problem, I get the following if I re-register or un-register

http://img483.imageshack.us/img483/9301/corecodecgr5.jpg

So its not fixed ,right....Oh man, ia it ao hard to fix it ?, i cant belive

Revgen
11th August 2007, 10:14
Yeah. I tried now and worked. Maybe it was a Mediafire server bug. I'll bench my Allendale right now with these videos. :)

EDITED: man, these videos are REALLY heavy. Althought they run well here, the CPU usage with the 10000kpbs one was around 60%, with a maximum of 72%. But, hey, I'm talking about a Core 2 Duo running at 3 GHz! I think that I found the heaviest video. Thanks to CoreAVC it can be decoded perfectly. :)

Wow. I was pretty confident the Core Duo would do the 5000kbps one. I wasn't so sure about the 10,000kbps one though, but your report sounds awesome. Apparently Quad-Core isn't needed as far as playback is concerned for most videos. 1920x1080p/10,000kbps/60fps is about as good as it gets for AVC.

foxyshadis
11th August 2007, 11:37
Well, unless you play an HD disc with 18Mbps avg/28Mbps peak. What's the peak on that clip? (Don't have the bandwidth to download now.)

arfster
11th August 2007, 14:41
Nasty clips those. For comparison, I ran the 10mbit one through PDVD's decoder in software mode, and my C2D 3.2ghz manages 60% average. The 5mbit one is barely less, at around 55%.

Lowering the clock to e6400 speeds (2.4ghz) and it only just manages the two, hitting 90%. Any slower and I think some frames would be dropped.

Incidentally, although the peak is only 15mbit, that clip is actually much harder on the CPU than a high bitrate AVC Bluray title like Pirates of the Carribean. I ran a sequence with avg 20mbit/peak 45mbit, and it averaged 40% CPU at 3.2ghz. Probably the key difference is that 60fps really eats CPU compared to 24fps, regardless of the bitrate.

Crisidelm
11th August 2007, 15:32
Could somebody check if they have a better Quality Chroma upsampleing now (compared to Mainconcept/Elecard and FFdshow High Quality Mode) (quality problem i told the devs some months ago, can't read anything about it in the Changelog so that suprises me somehow)

I recorded a couple of minutes of a football match on Premiere HD (1080i, variable bitrate), and send it to a friend who's got CoreAVC 1.5.0.0. He compared it against Mainconcept codec (set to Software of course), and told me that CoreAVC isn't quite up to it qualitiy-wise yet.Furthermore he told me that with CoreAVC it wasn't fluid, losing frames every few seconds, whilst with Mainconcept the TS played absolutely fine (CPU is E6600).

Jay Bee
11th August 2007, 15:39
Apparently Quad-Core isn't needed as far as playback is concerned for most videos. 1920x1080p/10,000kbps/60fps is about as good as it gets for AVC.

If want hard, do 1080p60 lossless AVC. :) I'm not sure 4 cores would suffice.

Jay Bee
11th August 2007, 15:42
I recorded a couple of minutes of a football match on Premiere HD (1080i, variable bitrate), and send it to a friend who's got CoreAVC 1.5.0.0. He compared it against Mainconcept codec (set to Software of course), and told me that CoreAVC isn't quite up to it qualitiy-wise yet.Furthermore he told me that with CoreAVC it wasn't fluid, losing frames every few seconds, whilst with Mainconcept the TS played absolutely fine (CPU is E6600).

I wouldn't mind a piece of that clip to test on 1.5. :) Did you tell your friend to set CoreAVC deinterlacing mode to directshow? It's essential to smooth motion as the default CoreAVC setting will half the resolution.

Crisidelm
11th August 2007, 16:02
Yes, Standard deblocking and DirectShow deinterlacing.
The file is 254MB (a few seconds short of two minutes of play)...

Delerue
11th August 2007, 17:49
Wow. I was pretty confident the Core Duo would do the 5000kbps one. I wasn't so sure about the 10,000kbps one though, but your report sounds awesome. Apparently Quad-Core isn't needed as far as playback is concerned for most videos. 1920x1080p/10,000kbps/60fps is about as good as it gets for AVC.

Yeah. Dual-core seems to be enough, but I think that Pentium 4 and Athlon X2 isn't capable of. So we need a high CPU clocks and a really great architecture. Let's hope Barcelona do the job with less GHz. :)

I ran a sequence with avg 20mbit/peak 45mbit, and it averaged 40% CPU at 3.2ghz. Probably the key difference is that 60fps really eats CPU compared to 24fps, regardless of the bitrate.

You're right. The heavy factor here is the FPS. Comparing to 24 FPS we're talking about almost 250% of additional job. :)

If want hard, do 1080p60 lossless AVC. I'm not sure 4 cores would suffice.

Sorry if I'm saying *******, but lossless don't use high compreession algorithms, right? Maybe the space in disk is higher than the CPU usage. Lossless audio (FLAC, for example) works in that way. What you think?

arfster
11th August 2007, 19:47
I wouldn't mind a piece of that clip to test on 1.5. :)


Some 16mbit h264 1080i from BBC HD's Wimbledon coverage:

http://rapidshare.com/files/46651266/BBC_HD__H264_AC3_eng__07-07_13-25-26.ts.03.ts.html

andybno1
11th August 2007, 20:32
This was the same error I had from the install log to the dll initialization error. The problem was on the account side (iirc they had the wrong serial in my account). Have you opened a ticket through Core?

no I haven't but shall do now ;)

espentan
11th August 2007, 21:55
well I think we have found the problem, I get the following if I re-register or un-register

http://img483.imageshack.us/img483/9301/corecodecgr5.jpg

That's the very same error I'm getting.

Tried to download the installer twice just to verify it's not caused by a broken installer, or whatever.

Fix, pretty plix?

K k tnx bye :)

Delerue
11th August 2007, 22:20
Some 16mbit h264 1080i from BBC HD's Wimbledon coverage:

http://rapidshare.com/files/46651266/BBC_HD__H264_AC3_eng__07-07_13-25-26.ts.03.ts.html

Weird. I can't hear the audio track of this video. I'm using MPC last build by clsid (http://forum.doom9.org/showthread.php?t=128616) + CoreAAC 1.2.0.575; using the MPC AAC internal decoder doesn't change. If I use VLC I get the same thing. But if I use SMPlayer (a MPlayer GUI) I can hear the audio, but no video.

mitsubishi
11th August 2007, 22:50
Weird. I can't hear the audio track of this video. I'm using MPC last build by clsid (http://forum.doom9.org/showthread.php?t=128616) + CoreAAC 1.2.0.575; using the MPC AAC internal decoder doesn't change. If I use VLC I get the same thing. But if I use SMPlayer (a MPlayer GUI) I can hear the audio, but no video.

The audio is AC3, try AC3filter.

BetaBoy
11th August 2007, 23:58
I recorded a couple of minutes of a football match on Premiere HD (1080i, variable bitrate), and send it to a friend who's got CoreAVC 1.5.0.0. He compared it against Mainconcept codec (set to Software of course), and told me that CoreAVC isn't quite up to it qualitiy-wise yet.Furthermore he told me that with CoreAVC it wasn't fluid, losing frames every few seconds, whilst with Mainconcept the TS played absolutely fine (CPU is E6600).


I'd like to try that clip or see actual stats on that. On quality I'm not sure how your friend can state that really... I mean its 'bit-exact', you are not gonna get any more 'quality' out of it.

BetaBoy
12th August 2007, 00:02
Anyone with the AX issue can submit a ticket... http://support.corecodec.com/index.php?_m=tickets&_a=submit

Although I do think we have the installer bugs fixed... we think the ppl here that are reporting the AX problems were those who had downloaded and installed the old un-fixed installer.

(Although I reserve judgement on that still ;-) . . . anyway we will keep track of any potential issue.

BetaBoy
12th August 2007, 00:03
That's the very same error I'm getting.

Tried to download the installer twice just to verify it's not caused by a broken installer, or whatever.

Fix, pretty plix?

K k tnx bye :)

Likely because your install needs to be reset... pls submit a ticket to have the staff do this for you. http://support.corecodec.com/index.php?_m=tickets&_a=submit

Revgen
12th August 2007, 01:48
Well, unless you play an HD disc with 18Mbps avg/28Mbps peak. What's the peak on that clip? (Don't have the bandwidth to download now.)

I'm not sure exactly. I don't have pro tools to analyse peak bitrate for AVC. Unless there are open-source ones available.

Also, do HD-DVD or Blu-Ray support 1080p 60fps? I thought they only supported up to 1080p 24p.

DeadRinga
12th August 2007, 02:31
Betaboy... XP had recently needed to re-activate on my machine for whatever reason and now CoreAVC 1.5 cant re-activate... Who should i email?

foxyshadis
12th August 2007, 05:13
I'm not sure exactly. I don't have pro tools to analyse peak bitrate for AVC. Unless there are open-source ones available.

Also, do HD-DVD or Blu-Ray support 1080p 60fps? I thought they only supported up to 1080p 24p.

They support it, but only movies have come out so far. Wait until the soccer tapes start showing up. :p But really, the whole TV industry seems to be moving toward 24p or sticking with interlaced for now, so unless you watch a lot of BBC or sports it doesn't look like most people will have to deal with this.

I'm not surprised 60p adds 50-80% to the decoding power, that's a lot more macroblocks, especially if there are few skips. Didn't realize it wasn't 24p last post.

Crisidelm
12th August 2007, 07:36
I'm not sure exactly. I don't have pro tools to analyse peak bitrate for AVC. Unless there are open-source ones available.

Also, do HD-DVD or Blu-Ray support 1080p 60fps? I thought they only supported up to 1080p 24p.

In Italy a movie on BD has come out that is 1080i50 ("Memorie di una Geisha" is the title, dunno the English name). Also che HD-DVD about 2006 World Cup in Germany is 1080i50 afaik. Are there any more BD or HD-DVD out there that are not 24p?

Crisidelm
12th August 2007, 07:39
I'd like to try that clip or see actual stats on that. On quality I'm not sure how your friend can state that really... I mean its 'bit-exact', you are not gonna get any more 'quality' out of it.

On quality it's just a matter of personal opinions: since I can't compare myself the two codecs output.
If you want to test the file, I'll see if I can upload the file somewhere...

Revgen
12th August 2007, 08:01
In Italy a movie on BD has come out that is 1080i50 ("Memorie di una Geisha" is the title, dunno the English name). Also che HD-DVD about 2006 World Cup in Germany is 1080i50 afaik. Are there any more BD or HD-DVD out there that are not 24p?

1080i50?

The "i" typically stands for interlaced. A correct way to say it would be 1080p50. 1080i50 would mean 50 interlaced fields. That would be 25 fps not 50fps. Can you link me to this movie?

I'm not saying you're wrong, I just want some confirmation. The specs I've seen at this Wiki http://en.wikipedia.org/wiki/HD-DVD#HD_DVD_.2F_Blu-ray_disc_comparison don't mention 60fps or 50fps at 1080p.

Unless there is some kind RFF flag type of strategy that converts 50p or 60p to 60i or 50i like Pulldown flags do for DVD.

ACrowley
12th August 2007, 09:21
Anyone with the AX issue can submit a ticket... http://support.corecodec.com/index.php?_m=tickets&_a=submit

Although I do think we have the installer bugs fixed... we think the ppl here that are reporting the AX problems were those who had downloaded and installed the old un-fixed installer.

(Although I reserve judgement on that still ;-) . . . anyway we will keep track of any potential issue.

I have no old Registry entries from working installer anymore...
everything was clean

It it a charge to submit a Ticket ? And when i aubmit a Ticket...how long do i have to wait for a working ax ?
..since 3 Days i have no working Decoder for my money.
SRY but im very dissapointed

Crisidelm
12th August 2007, 10:01
1080i50?

The "i" typically stands for interlaced. A correct way to say it would be 1080p50. 1080i50 would mean 50 interlaced fields. That would be 25 fps not 50fps. Can you link me to this movie?

I'm not saying you're wrong, I just want some confirmation. The specs I've seen at this Wiki http://en.wikipedia.org/wiki/HD-DVD#HD_DVD_.2F_Blu-ray_disc_comparison don't mention 60fps or 50fps at 1080p.

Unless there is some kind RFF flag type of strategy that converts 50p or 60p to 60i or 50i like Pulldown flags do for DVD.

The references are the Italian purchasers who confirmed that: in fact it was a surprise since it is much more fluid than other BDs or HD-DVD that are 24fps on several VPRs that don't support natively 24fps/60fps. I can link you to Italian forums where it's been discussed, but it's only in Italian, of course.
Btw, this is the film (in English): http://en.wikipedia.org/wiki/Memoirs_of_a_Geisha_%28film%29
From what I can read, it's even specified on the cover of the BD:"Attivato operazioni di indagine. In effetti, rispetto alla prima fascetta resa disponibile da eagle (potrei sbagliarmi, parliamo di un paio di mesi fa) il 1080@23,98p è diventato 1080@50i. Parrebbe quindi che il film sia stato encodato a 50i. La cosa è molto strana, anche perchè da quanto mi risulta, "Memorie" è stato gilrato in pellicola"...


BTW, a link to download the TS I mentioned before: http://rs154.rapidshare.com/files/48477373/GermanFootballHD1080i.ts

bob0r
12th August 2007, 11:17
@Crisidelm

Thats .ts file is not a valid .ts file.

I noticed the same issue too, but i had a feeling it came from Tandberg's encoder, as other PAFF-interlaced clips run just fine.

In all honesty i forgot to capture a soccer sample to be tested :p

Crisidelm
12th August 2007, 12:10
bob0r, probably when I cut the 100MB from the original 254MB .TS I did something wrong: Tsplayer, the program I used for cutting (and for viewing) isn't quite perfect, for the cutting part at least.

CruNcher
12th August 2007, 12:36
@ Crisdelm
as bob0r said it was wrongly captured the .ts will most likely not open in most commercial solutions try to remux it with non commercial stuff like mplayer,mencoder or tsremux then it should be standard complaint :)


Sequence Summary:

File Size Processed: 100.04 MB, Play Time: 00h:00m:42s
47.38 FPS (Average), 18.58 Mbps (Average).
AC3 Audio: 2/0 Channels (L, R), 48.0 kHz, 448 kbps.
Dialog Normalization: -27.0 dB

I can reach 42.49 fps (deinterlaced jitter 13ms 2 frame drops) 24.79 fps (interlaced jitter 4ms 0 frame drops) here with my 7600 GS PV1 Cyberlink (real Playback Fullscreen 1680x1050 (but still it stutters sometimes seems PV1 comes to an end here, but also the stream seems not very well balanced (complexity wise) ) (Colorspace: i think YUY2 but who knows what PV1 and Cyberlink do internaly :P) (VMR9 Windowed)

CoreAVC gives me 20.20 (deinterlaced dshow jitter 38ms frame drops 1082) 22.01 fps (interlaced jitter 36 ms 23 frame drops) for this Stream (real Playback Fullscreen 1680x1050) (Colorspace: YUY2 Active) (VMR9 Windowed)


Benchmark Results:

User: 25s, kernel: 2s, total: 28s, real: 38s, fps: 70.8, dfps: 52.9 (Cyberlink PV1 deinterlaced) (VMR9)

User: 31s, kernel: 0s, total: 31s, real: 39s, fps: 64.1, dfps: 51.3 (CoreAVC non deinterlaced) (VMR9)

and yes i think that Bitstream is an older one seeing the red stripe on the bottom like in earlier Premiere HD Film times i doub't this stream is a new one is it ?

Edit: Real Playback in Exclusive VMR9 Renderless Mode (3D Surface) is Flawless with Cyberlinks Decoder and PV1 not 1 frame drop and jitter is perfect :)

Crisidelm
12th August 2007, 14:40
Well, it's a match played yesterday, Bayern Munich-Hansa Rostock, it can't be that old :)
I can watch it perfectly too using Mainconcept codec with my E6400 slightly overclocked too. Also with Cyberlink H.264 codec , DxVa on, and my 7600GT it's completely fluid.

Crisidelm
12th August 2007, 15:47
Used Tsremux, choosing TS...hope it works fine now.
http://rapidshare.com/files/48540171/GermanFootballHD1080iok.ts.html

BetaBoy
12th August 2007, 17:26
I have no old Registry entries from working installer anymore...
everything was clean

It it a charge to submit a Ticket ? And when i aubmit a Ticket...how long do i have to wait for a working ax ?
..since 3 Days i have no working Decoder for my money.
SRY but im very dissapointed

No charge, and likely its not about your side but ours that has to be reset.... its the weekend but the staff usually logs in a few times on there own to work on tickets, but i'd say first thing tomorrow AM (EST).

Jay Bee
12th August 2007, 18:45
Thanks for the sample files. For me the BBC clip is perfect with CoreAVC and MPC. The Premiere clip is slightly stuttery (maybe a splitter issue?) and both are horrible in Zoom Player (any ideas?).

C2D @ 2.7 GHz, 7950 GT.

Crisidelm
12th August 2007, 19:25
Both are flawless for me using Tsplayer (which uses Dvbviewer Source filter for splitting purpose), E6400 at 2.6GHz and 7600GT (but I prefer using Mainconcept codec therefore software mode only). Live viewing is flawless using Mainconcept only with AltDVB though, while it stutters with Dvbviewer.

CruNcher
12th August 2007, 20:02
Stuttering can also be coused by latency problems (bad programed applications running in the background (polling every once in a while or doing some other nasty stuff)
For Example for me it's problematic to let Portrait Displays: Forte Manager (Monitor Calibration software with Direct Film Mode management for my LG LCD) running in the background it couses Micro stuttering it access every 10 secs the cpu by 2% on playback this can be problematic and setting the Player to high priority not allways helps their as this can couse problems with the dshow filters and their priority.

Jay Bee you have to debug everything to find the couse for your problems, but if you have a Nvidia card i can advice you to try the Exclusive VMR9 Renderless Mode, it reserves every power your machine has for the Fullscreen Playback (Windows XP)
Vista has a new type of Multimedia Scheduler in the Kernel that should avoid such latency problems (but only if the applications support it @ the moment only WM11 and PowerDVD do i think)

it's funny to see your C2D stuttering compared to my Singlecore 2.4 Ghz AMD chip and 7600 GS card (but that's the difference to Consoles, most of the times you tweaking your machine and try to find problems couseing this kind of slowdowns and hey isn't it fun :D )

Fact is for my System CoreAVC has no (Speed, Quality advantage) in Playback over GPU assisted Decoding with my 7600 GS @ native LCD resolution of 1680x1050 especialy for Sattelite (Interlaced content) as i can use Nvdias Motion Adaptive Deinterlacing with Cyberlink their and this is as good as YADIF(BoB) on the 7600 GS and in realtime so 1080p @ 50 fps for the Premiere sample here) very nice for 2.4 Ghz and a GFX card you can get for under 50€ (almost as cheap 2nd hand as CoreAVC costs ;)) now but better go with a 2nd Generation card based on ATI/Nvidias new Video cores those have even better Deinterlacing in realtime and even less CPU use :) (but still no one yet compared ATI/Nvidias Hardware Cores vs CoreAVC in Energy Efficience)

BetaBoy couldn't Picard speedup Yadif and add MBAFF and PAFF support a little with some ASM magic and you implement it as your Software Deinterlacing mode (non Bob and BoB mode selectable from the GUI) in CoreAVC 2.0 ;) or at least get a license from Nvidia to use their Hardware Deinterlacing for some speedup here. (I would add both because of the Editing Aspect of CoreAVC)

CruNchers Sugesstions for CoreAVC 2.0:

+ Add a Better (Quality) Software Deinterlacing like YADIF as Option (let the users chose in the Gui wich one to use YADIF or the Simple one)
+ Support at least ATI/Nvidias Motion Adaptive Hardware Deinterlacing PV1/PV2/UVD
+ Add better Chroma upsampleing (like Mainconcept and FFdshow can make use of)

this also would apply for CoreDVD and most probably CoreVC-1 aswell

Crisidelm
12th August 2007, 20:06
Yes cruncher, the stuttering in Dvbviewer may be caused by the program itself polling the signal level, which causes an abnormal cpu hit with DVB-S2 cards BDA drivers by Technotrend/Technisat. Unfortunately with Dvbviewer you can't tweak that polling task, whereas ALTDVB lets you choose a huge time span between each polling thus offering a workaround for that bug.

hekoheko
12th August 2007, 21:20
GermanFootballHD1080iok.ts


A64 3200+

Lowest CPU 0%, peak was @ 10%.
"Little" help provided by ATI Radeon HD2600XT. :p

And use 50hz with that clip, only way to play smoothly since its 25fps.

Crisidelm
12th August 2007, 21:41
Sure, but try it without Dxva then tell us...

hekoheko
12th August 2007, 22:12
Sure, but try it without Dxva then tell us...

It's powerpoint then. :)

BetaBoy
13th August 2007, 16:26
Ok... we have tracked down two installer bugs that pulls in the 'Owner ID' rather then the product ID and then bombs the install. Its limited to only a handful of purchases atm and we will push a release out later today/early tomorrow once we verify they are fixed (yes, with the new 1.5 readme).

BetaBoy
13th August 2007, 16:30
Additionally.... we have received impressive CoreAVC Professional 1.5 SMP '4 Core' test results on some very high B/W files.

Also on the 60FPS comments..... Haali noted to me that:

<Haali> btw, don't forget that playing 60fps video on a 60fps display will almost always drop frames
<Haali> when using dshow for playback
<Haali> dshow uses audio as master clock and it usually doesn't match the display
<Haali> this also includes 60i stuff that is deinterlaced by frame doubling

oddball
13th August 2007, 20:06
Still awaiting BetaBoy's official response to non-spec motion vectors in old x264 encodes.

Revgen
13th August 2007, 20:33
Also on the 60FPS comments..... Haali noted to me that:

Quote:
<Haali> btw, don't forget that playing 60fps video on a 60fps display will almost always drop frames
<Haali> when using dshow for playback
<Haali> dshow uses audio as master clock and it usually doesn't match the display
<Haali> this also includes 60i stuff that is deinterlaced by frame doubling

So does this mean I'm supposed to have audio in my encodes in order to do these tests? :confused:

wozio
13th August 2007, 20:59
Also on the 60FPS comments..... Haali noted to me that:

<Haali> btw, don't forget that playing 60fps video on a 60fps display will almost always drop frames
<Haali> when using dshow for playback
<Haali> dshow uses audio as master clock and it usually doesn't match the display
<Haali> this also includes 60i stuff that is deinterlaced by frame doubling


That is true but only in windowed mode due to limitations of direct3d or drivers. In exclusive fullscreen mode I get perfectly smooth playback of 60fps sources on 60Hz display.

In fact best results are when display is the same refresh rate as source or at least multiply of it.

CruNcher
13th August 2007, 22:05
yep but it's important to have V-sync enabled or you get tearing like in other 3d applications, Exclusive Mode Rocks under Windows XP the best mode imho (and you can use DXVA via VMR-mixer) for watching Video :)

wozio
14th August 2007, 06:47
Of course, vsync must be on. In my opinion fullscreen with vsync is only option when playing video on XP.

OT continues ;) : How it is on vista?

arfster
14th August 2007, 12:27
Tearing disappeared as soon as I went to Vista. No more need for exclusive modes and the like.

wozio
14th August 2007, 13:19
What about dropping frames when playing for example 60 fps source on 60 Hz display? I don't have tearing in XP when vsync is enabled even in windowed mode but playback is far from smoothness.

andybno1
14th August 2007, 18:10
has an updated installer been released yet to help with the current issues?

BetaBoy
15th August 2007, 03:44
One of the issues has been fixed but we are still working on the webpage fallback as we speak. I would hope for us to complete testing by tomorrow and push the new installer release, but lets see how testing goes with the few users that are having issues.

bob0r
15th August 2007, 09:35
@betaBoy:
Since all has been updated, i wonder:

- When does CoreAVC actually check for activation during installer?
- To what is CoreAVC bind again?
As in.... when i reinstall vista/xp, what does it look for?
Windows serial?
- What happens when i run a new installer over a already working CoreAVC, but this install fails? (related to the first question i guess)

ACrowley
15th August 2007, 12:02
After a fresh Xp install the installer/ax works again...

So ive no Problmes anymore to reg the .ax :)

trueimage
16th August 2007, 16:41
I want my system to play 1080p h.264 mkv files smoothly.

Right now I have E6400 @ stock and 2GB RAM, Windows XP and a 7900 GS HDCP over DVI.

I'm using mplayerc and CoreAVC 1.3 I saw linked somewhere. I want to buy/use this new version no doubt.

What I'm wondering is is my machine ok? Will this new software work fine on these? Does anyone have a stress test high bitrate high res etc file to test?

I can get a decent deal on a Q6600 (4 core, 2.4GHz) and I am going to reinstall soon so I can go with Vista or XP, doesn't matter to me.

Any ideas? Almost all of my files are now 720p or 1080p h.264 mkvs, as I'm backing everything up that way

deets
16th August 2007, 16:58
yeah should be ok?

do they play now ok?

and i would kill your thing in ()

i have a 6600

trueimage
16th August 2007, 17:23
yeah should be ok?

do they play now ok?

and i would kill your thing in ()

i have a 6600

thanks

The files play ok for the most part, but I have a lot of 720p files, not a lot of 1080p. I'm hoping to find a particularly intense scene and maybe encode that at a high bitrate and 1080p res, unless someone else has done it... just to see.

A little off topic, but I'm noticing some random pauses in my audio, and I'm using onboard spdif output, so I might have to look into that - anyone else ever notice something like that with onboard sound?

You have an E6600 or Q6600? Just wondering the advantage of the Quad core vs Dual core.

deets
16th August 2007, 17:39
someone did post some very high level basketball clips earlier on i think which push core to the limit.

random pauses in the 5.1 output?

Q6600. coreavc is supposed to support quad cores, so thats cool. that should mean all works just fine, but the test clips some pages back should be a guide.

i paid 170 quid for my Q6600 but i do tonnes of x264 encoding :) think its a great chip for its price

andybno1
16th August 2007, 18:54
sooo any news on a new installer yet with the bug fixes?

trueimage
16th August 2007, 19:14
someone did post some very high level basketball clips earlier on i think which push core to the limit.

random pauses in the 5.1 output?

Q6600. coreavc is supposed to support quad cores, so thats cool. that should mean all works just fine, but the test clips some pages back should be a guide.

i paid 170 quid for my Q6600 but i do tonnes of x264 encoding :) think its a great chip for its price

Yeah, small pauses in the audio, over coax. I'm going to try switching to an optical cable I have laying around, and updating the drivers.

I can get the Q6600 for $288 CAD ($268 USD, £136 GBP) so that seems like a good price for Quad cores to me, and I'll move the E6400 to my desktop and try some overclocking on it maybe.

Delerue
16th August 2007, 23:42
Some 16mbit h264 1080i from BBC HD's Wimbledon coverage:

http://rapidshare.com/files/46651266/BBC_HD__H264_AC3_eng__07-07_13-25-26.ts.03.ts.html

This video has two audio tracks, right? At least is what VLC tells me. But I can't switch the tracks using MPC. Can you?

espentan
17th August 2007, 09:40
BetaBoy, I still get an error loading the CoreAVDecoder.ax.

Is this issue supposed to be fixed now?
I submitted a ticket asking to reset my install, but I was told to wait a that you were still working on a new version...?

This is under Vista x86, btw.

trueimage
17th August 2007, 18:46
I'm going to reinstall XP Pro SP2

Can anyone give me a guide on what I should install?
mplayerc, coreavc, ac3filter
is that it?

deets
17th August 2007, 18:49
mpc, coreavc and haali :D maybe ffdshow

leebo
17th August 2007, 19:56
Is there some other area I should post a complaint about being charged twice and yet not able to download CoreAVC Pro?

I bought the software this past Tuesday. I've PM'd Beta Boy, I've emailed their sales, tech support, and even sent an email to the link they provided when my download link came up as "expired".

I also sent a trouble ticket to the link Beta Boy provided a couple of pages back.

It's now been 4 days and no response from anyone!!!

Rectal Prolapse
17th August 2007, 20:41
Good luck leebo - you will need it. :P

Anyways, good thing you found this forum - Betaboy may actually be able to help you now!

andybno1
17th August 2007, 21:00
Good luck leebo - you will need it. :P

yeh I second that - coreavc... worse customer service I have EVER experienced........ and I've spoken to indian call centres lol

after installing the installer with the dll error even 1.3 doesn't work now I get the same fault so well done coreavc people

oh and 4 days a go I was told there was gonna be a new installer pushed out on tuesday with this problem fixed........ 4 days on and wow wouldn't u know nothing

sillKotscha
17th August 2007, 21:31
wrong thread for rant...

_xxl
17th August 2007, 21:48
@Admin
Please remove:
one CoreDay roughly translates to six normal earth month...
__________________
http://ffdshow-tryout.sourceforge.net/

ffdshow-tryouts has nothing to do with this.

BetaBoy
17th August 2007, 21:50
yeh I second that - coreavc... worse customer service I have EVER experienced........ and I've spoken to indian call centres lol

after installing the installer with the dll error even 1.3 doesn't work now I get the same fault so well done coreavc people

oh and 4 days a go I was told there was gonna be a new installer pushed out on tuesday with this problem fixed........ 4 days on and wow wouldn't u know nothing


Well I am not gonna comment on your specific situation other then you taking it here rather then in our support center will not help you any faster if the staff is unaware of your discomfort.

On the installer we have now found that most of the delivery and installer issues were mostly based on an issue with e-junkies delivery and how they handled it. So we have taken down the purchase link and are completing our work for the new purchasing frontend we had planned for 1.6 but will release it now instead.

CiNcH
17th August 2007, 22:10
Means another month minimum that nobody can purchase the shit or try a demo version?

BetaBoy
17th August 2007, 22:13
No... just till after the weekend.

leebo
18th August 2007, 00:51
Well I am not gonna comment on your specific situation other then you taking it here rather then in our support center will not help you any faster if the staff is unaware of your discomfort.


Well, I have tried that. Not only has nobody helped me, they haven't even acknowledged my existence!!!

BetaBoy
18th August 2007, 01:47
If you PM me the purchase info I will be more then glad to help you as well as look up any ticket you may have submitted to see what the staff has done or not done for you.

leebo
18th August 2007, 03:40
Thank you.

ACrowley
20th August 2007, 21:07
Still awaiting BetaBoy's official response to non-spec motion vectors in old x264 encodes.

me too...

Jay Bee
20th August 2007, 22:28
Sorry for the late reply, been away.


Jay Bee you have to debug everything to find the couse for your problems, but if you have a Nvidia card i can advice you to try the Exclusive VMR9 Renderless Mode, it reserves every power your machine has for the Fullscreen Playback (Windows XP)
Vista has a new type of Multimedia Scheduler in the Kernel that should avoid such latency problems (but only if the applications support it @ the moment only WM11 and PowerDVD do i think)



Thanks for the tips. I managed to fix my Zoom Player problem by changing some settings in Zoom Player (for anyone having problems with interlaced content and ZP: use VMR7 + "Enable YUV mixing" but NOT "Disable Overlay on VMR7").

Now almost all files I've tried are smooth but the Football clip from this thread still has slight stutters no matter what combination of software/hardware/renderer/player I use. Maybe I'm just sensitive to small stutters. And BTW 60 Hz refreshrate mismatch was not the reason as suggested further up. I used a CRT to test.


Fact is for my System CoreAVC has no (Speed, Quality advantage) in Playback over GPU assisted Decoding with my 7600 GS @ native LCD resolution of 1680x1050 especialy for Sattelite (Interlaced content)


what about deblocking? If you're using DXVA decoding on a 7600 GS you won't be getting any. In case you were not aware of the problem here are two screen grabs of the Football clip for you to compare. The first one is Cyberlink DXVA, the second one is CoreAVC with deblocking. Of course your single core wouldn't be fast enough to use CoreAVC on that clip but I was just wondering why you state that CoreAVC has no quality advantage over the DXVA decoders.

http://xs218.xs.to/xs218/07341/cyberlink.jpg.xs.jpg (http://xs.to/xs.php?h=xs218&d=07341&f=cyberlink.jpg)

http://xs218.xs.to/xs218/07341/coreavc.jpg.xs.jpg (http://xs.to/xs.php?h=xs218&d=07341&f=coreavc.jpg)


or at least get a license from Nvidia to use their Hardware Deinterlacing for some speedup here.


I'm not sure it has anything to do with a license. If you set CoreAVC to "DirectShow deinterlacing" it will also use the GPU to do deinterlacing. But after doing some tests it seems that the result isn't quite as high quality as when DXVA decoding is performed as well. But still way, way better than the CoreAVC software decoder. Again, some screen grabs for you to compare. The first is Cyberlink Purevideo, the second is CoreAVC DirectShow and the third is CoreAVC software.

http://xs118.xs.to/xs118/07341/purevideo.jpg.xs.jpg (http://xs.to/xs.php?h=xs118&d=07341&f=purevideo.jpg)

http://xs118.xs.to/xs118/07341/coreds.jpg.xs.jpg (http://xs.to/xs.php?h=xs118&d=07341&f=coreds.jpg)

http://xs118.xs.to/xs118/07341/coresoft.jpg.xs.jpg (http://xs.to/xs.php?h=xs118&d=07341&f=coresoft.jpg)

Yadif would of course also be great but I doubt it can be sped up to do 1080i in realtime. Or maybe it could on a quad core? That would make the whole DXVA/hardware/driver mess a thing of the past.

Crisidelm
21st August 2007, 18:02
I also have a short clip of football match, this time from Canal+HD, 1440x1088i. It's less taxing for the system, but it looks terribly bad with Cyberlink DXVA on.

Schrade
21st August 2007, 23:54
BetaBoy,

Adobe just announced playback of h.264 video is coming to their Flash Player. Any chance we're going to see them using a CoreAVC derivative in it? Otherwise I fear that we're going to be getting slow-ass decoding being commonplace like with embedded Quicktime media.

Adobe brings high definition to Flash videos (http://news.com.com/Adobe+brings+high+definition+to+Flash+videos/2100-1012_3-6203500.html?tag=nefd.top)

Edit: Link to the beta of the Flashplayer 9 with H.264/AAC support: http://labs.adobe.com/technologies/flashplayer9/

I haven't tried it out yet.

CruNcher
22nd August 2007, 00:09
@Jay Bee
jep the deblocking is the only downside but for high quality sat channels it's no problem either and not even the slightest for HD-DVD and Blu-Ray :P

@Schrade
I doub't that Adobe didn't thought about Hardware accelleration support imo it's very important and the Adobe engineers are surely not dumb to take it into account :P

from the releasenotes

Enhancements to full-screen mode to use hardware scaling for improved video performance and quality on systems running Windows 2000 and newer or Mac OS X 10.2 and newer.

Ok actually this doesn't says anything about PV1/PV2 and UVD support hmm just scaling is a bit to less but maybe full acceleration is coming, it has to be (maybe they clearing up license issues @ the moment with Nvidia/Ati to use their APIs)

foxyshadis
22nd August 2007, 01:29
If flash's implementation is based on Mainconcept's decoder as well as the encoder, it will be fast enough for most SD video. There's no good reason to waste their time and money reinventing it if they can just license it cheap.

Hardware support just means overlay/VMR, maybe EVR now. In the past flash was 100% GDI, with the horrible performance that you'd expect.

Schrade
22nd August 2007, 02:01
If you guys want to talk more about the flash stuff there's a thread for that topic specifically now:

http://forum.doom9.org/showthread.php?t=129134

BetaBoy
22nd August 2007, 05:02
BetaBoy,

Adobe just announced playback of h.264 video is coming to their Flash Player. Any chance we're going to see them using a CoreAVC derivative in it? Otherwise I fear that we're going to be getting slow-ass decoding being commonplace like with embedded Quicktime media.

Adobe brings high definition to Flash videos (http://news.com.com/Adobe+brings+high+definition+to+Flash+videos/2100-1012_3-6203500.html?tag=nefd.top)

Edit: Link to the beta of the Flashplayer 9 with H.264/AAC support: http://labs.adobe.com/technologies/flashplayer9/

I haven't tried it out yet.

I see this as great news for H.264 and very, very, bad news for DivX. I've had access to the beta for a few days now and have found the video playback to be slow at best and 720P is the max it supports now but I suspect that will change soon enough. But the bigger issue I see is that for the high-end video enthusiast, Flash is not a great (great=efficient) means for playing big b/w multimedia like H.264 and HE-AAC (not that this is targeted towards that demographic). But the Flash platform does a great job of making it seemless... that, nobody can touch.

*cough* If they have one *cough* DivX should release their H.264 decoder and encoder now before its too late and their marketshare continues to falter.

solaq57
22nd August 2007, 20:16
Hi Jay (or anyone), how do you enable the Core AVC DirectShow deinterlacing, I am trying to play some BBC-HD material (live earth for example) and checking the DirectShow deinterlacing box does nothing???

If I select software deinterlacing, I can see a benefit. I have a 8600gts with the latest approved drivers.

Thanks for any advice.

Sorry for the late reply, been away.

I'm not sure it has anything to do with a license. If you set CoreAVC to "DirectShow deinterlacing" it will also use the GPU to do deinterlacing. But after doing some tests it seems that the result isn't quite as high quality as when DXVA decoding is performed as well. But still way, way better than the CoreAVC software decoder. Again, some screen grabs for you to compare. The first is Cyberlink Purevideo, the second is CoreAVC DirectShow and the third is CoreAVC software.

Selur
24th August 2007, 15:48
Are there any plans to add some postprocessing options to coreavc? Would love to have something like ffdshows deband in coreavc.

Jay Bee
24th August 2007, 18:43
Hi Jay (or anyone), how do you enable the Core AVC DirectShow deinterlacing, I am trying to play some BBC-HD material (live earth for example) and checking the DirectShow deinterlacing box does nothing???



Could you explain exactly in which way DirectShow deinterlacing isn't working? What GPU are you using?

solaq57
24th August 2007, 21:13
HI,

1. play title using mpc
2. select filters->coreavc
3. select software deinterlacing, click apply, output comes deinterlaced

4. select DirectShow deinterlacing, click apply, output reverts to interlaced display (jagged lines during panning)

I am using a 8600gts

Thanks

Could you explain exactly in which way DirectShow deinterlacing isn't working? What GPU are you using?

CruNcher
25th August 2007, 02:56
Are there any plans to add some postprocessing options to coreavc? Would love to have something like ffdshows deband in coreavc.

You can use ffdshow for any Decoder so why implement that into CoreAVC it's really not needed you can even use ffdshow + CoreAVC for editing purposes this way, no problem :)
i replaced Mainconcepts Decoder in many applications with CoreAVCs Decoder for faster Rendering either directly for Direcshow Applications or you can use some workarrounds for other applications useing makeavis for example and fake .avi triggering CoreAVC, CoreAVC is great for Editing at least for now different situation when Hardware Accelerated Editing becomes available for standard GPUs ;) AVC is nice as intermediate solution vs CineForm for example :)

Jay Bee
25th August 2007, 09:53
HI,

1. play title using mpc
2. select filters->coreavc
3. select software deinterlacing, click apply, output comes deinterlaced

4. select DirectShow deinterlacing, click apply, output reverts to interlaced display (jagged lines during panning)

I am using a 8600gts

Thanks

Hmm, can't really think of anything. Do you have the "aggressive deinterlacing" option checked? Are you using CoreAVC 1.5? Have you tried any other clips? arte.hd.ts from http://x264.nl/h.264.samples/ should be a good test.

espentan
25th August 2007, 10:52
I'm still struggling with the DLL loading error.

Is this problem supposedly fixed now, or is it still an issue?

I should probably go back to XP for my media box, hu? :)

solaq57
25th August 2007, 12:45
Hmm, can't really think of anything. Do you have the "aggressive deinterlacing" option checked? Are you using CoreAVC 1.5? Have you tried any other clips? arte.hd.ts from http://x264.nl/h.264.samples/ should be a good test.

Hi, I have tried aggressive on/off makes no difference.

Tried arte.hd.ts, only software deinterlacing correctly deinterlaces the output...

Anything else?

Regards

Jay Bee
25th August 2007, 22:00
Sorry, no idea. Maybe HW deinterlacing is only available in combination with HW decoding on your card? But that would be a problem for interlaced VC-1, no? You could confirm this by playing an interlaced MPEG-2 file with the DScaler decoder: it uses HW deinterlacing by default.

You could also try newer or older drivers.

TEB
27th August 2007, 18:57
my bet is ibc 2007 (6-11 sept)

Sirber
28th August 2007, 13:08
Woa! 1.5.0.1 with no more online auth! :D

WOOT! THANKS A LOT CORECODEC!!!!!!!!!!!!!!!!!!

Ice =A=
28th August 2007, 13:28
Ok, that are good news!

I have criticized the core team a lot recently. And since I really hate online activation of all kinds I have been looking around in the last days for a new codec or MP4 player to buy (to get rid of CoreAVC).

But now you obviously have taken a step (back?) in the very right direction, and I realy congratulate you on that! Well done! :thanks: :)

Edit: 1.5.0.1 installed without a problem and seems to work well! :)

BlackSun
28th August 2007, 13:42
oh my god I wasn't fast enough to announce it here :p We hope you appreciate the move from us. Sales are also back, so you can buy it if you want.

smok3
28th August 2007, 14:13
edit: nm, found the changelog, but how should i read this:

CoreAVC™ Standard Edition Decoder
- H.264 Baseline, Main, High profile support
- No Interlaced support
- No SMP support
- No GPU support

whats deinterlacer doing here then if iam unable to read interaced streams anyway?

BetaBoy
28th August 2007, 14:19
Trial version is next but the new installer requires we do so additional DB/PHP work on the backend... so give us a week or so to get it done.

espentan
28th August 2007, 14:45
oh my god I wasn't fast enough to announce it here :p We hope you appreciate the move from us. Sales are also back, so you can buy it if you want.

Great news!

I think you'll find that the lower support time and higher customer satisfaction will pay off.

I've already bought two licenses ;)

To hell with DRM.

espentan
28th August 2007, 14:49
Does anyone by chance know how to run PowerDVD and CoreAVC along side?

I use PowerDVD for my Blu-ray needs, but I'd like CoreAVC to handle what I don't play in PowerDVD.

As it is know, the cyberlink decoder just marches on in and takes full control over everything i play in WMP.

mitsubishi
28th August 2007, 15:03
espentan, if you download Radlight Filter Manager (http://www.free-codecs.com/download/RadLight_Filter_Manager.htm) You can check the "Filter Merits" and give CoreAVC a higher number, then it will be used in preference by any directshow player. PowerDVD isn't bothered by the merit and will continue to use it's own codec.

Rectal Prolapse
28th August 2007, 16:43
This is good news. Well done.

Disabled
28th August 2007, 17:18
Weeeee many thanks for this great great change!
I gladly uninstalled my hassle free version and updated to this hassle free version!
One big step forward for me to recommend CoreAVC again...


And for the non-DRM fanboys: I've said it before, I'll say it again, DRM is here to stay, we just have to live with it and work around the issues.

Jay Bee
28th August 2007, 18:26
EDIT: Oops, didn't see the information was already there. Removed.

Finally CoreAVC is a fully recomendable product. :up: I hope you guys can get a sales boost from this.

espentan
28th August 2007, 19:52
espentan, if you download Radlight Filter Manager (http://www.free-codecs.com/download/RadLight_Filter_Manager.htm) You can check the "Filter Merits" and give CoreAVC a higher number, then it will be used in preference by any directshow player. PowerDVD isn't bothered by the merit and will continue to use it's own codec.

Great, thank you mitsubishi!

It works like a charm. And charm works pretty darn well, if you were wondering.

3ngel
28th August 2007, 19:58
Ohhh, what a good news!
In the end they finally did the right choice.
Maximum respect from me.

jchunter_2
28th August 2007, 20:20
I installed v 1.5.0.1 but do not see CoreAVC as a selectable filter in MPC. Ulead Video Studio can't see it either.

Edit: Sorry. My bad. I do see Core AVC in MPC. However, an AVCHD .mts file plays with no audio.

Sirber
28th August 2007, 21:39
I installed v 1.5.0.1 but do not see CoreAVC as a selectable filter in MPC. Ulead Video Studio can't see it either.

Edit: Sorry. My bad. I do see Core AVC in MPC. However, an AVCHD .mts file plays with no audio.
then you have an audio problem ;)

ACrowley
29th August 2007, 14:50
Mh... all i get via my CoreAccount is the old 1.5.0.0 Installer ?Decoder Version is still 1.5.0.0 not 1.5.0.1?

AH, SRY got Update Email

deets
29th August 2007, 21:05
my core email about 1.5.0.1 was blocked by my DCC filter :( could someone PM it to me as i dont know what it said!!

ta?

espentan
29th August 2007, 21:14
my core email about 1.5.0.1 was blocked by my DCC filter :( could someone PM it to me as i dont know what it said!!


It contained a download link and your new serial.

You need to e-mail support and ask for a new mail...

BetaBoy
31st August 2007, 01:30
Does anyone by chance know how to run PowerDVD and CoreAVC along side?

I use PowerDVD for my Blu-ray needs, but I'd like CoreAVC to handle what I don't play in PowerDVD.

As it is know, the cyberlink decoder just marches on in and takes full control over everything i play in WMP.

We are going to be giving the end user the power to choose merit rather then play this back and forth shell game other filter makers have been doing. Starting with the next version of CoreAVC we will be adding a Merit slider (something we have already done this with our CoreMP3 and new CoreAAC v2.0 directshow filters).

Sharktooth
31st August 2007, 02:03
the changelog says "New installer".
so i suppose there are no changes other than those that has been said here and on the changelog.
however if things are going to stay as they are now, maybe it's time for me to buy a license for CoreAVC hoping there will be a linux version soon.

popper
31st August 2007, 04:12
CruNcher.... don't forget about Matroska adoption as well!!! We will have millions of hardware devices supporting it by the end of the year ;-)

On the CoreAVC encoder... while it would be great to put it out there publically, we think our efforts are better spent on CoreSVC since it is the future. We can always back track at that point and release CoreAVC as a standalone encoder.

On GPU.... our beliefs are the reliance in DXVA is a mistake by GPU vendors as a short cut and unnecessarily locks third party vendors into restraints right from the get go. While DXVA is more than just for decoding, its also for video processing and capturing (amung other things), we feel its outright overkill.

Although I am sure zambelli would disagree... Simple i/o hooks and a K.I.S.S. approach is needed.... don't believe all the other talk about what is required for GPU, and I am not going to comment on specific functions as they are pretty well known on these forums. Simply put, something needs to be done for the future of GPU and marketing must be fixed in order to move forward and garner mass adoption (Linux comes to mind first when thinking about this).

thats all very nice BetaBoy but you seem to refuse to take the time to compile a PowerPC (with Altivec) version of Core tools, and dont apparently see your codecs being used on the mass PPC embeded markets hardware, $99/€75.00 Efika PPC board being a case in point.

these boards are in effect what runs in your upper/High end in-car computers as its on average 1W power helps a lot,and now that Efika is affordable by anyone, expect it to be found in lots of portable 7" and home A/V kit once Efika2 ships.

http://www.efika.de/index_en.html
http://book.efika.org/

EFIKA2 Developer Program Begins:
http://www.powerdeveloper.org/forums/viewtopic.php?p=8621#8621
"... The EFIKA2 will feature the Freescale MPC5121e with has an integrated PowerVR graphic core. ..."

OC if you ever did compile a PPC (thats powerPC remember)version then its potentially usable
in PS3 PPC linux A/V markets and even Xbox360 with effort to use linux.

dont forget several PPC (Pegasus)linux guys are always helping improve the codebase to optimise the free
video tools/Codecs for the PPC base and Altivec that the PS3 users are now taking advantage of...

i always hoped your guys would too, and help improve all the future PPC Embeded projects and sell your wares there to both end users and OEM as the markets grow as reward........ and weres your FPGA embedable CORE AVC codebase?, shame.

popper
31st August 2007, 05:39
@ bobor


Hmm is this result based on a DualCore Cpu ?
For Singlecore i can definately say this isn't true Cyberlinks PV1 Decoder (i can only test PV1 Geforce 7600 GS) is still a tad faster (in terms of raw fps) then CoreAVC without deblocking (dunno about DualCore yet ;) ) Results based on Windows XP Sp2 Low Latency Driver optimized ), but as i said all the Benchmarks @ the moment on the net about PV1/PV2 and UVD say nothing about it's Energy Efficiency compared vs CPU useing CoreAVC (they only test raw fps or most only CPU usage on every site, but not GPU usage and the resulting Energy consumption) :P, but ok if you gonna build a CE Device as Betaboy allready said you would go the K.I.S.S way so Broadcom AVC/VC1 DSP and you good to go and for sure with less Energy loss, but for all the HTPC builders i think this should be compared anyways CoreAVC + current low voltage CPU vs GPU based decoding + low voltage cpu and then measure the power of both systems and take this into account in the benchmarks (in times of raising energy prices) energy efficiency of Codecs (for a given purpose you wan't to reach) should be tested too. (Exactly in this terms Microsoft tweaked VC-1 over H.264)

i cant agree on the DSP, in the case of codecs and CE its far better long term to use a current FPGA , sure it costs slightly more until you get to mass lots purchase and perhaps a little more power (not so with Kilocore though ;) )

but at the end of the day, you then have a massive long term advantage that you can software upgrade the FPGA codecs
if and when you need to, or with DSP be obsolete and have to keep the old Mpeg2 standards as can be seen by the masses of sold (UK) DVB-T that cant take the AVC codec so everyone will need to buy new to take any new future AVC broadcasts (sky), the majority of broadcasters will not change to AVC as there are no CE AVC DVB-T STBs available, chicken/egg.......

software programable FPGA'a in all new CE kit should be the way its done from now on, and help the future markets grow and innovate....

espentan
31st August 2007, 16:54
We are going to be giving the end user the power to choose merit rather then play this back and forth shell game other filter makers have been doing. Starting with the next version of CoreAVC we will be adding a Merit slider (something we have already done this with our CoreMP3 and new CoreAAC v2.0 directshow filters).

Certainly a sweet piece of functionality :)
Keep up the good work!

popper
5th September 2007, 02:20
will you be supporting the PowerVR chipset any time in the near future ?

today:
http://uk.theinquirer.net/?article=42120
"First DX10.1 silicon is unexpected

Honour goes to PowerVR SGX family of mobile parts

...."

and the way back machine 2005
http://www.theregister.co.uk/2005/07/29/imagination_powervr_sgx/

as found in the original PPC (thats PowerPC)Freescale MPC5121e SOC.

" and In addition to Intel, Imagination has licensed PowerVR MBX to Sony Ericsson, Texas Instruments, Freescale, ARM - which also has the right to sub-license the graphics technology - Philips, Samsung and others. ®"

BetaBoy
7th September 2007, 19:11
All.... a new installer has been 'silently' released for CoreAVC Standard and Professional Editions v1.5.0.1 that during the install prompts you to choose between the 'Current user' and or 'All users' for both XP and Vista.

Next up is the Merit slider and the Trial version.

BetaBoy
7th September 2007, 21:44
For the ppl who emailed me... thx for letting me know about the site issues... we have moved to a new network today so www.coreavc.com is still propagating.

ACrowley
9th September 2007, 10:50
What about the Activation of 1.5.0.1 ?

When i install my Version on a other Machine/ other/ new installed Windows, will it work or do i still get a "already Activated" Error Message?

bob0r
9th September 2007, 11:39
There should be no more activation, just a serial.

ACrowley
10th September 2007, 10:40
:rolleyes:There should be no more activation, just a serial.


nice...so i can setup a fresh Install/ new System and i only need my Serial to activate it .
Thats really a good update
Old Activation sucks! more Restrictions/Trouble as a few $ Software

BetaBoy
19th September 2007, 21:27
Can any advanced users with a new version of Cyberlink give more details on how they are handling Merits and why the new version is diff then the old way they handled merits?

Just curious.

Theliel
20th September 2007, 08:51
In the newest version:

http://img459.imageshack.us/img459/2854/capturacl8.jpg

I dont remember others build, sorry.

BetaBoy
20th September 2007, 16:47
In the newest version:

I dont remember others build, sorry.

Theliel.... thanx... I guess what I am saying is what are they doing diff now vs. before that based on the reports we are getting, even when any other AVC decoder is installed that has an equal merit, that cyberlink still is being used.

What gets me is that over the past year that Cyberlink has increased their AVC merit for no reason (that I or our developers are aware of) at all.

But hey.... maybe I am wrong here.... lmk.

CruNcher
20th September 2007, 20:21
i know that for parser there is a setting (registry) based on file extensions (.xxx) dunno if this also can be used for decoders or other types of Directshow filter, maybe you should look there :)

Dark Shikari
20th September 2007, 20:27
Theliel.... thanx... I guess what I am saying is what are they doing diff now vs. before that based on the reports we are getting, even when any other AVC decoder is installed that has an equal merit, that cyberlink still is being used.

What gets me is that over the past year that Cyberlink has increased their AVC merit for no reason (that I or our developers are aware of) at all.

But hey.... maybe I am wrong here.... lmk.
That's how DirectShow works: Cyberlink's competitor comes out with a better product, so they raise their merit to compensate! :rolleyes: ;)

BetaBoy
20th September 2007, 21:13
That's how DirectShow works: Cyberlink's competitor comes out with a better product, so they raise their merit to compensate! :rolleyes: ;)
LOL :devil:

Guest
20th September 2007, 23:34
Is there any way to make CoreAVC decode an elementary AVC stream (raw H.264)? I can't find anything that will connec to CoreAVC's input pin, e.g., File source (async) won't connect.

Sergey A. Sablin
20th September 2007, 23:48
Is there any way to make CoreAVC decode an elementary AVC stream (raw H.264)? I can't find anything that will connec to CoreAVC's input pin, e.g., File source (async) won't connect.

file source async outputs plain data stream, so it's supposed to be a demultiplexer between them which understands Annex B byte stream.

edit: just to make clear - in directshow majority of decoders do not connect to "unknown" mediatypes like GUID_NULL, in case annex B, demuxer shall parse the data, construct mediatype and then you can connect to its output decoder. Same way as PS/TS

Guest
20th September 2007, 23:59
Can you suggest an Annex B demuxer that I can use?

EDIT: Never mind, Sonic HD Demuxer works fine. Thank you for your help.

Guest
21st September 2007, 00:34
Sonic HD Demuxer is not reliably working for all my test files. Many that open fine in DGAVCIndex (has NAL parser from JVC reference software) won't connect to the Sonic HD Demuxer. Can you suggest any other demuxers suitable for connecting raw H.264 NAL streams to CoreAVC?

Sergey A. Sablin
21st September 2007, 00:45
Sonic HD Demuxer is not reliably working for all my test files. Many that open fine in DGAVCIndex (has NAL parser from JVC reference software) won't connect to the Sonic HD Demuxer. Can you suggest any other demuxers suitable for connecting raw H.264 NAL streams to CoreAVC?

I'm afraid no. Released version of ours do not support CoreAVC either. Next version will, but I don't know yet the release date.

Probably I could send you the one from development tomorrow, if you're interested.

Guest
21st September 2007, 00:58
Probably I could send you the one from development tomorrow, if you're interested.
Yes, I am interested. Thank you, Sergey. I will keep it private and send you any feedback that I have.

Sergey A. Sablin
21st September 2007, 06:24
Yes, I am interested. Thank you, Sergey. I will keep it private and send you any feedback that I have.

ok, I was said release planned to be in 2-3 weeks. then updated demuxer will be available within our player and other products.

PS. Donald, pm me with your email.

Sergey.

sweetbox
24th September 2007, 20:13
Does CoreAVC hand decode within every following step?
EntropyDecoder ,Reorder ,Inverse quantization ,iDCT and CABAC/CAVLC decoder

I'm not very clear about decoder steps,but the question is that the change on iDCT setting of Libavcodec do infect the decode speed when using CoreAVC to decode X.264 720P video on the kmplayer,so that does CoreAVC hand the iDCT(the CoreAVC properly working when playing)?

Anyone help me about the decoder process steps and CoreAVC hand then all?
Thanks .

foxyshadis
24th September 2007, 21:30
CoreAVC handles the entire decoding process, and not only that, the idct setting in ffdshow is completely unused for h264 and post-processing raw video (which is how ffdshow is used when CoreAVC is decoding). Either you're mistaken about the idct affecting speed, or you're not watching actual h264.

A number of game trailers that claim to be h264 are actually Sorensen 3 (SVQ3). Check that with something like mediainfo, first.

BetaBoy
28th September 2007, 21:26
All.... a few things to note that has been going on here relating to CoreAVC...

- The reported issues with CoreAVC as it relates to MediaPortal may not in fact be CoreAVC at all, but instead it looks like tsreader is the problem. We are looking into it more.

- Merit slider.... it was noted internally that the only thing left is the UI and then we can release an update. I'd look for this to be push out soon.

Lastly.... 'drum roll please'......

I'd like to annouce that starting in late October we will be doing a closed (initially) beta for our upcoming CoreAVC Encoder Editions. Please no PM's yet on it but so far I think that ppl will be happy with whats coming (I know we are). We will ask some of the Doom9 Elite at first to have a go and tell us what they are finding.

BlackSun
28th September 2007, 22:29
i know that for parser there is a setting (registry) based on file extensions (.xxx) dunno if this also can be used for decoders or other types of Directshow filter, maybe you should look there :)

That only apply to source filters

CruNcher
29th September 2007, 16:30
@Blacksun

yes ofcourse Source not Parser :P

All.... a few things to note that has been going on here relating to CoreAVC...

- The reported issues with CoreAVC as it relates to MediaPortal may not in fact be CoreAVC at all, but instead it looks like tsreader is the problem. We are looking into it more.

- Merit slider.... it was noted internally that the only thing left is the UI and then we can release an update. I'd look for this to be push out soon.

Lastly.... 'drum roll please'......

I'd like to annouce that starting in late October we will be doing a closed (initially) beta for our upcoming CoreAVC Encoder Editions. Please no PM's yet on it but so far I think that ppl will be happy with whats coming (I know we are). We will ask some of the Doom9 Elite at first to have a go and tell us what they are finding.

Sounds great but for sure it will need heavy tweaking (bugfixing) seeing how young it is, though i really wonder when XviD AVC is gonna see the light now as it was finished alot longer then CoreAVC but no life sign since the last Doom9 test :( anyway im looking forward to your CoreAVC Encoder release, maybe some info infront wich tools are allready implemented ? FreXt support ? any psy stuff ?

BetaBoy
6th October 2007, 23:27
I'd like to grab a few testers in this thread to test our plug-in for CoreAVC Professional in GStreamer on Windows, Linux and OS X.... anyone interested pls email me betaboy@corecodec.com and I'll give you more info.

Usa1955
7th October 2007, 13:33
Does CoreAVC support Windows XP x64/64bit?

tomos
8th October 2007, 00:58
latest works fine on vistax64. no idea on xp tho.....

BetaBoy
8th October 2007, 01:06
We plan on releasing a native 64 bit version next year. But tomos is correct it will install fine on x64 now... but will run in 32bit mode.

BetaBoy
8th October 2007, 01:11
@Blacksun

yes ofcourse Source not Parser :P



Sounds great but for sure it will need heavy tweaking (bugfixing) seeing how young it is, though i really wonder when XviD AVC is gonna see the light now as it was finished alot longer then CoreAVC but no life sign since the last Doom9 test :( anyway im looking forward to your CoreAVC Encoder release, maybe some info infront wich tools are allready implemented ? FreXt support ? any psy stuff ?


At this time we plan on first releasing the CoreAVC Standard Edition Encoder. It will support one-pass encoding and Baseline profile. Professional will support Base, Main, Extended... and will have 2 pass.... Enterprise will feature all the above plus 4:2:2, 4:4:4, etc. and have a 3 pass mode (i'll discuss 3 pass later).

FreXt and psy support.... yes.

BlackSun
8th October 2007, 16:38
Can anyone tell me what is the default merit of the cyberlink h264 dshow decoder please ? I changed mine and cannot remember what it was.

Thanks :) (Yes we're working on that too).

Btw, the Media Portal problem will be fixed on the next release !

bob0r
8th October 2007, 16:50
@BlackSun:

On my system:
CoreAVC Video Decoder: 00600200
Cyberlink H.264/AVC Decoder (PDVD 7.x): 00600400

TheShadowRunner
9th October 2007, 02:54
Is hardware acceleration still planned?
Later,

TSR

oddball
9th October 2007, 03:35
Is hardware acceleration still planned?
Later,

TSR


Something about flying pigs etc

dieselgg
9th October 2007, 05:30
Perhaps one of you guys can help me out. I have a laptop, 3.07 GHz Hyperthread, 1.5 gigs RAM, ATI Mobility Radeon 9000 IGP. FFDshow and matroska media splitter installed. Also using AVC x264 decoder.

I am trying to play a High Defn video of a soccer game encoded in x264, container is .mkv. and the file size is 2.2Gigs. When I try to play it in Media Player Classic, the video slows down after a couple of minutes and the sound starts to break up.

It did work one time but it was when I had a virus and it stopped a whole bunch of services in my system tray but I also had to disable "Enable write combining" in my video card properties for it to work. With my system cleaned all the services back up and running, the video slows down. I don't think the services in my system tray would prevent it from running or or use to much resources.

Well if anyone has any tips I would really appreciate it or if I posted in the wrong forum .. let me know. I will create a new thread.

Jay Bee
9th October 2007, 11:04
Could be overheating. Try speedfan to check the CPU temp.

dieselgg
9th October 2007, 13:44
Could be overheating. Try speedfan to check the CPU temp.

JayBee,

Actually, the fan does kick into a higher speed when the video begins to slow down. My room for some reason picks up a lot of dust so I have to vacuum the vent of the intake fan is located to remove a lot of dust that builds up inside.

I will vacuum again and then install speedfan and see what happens.

Thanks,

Jay Bee
9th October 2007, 18:28
so I have to vacuum the vent of the intake fan is located to remove a lot of dust that builds up inside.

You should use a can of compressed air, much more effective than vacuuming.

dieselgg
9th October 2007, 18:29
Could be overheating. Try speedfan to check the CPU temp.

I don't know who you are but I think you may have solved my issue. I don't know why you suggested it but you definitely know your stuff. I did some searching on the net and apparently my model Toshiba A70 laptop is known to have the heatsink clogged with dust. It is a common problem apparently. I regularly vacuum it, but apparently it is not enough. I have to either blast the heat vents with compressed air or take it apart and remove the dust and perhaps reapply thermal grease on the cpu as it could dry up.

Again I don't know who you are but thanks a million. If it was not for your post I would not have google searched my laptop for the overheating issue. I am 90% sure it will fix my problem. I have been racking my brain for the past month, changin hardware and software settings. Reinstalling codes and other stuff.

Take it easy

CruNcher
9th October 2007, 20:52
JayBee,

Actually, the fan does kick into a higher speed when the video begins to slow down. My room for some reason picks up a lot of dust so I have to vacuum the vent of the intake fan is located to remove a lot of dust that builds up inside.

I will vacuum again and then install speedfan and see what happens.

Thanks,

i hope you mean you gonna vacuum clean your room and not the interior of the PC :P

leebo
9th October 2007, 22:30
I have a question.

Ever since I installed the codec, my encodes display tall and skinny. File properties show 1080X720, but it's not being displayed that way.

This happens with WMP 10, Nero Showtime, and TheaterTEK. When I use Media Player Classic however, it displays OK (i.e. widescreen), except when I select "Full screen", in which case it's tall and skinny like in the other players.

I'm running MCE 2005 w/rollup2. Again, this only started after I installed CoreAVC. I've checked CoreAVC settings but I don't see anything that might be related to this.

I'm not possitive CoreAVC is the problem, but it's the only think I can remember that has changed on the system.

bob0r
9th October 2007, 22:56
@leebo

Right mouse on video > Filters

Please type or make a screenshot and show us what you got there. (In media player classic)

Shinigami-Sama
10th October 2007, 01:47
actually the small hose attachement on a vacuum plus a can of air helps
don't get the vacuum to close though else it work as well

TheShadowRunner
10th October 2007, 01:58
Hey guys, i have a problem with CoreAVC 1.5 and most 720p MKV files.
When using VMR9, the framerate is around 10-15fps max (source is 24 fps), although the CPU is quite low, about 20-25% usage max. I don't get it, isn't the CPU supposed to be maxed out before experiencing stutters like i do?
When I switch to Overlay, it's a bit better but i'm pretty sure i'm not getting 24fps either. The CPU with overlay is just a bit lower, 15-20% usage.
Why isn't CoreAVC using my CPU more in order to display 24fps?
When using Cyberlink is soft mode or FFDshow, i have solid 24fps with both overlay & VMR9. What's going on?

My Videocard is geforce 8500GT, the CPU is Intel Dual Core E2180 (2ghz, not overclocked). I'm on XP SP2. (if it makes any difference nvidia drivers are 163.71)
Thanks for any help, i don't get it.
Later,

TSR

lexor
10th October 2007, 05:27
Hey BetaBoy, sorry to hijack this thread for a bit, but I don't know if you'll check audio forums.

I was wondering if with all these new developments from Core team, CoreAAC will be making a triumphant comeback? I can't access any of its websites: corecodec.org isn't there, .com doesn't have it, coreforge doesn't seem to have it either. The only thread on Doom9 I can find is from may of 2006 and there was talk of 2.0 "in weeks", but then nothing for over a year. Any news on that front? Or has the project been nixed?

BetaBoy
10th October 2007, 06:12
CoreFLAC, CoreVorbis will return on CoreForge.org soon. I actually created the projects... I just need to ping Toff on doing some code updates to them.

CoreAAC v2.0 has been done for a while now but we are adding HE support atm. Once completed i'll post more info... on it.

BetaBoy
10th October 2007, 06:20
Something about flying pigs etc

Moo! Actually Flying Cows... but yes it is planned.

TheShadowRunner
10th October 2007, 06:22
BetaBoy, any idea why i experience this?

Hey guys, i have a problem with CoreAVC 1.5 and most 720p MKV files.
When using VMR9, the framerate is around 10-15fps max (source is 24 fps), although the CPU is quite low, about 20-25% usage max. I don't get it, isn't the CPU supposed to be maxed out before experiencing stutters like i do?
When I switch to Overlay, it's a bit better but i'm pretty sure i'm not getting 24fps either. The CPU with overlay is just a bit lower, 15-20% usage.
Why isn't CoreAVC using my CPU more in order to display 24fps?
When using Cyberlink is soft mode or FFDshow, i have solid 24fps with both overlay & VMR9. What's going on?
My Videocard is geforce 8500GT, the CPU is Intel Dual Core E2180 (2ghz, not overclocked). I'm on XP SP2. (if it makes any difference nvidia drivers are 163.71)
Thanks for any help, i don't get it.
Later,

TSR

Any hints very welcome. ;)

BetaBoy
10th October 2007, 06:33
We have been a little more busy then many of you may have thought.... we are about to release CoreAVC v1.6 (internally called CoreAVC 'Next Generation'). The filter is a complete re-write from scratch and from my testing 'smokes' v1.5 and previous versions. Why a re-write? Simple, speed... I'll put up more details on the release date. But here is a new screen cap.

http://img186.imageshack.us/img186/4969/coreavcpropertiesboxfz4.png (http://imageshack.us)

Hans Ohlo
10th October 2007, 09:02
hi betaboy,
glad to hear about all the work. as i was a big critic about corecodec in the past i want to say how happy i am now with coreavc 1.5 and i am looking forward to new version/products.

Olebrumm71
10th October 2007, 10:46
CoreFLAC, CoreVorbis will return on CoreForge.org soon. I actually created the projects... I just need to ping Toff on doing some code updates to them.

CoreAAC v2.0 has been done for a while now but we are adding HE support atm. Once completed i'll post more info... on it.

Great! Maybe CoreAVC and CoreAAC may be used for the brand new Norwegian DVB-T broadcasts, which use H.264 and AAC-HE, for which there currently does not seem to be any software support.

As a side note: for the AAC-HE audio in the DVB-T broadcasts in Norway, a DirectShow audio-filter would need to support LATM/LOAS encapsulation.

So, BetaBoy, any chance of supporting this?

foxyshadis
10th October 2007, 12:35
That would be the splitter's (ie, Haali's) job, wouldn't it? The splitter is supposed to unencapsulate everything for the decoder, whether it's coreaac or ffdshow or whatever.

TheShadowRunner
10th October 2007, 20:23
well guys, i found the root of my problem with coreAVC : the MKV Splitter by Gabest, when using it along with VMR9 renderless; fps is around 15. When I use the Haali splitter instead, i get 24 alright!
What puzzles me is that Cyberlink and FFDshow ran fine with Gabest's Splitter.. so why not Coreavc? Anyway, it's solved now ;)
Later,

TSR

Jay Bee
11th October 2007, 00:06
I don't know who you are but I think you may have solved my issue. I don't know why you suggested it but you definitely know your stuff. I did some searching on the net and apparently my model Toshiba A70 laptop is known to have the heatsink clogged with dust. It is a common problem apparently. I regularly vacuum it, but apparently it is not enough. I have to either blast the heat vents with compressed air or take it apart and remove the dust and perhaps reapply thermal grease on the cpu as it could dry up.

Again I don't know who you are but thanks a million. If it was not for your post I would not have google searched my laptop for the overheating issue. I am 90% sure it will fix my problem. I have been racking my brain for the past month, changin hardware and software settings. Reinstalling codes and other stuff.

Take it easy

Thx for the kind feedback. :)

Chainmax
11th October 2007, 01:28
BetaBoy, would there be any chance to release a video player for the PSP that included CoreAVC v1.6, be it free or commercial?

BetaBoy
11th October 2007, 05:48
BetaBoy, would there be any chance to release a video player for the PSP that included CoreAVC v1.6, be it free or commercial?

Technically CorePlayer Mobile already supports the PSP. But because of the Sony control issue we never went there.

Morte66
12th October 2007, 11:54
Why a re-write? Simple, speed...

Have you guys considered making a VC-1 decoder? I'm decoding some HD DVD rips with the Microsoft decoder from WMP11, and it runs about 85% CPU on my X2 64 3800+. It's jittery as hell and every couple of minutes it drops 1-20 frames. On the same PC CoreAVC Pro can play my more complex h264 unrestricted high profile encodes and it's completely smooth at about 55% CPU.

Go on, you know you want to... :)

xW0Lf
12th October 2007, 15:15
hmmm... betaboy, what's about harware support for decoding? (dxva).... can we see that in 1.6, or no yet?

now, when cyberlink decoder/hali mkv splitter combination is buggy (20fps bug + 1080p not work in dxva mode) we wait for something better.... for some 720p mkv files that work with cyberlink+hali-spliter (but with 20fps bug) i can't believe that my cpuload is only 2-5% while GPUload is 15-25% (i have ati 2600xt card)...

so, dxva soon?

:)

ChronoCross
12th October 2007, 15:34
I don't really see the point of GPU support.

I have a single core machine that Coreavc can play 1080p stuff just fine.

xW0Lf
12th October 2007, 15:35
and one more question.. if this is not too much..

can we know how your team make coreavc codec to be that fast, compared to others in software mode (not detailed answer, i know it's secret.. just some global ideas)

do you use pure ASM for some speed-critical tasks or just good optimisation? (i hope you don't use hacks to get better speed)

xW0Lf
12th October 2007, 15:44
yeah... but i want to have free cpu for other task while i watch SAT-hdtv... cpu for sat-hdtv 1080p is better to use for decode protected channels....

or just work something other while watching 1080p (i have two monitors...)

pankov
12th October 2007, 15:58
there is something else that's important in DxVA and it's the hardware deinterlacing. IMO it's much better than any software deinterlacing method offered by the Core team. And having it done in the hardware it's not hogging the CPU even more.

xW0Lf
12th October 2007, 16:06
ofcourse

dxva + hardware deinterlacing + hardware post-processing (if it's posible to deblock in hardware with current gpu's?) is "a must" !

bmnot
14th October 2007, 19:05
Have you guys considered making a VC-1 decoder? I'm decoding some HD DVD rips with the Microsoft decoder from WMP11, and it runs about 85% CPU on my X2 64 3800+. It's jittery as hell and every couple of minutes it drops 1-20 frames. On the same PC CoreAVC Pro can play my more complex h264 unrestricted high profile encodes and it's completely smooth at about 55% CPU.

Go on, you know you want to... :)

Yeah, the world really needs a good VC-1 decoder right now. Step up to the plate CoreCodec!

Jay Bee
15th October 2007, 10:06
there is something else that's important in DxVA and it's the hardware deinterlacing. IMO it's much better than any software deinterlacing method offered by the Core team. And having it done in the hardware it's not hogging the CPU even more.

You can get hardware deinterlacing without DXVA decoding. It's called "directshow deinterlacing" in the current version of Coreavc. But you're right, even in hardware mode the deinterlacing still isn't as good quality as with decoders that use DXVA decoding.

hdboy
19th October 2007, 17:09
betaboy please define "smokes". what % of improvement over previous version?

would a X2 3800+ @2.4ghz be able to handle decrypted blue-ray/hd-dvd with high bitrate AVC without dropping frames?

Sharktooth
19th October 2007, 18:03
Yeah, the world really needs a good VC-1 decoder right now. Step up to the plate CoreCodec!
The world does not need VC-1 at all...

Inventive Software
19th October 2007, 18:18
What the world wants is not necessarily what the world gets. We're stuck with it in the immediate short-term, we may as well take advantage of it somehow....

ACrowley
21st October 2007, 10:02
betaboy please define "smokes". what % of improvement over previous version?

would a X2 3800+ @2.4ghz be able to handle decrypted blue-ray/hd-dvd with high bitrate AVC without dropping frames?

my x2 3800 in 2nd System handles Bluray H264 very well with CoreAVC

Shinigami-Sama
21st October 2007, 22:19
The world does not need VC-1 at all...

I agree, it just makes things to confusing to less savvy people...

ChronoCross
30th October 2007, 17:37
Version 1.6 has been released :)

Blacksun's Changelog

CoreAVC H.264 Video Codec - Version 1.6.0.0 (20071029)
- Add: Rewrite of the DirectShow wrapper for better compability
- Add: Option to override other h.264/AVC decoders (Merit change)
- Add: Rewrite of the configuration dialog to be cleaner
- Add: RGB656 and RGB555 Output format support
- Fix: Resizing problems with MediaPortal's TS Reader filter
- Fix: Small others fixes

BlackSun
30th October 2007, 17:40
Oh ! I'm way too slow ;) Updates are being sent per email.

I hope to finish the trial version soon.

Kurtnoise
30th October 2007, 18:15
How can I retrieve my serial number ? I lost the email which including it...:o

Jay Bee
30th October 2007, 18:32
New version broke deinterlacing again. Get euro1080.hd5.ts from here (http://x264.nl/h.264.samples/). In bob mode the field order is wrong. In hardware mode there is no deinterlacing at all. Encode a file with x264 --interlaced. No deinterlacing regardless of settings.

Everything's fine with 1.5. And since there is no performance difference between 1.5 and 1.6 (tested) I'll just go back to 1.5...

Disabled
30th October 2007, 18:33
.... we are about to release CoreAVC v1.6 (internally called CoreAVC 'Next Generation'). The filter is a complete re-write from scratch and from my testing 'smokes' v1.5 and previous versions. Why a re-write? Simple, speed...


Where does this fit into the changelog? I'm doing some tests right now, but as JayBee wrote there are none to be expected...

*edit*
CoreAVC 1.5: User: 46s, kernel: 0s, total: 46s, real: 587s, fps: 1316.3, dfps: 105.1
CoreAVC 1.6: User: 46s, kernel: 0s, total: 47s, real: 579s, fps: 1295.2, dfps: 106.6

lexor
30th October 2007, 19:01
- Add: RGB656 and RGB555 Output format support

what is that, and when/who should use that?

nm
30th October 2007, 19:17
They probably mean RGB565 instead of RGB656. It is useful when rendering on a 16bpp RGB surface (like when a 16-bit display mode is used instead of a 24- or 32-bit mode).

BetaBoy
30th October 2007, 19:29
Where does this fit into the changelog? I'm doing some tests right now, but as JayBee wrote there are none to be expected...

*edit*
CoreAVC 1.5: User: 46s, kernel: 0s, total: 46s, real: 587s, fps: 1316.3, dfps: 105.1
CoreAVC 1.6: User: 46s, kernel: 0s, total: 47s, real: 579s, fps: 1295.2, dfps: 106.6

As it relates to high B/W content.

BetaBoy
30th October 2007, 19:51
New version broke deinterlacing again. Get euro1080.hd5.ts from here (http://x264.nl/h.264.samples/). In bob mode the field order is wrong. In hardware mode there is no deinterlacing at all. Encode a file with x264 --interlaced. No deinterlacing regardless of settings.

Everything's fine with 1.5. And since there is no performance difference between 1.5 and 1.6 (tested) I'll just go back to 1.5...

We are looking into it. Thx

Gnerma
30th October 2007, 20:41
I gave 1.6 a go with some high bitrate video and there was a noteable performance improvement on my V0 Q6600 @ 3.2.

1501 - User: 630s, kernel: 1s, total: 631s, real: 957s, fps: 192.6, dfps: 127.1
1600 - User: 171s, kernel: 1s, total: 172s, real: 859s, fps: 703.3, dfps: 141.6

On the 1501 test CPU was between 82% & 97%. Using 1600 CPU usage was between 72% & 92% percent. So not only was it faster overall, but CPU usage was less.

Thanks a lot for the update BetaBoy and everybody else responsible at CC.

Disabled
30th October 2007, 20:50
As it relates to high B/W content.
Here is a 20Mbit sample (3min20)
1.5: User: 28s, kernel: 0s, total: 28s, real: 123s, fps: 177.5, dfps: 40.6
1.6: User: 7s, kernel: 0s, total: 7s, real: 111s, fps: 676.1, dfps: 45.0
Thats a nice 10.8% improvement. Great job!

*edit*
btw I have a e6400

Jay Bee
30th October 2007, 21:49
How are you guys creating these stats?

Disabled
30th October 2007, 21:56
I'm using timecodec from here (http://haali.cs.msu.ru/mkv/timeCodec.exe).

Jay Bee
30th October 2007, 23:45
Thx, just ran a couple of tests on my single core Opteron.

In the order CoreAVC 1.6, CoreAVC 1.5, FFDShow, Cyberlink (no DXVA):

Apple trailer: 55.1 fps, 55.4 fps, 37.3 fps, 46.8 fps
Blu-Ray stream: 22.1 fps, 22.2 fps, 17.1 fps, 26.5 fps(!)

BetaBoy
31st October 2007, 14:07
Can anyone else confirm the results being given? It seems a few ppl are slower and we are trying to userstand what makes them unique to the others that are reporting 1.6 is faster.

audyovydeo
31st October 2007, 14:59
Can anyone else confirm the results being given?


Not enough to be conclusive, but enough to be worried :

Usind TimeCodec :
clip / renderer / coreavc1.5.0.1 / Coreavc1.6
clip1 null 102.2 100.9
clip1 VMR9 102.5 102.0
clip2 null 96.7 78.6
clip2 VMR9 95.4 70.43


clips are 720x576@25fps material (30s and 3m) encoded with x264 to be level 3.1 compliant.
System is a Pentium M @ 1.80 GHz running WindowsXP SP2
I'll try tonight on my dual-core, maybe 1.6 was optimised for multicore CPUs.

Probably the settings used to encode a clip are the differenciating factor.

cheers
audyovdeo

LigH
31st October 2007, 18:29
A user in the german board reported upside-down flipped output (http://forum.gleitz.info/showthread.php?t=35886); downgrading to 1.5 restored the correct direction.

Any suggestions what he should enable/disable inside CoreAVC 1.6 to flip the output back?

Momber
31st October 2007, 23:58
On my machine (P4 3 GHz @ 3.3 GHz, 1 GB RAM) the old CoreAVC 1.1.0.5 is still king of the hill with respect to CPU efficiency (which is very important on such an antiquated machine).
Here are the CPU-graphs of a high bitrate x264 720p opening sequence:

http://img229.imageshack.us/img229/9721/core16hd2.jpg

And yes, I agree, deinterlacing of H.264 files (e. g. from BBC HD) is totally non-functional. It really makes no difference which setting I choose - none works.
Plus, with those files, Core 1.6 refuses to connect to either Elecard Demultiplexer or Cyberlink Demux. Only Haali works (that's under Zoom Player 5).

Ciao
S.

BetaBoy
1st November 2007, 01:23
On the deinterlacing issue... Is the content local or from a source program like DVBViewer, etc.?

Also in Graphedit what does the pin output look like? Can you compare 1.5 to 1.6?

Momber
1st November 2007, 03:04
On the deinterlacing issue... Is the content local or from a source program like DVBViewer, etc.?

Always local. A P4 CPU is by far not fast enough for live-H.264-HDTV in DVBViewer.

Also in Graphedit what does the pin output look like?
The Problem in Graphedit is pretty much the same as in ZoomPlayer - it crashes either outright (with Elecard) or refuses to connect (with Cyberlink).

http://img236.imageshack.us/img236/1339/graph1jw0.jpg

Can you compare 1.5 to 1.6?
Yeah OK, here is a graph of the same opening sequence when played back with 1.5:

http://img89.imageshack.us/img89/1318/core15yi1.jpg

Greets
S.

lexor
1st November 2007, 03:36
Yeah OK, here is a graph of the same opening sequence when played back with 1.5:

Greets
S.
I think comparison was meant to be for Graphedit layout, 1.5 vs 1.6, not cpu usage.

Momber
1st November 2007, 04:54
I think comparison was meant to be for Graphedit layout, 1.5 vs 1.6, not cpu usage.
I see. Thanks for clearing that up.
I just checked - both 1.1 and 1.5 show the same behaviour with that particular file (and that includes Sonic HD Demux). So this file only seems to work with CoreAVC when Haali is used as a splitter.
However, when I select the Cyberlink H.264 decoder instead of Core, I have the choice to use either Haali, Sonic or Cyberlink splitters successfully (Elecard still crashes).


S.

Jay Bee
1st November 2007, 18:12
VMR input pin info for the euro1080 sample I mentioned earlier.

1.5

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output

- Connection media type:

Video: YUY2 1472x1080 (491:270) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3179520
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x000000a1
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1964
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1472
biHeight: -1080
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 3179520
biXPelsPerMeter: 1555200
biYPelsPerMeter: 2121120
biClrUsed: 0
biClrImportant: 0



1.6

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output

- Connection media type:

Video: YUY2 1472x1080 (7447:4096) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3179520
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000025
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 7447
dwPictAspectRatioY: 4096
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1472
biHeight: -1080
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 3179520
biXPelsPerMeter: 4096
biYPelsPerMeter: 5585
biClrUsed: 0
biClrImportant: 0




As you can see there's a difference in dwInterlaceFlags. And another problem. At the beginning of the file 1.6 does this
http://xs321.xs.to/xs321/07444/vdssg.jpg
while 1.5 doesn't. This is frustrating. Ever since buying CoreAVC about 18 months ago I've been waiting for a version that works. I was very happy when it finally came with 1.6: it has great compatibility with all kinds of AVC streams especially types that matter such as interlaced HDTV but it only lasted until 1.6 to break that again. I hope the pin info above helps although I'm sure your team of engineers has had enough time to get that data themselves.

DeepBeepMeep
2nd November 2007, 02:12
CoreAVC 1.6 seems to cause some unexpected glitches on some frames. I can't check if this new to 1.6 as 1.5 will not accept to be installed again. However, It is certainly not a stream issue as Powerdvd plays the same files correctly.

I would be grateful if you could fix that quickly or tell me how to reinstall version 1.5. Here is a link to a sample: around 1s, a glitch appears in the middle of the screen for just one frame.
http://www.sendspace.com/file/gmf0wc

Thanks

BetaBoy
2nd November 2007, 03:16
We are looking into the reported issue and will likely have 1.6.1 pushed out soon.

JohnnyFu
2nd November 2007, 03:40
I stopped asking about GPU support for a couple of months because some people got slighty aggressiv on this matter. But I still wanna know when I finnally get the GPU support I payed for.

Since my question I asked on corecodec.com yesterday got instantly deleted by BetaBoy because I supposedly violated their forum rules with my question. I ask my question again in this forum:


"So what about GPU support you guys announced almost 20 months ago?"

(thats all I wrote on corecodec.com, I don't know what's wrong on this sentence/question ? how could that violate the forum rules ? BetaBoy wont tell me, at least it seems that he is ignoring my personal message)

I hope this doesn't violate the rules of this forum.

p.s. And please stop comments like "who cares about GPU support" alot of people do care.

BetaBoy
2nd November 2007, 05:56
JohnnyFu... A post in the CoreCodec forums has to do what with Doom9? Please keep comments like this over on the CoreCodec forums, there. As far as GPU is concerned... I have already answered you going back about 50 pages ago in this thread.

Simply put... till the GPU companies stop relying on means like DXVA you will not get MASS adoption. Now that the cracks are starting to appear, it seems that 2008 in going to be a great year in regards to this (see ATI/AMD). I also applaud other companies looking into an 'open' approach and have seen some great presentations recently that lean towards this. I would also note that I am 'limited' to say everything I know because of NDA considerations.

LigH
2nd November 2007, 06:24
@ BetaBoy:

Just a little reminder: Any suggestion about the flipped output?

My guess: Can it be related to the output format (YUY2 vs. YV12), or connecting to different renderers?

How about adding a checkbox in case of doubt?

DeepBeepMeep
2nd November 2007, 10:15
We are looking into the reported issue and will likely have 1.6.1 pushed out soon.

Please note the issue I have reported seems to be a different one to the other one which has been reported on 1.6 since deinterlacing is completely disabled.

Thanks

red5goahead
2nd November 2007, 18:28
Could be very usefull a telecining process in the decoding to bring frame rate to 60 fps from 24 fps material. A lot of tv panel support 60 Hz. but not 24 or multiple as 72 Hz.
So could be very interesting this features.
I use KMPlayer with Dual Core e4400 processor and an Ati 2600 Pro with a Panasonic Plasma 37PV60
I hope so... :thanks:

TheShadowRunner
4th November 2007, 13:45
Agreed with JohnnyFu, the product was marketed as having GPU HA soon, was it not?
And that was almost 2 years ago.
I don't understand your justification either, BetaBoy.
Anyway, there clearly is a need for a h.264 decoder with proper hardware acceleration.
Cyberlink is very buggy and can only be relied on when it comes to HDDVD or BD. MKV @ 720p have either the "locked 20fps" bug or display ugly artifact when older version of the codec are used to avoid the 20 fps bug. And for 1080p, easy, it's a no go (black screen with 90% of the sources).
Of course this can be also decoded in software, more or less good depending on the CPU, but I'm sure all those people who buy nVidia 8x00 series card nowadays have in mind that they will offload h.264 decoding to the card totally and profit from the card's shaders and everything.
The problem is that as of now, this is impossible.
Oh lord I wish nVidia had their own h.264 software decoder with HA support but that won't happen. The only thing i can wish for atm is that you do what you said (and marketed your product with).
Later,

TSR

edit: Red5, check ReClock, it works fine with CoreAVC

BetaBoy
4th November 2007, 14:03
TSR..... I must also note that as far as DXVA is concerned I never said never. At some point we will add support for it... but we feel our efforts are better spent now on making CoreAVC more effecient, adding more features and when possible making it faster. This is why v1.6 'Next Generation' is a complete filter re-write and addresses those goals.

xW0Lf
4th November 2007, 19:24
4 betaboy, ok then add dxva hw as gift to your customers... (bonus feature.. hehehe)

about supported cards (4 theshadowrunner), don't forget thant nvidia 8x00 cards are not only one that have gpu support for h264... amd ati 2x00 cards work excellent that job too! :)

JohnnyFu
4th November 2007, 21:05
about supported cards (4 theshadowrunner), don't forget thant nvidia 8x00 cards are not only one that have gpu support for h264... amd ati 2x00 cards work excellent that job too! :)

As well as some GeForce generation 6 and 7 cards.

xW0Lf
4th November 2007, 21:48
yeah... but new generation of nv8x00 and ati2x00 cards have much more advanced hw decoding.... than previous generations (including nv6x00 & nv7x00 cards)

TheShadowRunner
4th November 2007, 23:01
There is even a difference within 8x00 cards.
8400, 8500 & 8600 being far superior to 8800 in this field.
See you!

TSR

Gnerma
4th November 2007, 23:19
There is even a difference within 8x00 cards.
8400, 8500 & 8600 being far superior to 8800 in this field.
See you!G80 based 8800 anyway. The 8800 GT and all future SKUs based on the 65nm G92 chip have the same PV2 engine found in 8600 etc.

Yufi
4th November 2007, 23:37
Any more updates on the Linux version? CoreAVC for Windows is the only thing keeping me using Windows Media Center for my HTPC (pesky 1080p x264 content), and as soon as the Linux version comes out I'll be switching over the very same day to run MythTV.

nm
5th November 2007, 00:03
CoreAVC dshow filter can be used on Linux by patching MPlayer, Xine or MythTV: http://code.google.com/p/coreavc-for-linux/

Of course, it would be nicer if an official library was released.

Yufi
5th November 2007, 00:24
CoreAVC dshow filter can be used on Linux by patching MPlayer, Xine or MythTV: http://code.google.com/p/coreavc-for-linux/

Of course, it would be nicer if an official library was released.

Those patches don't work with the latest versions of mythtv or mplayer, unfortunately; nor do they work with the latest versions of CoreAVC. Plus, I'd really prefer having an "official" linux version then having to hack together patches each time software was updated.

red5goahead
5th November 2007, 14:02
edit: Red5, check ReClock, it works fine with CoreAVC

I know ReClock but under Vista or related to multichannel audio spdif stream Reclock do not work. Should be the decoder (CoreAvc) or the renderer (?) to build the progressive telecining. is it weird think that features in CoreAvc?

BetaBoy
9th November 2007, 15:19
All.... prior to CoreAVC v1.6.1 we have two goals. One is here:
http://www.coreavc.com/retrieve

You can now retrieve your CoreAVC Serial number at anytime in case you have forgotten or lost it (this information has also been added into our CoreAVC KB at http://support.corecodec.com ).

The second goal we are working on now is the 14 day Trial version which we hope to have out shortly.

Eretria-chan
9th November 2007, 16:37
14 days? Isn't that a bit cheap? Most give 30 days.

GmorG McRoth
9th November 2007, 17:13
14 days? Isn't that a bit cheap? Most give 30 days.

Maybe that means 336 Hours of playback :)

BetaBoy
9th November 2007, 18:24
That debate is still going on internally 14 vs 30, but its 14 as of this moment... but as demographic studies are concerned.... a user has made his decision way before the 14 days is over with.

bkman
11th November 2007, 05:22
Betaboy,

I have a clip where CoreAVC displays motion errors but ffmpeg does not, so I think it may be a bug in CoreAVC. Though it could also be a bug in x264, or a bug in my ram.

Can you look into it? Here's the clip:

http://www.mediafire.com/?djcnyc0wzto

ACrowley
11th November 2007, 09:19
Betaboy,

I have a clip where CoreAVC displays motion errors but ffmpeg does not, so I think it may be a bug in CoreAVC. Though it could also be a bug in x264, or a bug in my ram.

Can you look into it? Here's the clip:

http://www.mediafire.com/?djcnyc0wzto

Its the "Motion Vector Bug"
It was discussed in this Thread before
The Problem was caused by older 264 Builds (under rev663) because the encoded Motion Vector Value was to high/wrong (so far i can remember)

CoreAVC produce ugly Blocking in this Sceens with fast movement and/or Water,Rain etc. Where libavcodec,Cyberlink,Sonic have no Problem

So encode only with new x264 Builds and youve no Problem
When you ask me, i hope Corecodec can fix it :)

bkman
11th November 2007, 11:09
But I used a newish x264 build for that encode. Cef's 680. :confused:

ACrowley
11th November 2007, 11:37
But I used a newish x264 build for that encode. Cef's 680. :confused:

i use 682 (AQ) and i have no Problems with new Builds .
No more Blocking..it was with Builds - rev 663, are you sure it was a new Build ?

What Source ?
What Decoder for Source Decoding
etc...

bkman
12th November 2007, 07:16
The source is DVD. The decoder is DGDecode. You know, the usual.

That part of this movie was the only instance of this problem I've seen out of multiple encodes.

ACrowley
12th November 2007, 09:59
Ok..so its caused by Decoding

Try to use another Mpeg2 Decoder

HowlerX
12th November 2007, 10:11
Ok..so its caused by Decoding

Try to use another Mpeg2 Decoder

Dude, did you download the sample? The sample plays and looks fine with ffdshow decoder. Looks like shit with CoreAVC.

Either bkman has an older build of x264 and doesn't know it. Or the bug is still present. Who can tell?

Someone posted that this would be a simple fix for the CoreAVC team to implement, maybe they should just listen and fix it.

I've seen this "video corruption" on many of my older encodes and seems like a waste to re-encode all over again.

Shinigami-Sama
12th November 2007, 21:20
it doesn't seem like it'd be that hard to make it handle it, even if it was a checkbox in the advanced section to do it...

ACrowley
12th November 2007, 22:38
Dude, did you download the sample? The sample plays and looks fine with ffdshow decoder. Looks like shit with CoreAVC.

Either bkman has an older build of x264 and doesn't know it. Or the bug is still present. Who can tell?

Someone posted that this would be a simple fix for the CoreAVC team to implement, maybe they should just listen and fix it.

I've seen this "video corruption" on many of my older encodes and seems like a waste to re-encode all over again.

Ah yes...didnt spend much Time on it.
Ofcourse youre Right, when its Ok with other Decoders it shouldnt be a Source Decoding Problem

I know...i cant understand why CoreCodec wont fix this MotionVector Thing!
I pers wont reencode my whole x264 encodes from "older" x264 encodes (-rev 663) only because CoreAVC cant handle them :)
Cyberlink/ffdshow etc works perfect.

I think its Easy : Corecodec ( and some Posting here) say it not a CoreAVC Problem, its a x264 Problem :rolleyes:
But in Fact, when CoreAVC is the only Decoder with Problems on those encodes...its a CoreAVC Problem too, so or so.

However, his Sample looks exactly like the MotionVector Bug so i assume its was really a older x264 rev.
You cant see extended H264 User Data Infos in this short Sample with Avinaptic Tool, so i cant see the "real" x264 rev from encoding

@bkman
Even when you know it was a new x264 rev, please check your full Encode with AVInaptic Tool
You can see the x264 rev in "About H264 encoding / User Data "

Inventive Software
12th November 2007, 22:59
Their problem is that they've created a spec-compliant decoder. x264 didn't create spec-compliant files until 663, so why should they adapt the code for it? A simple check mark that allows relaxed restrictions would probably allow decoding for it...

akupenguin
12th November 2007, 23:12
it doesn't seem like it'd be that hard to make it handle it, even if it was a checkbox in the advanced section to do it...
Not necessarily. I can only guess why CoreAVC depends on the exact mv length restriction, but some reasons could depend on optimizations that would be impossible to handle (even optionally) without costing speed. e.g. if they pack mvs into a 12bit data data structure, mvs > 12bits will be borked, and you can't exactly re-layout your data structures at runtime.

Disabled
12th November 2007, 23:20
Their problem is that they've created a spec-compliant decoder. x264 didn't create spec-compliant files until 663, so why should they adapt the code for it? A simple check mark that allows relaxed restrictions would probably allow decoding for it...
Yeah right, why should Xvid support DivX 3.11 files? They are not standart compliant, so why bother? Just redo every encode and it doesn't matter, if you perhaps don't have the source anymore (DVB capture for instance).
A lot of ppl have a lot of files encoded with the older x264 builds. Sure Core doesn't need to deliver a working decoder for these files, but it would be pretty nice!
Did we hear an official word from them yet? Or do they think the thugs telling us there is no need for a proper decoder is enough?
*edit*
Not necessarily. I can only guess why CoreAVC depends on the exact mv length restriction, but some reasons could depend on optimizations that would be impossible to handle (even optionally) without costing speed. e.g. if they pack mvs into a 12bit data data structure, mvs > 12bits will be borked, and you can't exactly re-layout your data structures at runtime.
Thats my assumption too, but it would be great to have an official explanation.

Shinigami-Sama
12th November 2007, 23:49
Not necessarily. I can only guess why CoreAVC depends on the exact mv length restriction, but some reasons could depend on optimizations that would be impossible to handle (even optionally) without costing speed. e.g. if they pack mvs into a 12bit data data structure, mvs > 12bits will be borked, and you can't exactly re-layout your data structures at runtime.

they had it working before
so I know it can be done
thought they might have to wrap a whole chunk of code into a giant if/switch/terny to do it

lexor
13th November 2007, 04:47
Yeah right, why should Xvid support DivX 3.11 files?
Why should it? What do you even mean? Xvid is an encoder, divx3 has an encoder (albiet antiquated), and a standard compliant mpeg4asp decoder decodes both, thus making each a codec. The decoder that ships with Xvid doesn't specifically decode Xvid, it decodes an mpeg4asp compliant stream. Xvid itself is an encoder, and what does one encoder has to do with the other?

And yes, non-compliant streams should be left broken, since they are... broken (assuming they are broken and not some esoteric restriction of a specific implementation, like HD-DVD or Blu-ray).

All.... prior to CoreAVC v1.6.1 we have two goals. <...>
The second goal we are working on now is the 14 day Trial version which we hope to have out shortly.
You want to release an evaluation copy before you fix the bugs? ... right, solid logic.

akupenguin
13th November 2007, 05:20
Why should it? What do you even mean? Xvid is an encoder, divx3 has an encoder (albiet antiquated), and a standard compliant mpeg4asp decoder decodes both, thus making each a codec.
But divx3 isn't mpeg4asp. It's msmpeg4v3, i.e. Microsoft's implementation of a draft of mpeg4. Significant changes were made between the draft and the final version. I don't know about xvid, but libavcodec needs about 4000 lines of code dedicated to msmpeg4, in addition to some code it shares with standards compliant mpeg4 decoding.

bkman
13th November 2007, 09:24
Guys, I'm certain it was a recent revision of x264.

Here's the info:


User data: x264
User data: core 56 svn-680
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-2:-1
User data: analyse=0x3:0x133
User data: me=umh
User data: subme=6
User data: brdo=1
User data: mixed_ref=1
User data: me_range=24
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=2
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=1
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=2pass
User data: bitrate=1696
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: zones=137782,143079,q=40
SPS id: 0
Profile: High@L5.1
Num ref frames: 8
PPS id: 0
Entropy coding type: CABAC
Weighted prediction: No

I also used the Prestige CQM.

Someone should have a look at the sample to see if x264 is still producing MV's of illegal length.

Disabled
13th November 2007, 10:52
Why should it? What do you even mean? Xvid is an encoder, divx3 has an encoder (albiet antiquated), and a standard compliant mpeg4asp decoder decodes both, thus making each a codec. The decoder that ships with Xvid doesn't specifically decode Xvid, it decodes an mpeg4asp compliant stream. Xvid itself is an encoder, and what does one encoder has to do with the other?
I always thought Xvid was a coDec and mistakenly they are also stating this on their main page. But if it istn't please excuse me and take the obvious from my post: The decoder shipped with Xvid decodes ASP and non standart 3.11 for no real reason and there is not a single person that needs decoding of non standart spec files.

*note* In my opinion not many care about 3.11 support today, I should have written all this in the past tense.

lexor
13th November 2007, 16:01
I always thought Xvid was a coDec and mistakenly they are also stating this on their main page. But if it istn't please excuse me and take the obvious from my post: The decoder shipped with Xvid decodes ASP and non standart 3.11 for no real reason and there is not a single person that needs decoding of non standart spec files.

*note* In my opinion not many care about 3.11 support today, I should have written all this in the past tense.

ok, now according to aku's reply, 3.11 isn't even a mpeg4asp codec, which xvid is, so I now completely don't understand what one has to do with the other. It's like asking xvid to support wmv... it's meaningless.

Disabled
13th November 2007, 16:09
ok, now according to aku's reply, 3.11 isn't even a mpeg4asp codec, which xvid is, so I now completely don't understand what one has to do with the other. It's like asking xvid to support wmv... it's meaningless.
The thing is, the decoder bundled with Xvid does support 3.11 and for the same reasons why Core should support the non spec h264 files, cause there are a lot of them around and not everyone has the time and sources to redo the encodes. And ppl don't want to switch the decoder everytime. (And that problem didn't exist with 3.11, as they had a different fourcc)

clsid
13th November 2007, 18:35
Implementing a workaround for an encoder bug is a different thing than supporting a whole different format.

ChronoCross
13th November 2007, 19:20
Implementing a workaround for an encoder bug is a different thing than supporting a whole different format.

But the problem is if you make a workaround for 1 encoder bug you gotta do it for all of them.

With the wide variety of encoders out there the possibility for them at some point to be doing something slightly out of specs is higher.

This will increase the number of workarounds which may eventually start to weight the codec down.

pankov
13th November 2007, 19:52
guys,
for me it's all about percentages - I think x264 is one of the most popular encoders at the moment and it's been this way for a while. Since it had a bug in the past and there are so many encodes affected by it and this bug could be worked around in the decoder I think it should be done. I'm not saying to add workarounds for all the bugs in all the encoders in the world but only for the most commonly used. This way the user will not have negative feelings about Core's decoding ability, face it - most of the users don't even know what's an encoder and how it could be the cause for the ugly artifacts in "my favorite movie" and he will not have to look for other decoders that can solve the issue.
I think most of you will agree with me, so let's hope the Core team will too.

Inventive Software
13th November 2007, 20:02
The thing is, the decoder bundled with Xvid does support 3.11 and for the same reasons why Core should support the non spec h264 files, cause there are a lot of them around and not everyone has the time and sources to redo the encodes. And ppl don't want to switch the decoder everytime. (And that problem didn't exist with 3.11, as they had a different fourcc)

It supports 3.11 because it's originally based on that decoder, the project originally coming from OpenDivX.

Disabled
13th November 2007, 20:16
Implementing a workaround for an encoder bug is a different thing than supporting a whole different format.
Thats not actually an argument agains implementing the workaround is it?
But the problem is if you make a workaround for 1 encoder bug you gotta do it for all of them.

I'm with pankov there: Just implement workarounds when there are massive encodes nedding it. Do this on a case by case basis, if enough ppl want it and it's not that much work, do it.
And I hereby apologise for the Xvid comparison, please just forget it.
A question though: Did anyone official state, they are not gonna support the non-spec x264 files?

Scoty
13th November 2007, 23:05
i can download 1.6 but not the 1.6.1 ??

Disabled
13th November 2007, 23:23
i can download 1.6 but not the 1.6.1 ??
Might be because there is no 1.6.1 out yet? At least I didn't get a notice like the last times.
And this:
All.... prior to CoreAVC v1.6.1 we have two goals.

Shinigami-Sama
13th November 2007, 23:43
hey beta boy

any chance a lowly P4 3ghz, pc3200 1.5GB can handle 1080i in the next version or two?
if so you'll get my money sooner

Inventive Software
14th November 2007, 02:38
Bloody hell Shinigami-Sama, you're asking a lot aincha? :D

Shinigami-Sama
14th November 2007, 02:42
Bloody hell Shinigami-Sama, you're asking a lot aincha? :D

nah I was just wondering if I could put that old PC to good use as an HTPC
my laptop plays 720p with FFDshow pretty smoothly, and its about the same speed wise as the PC

ACrowley
14th November 2007, 13:48
Their problem is that they've created a spec-compliant decoder. x264 didn't create spec-compliant files until 663, so why should they adapt the code for it? A simple check mark that allows relaxed restrictions would probably allow decoding for it...

Yes.
Cyberlink/Nero/Sonic are spec Compliant too :)
And they have no Problem with large MV. So CoreAVC shouldnt have too..thats my simple Opinion

Also i cant see any Perfomance loss with Cyberlink Decoder on these x264 encodes with large MV

bob0r
14th November 2007, 14:31
Maybe following mv range specs strictly is the HOLY SECRET of CoreAVC's speed!! :script:

clsid
14th November 2007, 14:32
Being spec compliant means correctly supporting all features described in the specification. If CoreAVC would support large MV, then it would still be spec compliant.

The only arguments against implementing it would be performance. But given the fact that the performance of CoreAVC was already very good in the past when large MV were still supported, I don't think that argument holds much strength. In any case, support for large MV could be made optional and there could be two different code paths.

lucassp
14th November 2007, 14:58
Does anyone have any idea about how much does CoreAVC score in the HQV HD Benchmark?

nm
14th November 2007, 16:00
Probably not very high since CoreAVC is a H.264 decoder, not a scaler, and the only filtering it can do are colorspace conversions and simple deinterlacing (which you'll probably want to avoid in favor of using hardware deinterlacing or better software filters).

hakujin
18th November 2007, 05:27
is coreavc becoming more processor intensive as it's revised? I'm wondering whether 1.6 release is good for a 3.0ghz northwood P4 box. Previous version played 720p x264 rips smooth as butter. But on the newer release, there's no explicit turn off deblocking or deinterlacing so wondering... Also any new bugs introduced (noticed motion vector problem) that would make 1.5 a better choice?

TIA

BetaBoy
18th November 2007, 07:16
You want to release an evaluation copy before you fix the bugs? ... right, solid logic.
I'm sorry... did we release a trial yet?

BetaBoy
18th November 2007, 07:31
I appreciate all the comments in this thread... even the off base ones... as bob0r hinted at.

We are working on 1.6.1.... on several different fronts... On the non-compliant streams... I'd like to make a comment more or less without being too specific.... Rather then create work around, after work around, after work around... we would rather tell/work/inform the ppl who created the encoders about the issue to have them resolve it.

This would make a situation even worse for the future when you start to add the SVC layer on top of that.

Also, this does not by any means, mean that by me stating the above that there are not things wrong with the decoder on our side... thats why we are here, for the community to tell us what's wrong and for us to make those changes to fix it.

Another Devel thing to note.... we are also working again on the CORE optimizations to increase speed. As I had indicated here a few times there is still more %'s to be had. We hope to include some of these enhancements in 1.6.1.

oddball
18th November 2007, 19:18
The fact that ffdshow (Beta) now supports dual core, is better quality, supports non-standard motion vectors and is *FREE* now makes CoreAVC obsolete for everything but low spec systems. Speed is the only thing CoreAVC seems to have over other decoders. Since I am on a decent specced system I am now using the new ffdshow build instead of CoreAVC even though I purchased CoreAVC (More fool me).

I find the total disregard for supporting non-standard motion vectors like EVERY other decoder out there even though it would make NO difference to the decoders fucntionality for standard encodes totally ludicrous. Betaboy I am sorry but your product is now a complete lemon to me.

BetaBoy
18th November 2007, 19:40
oddball... I suggest until you state FACTS by means of EXAMPLES, then you should not state anything at all.

ACrowley
18th November 2007, 20:04
yeah oddball...but ffdshow Mutithreading is currently no "real" Multithreading ..only one Slice per Thread, right ?

clsid
18th November 2007, 20:15
There also is an experimental patch for frame based multi-threading.

oddball
18th November 2007, 21:28
Well I can supply an example of an encode that plays back badly with CoreAVC (Blocking all over the place) because it uses non-standard motion vectors. But you have already clearly stated you won't support non-standard encodes so what's the point?

Jay Bee
18th November 2007, 21:51
Speed is the only thing CoreAVC seems to have over other decoders.

It's the only decoder that can play HDTV without needing a latest generation GPU.

oddball
18th November 2007, 22:10
It's the only decoder that can play HDTV without needing a latest generation GPU.

Absolutely and for that I give credit where credit it due. However this will become less and less an issue as time goes by for many people as they upgrade their systems. To stay ahead of the competition you need more than just the speed of the decoder alone. Compatability across the board would be a start. Standards based decoders are all well and good but ffdshow (Did I mention it's free?), PowerDVD and probably a few others seem to handle non-spec encodes just fine. If a decoder cannot playback ALL the 264 material I throw at it then it's not really worth using let alone paying for.

You wanted examples BTW

http://img229.imageshack.us/img229/1813/example1tt9.jpg

http://img215.imageshack.us/img215/4277/example2tg4.jpg

I do not get this blocking with any other decoders.

I also posted examples before but you clearly IGNORED them.

BetaBoy
18th November 2007, 23:39
... and these example screencaps were created using what encoder/build?

oddball
18th November 2007, 23:55
CoreAVC 1.6.1 but all builds exhibit the same problem.

No idea who/how it was encoded (In b4 ****storm).

honai
19th November 2007, 00:17
Those screenshots are from a private x264 encode of Apocalypto Blu-ray distributed over P2P, and the issue is well-known: certain older x264 builds used out-of-spec motion vectors.

oddball
19th November 2007, 00:54
Those screenshots are from a private x264 encode of Apocalypto Blu-ray distributed over P2P, and the issue is well-known: certain older x264 builds used out-of-spec motion vectors.

The thing is that does not really help the matter and the last thing I need is people giving me grief about something that is not relevant to this topic. Suddenly you will get 'oh it violates the boards rules' so it ends up as a cop out to avoid addressing the problem. The problem being that CoreAVC cannot handle those type of encodes. Anyhow since nobody but me appears to give two flying F's about it I will just stick with ffdshow and let CoreCodec go about their business (Whatever that may be).

Wish I had not bothered even mentioning it. Actually I wish I had not bothered even buying it.

BetaBoy
19th November 2007, 03:17
oddball pls PM me your transaction # and I will refund your purchase.

bmnot
19th November 2007, 03:42
Uh..... why doesn't CoreAVC 1.6 have the deblocking setting? Is it on or off by default? Why can't I change it anymore?

BetaBoy
19th November 2007, 03:43
We are re-adding it to the next release.

bmnot
19th November 2007, 03:44
Ok, thanks betaboy!

oddball
19th November 2007, 03:52
To be frank a refund is not what interests me at this point. I realise that you may think this might shut me up. But I'd rather you actually add the code in to allow non-spec encodings to play. Not just for me but for anyone else who may run into this problem. I appreciate the gesture though. It's just not the answer I was looking for. Keep it.

bmnot
19th November 2007, 04:05
^Maybe you should stop get getting crap encodes?

And CoreAVC is not obsolete for everything but low spec systems. My system is pretty high end (X2 2.6Ghz) but it cannot playback 30Mbps AVC from Blu-rays with ffdshow. CoreAVC plays it fine.

Shinigami-Sama
19th November 2007, 04:24
To be frank a refund is not what interests me at this point. I realise that you may think this might shut me up. But I'd rather you actually add the code in to allow non-spec encodings to play. Not just for me but for anyone else who may run into this problem. I appreciate the gesture though. It's just not the answer I was looking for. Keep it.

I do agree that legacy non-spec support should be there, even if they just repack an old coreavc release into the .ax to handle it
but whining and making a scene like this isn't helping the situation much

oddball
19th November 2007, 05:22
I do agree that legacy non-spec support should be there, even if they just repack an old coreavc release into the .ax to handle it
but whining and making a scene like this isn't helping the situation much

Fair enough. But I have mentioned this before and it went completely ignored. Also the much anticipated hardware acceleration using the video cards inbuilt decoding engine pretty much died a long time ago. It was pure hyperbole. Would it have made any difference to decoding speed? Who knows. All I know is that it was on the cards but never materialised.

Anyhow I have said my peice. I've done as much as I can to see that this issue was addressed by the devs. If nothing happens after this then so be it. I will quit carping on about it from now on.

Inventive Software
19th November 2007, 05:46
Anyhow I have said my peice. I've done as much as I can to see that this issue was addressed by the devs. If nothing happens after this then so be it. I will quit carping on about it from now on.

Please do. The fact you made your point with an illegal encode suggests your morals are a little, shall we say, twisted?! Yes, CoreCodec don't account for a PRE-ALPHA encoder's prior limitations. This is down to the developers who started from scratch, and are still improving the codec and making it spec-compliant so the P2P files you illegally download will actually play correctly with this decoder.

My $0.02, which are actually worth less than £0.01! ;)

Momber
19th November 2007, 09:02
Speed is the only thing CoreAVC seems to have over other decoders.
I would agree on that part.
Unfortunately, CPU efficiency has decreased gradually with every release after 1.0.5. I would like to see Core addressing this issue and concentrate on its traditional strength.

S.

G_M_C
19th November 2007, 09:32
I've got a question;

I've build myself a new machine, with a E6750 & 4Gb of fast ram, and i would like to start using Vista 64 bit (XP 32 bit is used now).

Is there allready a CoreAVC-version that works on Vista 64 bit ? Or is one coming soon ?

ACrowley
19th November 2007, 09:51
I've got a question;

I've build myself a new machine, with a E6750 & 4Gb of fast ram, and i would like to start using Vista 64 bit (XP 32 bit is used now).

Is there allready a CoreAVC-version that works on Vista 64 bit ? Or is one coming soon ?


CoreAVC 1.6.0.0 works fine on Vista x64 :)

ACrowley
19th November 2007, 09:54
It's the only decoder that can play HDTV without needing a latest generation GPU.


CyberlinksH264Decoder works with nice Perfomance in Software Mode

I can run Bluray 1080p H264 with Cyberlink Decoder smooth on my
X2 @5000

Also MBAFF Content

G_M_C
19th November 2007, 10:43
CoreAVC 1.6.0.0 works fine on Vista x64 :)

Thx for your fast reply.

Now all i need to do is find the rest of "the stuff" for Vista 64, and than i can set up my machine (MPC, FFDShow_Tryouts etc). Switching over to Xp 32 bit to Vista 64 bit proves to be a big quest for software :o

I can find the drivers (since i have very new machine) but finding software is less easy.

Jay Bee
19th November 2007, 12:01
CyberlinksH264Decoder works with nice Perfomance in Software Mode

I can run Bluray 1080p H264 with Cyberlink Decoder smooth on my
X2 @5000

Also MBAFF Content

Yes but HDTV is interlaced. Cyberlink doesn't do hardware deinterlacing in software mode and doesn't do deblocking in hardware mode on most cards. CoreAVC does both. For non-interlaced content I agree, CoreAVC isn't really needed but PDVD isn't free either.

ACrowley
19th November 2007, 17:43
Yes but HDTV is interlaced. Cyberlink doesn't do hardware deinterlacing in software mode and doesn't do deblocking in hardware mode on most cards. CoreAVC does both. For non-interlaced content I agree, CoreAVC isn't really needed but PDVD isn't free either.

As i say "all" in Software Mode.
Cyberlink applies full deinterlacing on MBAFF Content in Software Mode too
Ofcourse COREAVC is faster on all H264 Types, but its possible wit cyberlink in Software Mode on a fast DualCore

In PremiereHD or SkyHD are more or less no interlaced Frames.
Its more progressive...only BBCHD is "real" interlace because its MBAFF

Jay Bee
19th November 2007, 18:00
You say PDVD does proper 50 fps deinterlacing in software mode? And Premiere Bundesliga isn't really interlaced?

Both are not true, I'm afraid. :confused:

bob0r
19th November 2007, 20:01
....

In PremiereHD or SkyHD are more or less no interlaced Frames.
Its more progressive...only BBCHD is "real" interlace because its MBAFF

95% of all broadcasts are progressive, only a live music show now and then is interlaced.

MBAFF can be 100% all progressive blocks, thus frames.

@Core

- CoreAVC the green start frames issue
- CoreAVC readds to disable deblocking (why the hell was it removed??)
- CoreAVC _possibly_ add an option for large mv range
- CoreAVC check all speed decrease reports.... (ASK PEOPLE TO SEND IN TIMECODEC REPORTS?? C O M M U N I C A T E)

If Core will do this in a next version soon, they back on track again.

BetaBoy: If for some reason some issues can not be solved: BE HONEST!
Just say: we cant fix *this* because <insert reason here>
reasons can be:

- We dont want to put in more time, time is money
- We are not able enough to do so (which is not true :p)
- We will ONLY follow spec and hence some issues will never we resolved (which sounds fair to me)
However, if possible adding some spec voiding features like disable deblock and large mv range, could go in a seperate box + warning when you enable them.

I repeat: C O M M U N I C A T E (life can be so easy)

BetaBoy
19th November 2007, 20:09
bob0r... I never expected a response like this from you.... Please note from 1 page back...

Also, this does not by any means, mean that by me stating the above that there are not things wrong with the decoder on our side... thats why we are here, for the community to tell us what's wrong and for us to make those changes to fix it.

We are addressing ALL of the issues posted... and I have touched on each of them from within this thread.

Jay Bee
19th November 2007, 20:20
95% of all broadcasts are progressive, only a live music show now and then is interlaced.


Many of the most popular broadcasts are interlaced (read: sports).

bob0r
19th November 2007, 20:46
I would agree on that part.
Unfortunately, CPU efficiency has decreased gradually with every release after 1.0.5. I would like to see Core addressing this issue and concentrate on its traditional strength.

S.

http://haali.cs.msu.ru/mkv/timeCodec.exe results:
coreavc 1.3.0.0 User: 6s, kernel: 0s, total: 6s, real: 36s, fps: 163.8, dfps: 31.2
coreavc 1.5.0.0 User: 6s, kernel: 0s, total: 6s, real: 35s, fps: 185.1, dfps: 31.7
coreavc 1.6.0.0 User: 1s, kernel: 0s, total: 1s, real: 34s, fps: 684.7, dfps: 33.3
ffdshow tryouts 1625: User: 2s, kernel: 0s, total: 2s, real: 60s, fps: 384.0, dfps: 18.7
Cyberlink H.264 Decoder (PowerDVD 7.3 3319a) User: 9s, kernel: 0s, total: 9s, real: 33s, fps: 120.8, dfps: 33.5
Cyberlink H.264 Decoder (PowerDVD 7.3 3319a) User: 9s, kernel: 0s, total: 9s, real: 33s, fps: 122.0, dfps: 34.3 (dxva unchecked)
Mainconcept H.264 1.00.6639.00: User: 53s, kernel: 0s, total: 53s, real: 98s, fps: 21.0, dfps: 11.5

Hmm, cyberlink is fastest?? that never happened before, or they optimized GPU drasticly, or they slowly improving everything :)

The source file is: kill.bill.2.sm-hd.h.264.mkv, 45 seconds
Sky Movies Sample 1920x1080p H.264 (possible PAFF frames)

Edit:
LOL, added Cyberlink dxva unchecked results (did 3 runs to confirm)
WITHOUT DXVA (hardware? support) Cyberlink H.264 decoder is even more faster.
My card: Nvidia 7600GT

TheShadowRunner
19th November 2007, 20:48
bob0r, which version of the Cyberlink H.264 Decoder?
Also i assume those numbers are for software mode?
Later,

TSR

bob0r
19th November 2007, 21:18
The one that comes with powerdvd 7.3 3319a, so uhm file version 2.1.0.828 is all i could fine.

And yes, when i turned OFF dxva, it runs faster :scared:

TheShadowRunner
19th November 2007, 21:26
2.1.0.828, alright.
I'm surprised you don't suffer the "20fps locked" bug with this version.
software mode fast than HA? odd indeed o_O
what video card/drivers are you using?
and which mkv splitter?
Later,

TSR

bob0r
19th November 2007, 21:29
Nvidia 7600 GT, drivers 169.09_forceware_winxp_32bit_international_beta.exe (Crysis optimized)

New haali splitter from yesterday: http://haali.cs.msu.ru/mkv
(But older ones work too)

But obviously no hardware accel is done, so i guess thats why i dont have locked 20fps issues :sly:

Edit:

NOTE: Ofcourse Cyberlink is still horrible at playing H.264 MBAFF files or even BLURAY/HDDVD H.264, so coreavc is still by far the best :p

TheShadowRunner
19th November 2007, 21:49
7600, i see, so only PureVideo1 is supported, no PV2.
I'm not sure if the 2.1.0.828 isn't optimized for VP2...
In which case you would have better luck with HA on your card with version 1.99.0.1405 of the cyberlink decoder.

I use the same splitter, haali released yesterday and same nv drivers. (horrible bugs with new nv control panel, no scaling options, buggy custom resolutions, really nvidia is a nightmare with their drivers)

Anyway, sorry for the digression, back to CoreAVC talk.
Later,

TSR

arfster
20th November 2007, 01:22
It's hardly ATI's fault that the cyberlink decoder hiccups on non-standard encodes. Nvidia's do exactly the same thing, after all.

Feed them proper standards-compliant h264 and they both accelerate fine. I've currently got 16mbit 1080i50 mbaff running on my HDTV via my 2600 (vector-adaptive deinterlacing too), and the CPU hit is under 1%.

bob0r
20th November 2007, 01:23
Rule 6, you're fired!

lexor
20th November 2007, 05:03
I'm sorry... did we release a trial yet?

And what is that supposed to mean? You said you will release trial before fixing bugs. You said that exact thing and I even quoted it to be clear what I'm replying to. Don't give me (or anyone else) shit if you either can't write down what you mean or can't read what you wrote.

Your arrogance and non-replies are making you a prime candidate for next hire for Sony's PR department.

ChronoCross
20th November 2007, 06:15
This thread is becoming seriously off track.

We got 2 guys telling us how their warez encodes don't work.

3 guys restating old things we already know.

1 guy posting about how arrogant betaboy is (perhaps he's just pissed that the same people rail him in this thread no matter how much work they put in).

Seriously people bring forth some stuff that can actually help development instead of having your 14 year old pissing contest about how unhappy you are.

Things that might help:

1) Clips (legal) The slow down or even speed up between Core releases.

2) Timecodec Results using multiple decoders.

3) Feature Request (not including GPU support or the motion vectors can be infinite bug as it's already been requested.)

Ex:
OSD support (ffdshow syle)
Additional built in filters

4) Also additional results that you might think important to improving users experiences when using the codec. Quircks you've encountered, players that work best for different file types, etc.

To those of you who don't like corecodec for one reason or another you've made you point now move on to something else. Maybe you could discuss this:

http://torrentfreak.com/top-pirate-reveals-warez-scene-secrets-071119/

BetaBoy
20th November 2007, 06:37
lexor... If you go back over this thread I stated:
All.... prior to CoreAVC v1.6.1 we have two goals. One is here:
http://www.coreavc.com/retrieve

You can now retrieve your CoreAVC Serial number at anytime in case you have forgotten or lost it (this information has also been added into our CoreAVC KB at http://support.corecodec.com ).

The second goal we are working on now is the 14 day Trial version which we hope to have out shortly.

and then I said...

I appreciate all the comments in this thread... even the off base ones... as bob0r hinted at.

We are working on 1.6.1.... on several different fronts... On the non-compliant streams... I'd like to make a comment more or less without being too specific.... Rather then create work around, after work around, after work around... we would rather tell/work/inform the ppl who created the encoders about the issue to have them resolve it.

Another Devel thing to note.... we are also working again on the CORE optimizations to increase speed. As I had indicated here a few times there is still more %'s to be had. We hope to include some of these enhancements in 1.6.1.

Please don't confuse arrogence with my agressiveness in trying to be informative to the community in what our plans are (maybe too upfront) and from this point forward will not be baited in this thread.

A few things to note, and i'll let this comment go...

On Larger MV.... We went and tested against all older CoreAVC builds, and went back as far as v0.1 and found that we never supported them at our CORE level at anytime. We also noted no changes to the CORE at anytime to be able to support larger MV either.

So the bottom line at the moment is that with larger MV will _not_ be supported because:
1) it is not AVC spec compliant
2) would come at the cost of speed

Also, Haali noted that when using his timecodec.exe in regards to DFPS output, that it is meaningless for multithreaded codecs like CoreAVC and that the time spent in the main thread is called by the splitter so DFPS is only "relative to a wallclock". He is going to look into a means of warning the user of these results.

One last thing... we went into the current x264 source code and noted that MV is -/+ 512 which is out of range (max vertical MV is +511.75). Haali made a note to contact pengvado.

bob0r
20th November 2007, 09:28
...

On Larger MV.... We went and tested against all older CoreAVC builds, and went back as far as v0.1 and found that we never supported them at our CORE level at anytime. We also noted no changes to the CORE at anytime to be able to support larger MV either.

So the bottom line at the moment is that with larger MV will _not_ be supported because:
1) it is not AVC spec compliant
2) would come at the cost of speed

Also, Haali noted that when using his timecodec.exe in regards to DFPS output, that it is meaningless for multithreaded codecs like CoreAVC and that the time spent in the main thread is called by the splitter so DFPS is only "relative to a wallclock". He is going to look into a means of warning the user of these results.

One last thing... we went into the current x264 source code and noted that MV is -/+ 512 which is out of range (max vertical MV is +511.75). Haali made a note to contact pengvado.


Now thats a proper and clear post.
Now we know where we stand with the MV range.

Also good catch on the mv range limits.


So to quote myself:
- CoreAVC the green start frames issue ** fixed next version **
- CoreAVC readds to disable deblocking (why the hell was it removed??) ** fixed next version **
- CoreAVC _possibly_ add an option for large mv range ** will not happen, in fact x264 may need another update **
- CoreAVC check all speed decrease reports.... (ASK PEOPLE TO SEND IN TIMECODEC REPORTS?? C O M M U N I C A T E) ** there seems to be no speed decrease **

Small changes means update can be out soon, good luck!

Shinigami-Sama
20th November 2007, 09:49
On Larger MV.... We went and tested against all older CoreAVC builds, and went back as far as v0.1 and found that we never supported them at our CORE level at anytime. We also noted no changes to the CORE at anytime to be able to support larger MV either.

So the bottom line at the moment is that with larger MV will _not_ be supported because:
1) it is not AVC spec compliant
2) would come at the cost of speed

Also, Haali noted that when using his timecodec.exe in regards to DFPS output, that it is meaningless for multithreaded codecs like CoreAVC and that the time spent in the main thread is called by the splitter so DFPS is only "relative to a wallclock". He is going to look into a means of warning the user of these results.

One last thing... we went into the current x264 source code and noted that MV is -/+ 512 which is out of range (max vertical MV is +511.75). Haali made a note to contact pengvado.

hot dam, another x264 bug
and an informative post from Core
my faith is being restored

so
back to my question a while back

any hope for 1080i/p on an old P4 @ 3ghz in the next few releases?
or would that have to wait till eventual GPU support?

bob0r
20th November 2007, 10:00
...

One last thing... we went into the current x264 source code and noted that MV is -/+ 512 which is out of range (max vertical MV is +511.75). Haali made a note to contact pengvado.


Fixed in x264 revision 697.

bkman
20th November 2007, 11:16
Fixed in x264 revision 697.

Does this mean I can re-encode the film which displayed the bug with CoreAVC (shown in the sample I posted earlier), and expect the problem to no-longer occur?

I'd like some assurances before I spend however many hours on it...

foxyshadis
20th November 2007, 11:43
Does this mean I can re-encode the film which displayed the bug with CoreAVC (shown in the sample I posted earlier), and expect the problem to no-longer occur?

I'd like some assurances before I spend however many hours on it...

Do you shut the computer off overnight, or do you have a lot of other movies to encode? Because if not, re-using your old script and setting it to run overnight won't really take that long. Even when you're using the system, it's not usually noticeable with low priority. The computer's time is a lot less valuable than your time. ;)

bkman
20th November 2007, 12:29
My computer is not the fastest, so it would take in excess of 24 hours. Also, there is quite a heat wave right now, so I shut down overnight.

I suppose if I shut down using hibernation then it would not interrupt the encode, but I'd still like to not push my CPU too hard right now ;)

BlackSun
20th November 2007, 12:40
Now thats a proper and clear post.


So to quote myself:
- CoreAVC the green start frames issue ** fixed next version **
- CoreAVC readds to disable deblocking (why the hell was it removed??) ** fixed next version **
- CoreAVC _possibly_ add an option for large mv range ** will not happen, in fact x264 may need another update **
- CoreAVC check all speed decrease reports.... (ASK PEOPLE TO SEND IN TIMECODEC REPORTS?? C O M M U N I C A T E) ** there seems to be no speed decrease **

Small changes means update can be out soon, good luck!

The green start frame issue should be fixed (in theory), but we would appreciate a small sample file to verify.

Thanks for fixing x264 about Motion Vector range. Does any of you has a small sample file with Motion Vector being > 511.75 ?

Can any of you provide samples (or link to samples) that could help us to test and improve speed ?


@xwolf: Can you provide a small sample file with the artifacts showing ?

@All: What kind of OSD and built-in filters do you guys want ? This is just because I am curious, it is not planned at the moment.

lexor
20th November 2007, 14:43
Please don't confuse arrogence with my agressiveness in trying to be informative to the community in what our plans are (maybe too upfront) and from this point forward will not be baited in this thread.


You've got to be kidding me, I am seriously beginning to doubt that you can read your own writing. Your first quote clearly states that you will get preview version out before fixing bugs. Your second quote is AFTER I posted a reply to the first and still doesn't contradict your statement in the first and my reply to it.

And you still have the gall to come in here and try to take the high moral ground and spew out condescending nonsense above? That is arrogance, the kind that only a high ranking Sony executive can trully appreciate.

Guest
20th November 2007, 15:05
I've issued rule 4 and 6 strikes, and moved the offending rule 6 posts to Thread Moderation. We do not tolerate insults and discussion in any way of pirated material (even "as an example").

ACrowley
20th November 2007, 17:04
Mh , i had absolutly no Problems anymore with CoreAVC and x264 Builds - rev 697 with the 512 MV ..

Anybody knows a Site with latest AQ Patched Builds rev 697 ?

Latest Build here is 682
http://mirror05.x264.nl/Cef/

But as i say, no Problems since rev 663

Rectal Prolapse
20th November 2007, 18:36
@All: What kind of OSD and built-in filters do you guys want ? This is just because I am curious, it is not planned at the moment.

It would be cool to have a resize filter similar to LanzcosResize used in AVISynth, except coded to be super-fast. It will be great for downscaling 1080p to 720p for those of us with the cheaper displays, yet also remove the jaggies you sometimes see with the videocard scaling. :)

bob0r
20th November 2007, 21:26
Mh , i had absolutly no Problems anymore with CoreAVC and x264 Builds - rev 697 with the 512 MV ..

Anybody knows a Site with latest AQ Patched Builds rev 697 ?

Latest Build here is 682
http://mirror05.x264.nl/Cef/

But as i say, no Problems since rev 663

Offtopic: x264.697.fast-ref-search.01.aq-brdo.exe (http://forum.doom9.org/showthread.php?p=1067405#post1067405)

Ontopic: Indeed i never found a blocky x264 file post 663 also.

Morte66
21st November 2007, 11:19
My computer is not the fastest, so it would take in excess of 24 hours.

Could you not find an area that shows the problem, and reencode a clip (put a trim in the AviSynth) to test?

Morte66
21st November 2007, 11:38
All: What kind of OSD and built-in filters do you guys want ? This is just because I am curious, it is not planned at the moment.

I would like:

- Multi-threading, load-balancing, high-quality (lanczos/spline/sinc) resizers. With CoreAVC --> ffdshow spline I can end up at 70% on one core and "105%" on the other, ie. stuttering. But there is clearly enough CPU there to do the job if it were evenly split.

- Support for more than two cores some time around February when I upgrade my rig ;) [Not that I can't decode on two, but I'd like to free maximum CPU for ffdshow image processing.]

- On an OSD, and indication of input and output levels (PC or TV) including what the autodetect is doing. These days I find a right old mix of levels going through my player, between HD material with PC levels and TV/DVD cleanups which I used to do in TV levels but now do in PC. A quick hotkey to know what's going on would be handy.

- CoreVC-1 Pro!

BlackSun
21st November 2007, 11:47
The Professional version already support up to 4 cores/CPUs

honai
21st November 2007, 12:03
@All: What kind of OSD and built-in filters do you guys want ? This is just because I am curious, it is not planned at the moment.

Artificial grain. At the moment the Noise option in ffdshow, set to mplayer noise, luma=20, chroma=0, produces nice results, especially after resizing 720p material to 1920x1200.

So ideally CoreAVC should offer an option to resize to physical display dimensions and then add "film grain" before rendering to the desired plane.

Morte66
21st November 2007, 12:13
The Professional version already support up to 4 cores/CPUs

My apologies, for some reason I thought it was 2 with 4 "coming soon". [I have Pro, but only 2 cores in my CPU.]

audyovydeo
21st November 2007, 14:25
The Professional version already support up to 4 cores/CPUs

Then someone should update CoreCodec's website, cos it says :

"SMP (multi-core CPU) support (limit 2)"

last time I checked (30s ago).

http://www.corecodec.com/products/coreavc.html


cheers
audyovydeo

BetaBoy
21st November 2007, 15:19
Thx change made...

DigitalDeviant
21st November 2007, 16:44
What kind of OSD and built-in filters do you guys want ? This is just because I am curious, it is not planned at the moment.

Something akin to ffdshows debanding option would be nice :cool:

Maxiuca
21st November 2007, 17:46
And as usual CoreCodec doesn't give a damn about it's custorems. It's been 3 weeks since they've release version 1.6.0.0 and there is still no new version allowing to turn deblocking off (and preferably deinterlacing) and therefore to enable slower computers to handle most avc streams.

Any official comments on this topic BetaBoy? Cause noone at the offical forum seems to care? Do you?

BetaBoy
21st November 2007, 19:38
Your answer is in your post in the CoreCodec forums.

Shinigami-Sama
21st November 2007, 20:45
unsharp mask
colour level sliders - ffdshow style

foxyshadis
21st November 2007, 23:12
And as usual CoreCodec doesn't give a damn about it's custorems. It's been 3 weeks since they've release version 1.6.0.0 and there is still no new version allowing to turn deblocking off (and preferably deinterlacing) and therefore to enable slower computers to handle most avc streams.

Any official comments on this topic BetaBoy? Cause noone at the offical forum seems to care? Do you?

Neuron2 just told everyone to quit trolling, the issue is raised and Betaboy's already assured us it'll be taken care of whenever the next release is. Anyone assuming CoreAVC release dates are anything but wildly optimistic at this point needs a bit of a reality check. Next bait is a strike.

molitar
23rd November 2007, 20:55
I would like to see a systray icon when CoreAVC is working. I just recently found out that Nero 8 had taken priority over CoreAVC and because their is no indicator of CoreAVC running. I was running some test with graphedt that I discovered Nero was running in place of CoreAVC.

Hope we see GPU support soon and what is the best deinterlacing option in CoreAVC? Running a Geforce 6600GT video card.

BetaBoy
23rd November 2007, 23:32
We differ a tray icon to Haali's Splitter... I actually had proposed to Haali a standard set of API's so that third party codec company's could easily create codec property access or other features/options.

molitar
24th November 2007, 08:58
We differ a tray icon to Haali's Splitter... I actually had proposed to Haali a standard set of API's so that third party codec company's could easily create codec property access or other features/options.

Huh? We differ a tray icon to Haali's Splitter? What do you mean by that? BTW Haali's Splitter doesn't show if CoreAVC is being used or not so I really don't see how someone is suppose to know if their CoreAVC is working or if some other filter is overriding it without a tray icon.

Shinigami-Sama
24th November 2007, 09:01
Huh? We differ a tray icon to Haali's Splitter? What do you mean by that? BTW Haali's Splitter doesn't show if CoreAVC is being used or not so I really don't see how someone is suppose to know if their CoreAVC is working or if some other filter is overriding it without a tray icon.

I think he means halii splitter is supposed to show an icon for it if its being used


also
beta boy, you havn't even touched my question yet

easy2Bcheesy
24th November 2007, 13:31
Does Core have any plans to create a webplayer based on CoreAVC, with cross-platform support, ActiveX support, etc? The reason I ask is that I'm creating beautiful AVC videos but the beta Flash AVC player is massacring them on playback.

CoreAVC's quality and low CPU horsepower requirements surely make it a shoe-in? Support for streaming playback of Matroska would be awesome.

TheShadowRunner
24th November 2007, 13:46
Speaking about matroska splitters, CoreAVC 1.6 exhibits the same problem as 1.5 did : when Gabest matroska splitter is used instead of Haali's to split .MKV files; framerate is "locked" around 15-16fps for some reason.
Can that be corrected?
Or is this rather an issue with Gabest's splitter?
See you,

TSR

ACrowley
24th November 2007, 14:24
Speaking about matroska splitters, CoreAVC 1.6 exhibits the same problem as 1.5 did : when Gabest matroska splitter is used instead of Haali's to split .MKV files; framerate is "locked" around 15-16fps for some reason.
Can that be corrected?
Or is this rather an issue with Gabest's splitter?
See you,

TSR

Theres no Problme..
I cant remember any fps Problmes with Gabest Splitter and CoreAVC

All my mkv with Gabest (internal mpc) and CoreAVC are playing at corect fps

Shinigami-Sama
24th November 2007, 21:23
Does Core have any plans to create a webplayer based on CoreAVC, with cross-platform support, ActiveX support, etc? The reason I ask is that I'm creating beautiful AVC videos but the beta Flash AVC player is massacring them on playback.

CoreAVC's quality and low CPU horsepower requirements surely make it a shoe-in? Support for streaming playback of Matroska would be awesome.

+1
coreflash player would rock the crap out of what ever adobe decides to butcher

sillKotscha
24th November 2007, 21:33
but the beta Flash AVC player is massacring them on playback.

no, the player is by Jeroen :D

what you mean is adobe's flash 9 avc implementation... I don't think it is the players fault when playback is jerky... my guess it is more or less adobes implementation of Mainconcepts h.264 decoder... as it is still beta/ RC they will surely work on improved decoding speed - they must have bought a license just before DivX took over Mainconcept ;)

hence I don't see a reason for CoreFlashPlayer as decoding is done by adobe's flash engine and not the player...

Shinigami-Sama
24th November 2007, 21:36
no, the player is by Jeroen :D

what you mean is adobe's flash 9 implementation... I don't think it is the players fault when playback is jerky... my guess is more or less adobes implementation of Mainconcepts h.264 decoder - they must have bought a license just before DivX took over Mainconcept ;)

hence I don't see a reason for CoreFlashPlayer as decoding is done by adobe's flash engine and not the player...

shouldn't you be able to override that with the player?
I mean the AX itself is very small anyways

BetaBoy
24th November 2007, 21:44
Does Core have any plans to create a webplayer based on CoreAVC, with cross-platform support, ActiveX support, etc? The reason I ask is that I'm creating beautiful AVC videos but the beta Flash AVC player is massacring them on playback.

CoreAVC's quality and low CPU horsepower requirements surely make it a shoe-in? Support for streaming playback of Matroska would be awesome.

Not to get too OT... but we already have several products that do that...

- CorePlayerX Web Browser Plug-in: (for IE, FireFox, Mozilla, Netscape, and Opera) Although the newer one is not public... you can see what the old one looks like here: http://www.CorePlayerX.com

- CorePlayer Embedded: is our CE/Windows ActiveX, COM, IDL embedded multimedia player that allows third party developers to easily embed audio, or image playback in the applications.

- CorePlayer Mobile: Starting with v1.2 CP will now support embedded multimedia playback into web browsers like PocketIE, Minimo, Opera and we are planning to also release a WebKit plug-in.

On Flash... we will have several SVG based features within the CorePlayer Platform next year. Not 'flash' and it never will be.... we are making at least 2 announcements at CES this year in regards to these efforts.

sillKotscha
24th November 2007, 21:49
shouldn't you be able to override that with the player?
I mean the AX itself is very small anyways

if that would be the case than Adobe could have saved a looot of money for the license to implement avc decoding... as "every" flash-player developer would/ could have implemented avc decoding by a reverse engineering CoreAVC alpha release for example - as that was "free"...

no, it won't be that easy ;)

molitar
24th November 2007, 21:57
Not to get too OT... but we already have several products that do that...

- CorePlayerX Web Browser Plug-in: (for IE, FireFox, Mozilla, Netscape, and Opera) Although the newer one is not public... you can see what the old one looks like here: http://www.CorePlayerX.com


Well it sure wouldn't install the plugin. I just get message unknown plugin from that url in Firefox 2.

Shinigami-Sama
24th November 2007, 22:35
if that would be the case than Adobe could have saved a looot of money for the license to implement avc decoding... as "every" flash-player developer would/ could have implemented avc decoding by a reverse engineering CoreAVC alpha release for example - as that was "free"...

no, it won't be that easy ;)

true...
leave it to adobe to over complicate things
:rolleyes:

foxyshadis
25th November 2007, 03:09
- CorePlayer Mobile: Starting with v1.2 CP will now support embedded multimedia playback into web browsers like PocketIE, Minimo, Opera and we are planning to also release a WebKit plug-in.

Oh, nice. That might make picking up a used N770 or N800 worthwhile.

TheShadowRunner
25th November 2007, 05:39
Theres no Problme..
I cant remember any fps Problmes with Gabest Splitter and CoreAVC

All my mkv with Gabest (internal mpc) and CoreAVC are playing at corect fps

Maybe the internal splitter is OK.
I'm talking about MatroskaSplitter.ax from the Guliverkli page at Sourceforge.
Later,

TSR

BetaBoy
25th November 2007, 08:34
Speaking of... We will be at CES showing the CorePlayer Platform on Linux. We will have various Linux devices there (and OS X) to demo including a few Linux Distros including the the N800 running CorePlayer Mobile.... if anyone from D9 is going on being there and would like to see how it looks, PM me as we are planning a get together at a local pub.

ACrowley
25th November 2007, 09:23
Maybe the internal splitter is OK.
I'm talking about MatroskaSplitter.ax from the Guliverkli page at Sourceforge.
Later,

TSR

yes, sure.....but it should be the same splitter

Give me a link to exactly the .ax you use and i can test it on my Machine

easy2Bcheesy
25th November 2007, 10:36
- CorePlayerX Web Browser Plug-in: (for IE, FireFox, Mozilla, Netscape, and Opera) Although the newer one is not public... you can see what the old one looks like here: http://www.CorePlayerX.com

Doesn't seem to do anything on either Opera or IE...?

TheShadowRunner
25th November 2007, 12:46
yes, sure.....but it should be the same splitter

Give me a link to exactly the .ax you use and i can test it on my Machine

Thanks for this.
Here it is:
http://downloads.sourceforge.net/guliverkli/matroskasplitter_20050310.7z?modtime=1142033144
See you;

TSR
(edit: you need to use the unicode build if you're on XP SP2, but i'm sure you know that already ^^)

BetaBoy
25th November 2007, 17:52
I changed the CAB file installer for the old CorePlayerX on http://coreplayerx.coreforge.org/ so it works now... this version will only work on FireFox and IE and as I stated is old so it has a few bugs. One major one to note is a blitting slowdown bug related to CoreAVC.

molitar
25th November 2007, 18:24
I changed the CAB file installer for the old CorePlayerX on http://coreplayerx.coreforge.org/ so it works now... this version will only work on FireFox and IE and as I stated is old so it has a few bugs. One major one to note is a blitting slowdown bug related to CoreAVC.

Well I'm quite impressed by the performance. But the installer still has a major bug. It would not install in Firefox 2.0.0.9 I had to switch over to IE Tab than install in IE than go back to Firefox to make it work.

BetaBoy
25th November 2007, 18:39
yeah that FF/IE bug was fixed a long time ago... there was one transition installer (from TCPMPX to CPX) that was semi-public that I think fixes that: http://coreplayerx.coreforge.org/CorePlayerX-installer.exe

Use it at your own risk ;-) and pls uninstall the old one first before installing the new one.

easy2Bcheesy
25th November 2007, 21:14
That's really impressive. CoreAVC in a browser, with all the quality and speed benefits. Does it stream over IP?

BetaBoy
26th November 2007, 01:09
The new version of CorePlayerX (and our CorePlayer Platform IE; Mobile and Pro starting with the upcoming v1.2) fully supports TCP/UDP/RTP/RTSP streaming.... and yes unicast, multicast and http tunneling. It has been tested against and is fully compliant with Apple Darwin, Live555 and Helix Media Streaming Servers.

One last thing about CPX and then we can get back OT... Next year it will be a part of the distribution of Both CorePlayer Mobile and CorePlayer Pro..... and thats when you'll find out about our SVG plans.

ACrowley
9th December 2007, 14:40
Many of the most popular broadcasts are interlaced (read: sports).

I dont watch any Sports/Bundesliga on PremiereHD
Im talking about "Movie Channels like PremiereHD and SkyHD..what is most popular for me :)
And both Channles are broadcasting Movies with 100% progressive frames..even its called "1080i"

As i can say about Cyberlinks H264 Decoder :
1080i /p @25FPS = no Problem in Software Mode on fast DualCore

I have no 1080 interlaced @50 FPS H264 File..so i cant say anything about it
Maybe somebody can provide a sample ?

BetaBoy
11th December 2007, 08:34
We are testing CoreAVC 1.6.1 now... We have fixed all the reported issues... and by that I mean;

- deblocking options enabled
- bob deinterlacing
- renamed weave
- CORE changes on some smaller bugs
- It also it now checks for useless MT changes.

One last thing we need to QA with the testers is the reported DVBViewer slow down issue. I'll fill everyone in how testing is going by the end of the week.

Jarod, you ready?

LigH
11th December 2007, 08:38
We have fixed all the reported issues...

Including possible upside-down flipped output?

ACrowley
11th December 2007, 12:19
We are testing CoreAVC 1.6.1 now... We have fixed all the reported issues... and by that I mean;

- deblocking options enabled
- bob deinterlacing
- renamed weave
- CORE changes on some smaller bugs
- It also it now checks for useless MT changes.

One last thing we need to QA with the testers is the reported DVBViewer slow down issue. I'll fill everyone in how testing is going by the end of the week.

Jarod, you ready?

fine

no large (out of spec) Motion Vector compatibility Option planned ?

Disabled
11th December 2007, 12:40
fine

no large (out of spec) Motion Vector compatibility Option planned ?

They don't care:

On Larger MV.... We went and tested against all older CoreAVC builds, and went back as far as v0.1 and found that we never supported them at our CORE level at anytime. We also noted no changes to the CORE at anytime to be able to support larger MV either.

So the bottom line at the moment is that with larger MV will _not_ be supported because:
1) it is not AVC spec compliant
2) would come at the cost of speed

I wonder how much speed it would cost and how much work it would be to support it...

BetaBoy
11th December 2007, 14:21
ACrowley and Disabled.... pls stop trolling and obviously bring up something you both already knew the answer to XX pages back.

Disabled
11th December 2007, 14:33
ACrowley and Disabled.... pls stop trolling and obviously bring up something you both already knew the answer to XX pages back.

Did you state how much speed it would cost and how much work it would be?

ACrowley
11th December 2007, 17:57
Did you state how much speed it would cost and how much work it would be?


However...with Cyberlink Decoder ive "no noticable" Slowdown on those x264 Encodes :) and ofcourse no Blocking

Ok..no i know it.
CoreAVC cant/want hanlde large MV..if its no Spec or not.. Other Decoder = No Problem

foxyshadis
11th December 2007, 19:14
Seriously, guys, it's not happening. Further whining won't change their decision after all this discussion.

ChronoCross
11th December 2007, 20:31
@foxyshadis
I think it would be funny for Core to add a patch that makes it show nothing but a black screen when playing back clips with out of range motion vectors. they could at the very least say they patched it =D

clsid
11th December 2007, 22:06
http://i1.tinypic.com/86pn0hk.jpg

bob0r
12th December 2007, 05:34
http://icanhascheezburger.files.wordpress.com/2007/04/469761052_6f055c51e9.jpg

@BetaBoy
I have reported my findings to BlackSun, a lot more work for dvbviewer is needed, and please fix the green frames issue.
Deblocking skip seems to work again, and fix the small typo in the settings window.

My advice: Do not release anything yet! :sly:

BetaBoy
12th December 2007, 08:30
thx... As Haali has indicated the The initial greenframe issue is not as easy as you may think to fix as it pertails to black level(iirc). The continued DVBViewer slowdown on the other hand is something we are already aware of.

http://www.lolcats.com/images/u/07/38/lolcatsdotcom8k6kwv7su7go3xqo.jpg

silverwolf0
22nd December 2007, 07:31
I am having problems with playing back H.264 videos with coreavc. I have K-lite codec pack installed and it has coreavc 1.5 by default for playing h.264 files. However, videos will freeze sporadically when I play them, usually in fullscreen, and the only way to unfreeze is to cold boot my laptop. When I switch to FFDshow to play H.264 videos, all the freeze-ups disappear but the sound is a bit out of synch. Sometimes the voices are early and sometimes a bit late so it looks like bad lipsynching. When I play MKV files with subtitles, the subtitles go in tune with the sound, but out of synch with the video as well.

How should I solve this problem? I am currently still using coreavc 1.5 as I cannot stand watching the videos out of synch. However, having to coldboot is a constant annoyance also. Someone please help.

Dark Shikari
22nd December 2007, 07:59
I have K-lite codec pack installed and it has coreavc 1.5 by default for playing h.264 files.So in other words you're asking for help with pirated software.
When I switch to FFDshow to play H.264 videos, all the freeze-ups disappear but the sound is a bit out of synch. Sometimes the voices are early and sometimes a bit late so it looks like bad lipsynching. When I play MKV files with subtitles, the subtitles go in tune with the sound, but out of synch with the video as well.Its called "your computer is too slow to play that 720p anime rip with FFDShow."

Shinigami-Sama
22nd December 2007, 08:00
So in other words you're asking for help with pirated software.
Its called "your computer is too slow to play that 720p anime rip."

one post count wonder
why waste your breath?

molitar
22nd December 2007, 15:36
So in other words you're asking for help with pirated software.
Its called "your computer is too slow to play that 720p anime rip with FFDShow."

I actually I use CCCP myself but I do not believe CoreAVC comes at all with K-lite codec pack as it's not listed in the release at all. Now CoreAAC does so I imagine he might be mistaking CoreAAC as CoreAVC and he doesn't have CoreAVC. If that is the case than the issue he is playing through the ffdshow which we all knows uses alot more CPU resources hence taking a faster computer to play the video file in sync. Or he has configured ffdhow to use CoreAVC as the default player he really needs to explain himself more clearly before anyone really can give him any useful information.

JohnnyFu
22nd December 2007, 18:26
So where is the Christmas Edition BetaBoy ? :D

Merry Christmas to everyone out there.

Shinigami-Sama
22nd December 2007, 20:41
I actually I use CCCP myself but I do not believe CoreAVC comes at all with K-lite codec pack as it's not listed in the release at all. Now CoreAAC does so I imagine he might be mistaking CoreAAC as CoreAVC and he doesn't have CoreAVC. If that is the case than the issue he is playing through the ffdshow which we all knows uses alot more CPU resources hence taking a faster computer to play the video file in sync. Or he has configured ffdhow to use CoreAVC as the default player he really needs to explain himself more clearly before anyone really can give him any useful information.

k-lite used to have coreavc back a few months ago I think
I know I've seen it on other's PCs, and they don't buy software

ChronoCross
22nd December 2007, 20:50
Changelog 2.79 -> 2.80 | (2006-11-19)

* Updated ffdshow to revision 571
* Updated Xvid to version 1.2.0-dev build 2006-11-08
* Removed CoreAVC

silverwolf0
22nd December 2007, 21:14
CoreAVC is still in the k-lite mega codec, or at least the latest one I downloaded from free-codecs.com


Don't get so antsy on me. I didn't know it was pirated until now. As far as I am concerned, most codec packs use open source or free codecs. Also, I monitor my CPU usage while playing a video in FFDshow and it only goes to around 30-40% with the CPU automatically downclocking to 800mhz since I set it to laptop/portable in my power configurations (speedstep, viewed through mobilemeter).

Sheesh.

BetaBoy
22nd December 2007, 22:48
You too JF... funny u say that... we plan on releasing 1.6.5 (not calling it 1.6.2 as we had planned because of all the additional work thats been done.) over the holiday.

One last issue is the DVBViewer slow down... 1.6.5 will improve it for sure. But not as much as we would like. We are still working with the DVBViewer devs on this.

Additionally... one other thing to note is if we release a fix for the 'green bug' issue as there is question on how we should 'best' handle some streams when it's impossible to detect keyframes without external input.

Yufi
26th December 2007, 18:40
Any post-Christmas word on the linux version of CoreAVC? Still eagerly awaiting it so I can switch my HTPC back to MythTV and not have to deal with getting out of date patches working with mplayer.

ADude
26th December 2007, 19:04
Since DVBViewer usage is a small fraction of HT-PC software usage, wouldn't it make sense to release a version with all the fixes - except for DVBViewer fix - and then work on DVBViewer without the release hanging over your head ?

Fraeon Lux
27th December 2007, 14:50
Since DVBViewer usage is a small fraction of HT-PC software usage, wouldn't it make sense to release a version with all the fixes - except for DVBViewer fix - and then work on DVBViewer without the release hanging over your head ?

That was EXACTLY my thought. Why hold everyone else up for months because of some issues with DVBViewer specifically?

1.6.1 was slated to be promptly released after 1.6.0.

ChronoCross
27th December 2007, 19:21
That was EXACTLY my thought. Why hold everyone else up for months because of some issues with DVBViewer specifically?

1.6.1 was slated to be promptly released after 1.6.0.

because then you'll have the DVBViewer trolls doing the same thing your doing now. it's a lose lose situation for core. Might as well wait until everyone is happy

clsid
27th December 2007, 19:33
That's absolute nonsense. Why are you always defending every single decision that CoreCodec makes?

CiNcH
27th December 2007, 19:35
DVBViewer has no trolls!!! *g*

bob0r
27th December 2007, 19:44
I have solved my dvbviewer issues: Intel Q6600 :D
CoreAVC + Dvbviewer = black=black == bob0r happy!

Sadly i can no longer test coreavc+dvbviewer on my old system.

CoreAVC is still by FAR the best decoder SPEC wise!
- Colors flags are read
- Cropping flags are read
- ALL mbaff/paff encoders work
- Still the fastest, Cyberlink + Gforce 8800 GTS G92 is still slower than coreavc.

Most issues, which aren't really that bad are fixed now.
They are now working on the green-frames issue, but to be fair 1.5 still works fine :)

As for the new version:
- Deblocking was readded
- Dvbviewer itself is mostly the cause of the issues.
That only leaves the green frame issue, as possible other issues other users reported, but i never encountered those.

ChronoCross
27th December 2007, 19:56
That's absolute nonsense. Why are you always defending every single decision that CoreCodec makes?

why are you always bashing them?

CiNcH
27th December 2007, 20:29
- Dvbviewer itself is mostly the cause of the issues.

You got more infos about that? Or just an assumption?

bob0r
27th December 2007, 20:32
You got more infos about that? Or just an assumption?

From what i understood from the findings between coreavc and dvbviewer developer(s).

3.9.0 was much better with any coreavc than 3.9.1.
They are both working on it.

clsid
27th December 2007, 20:46
why are you always bashing them?
It is called constructive criticism.

ChronoCross
27th December 2007, 21:07
It is called constructive criticism.

Then mine is consumer support.

Rectal Prolapse
28th December 2007, 02:04
I agree with clsid. :P

Anyways, looking forward to an early release...

ADude
3rd January 2008, 01:43
Anyways, looking forward to an early release...

http://www.guzer.com/pictures/tiredkitten.jpg

3ngel
3rd January 2008, 17:10
A little OT Request for Core developers.

What about adding WVC1 support to the CoreAVC, or doing a separate optimized product?

ATM the only WVC1 codec (excluding PowerDVD) is the bad MS wich doesn't permit a smooth vision of 1080p WVC1 even on a high end dual core (especially on ATI wich doesn't have WVC1 GPU support).

More and more (almost all) HDDVD (and even bluray) use the WVC1 codec.

So what do you think about it?

I would gladly buy an optimized CoreVC1 product :)

ACrowley
3rd January 2008, 17:24
A little OT Request for Core developers.

What about adding WVC1 support to the CoreAVC, or doing a separate optimized product?

ATM the only WVC1 codec (excluding PowerDVD) is the bad MS wich doesn't permit a smooth vision of 1080p WVC1 even on a high end dual core (especially on ATI wich doesn't have WVC1 GPU support).

More and more (almost all) HDDVD (and even bluray) use the WVC1 codec.

So what do you think about it?

I would gladly buy an optimized CoreVC1 product :)

I (and all guys i know)can play 1080p WVC1 or VC1 100% smooth with max 60% CPU Load on ym A64 X2 @5000 and Ati HD3870
You must have a bad Sytem Config , it 100% should be no Problem on a fast CPU/GPU

And HDDVD/Bluray are using not WVC1 ,theyre using VC1 :) WVC1 is just the MS implemention.
Same as H264 and x264

3ngel
3rd January 2008, 17:53
Strangely enough, i'm not able to see smooth only VC1 contents that is HDDVD.

And yes i intended WVC1 as the AdvancedProfile of VC1 (used on HDDVD) that (as far as i know) is not supported by CoreAVC.

Anyway, can you tell me wich codec you use to see HDDVD?

I have an ATI 1950XT, and everywhere i've read all the tests (apart from PowerDVD) gives high cpu usage and not smooth vision for HDDVD, for this reason i asked.

You're using the MS codec?

Pheraps you're using GPU (wich seems to me is partially implemented on your card but i'm not sure about it)?
On ATI 19xx it is not supported for sure.

Thanks.

Ice =A=
3rd January 2008, 18:16
Don't forget that with HDDVDs (and BluRay of course) a lot of computing power is needed for DRM only, so if one is watching a not-DRM-ed video that should play much better.
And implementing a DRM conform playback would mean a big deal of work anyway, so I have no problem if that is left out for now.

P.S.:
The newer ATI/AMD cards do have a much better video acceleration than older ones (if it's working).

3ngel
3rd January 2008, 18:31
Yes i'm talking about non-drm content (for this reason i leave out powerdvd).

The newer ATI/AMD cards do have a much better video acceleration than older ones
And yes for this reason i was asking for an optimized VC1 codec :)

langman10
3rd January 2008, 19:58
I am trying to read from .m2ts files taken by a Blu-Ray-recording camera using AviSynth but am getting errors. :confused: I'm sure it's something in my configuration, so any directions someone could point me in to troubleshoot would be greatly appreciated.

Here's what I've done:

Obtained and installed coreavc. This also installed haali media splitter. I made sure to select "enable opening of MPEG-TS".

(BTW I have debugviewer on during all of the following, and nothing is logged.)

When I open the .m2ts file in gspot, I get:
------------------------------------------
Container:FileType: MPEG-2 Transport Stream
Mime Type: video/mp2t

Render OK. The following combination of filters was used:
[Src}-->>--(A)-->[CoreAVC Video Decoder ]>--(B)-->[Video Renderer ]
[Src}-->>--(A)-->[AC3Filter ]>--(B)-->[Default DirectSound Device ]
------------------------------------------
And the file previews fine in GSpot.

When I open the .m2ts file in WMP11, it plays ok, though jerky because it's HD i believe.

When I open the .m2ts file in VLC, the file begins to play, but then freezes and crashes with the message:
VLC media player has encountered a problem and needs to close. We are sorry for the inconvenience.
When I click on technical details, it reads
AppName: vlc.exe AppVer: 0.8.6.0 ModName: libffmpeg_plugin.dll
ModVer: 0.0.0.0 Offset: 0020f586

I then made an .avs AviSynth script with one line: directshowsource("file.m2ts")

When I open the .avs file in gspot, I get:
------------------------------------------
Container:FileType: Unknown
Mime Type: Unknown

Render OK. The following combination of filters was used:
[Src}-->>--(A)-->[Color Space Converter ]>--(B)-->[Video Renderer ]
[Src}-->>--(A)-->[AC3Filter ]>--(B)-->[Default DirectSound Device ]
------------------------------------------
But when I go to preview in GSpot, GSpot crashes.

I opened the .avs in VirtualDubMod 1.5.10.2:
Using Avisynth 2.56, VirtualDubMod just disappears.
Using Avisynth 2.57, gets "Avisynth read error: AviSynth caught an access violation at 0x00e25980, attempting to read from 0x03bcbfc0"
Using AviSynth 2.58, VirtualDubMod crashes with:
VirtualDub has encountered a problem and needs to close. We are sorry for the inconvenience.
When I click on technical details, it reads
AppName: virtualdubmod.exe AppVer: 1.5.10.0 ModName: virtualdubmod.exe
ModVer: 1.5.10.0 Offset: 000b118d

I opened the .avs in WMP11:
Using AviSynth 2.56, WMP11 just disappears.
Using AviSynth 2.57, blocky red letters on black show "AviSynth caught an access violation at (can't make out), attempting to read from (can't make out)"
Using AviSynth 2.58, blocky red letters on black show "CAVIStreamSynth: System exception - Access Violation at 0x0, reading from 0x0"

I've tried SetMemoryMax(16) at the beginning of the .avs script...no change. Thanks in advance.

Specs:
Microsoft Windows XP Professional SP2
Xeon 2.66GHz Proc:2
RAM 3.5GB
CoreAVC Version 1.6.0.0

Langman

Rectal Prolapse
7th January 2008, 03:02
langman, is it possible you are trying to play a movie ripped from a BD+ disc? That won't work if that is the case because of the additional random encryption.

langman10
7th January 2008, 19:50
Thanks for the response, RP. No, these are files taken on what I believe is a Sony camera that records to Blu-Ray, which brings Sony's own pseudo-format of transport stream complete with an extra 4 bytes per packet.

Any other suggestions anyone? If it's not even possible to open/read .m2ts files using AviSynth+CoreAVC+DirectShowSource, let me know.

Langman

Jay Bee
7th January 2008, 20:13
What are you trying to do exactly? You post goes from WMP to VLC to AVISynth. Just trying to open the file, no matter how?

It should definitely work but I don't want to list all possible ways to open the file.

langman10
7th January 2008, 21:01
I guess I was trying to make up for the times when I get "You didn't post enough information" responses. :o Sorry.

As I said, I'm trying to open these .m2ts files using AviSynth. All the other info I gave is just to help diagnose what could be wrong with my setup. I want to create AVI files to edit with. I posted at CoreAVC's forum a week and a half ago, but maybe they're on holidays.

Here's the Cliffs Notes:
With a one-line AviSynth script of directshowsource("file.m2ts) I get errors/crashes in GSpot & VDubMod & WMP. The same .m2ts file opened directly in Gspot & WMP plays fine but crashes VLC.

This happens with all .m2ts files from multiple cameras.

Thanks in advance for any help.

Jay Bee
7th January 2008, 21:26
Ah ok. What you need to do is build the graph with graphedit and save it as a grf file. The graph is haali + coreavc + audio decoder but no renderers and make sure that in CoreAVC deinterlacing is off as it can cause crashes. Then make an avs file with directshowsource("file.grf"). And then obviously open the avs with vdub.

Hope it works.

ACrowley
9th January 2008, 13:42
"CAVIStreamSynth: System exception - Access Violation at 0x0, reading from 0x0"


I know this Error because i had i very often in my encodes
I could fix it by using the latest Avsiyth 2.58 alpha (070919)

i never had it again :)

Sasovics
10th January 2008, 22:06
I have the very same problem :(

I am trying to load AVC stream from EVO (HD-DVD source) to AviSyth using the following graph:


Haali Splitter(EVO file) -> CoreAVC Video Decoder

Then my AVS script is as follows:

DirectShowSource("feature.grf",video=true,audio=false,fps=23.976,framecount=xxxx)
ConvertToYV12 ()


But when I try to load the avs to WMP or MPC it gives me a red error message

"CAVIStreamSynth: System exception - Access Violation at 0x0, reading from 0x0"

However the filter setup plays fine within the graph ...

What am I doing wrong ???

EDIT: I've tried with both AviSynth v2.5.7 and v2.5.8, the result is the same :(

langman10
10th January 2008, 23:38
I have the very same problem :(

"CAVIStreamSynth: System exception - Access Violation at 0x0, reading from 0x0"

What am I doing wrong ???



I don't think we're doing anything wrong, Sasovics. I'm beginning to think the issue is with CoreAVC. I used AviSynth 2.58a 070917 like ACrowley suggested above (thanks!) and tried graphedit from Jay Bee's advice from above (Thanks!) and the results are pretty much the same. I think the issue is in version 1.6 of CoreAVC. Check out this thread (http://www.corecodec.com/forums/index.php?topic=544.0) at Core's site, especially the comments like "Coreavc is useless to me now." ;) Another indication is that Jay Bee's post above mentions that interlacing in CoreAVC crashes, but in 1.6 the ability to turn off deinterlacing was removed. Unfortunately, I can't find any way to rollback to 1.5. Ver 1.6.1 is said to be coming soon. We'll see.

Edit: Here's another clue that may be related: In ver 1.6's changes is included "Rewrite of the Directshow wrapper for better compability"

Langman

Sasovics
11th January 2008, 00:07
That's what I was afraid of.

So there is nothing we can do at this moment .. anyway, I found a workaround: I use FFDshow fileters instead, and they work well!! ;)

My graph is as follows:

Haali Splitter(AVC Source) -> ffdshow Video Decoder

Try it out! Should work for you as well!

TheShadowRunner
11th January 2008, 05:43
So hmm.. probably a dumb question but now that FFDshow uses multithreading (uses all cpu cores) in all newer builds (not only with certain XXL builds anymore), what is the advantage of CoreAVC over ffdshow?

As DXVA is yet to be seen in CoreAVC (after SO many years btw), I'm really beginning to wonder...

ChronoCross
11th January 2008, 06:10
So hmm.. probably a dumb question but now that FFDshow uses multithreading (uses all cpu cores) in all newer builds (not only with certain XXL builds anymore), what is the advantage of CoreAVC over ffdshow?

As DXVA is yet to be seen in CoreAVC (after SO many years btw), I'm really beginning to wonder...


ffdshow only supports slice based threading (which x264 no longer uses) so in effect ffdshow is still single threaded on anything done on the latest versions of x264.

As for why you can't use coreavc in directshowsource() you might consider changing what mode the deinterlacing is using. Try all 4 and see if any of them work (I would do it if I had any sources to do so)

Also try disabling cropping and VMR AR Correction

_xxl
11th January 2008, 09:09
fdshow only supports slice based threading
yes and cabac / reconstruction parallelism, the code decodes up to 128 macroblocks in one thread while doing prediction+idct+deblock of the previously decoded 128 blocks in another thread.

Jay Bee
11th January 2008, 09:26
So hmm.. probably a dumb question but now that FFDshow uses multithreading (uses all cpu cores) in all newer builds (not only with certain XXL builds anymore), what is the advantage of CoreAVC over ffdshow?

As DXVA is yet to be seen in CoreAVC (after SO many years btw), I'm really beginning to wonder...

CoreAVC still has much better performance than any other AVC decoder. With ffdshow you need a very fast, probably overclocked CPU to decode Blu-Ray streams.

Dxva is a mess where you need the perfect combination of GPU, driver version, OS version, PDVD version and most GPUs that claim support aren't spec compliant anyway (deblocking).

CoreAVC will just play without any problems as long as your CPU is fast enough. The only thing they really need to get fixed is deinterlacing and DVBViewer stuttering so that PCs can finally become a viable solution for AVC HDTV. But they said they're working on it.

audyovydeo
11th January 2008, 10:07
Dxva is a mess where you need the perfect combination of GPU, driver version, OS version, PDVD version and most GPUs that claim support aren't spec compliant anyway (deblocking).


You've coined the most exact description of DXVA to date !
Look how much time & ink has been lost by doom9ers alone on this marketing ploy.

cheers
audyovydeo

3ngel
11th January 2008, 18:47
At this point, i would like to add my experience and again the "same" ever more important request.

Now with the experience. I had a 1950XT, and tried to see an unprotected HD-DVD content, in realtime. Installed the only VC1 Microsoft decoder, started WMP11, the video is not fluid. Processor in only 50%. Now i read that 1950 supported only 3/4 acceleration for HD content so HD2600 is the only one to support full accelleration. So test HD2600, WMP Video Accelleration set explicity to "Max". Same result. No fluid. This is unbelievable.

Now i don't doubt that is the MS codec wich is no good and dont' use for some reason DXVA (and moreover does an even more bad job being the CPU only 50%). I read from various sources only PowerDVD fully supports HD accelleration.
I don't want to use nor buy PowerDVD. I would more gladly spent money on this codec.

So my requests, that are 3 (in order of importance).

1) Add to CoreAVC support for VC-1 codec found in HD-DVD, so content can be played at last decently on every player.

2) Add fully support to CoreAVC for GPU accelleration (wich would make playing of HD contents flawless)

3) Possibly a 64bit compile of CoreAVC?

I know some of this requests are long time made, but i give to occasion to just remember to devs the importance of HD support and GPU accelleration :)

Thanks

Inventive Software
11th January 2008, 18:54
@3ngel: Regarding 1), the clue is in the name of the product: CoreAVC. It only decodes H.264, or AVC content, not VC-1. VC-1 and AVC are 2 completely different codecs. I wouldn't put it past CoreCodec to release CoreVC1 in the future.

As I understand it, MS' VC-1 decoder does support DXVA in VC-1, and, I believe, multi-threaded decoding, but you need to use WMP11 to get the full benefit.

3ngel
11th January 2008, 19:06
Well, my intention was or to include it in CoreAVC or do a separate CoreVC1. I would spent anyway :)

Now, unfortunately i use exactly WMP11 (the codec is installed with the complete WMP11 package). So although paper says GPU decoding, multithread and so on, i see nothing of it all.

ACrowley
13th January 2008, 10:18
@3ngel: Regarding 1), the clue is in the name of the product: CoreAVC. It only decodes H.264, or AVC content, not VC-1. VC-1 and AVC are 2 completely different codecs. I wouldn't put it past CoreCodec to release CoreVC1 in the future.

As I understand it, MS' VC-1 decoder does support DXVA in VC-1, and, I believe, multi-threaded decoding, but you need to use WMP11 to get the full benefit.

WM11 Decoder should supports DXVA 1+2 and ofcourse multithreading
http://www.kmplayer.com/forums/showthread.php?p=25724#post25724
But it supports only DXVA for WMV.
I cant see any difference between DXVA on /Off for VC1 into other Containers like EVO or MKV.
But obviously for VC1 into WMV, you can Test it with WMV9PowerToy. DXVA is inactive for (W)VC1 into EVO, but active for (W)VC1 into WMV
WMVideoDecoder can be used via Directshow in any DShow Player. Including all Features. So not only in WMP :)
However..this is the wrong Thread

3ngel
13th January 2008, 12:05
So you're saying that the VC-1 DXVA acceleration is present but only supported in a WMV container? That's crazy :D but now i know i'll do a test :)

Sorry for the wrong thread, what's the right thread?

Thanks

Sasovics
14th January 2008, 20:37
If any of you guys manage to get CoreAVC work with AviSynth, please let us know....

I don't really like FFDShow, I'd be much happier if it would work with AviSynth...

Sagekilla
15th January 2008, 04:20
You can use CoreAVC through Avisynth if you have Haali and use DirectShowSource.

At least that lets me do it.

idbirch2
18th January 2008, 19:14
I don't think we're doing anything wrong, Sasovics. I'm beginning to think the issue is with CoreAVC. I used AviSynth 2.58a 070917 like ACrowley suggested above (thanks!) and tried graphedit from Jay Bee's advice from above (Thanks!) and the results are pretty much the same. I think the issue is in version 1.6 of CoreAVC. Check out this thread (http://www.corecodec.com/forums/index.php?topic=544.0) at Core's site, especially the comments like "Coreavc is useless to me now." ;) Another indication is that Jay Bee's post above mentions that interlacing in CoreAVC crashes, but in 1.6 the ability to turn off deinterlacing was removed. Unfortunately, I can't find any way to rollback to 1.5. Ver 1.6.1 is said to be coming soon. We'll see.

Edit: Here's another clue that may be related: In ver 1.6's changes is included "Rewrite of the Directshow wrapper for better compability"

Langman
I can confirm this. I was trying to serve up an x264 and an AVC BluRay stream into HCEnc using avisynth. HCEnc would crash straight away and playing the avs in Media Player gives me the access violation errors. I rolled back to 1.5 and suddenly it works fine again.

mikegun
21st January 2008, 19:55
hi,

since I'm now owning a full hd device I'm having trouble with 1080p matroska files. decoder is core avc 1.6 pro.
my system freezes randomly and I have to turn off my htpc to reboot.
everything was fine with 720p output resolution. but with 1080p output there is trouble. I changed renderers from vmr7 to overlay, but that didn't changed anything. now it seems like a workaround could be to set refreshrate to 50hz instead of 60hz.
can anyone confirm that there is an issue or should I downgrade to 1.5 ?

regards,

mike

nm
21st January 2008, 20:05
Random freezing indicates a driver problem or hardware malfunction, which could be caused by bad memory (run memtest86+ (http://www.memtest.org/)) or overheating (is your system overclocked?).

mikegun
21st January 2008, 20:43
maybe it's the driver. haven't had any problems with 720p@60hz

John64
26th January 2008, 07:36
Windows x64 has been out since around 2005. It is currently 2008 and still there is no native 64bit H.264 decoder. I understand that it is complicated to account for differences in 64bit compilers and libraries. Windows Vista x64'd Media Center ships only as a 64bit binary as well as only allowing SPDIF pass-through from 64bit applications. Because of this, I need to use a 64bit H.264 decoder. While ffdshow-tryout has preliminary support for 64bit systems, its video component is by no means complete. This is one area where CoreCodec could really capitalize in my opinion. By not offering 64bit builds of your product you are loosing the customers who, like me, may only consider using your product for this purpose. When ffdshow-tryout 64bit builds work at the level of their 32bit counterparts, I will likely not consider your product, especially since the current ffdshow-tryout builds decode at more than acceptable speed on my system, aside from a couple artifacts.

I am wondering what is slowing down your release of a 64bit binary. Is it that you rely on mingw-w64 for compiling your code? If that is the case, why not contribute to a tool that you profit from by helping it support Windows X64 properly. Is it possible for a beta/alpha 64bit build that people can try, even if it is unofficial, unsupported and unoptimized?

By the way, I am not just using Vista X64 for the sake of using 64bit Windows. I am going to be running 8gb of ram in this machine by the end of next week, and a dual booting isn’t an option.

You mentioned earlier that there will be 64bit native builds this year, any idea when, even if it is just a guess?

KoD
26th January 2008, 11:15
I always wonder if the number of systems running 64bit OSes out there really justifies developing 64 bits builds of programs that do interesting low level work. Would be interesting to see some real statistics, like how Valve (http://www.steampowered.com/status/survey.html) does for its SteamPowered users, but this time for people at large.

My guess (highly biased) is that there are so few people running those OSes that development money and time would better be spent somewhere else in all cases.

tomos
26th January 2008, 12:52
i would imagine that people running 64bit windows OS's would be a % or less IMO

i mean when i uploaded my stats to steam I was honestly shocked at how the VAST majority of their users had single core CPU's. dual core usage was tiny and quad core? 2-3 % iirc.

John64
27th January 2008, 22:21
but that audience is useless for comparison to the audience of multimedia users. Gamers know that most games are optimized for single fast processors, not dual cores. In this situation, this is all the users of one specific game. It doesn't say anything about whether these users spend money on software or hardware. You are also forgetting that XP X64 was not only really hard to find, it was released a long time after XP 32bit, was mainly for a targetted audience and wasn't really XP. XP X64 was Server 2003 for the desktop in actuality.

Vista has 32 and 64bit releases at the same time. Also, there are a bunch of security benefits for using 64bit vista, and the 4gb memory boundary is already a problem for new computers. Most current computers bought are going to have 2gb of ram, which doesn't cross the boundary, however, 4gb is very soon going to be the norm for new computers, and 4gb requires a 64bit operating to make use of all of your 4gb unless you want to run Server 2003 or linux as some of your address space is used for hardware (700mb for me). PAE is available, but is a big hack. It is just 36/40 bit addressing with mapping functionality. This does nothing but increase latency and limiting compatibility

I think it is a chicken and egg situation as far as 64bit goes. We need more people to use 64bit before a lot of companies support it, but companies won't support it unless there are a lot of users.

Saying few people run 64bit without any substantiation is short sited, especially since most computers capable of running Vista are 64bit capable, and all consumer copies of vista come with the 64bit option.

All that aside, all I am saying is that I will only consider buying CoreAVC if it comes to market first with a reliable 64bit AVC decoder. Take that and do whatever you want with it.

CoreAVC focuses on effeciency. FFDshow/libavcodec have the same feature set as CoreAVC in the 32bit windows platform. They both have SMP support. The only major advantage is that it decodes slightly more efficiently (maybe ~10%) however, a lot of x264 encoded media doesn't even work properly with CoreAVC.

Doing a simple recompilation of your existing code with a 64bit compiler shouldn't be a major issue, unless you are using Mingw-W64, and in that case, maybe supporting that project would be the best option.

Shinigami-Sama
27th January 2008, 22:32
I agree
the only thing keeping masses of people from running 64bit is the fact that there isn't a whole lot of consumer 64bit apps
they could make a killing being the first on the block for 64bit

Romario
28th January 2008, 02:03
So, where is our CoreAVC guy to answer on this questions?

BetaBoy, please tell us your plans about 64-bit build?

ADude
28th January 2008, 06:42
CORE - Please release the new version and fix the DVB issue in the next version.

squid_80
28th January 2008, 07:06
Doing a simple recompilation of your existing code with a 64bit compiler shouldn't be a major issue, unless you are using Mingw-W64, and in that case, maybe supporting that project would be the best option.
If it's written in assembly (and probably is considering the speed) it all needs to be changed for x64. Worse still if it uses __asm {} blocks and visual studio, since inline assembly isn't supported for x64.
In short it's a bigger job than just recompiling. Being a commercial operation, CoreCodec would have to justify the cost of all this work with what they immediately expect to gain from it. Then you'd also probably have to maintain two separate codebases (for x86 and x64) making sure any bugfixes go into both, so ongoing costs are increased as well.

John64
29th January 2008, 01:29
is inline assembly not supported by current compilers or just in general on the x64 platform?

If it were done in C/C++ with no assembly as i beleive the current ffdshow-tryout 64bit builds are done, it should at least work. Having said that, it performs like a dog (40% of a Q6600). As i said before, the only way i am going to spend money on something i can get for free is if it has a workable 64bit implementation, since currently the 32bit ffdshow more than exceeds my needs and expectations

squid_80
29th January 2008, 03:01
Inline assembly is not supported by Visual Studio when targetting the x64 platform. Intel's compiler has no problem with it.

ChronoCross
29th January 2008, 05:25
is inline assembly not supported by current compilers or just in general on the x64 platform?

If it were done in C/C++ with no assembly as i beleive the current ffdshow-tryout 64bit builds are done, it should at least work. Having said that, it performs like a dog (40% of a Q6600). As i said before, the only way i am going to spend money on something i can get for free is if it has a workable 64bit implementation, since currently the 32bit ffdshow more than exceeds my needs and expectations

the whole lack of 64-bit software is what prevents me from upgrading to vista. I'm not going to waste time on 64-bit unless there is some stuff that actually uses it (if even a little). Plus Vista 32-bit is a waste I'm better off with XP.

I haven't really seen anything that benefits greatly from 64-bit other than native 4+GB Memory addressing. It does have potential however I am skeptical about it's true benefits as all my experiences with it thus far have been troublesome.

John64
29th January 2008, 07:51
Well, it is more evolution than revolution. It does have performance benefits for code that takes advantage of it. I am not really good with cpu architecture or assembly, but i beleive it has double the general purpose registers and something else that makes it even faster in 64bit mode. There are security benefits from using a 64bit os. The (extremely major) drawback is the prevalence of DRM. No driver can be installed unless it is digitally signed, which means that you won't be able to develop your own drivers. The only reason i care about 64bit AVC is that i can't output SPDIF unless i am using a 64bit media player. If it weren't for DRM, i would be fine.

Another nice thing about 64bit windows is that it is a dividing line, since certain assumptions can be made about hardware as to performance levels. It also allows API's and ABI's to be changed since everything needs a port anyway.

That all doesn't change the fact that i will buy the first good and reliable H.264 decoder to market. FFDshow-tryout works 100% in Windows Media Player, but has bugs in Media Center.

Eretria-chan
29th January 2008, 10:50
Inline assembly is not supported by Visual Studio when targetting the x64 platform. Intel's compiler has no problem with it.
I believe Microsoft wants to get rid of inline assembly altogether ;)

I am not really good with cpu architecture or assembly, but i beleive it has double the general purpose registers and something else that makes it even faster in 64bit mode.
Plus 64-bit registers! This can make the process able to process more data at once.
But I don't know how effective it is due to SSE since it has typically had precision up to 128-bits or so for a long time.

John64
29th January 2008, 15:11
that is stupid on microsoft's behalf. That is a feature that they shouldn't be exerting control on.

Either way, 64bit is a better architecture. Right now, the *only* issue i have is the lack of a good native 64bit H.264 decoder. Nothing else is a problem, since every other application works wonderfully under WoW64

squid_80
29th January 2008, 15:35
(Once again I must apologise for pulling a thread off-topic. Twice in two days.)
that is stupid on microsoft's behalf. That is a feature that they shouldn't be exerting control on.It's MS. They would like everyone to be dependant on *their* inventions... In this case it's .NET. They're not ashamed to remove beloved features (inline asm) or deprecate standard C functions (memcpy/set, strlen/cpy/dup, printf, scanf etc.) to help "push" people the way they want.Either way, 64bit is a better architecture.For sure. Writing assembly in x64 is great, 15 (+rsp) gp registers means you almost never have to spill and 16 XMM registers eliminates some issues caused by needing aligned memory for SSE vs. being able to use unaligned MMX. I find speed in most cases is just an added benefit, being able to write a whole function without allocating any space on the stack for variables is so much easier.

CruNcher
30th January 2008, 11:09
CoreAVC interoperability problems list:
Sonic HD Demuxer (EVO) (Hardware Deinterlacing Detection Fails frames get droped)
Sonic MPEG Demultiplexer (EVO) (No Connection Possible)
Mainconcept Mpeg Demultiplexer (EVO) (No Connection Possible)
Arcsoft MPEG Demux (EVO) (No Connection Possible)

Practicly all of those Decoders from these Companies are interoperable to each others Splitter/Demulitplexer, only CoreAVC has major problems here.

Mainconcept Mpeg Demultiplexer:
Mainconcept H264 Decoder = OK
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK (old Mainconcept Decoder)
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Sonic HD Demuxer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = Hardware Deinterlacing Problems (frames skipped)

Sonic MPEG Demultiplexer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Arcsoft MPEG Demux:
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

BetaBoy
30th January 2008, 12:50
CoreAVC interoperability problems list:
Sonic HD Demuxer (EVO) (Hardware Deinterlacing Detection Fails frames get droped)
Sonic MPEG Demultiplexer (EVO) (No Connection Possible)
Mainconcept Mpeg Demultiplexer (EVO) (No Connection Possible)
Arcsoft MPEG Demux (EVO) (No Connection Possible)

Practicly all of those Decoders from these Companies are interoperable to each others Splitter/Demulitplexer, only CoreAVC has major problems here.

Mainconcept Mpeg Demultiplexer:
Mainconcept H264 Decoder = OK
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK (old Mainconcept Decoder)
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Sonic HD Demuxer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = Hardware Deinterlacing Problems (frames skipped)

Sonic MPEG Demultiplexer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Arcsoft MPEG Demux:
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

We are aware of the issue and are working on the fix... in the meantime today we are releasing CoreAVC 1.6.5

On 64bit.... yes it is planned for a later release... but likely this would not be till 2.0 with the release of the CoreAVC encoders.

Also note in 3 weeks on February 21st we are releasing CorePlayer Pro for XP/Vista and OS X that will have CoreAVC Pro integrated into it. On XP/Vista our AVC testing shows at least a 8-15% improvement over the directshow version of CoreAVC. While OS X..... well its not even close as we are at least 40% faster then Quicktime / Quicktime Pro ;-) . . . CorePlayer Pro for Linux is planned for release in April (x11, GTK and QT, QTopia). Also on interface's... this is also the first desktop release to the public of our CoreUI widget interface (think QT but faster, simplier, and lighter).... we will post this on CoreForge.org in the next couple of weeks as OSS.

BlackSun
30th January 2008, 13:28
We are emailing people with the 1.6.5 update right now. It takes some time to send all those emails, so please be patient.

Here is the changelog:
CoreAVC H.264 Video Codec - Version 1.6.5.0 (20080129)
- Add: Ignore past display order frame when invalid
- Add: Disable deblocking option for slower computers
- Add: Support for MV out of specs (fix artifacts for buggy files)
- Fix: Green frames display with incomplete frames
- Fix: Some minor improvements with DVB Viewer
- Fix: Deinterlacing fixes with internal bob
- Fix: Settings dialog glitchs
- Fix: Renamed Weave deinterlacing to "None (Weave)" to avoid confusion
- Fix: Others internal fixes

bob0r
30th January 2008, 13:39
We are emailing people with the 1.6.5 update right now. It takes some time to send all those emails, so please be patient.

Here is the changelog:
CoreAVC H.264 Video Codec - Version 1.6.5.0 (20080129)
- Add: Ignore past display order frame when invalid
- Add: Disable deblocking option for slower computers
- Add: Support for MV out of specs (fix artifacts for buggy files)
- Fix: Green frames display with incomplete frames
- Fix: Some minor improvements with DVB Viewer
- Fix: Deinterlacing fixes with internal bob
- Fix: Settings dialog glitchs
- Fix: Renamed Weave deinterlacing to "None (Weave)" to avoid confusion
- Fix: Others internal fixes

Nice! :thanks:

Jay Bee
30th January 2008, 14:24
Geez, do you guys even test your decoder before release? All the interlaced files at http://x264.nl/h.264.samples/ deinterlace at 25 fps instead of 50 fps. Deinterlace mode is set to Hardware. Also the decoder only shows a black screen when connected to EVR (in Win XP). Back to 1.5 for me. I'm really tempted to go and buy a dxva capable GPU now so that I can use Cyberlink decoder. The waiting time for a working CPU decoder is getting ridiculous.

Atak_Snajpera
30th January 2008, 15:12
connected to EVR (in Win XP)

EVR is available in Vista

bob0r
30th January 2008, 15:31
Geez, do you guys even test your decoder before release? All the interlaced files at http://x264.nl/h.264.samples/ deinterlace at 25 fps instead of 50 fps. Deinterlace mode is set to Hardware. Also the decoder only shows a black screen when connected to EVR (in Win XP). Back to 1.5 for me. I'm really tempted to go and buy a dxva capable GPU now so that I can use Cyberlink decoder. The waiting time for a working CPU decoder is getting ridiculous.

Most Samples are 25fps progressive.
Blend = 25fps deinterlace
Bob = 50fps deinterlace
Hardware = I agree, this is a weird name for what used to be DirectShow deinterlacing, not 100% what that does though.

EVR is Vista indeed, some have made XP patches but they are not 100% confirmed or used widely.

You can indeed buy another GFX card, as long as you like no deblocking in GPU hardware mode, oh and no crop/color flags reading. Cyberlink fails epicly on those.

CoreAVC = read even set crop flags CoreAVC = read and set color flags correctly: INPUT: TV, OUTPUT: PC = black==black on LCD-PC monitors.

If you really want to spend some money, i recommend an Intel Q6600 Processor + CoreAVC, even 40mbit H.264 files play like mpeg1 files then :)

(And yes, CoreAVC is still the fastest decoder, yet Cyberlink isn't far away if you dont count deblocking :p)

nm
30th January 2008, 15:41
You can indeed buy another GFX card, as long as you like no deblocking in GPU hardware mode, [...]
I thought that problem only concerned the previous GPU generation (GeForce 7xxx, Radeon 1xxx). Do the newer cards, that do most of the decoding on hardware, also cheat on deblocking?

ADude
30th January 2008, 19:06
Betaboy -

The "Haali Media Splitter" that is installed by CoreAVC Pro 1.6.5 - what version is that ?

More than the number, I'm wondering whether:

- You get the latest "stable" or "release" version just before you create a new installer

OR

- You get the latest "beta" version just before you create a new installer

OR

- Oops, we actually don't always remember to check for new versions of it when we release our own new version (I included this choice, because it is the usual operating mode for other paid software like Zoom Player...)

[Figured I'd get a faster response here than on the Core Forums. ;) ]

Disabled
30th January 2008, 19:25
Great news and a big thank you for including the bad MV fix.

@ADude They included the latest version from 29/12/2007, the installer is a different binary though (72kb smaller but same content)

Jay Bee
30th January 2008, 21:14
EVR is available in Vista

Many players can use EVR in XP too. My point is that ZP+CoreAVC_1.5+EVR works fine while now most files just show a black screen.

Most Samples are 25fps progressive.
Blend = 25fps deinterlace
Bob = 50fps deinterlace
Hardware = I agree, this is a weird name for what used to be DirectShow deinterlacing, not 100% what that does though.


I'm obviously talking about the samples that are true interlaced, not the 25 fps files that are encoded as if. I don't have a problem with the name "Hardware", it seems clearer to me than the name directshow deinterlacing. My problem is that CoreAVC is supposed to tell my GPU to do deinterlacing without destroying the temporal resolution. Again, it worked fine in 1.5, got broken in 1.6 and isn't fixed properly now, months later.


You can indeed buy another GFX card, as long as you like no deblocking in GPU hardware mode, oh and no crop/color flags reading. Cyberlink fails epicly on those.

CoreAVC = read even set crop flags CoreAVC = read and set color flags correctly: INPUT: TV, OUTPUT: PC = black==black on LCD-PC monitors.

If you really want to spend some money, i recommend an Intel Q6600 Processor + CoreAVC, even 40mbit H.264 files play like mpeg1 files then :)

Deblocking works on the newer generation of cards, just not on mine. While there may be a colour flag problem, that is surely a small problem compared to deinterlacing problems. A Quad core CPU won't do anything to help hardware deinterlacing and a GPU upgrade would be cheaper anyway.

And yes, I agree that CoreAVC is by far the fastest and most compatible decoder. I'm just annoyed that real world use like watching HDTV is given so little consideration compared to watching Apple trailers and pirated anime. When I bought CoreAVC 2 years ago I thought it would enable me to just throw in a DVB-S2 card and allow me to watch HDTV. To this day I haven't bought the card because I can't justify spending money on something that doesn't work. And I'm annoyed that Core always take months to release new versions and I usually need about two minutes to find new problems.

I thought that problem only concerned the previous GPU generation (GeForce 7xxx, Radeon 1xxx). Do the newer cards, that do most of the decoding on hardware, also cheat on deblocking?

As far as I know the newer cards don't cheat but it's hard to find any real information on this as most people don't care.

EDIT: when set to "bob" the EVR problem goes away. But it also brings my X2@2.8 Ghz to it's knees.

John64
31st January 2008, 02:54
what is the timeframe on version 2.0 when the encoder and 64bit directshow filter is out?

Sasovics
31st January 2008, 09:27
We are emailing people with the 1.6.5 update right now. It takes some time to send all those emails, so please be patient.

Here is the changelog:
CoreAVC H.264 Video Codec - Version 1.6.5.0 (20080129)
- Add: Ignore past display order frame when invalid
- Add: Disable deblocking option for slower computers
- Add: Support for MV out of specs (fix artifacts for buggy files)
- Fix: Green frames display with incomplete frames
- Fix: Some minor improvements with DVB Viewer
- Fix: Deinterlacing fixes with internal bob
- Fix: Settings dialog glitchs
- Fix: Renamed Weave deinterlacing to "None (Weave)" to avoid confusion
- Fix: Others internal fixes

What about avisynth compatibility ?

Viper Zx
31st January 2008, 10:16
Version 1.6.5 is a trial version!?

In ONE week she is expired! Try it!


http://www.corecodec.com/forums/index.php?topic=683.0


Edit:
You must reload the 1.6.5 Update, there was a silent update, it´s OK now. :)



Tschau

Viper Zx

BlackSun
31st January 2008, 10:41
Version 1.6.5 is a trial version!?

In ONE week she is expired! Try it!



The mailling list got buggy when I updated the file to fix a latest bug and mixed files, if you got such version, please go to: http://www.coreavc.com/retrieve

pankov
31st January 2008, 12:57
BlackSun/Betaboy,
I've been asking for a long time for a way to change the email that is currently active for my purchase. In my case the purchase was made from a friend of mine because PayPal/Core wasn't available for my country yet. I don't want to bug her every time a new version is out or I have to retrieve a new download link (like in this case with the mixed up files) so I just want you to change my registration from hers e-mail address to my personal. Will this be possible and how?

Selur
31st January 2008, 13:02
Got the same problem,...

BlackSun
31st January 2008, 13:26
Unfortunately the way we send new version (e-junkie) does not allow to change user data (which is sad, I agree). Later we hope to have our own simple solution that would allow such things.

BetaBoy
31st January 2008, 20:09
Jay Bee.... Test? Extensively, we even have half the Doom9 Elite testing prior to each release and the issue was _not_ reported. So atm we are looking into the EVR issue... and we have already identified the issue with interoperability and it will be fixed with the next release.

CruNcher
31st January 2008, 21:11
Glad to hear that you found the interoperability problems with the other Demultiplexers :) and also nice to hear that CorePlayer Desktop is ready to be released, so i suspect that http://www.betaplayer.com/ and http://www.coreplayerx.com/ are also not far away from seeing the shine of the morning sun? ;)

BetaBoy
31st January 2008, 23:39
CorePlayerX has changed direction slightly... It will still remain as an OEM licensable stand alone installer for IE, FF, Moz, Netscape, and Opera...

But the biggest news is our addition of an HTML5 Web-Kit / Safari plug-in (OS X, iPhone, Windows, Linux). All of which will be installed into both CorePlayer versions later this year. However the iPhone version of CorePlayer Mobile will get the HTML5 plug-in first for Web-Kit in April/May.

Momber
1st February 2008, 00:01
Hi!

Thanks for re-introducing the deblocking options. With them it's indeed possible to shave a few percent off CPU usage, which is my main concern.

However, 1.6.5 doesn't seem to make good use of both my (logical) CPU threads. Previous versions fared better in that regard.

Here is a comparison with a late build of ffdshow (rev1803_20080120_xxl), used on a high bitrate 720p x264 file.

http://img85.imageshack.us/img85/5127/core165xu2.jpg

Regards
S.

Dark Shikari
1st February 2008, 00:03
What does "skip when safe" actually do?

Does it mean "skip unreferenced B-frames"? Does it mean "skip when the threshold is high enough that it would have minimal effect at that QP"?

ChronoCross
1st February 2008, 00:10
Hi!

Thanks for re-introducing the deblocking options. With them it's indeed possible to shave a few percent off CPU usage, which is my main concern.

However, 1.6.5 doesn't seem to make good use of both my (logical) CPU threads. Previous versions fared better in that regard.

Here is a comparison with a late build of ffdshow (rev1803_20080120_xxl), used on a high bitrate 720p x264 file.

http://img85.imageshack.us/img85/5127/core165xu2.jpg

Regards
S.

does even distribution really matter? In this case the one CPU is much lower than the second but the overall usage is less than ffdshow so your still getting better performance.

BetaBoy
1st February 2008, 00:25
nice to hear that CorePlayer Desktop is ready to be released

A note with CorePlayer Pro.... its really only for a small demographic at this time in the 1.xx phase. Its by no means a WMP, ZP, MPC, TCMP from a 'features' perspective. IE; no-dvd, blu-ray, subtitle, CDA support at this time... However its CORE is a great base to begin with to add all those desktop related features into.

Momber
1st February 2008, 01:16
does even distribution really matter?
Not in the example obviously. But when I try to play a 1080p file, one thread goes through the roof while the other one has cycles to spare.

bmnot
1st February 2008, 05:23
What does "skip when safe" actually do?

Does it mean "skip unreferenced B-frames"? Does it mean "skip when the threshold is high enough that it would have minimal effect at that QP"?

I'd like to know this too.

ChronoCross
1st February 2008, 06:15
Not in the example obviously. But when I try to play a 1080p file, one thread goes through the roof while the other one has cycles to spare.

Does the clip play choppy due to it?

Jay Bee
1st February 2008, 09:26
Jay Bee.... Test? Extensively, we even have half the Doom9 Elite testing prior to each release and the issue was _not_ reported. So atm we are looking into the EVR issue... and we have already identified the issue with interoperability and it will be fixed with the next release.

Good to hear that you are looking into it. BTW the deinterlacing problem is not just with EVR, it's with WMR7/8 as well. And even if your l33t testers didn't report deinterlacing problems, I did, over two months ago (http://forum.doom9.org/showpost.php?p=1060900&postcount=3289). And so did Momber (http://forum.doom9.org/showpost.php?p=1060668&postcount=3284) who you even replied to. The problem is still there. I'll post it here again, this time with some colourful bits.

1.5

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output

- Connection media type:

Video: YUY2 1472x1080 (491:270) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3179520
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x000000a1
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1964
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1472
biHeight: -1080
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 3179520
biXPelsPerMeter: 1555200
biYPelsPerMeter: 2121120
biClrUsed: 0
biClrImportant: 0



1.6

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output

- Connection media type:

Video: YUY2 1472x1080 (7447:4096) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3179520
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000025
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 7447
dwPictAspectRatioY: 4096
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1472
biHeight: -1080
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 3179520
biXPelsPerMeter: 4096
biYPelsPerMeter: 5585
biClrUsed: 0
biClrImportant: 0




I don't know exactly what the values of the flags stand for but I know that 1.5 works and 1.6.x doesn't.

BlackSun
1st February 2008, 12:14
Good to hear that you are looking into it. BTW the deinterlacing problem is not just with EVR, it's with WMR7/8 as well.


We're looking into it. I tried this morning that flag dwInterlaceFlags: 0x000000a1 but this does not solve the problem. We're going to look deeper. Thanks for the tip btw.

Momber
1st February 2008, 14:26
Does the clip play choppy due to it?
Yes it does. Even with deblocking disabled.

Momber
1st February 2008, 14:32
And so did Momber who you even replied to.

FWIW, I tried hardware deinterlacing with 1.6.5 on a (truly interlaced) 1080i 50fps H.264 file and it worked OK. Using XP, Overlay Mixer, ZP 5.0, with a Radeon x1800xl.
With software deinterlacing on the same clip I get A/V heavily off synch after only a few seconds.

BTW, Core 1.6.5 would not connect to either splitter from Cyberlink or Elecard. Needed to call Haali into action, which is not my fav splitter for 1080i H.264 transport streams.

S.

Episodio1
1st February 2008, 14:56
BlackSun, maybe you could tell us a short explanation when you fix something in CoreAVC. Just for curiosity. :)

Sulik
1st February 2008, 18:04
Yup, the dwInterlaceFlags values in 1.6 are wrong, it should really be using 0x81 or 0x85, ie: AMINTERLACE_IsInterlaced |
AMINTERLACE_DisplayModeBobOrWeave, then signal bob/weave and/or tff/bff by using the dwTypeSpecificFlags on the media samples (that's really basic dshow stuff).

langman10
1st February 2008, 20:41
Thanks Beta Boy for Core 1.6.5

I (and others) are still struggling with Avisynth compatibility, while 1.5 is Avisynth-happy.

Here's (http://rapidshare.com/files/88400466/20071219115849.m2ts.html) a 16-second .m2ts file shot on a camera.

With Core 1.6.5 I can open this file directly in WMP and it plays in sync.

In Avisynth I create a script directshowsource("file.m2ts"). When loaded in vdubmod it shows number of frames is 22173 and fps is 1387. Trying to play this script gives the message "couldn't initialize timer!" So I add changefps(29.97) to the script. Now number of frames and fps is accurate but a message pops up that "Changefps: Ratio must be less than 10 for linear access. Set LINEAR=false" which I do add. So my script is

directshowsource("file.m2ts")
changefps(29.97,linear=false)

The script plays very choppy in vdubmod, and an avi I create from vdubmod has random one-frame jitters like this (http://rapidshare.com/files/88402526/coreavc_avisynth_jitter.avi.html).

Deinterlacing is off. This behavior occurs with deblocking on or off. Any ideas?

Langman

JohnnyFu
1st February 2008, 23:56
Better late then never, the christmas edition is out :D

BetaBoy, gawky Johnny has deleted his update notification mail for 1.6.5 :helpful:, please check you pm's.

oddball
3rd February 2008, 16:03
Just came to say thanks for:

- Add: Support for MV out of specs (fix artifacts for buggy files)

Finally listening to your customers. It's a good step to take. :)

Ryokurin
3rd February 2008, 19:37
EVR is available in Vista

Its also available in XP when you install .net framework 3.0. This is where most of the patches that bob0r is referring to gets it from.

BetaBoy
3rd February 2008, 22:25
Just came to say thanks for:

- Add: Support for MV out of specs (fix artifacts for buggy files)

Finally listening to your customers. It's a good step to take. :)

Who didn't know you were gonna jump in on this? ;-) So your saying creating non-compliant AVC support is a good thing? I voted no for adding it. But for the time being we want playback as fluid as possible since we are the leading H.264 software decoder atm, so it made sense.... but by the time 2.0 comes out we will remove non-compliant MV support for sure.

BetaBoy
3rd February 2008, 22:29
which is not my fav splitter for 1080i H.264 transport streams.
S.

Just curious... What is your fav for 1080i and why?

Disabled
3rd February 2008, 23:15
So your saying creating non-compliant AVC support is a good thing? I voted no for adding it. But for the time being we want playback as fluid as possible since we are the leading H.264 software decoder atm, so it made sense.... but by the time 2.0 comes out we will remove non-compliant MV support for sure.

I really can't understand you. Is there an encoder out there producing out of spec streams? Non-Spec streams will die out by themselves, but why do you want to upset those who still have one lying around?

Dark Shikari
3rd February 2008, 23:39
I really can't understand you. Is there an encoder out there producing out of spec streams? Non-Spec streams will die out by themselves, but why do you want to upset those who still have one lying around?x264 produced out-of-spec streams before this revision (http://trac.videolan.org/x264/changeset/697) and this revision (http://trac.videolan.org/x264/changeset/663).

Since versions of libx264 and x264 before those revisions will continue to be around for years due to the stable version policy of Debian systems and similar, we will continue to see out-of-spec streams made by them.

Shakey_Jake33
4th February 2008, 00:41
Who didn't know you were gonna jump in on this? ;-) So your saying creating non-compliant AVC support is a good thing? I voted no for adding it. But for the time being we want playback as fluid as possible since we are the leading H.264 software decoder atm, so it made sense.... but by the time 2.0 comes out we will remove non-compliant MV support for sure.
Is there any need to remove it? I agree non-compliant streams are not a good thing, but is there a benefit in removing it? Don't really see the point otherwise.

Disabled
4th February 2008, 01:01
those revisions will continue to be around for years due to the stable version policy of Debian systems and similar, we will continue to see out-of-spec streams made by them.
Thanks for this answer, I forgot about those systems. But then again I think that the number of ppl knowing about x264 and actively using an old version is rather small compared to the amount of ppl that made encodes in the days x264 had no fix for the problem, thus bad encodes in the homes and in the wild will definately get lower (at least in per cent).

But then:
Is there any need to remove it? I agree non-compliant streams are not a good thing, but is there a benefit in removing it? Don't really see the point otherwise.
And I see no reason too. While I do understand that implementations of HTML parsers allowing to much non-spec stuff make it very hard to create HTML that look ok in every browser, the problem is much less pronounced here. Unlike HTML, AVC is a standard everyone tries to comply with. So if there was one isolated issue, it won't create a mess to support it for legacy purpose. And it won't start a trend, that h264 encoders will create non-spec files every decoder has to swallow.

Eretria-chan
4th February 2008, 03:58
Is there any need to remove it? I agree non-compliant streams are not a good thing, but is there a benefit in removing it? Don't really see the point otherwise.

I would see a benefit.
If removed in 2.0, it will force everyone with 2.0 to make standards compliant specs (or lose compability with decoders!). If you just continue to support it, then people will continue to make non-standard compliant streams (why stop doing the way you've always known when it works?). That's life.
But if you still want to play non-standard, then you should use an older version.

Dark Shikari
4th February 2008, 04:10
I would see a benefit.
If removed in 2.0, it will force everyone with 2.0 to make standards compliant specs (or lose compability with decoders!). If you just continue to support it, then people will continue to make non-standard compliant streams (why stop doing the way you've always known when it works?). That's life.
But if you still want to play non-standard, then you should use an older version.No major encoders, in their latest version, allow non-compliant streams (as far as I know). So that's not really a valid argument.

Eretria-chan
4th February 2008, 04:14
No, it makes sure they stay compliant and no "small" new encoder gets the urge to make non-compliant streams :)
If there is no decoder to decode it, then you can't make such encodes!

Dark Shikari
4th February 2008, 04:17
No, it makes sure they stay compliant and no "small" new encoder gets the urge to make non-compliant streams :)
If there is no decoder to decode it, then you can't make such encodes!This is an invalid argument also, because libavcodec is currently the most popular software PC H.264 decoder in the world (because its free, primarily) and has no limits on MV size.

As a result, if someone's encoder does generate non-compliant streams, most users will view it as "oh, CoreAVC is buggering out again, I guess I'll go back to using reliable libavcodec."

Your argument only works if you can convince libavcodec (along with all others that don't specifically limit MV size) to stop supporting them, which in many cases takes more code.

Remember, also, the standard does not say "decoders cannot support MVs above X size"; it says "MVs cannot be above X size." It does not define what the decoder should do with such an MV.

ChronoCross
4th February 2008, 04:23
This is an invalid argument also, because libavcodec is currently the most popular software PC H.264 decoder in the world (because its free, primarily) and has no limits on MV size.

As a result, if someone's encoder does generate non-compliant streams, most users will view it as "oh, CoreAVC is buggering out again, I guess I'll go back to using reliable libavcodec."

actually the only people who would think this are people whom currently know of the issue (mainly doom9 people).

The rest of the people who in the future purchase coreavc will just think the stream is broken.

anything that comes from a legitimate source (aka not pirated) will be spec compliant and is more than likely Core's target audience.

Dark Shikari
4th February 2008, 04:28
actually the only people who would think this are people whom currently know of the issue (mainly doom9 people).

The rest of the people who in the future purchase coreavc will just think the stream is broken.Completely incorrect, from experience. Here's the general process:

A: "My MKV files are playing too slow! What should I do?"
B: Get CoreAVC. Its only like 15 bucks.
A: OK, I'll try that. This better help!
...
A: Sweet, it works. Thanks a lot!
...
...
A: I'm getting some blockiness in some of my videos, and its in the same place every time. But my friend plays the same videos and they're fine!
B: Have you tried turning off CoreAVC?
A: OK.
...
A: Its fixed! Wait, is CoreAVC buggy?
B: Probably.

anything that comes from a legitimate source (aka not pirated) will be spec compliant and is more than likely Core's target audience.I don't know a single person who has purchased CoreAVC for watching anything other than pirated HD rips.

Overall, the issue is not very important; very few streams have such MVs, and rarely in more than a couple minor places. The point is that restricting yourself to every last rule in the standard isn't always a good thing--a classic example is the rule that one may not have more than 16 motion vectors per MB pair for levels higher than 3.1 (I think?) CoreAVC doesn't enforce this. Nothing enforces this. If it did, loads of streams would break.

Remember, the standard does not require decoders to enforce the rules in the standard. The standard merely defines what a compliant stream should look like.

molitar
4th February 2008, 05:02
Question: What is the skip when safe deblocking mode do? Does it intelligently know if deblocking is required and use it or just skips using it the majority of the time?

ChronoCross
4th February 2008, 05:16
C
A: I'm getting some blockiness in some of my videos, and its in the same place every time. But my friend plays the same videos and they're fine!
B: Have you tried turning off CoreAVC?
A: OK.
...
A: Its fixed! Wait, is CoreAVC buggy?
B: Probably.

I don't know a single person who has purchased CoreAVC for watching anything other than pirated HD rips.


your assuming that they are looking for the blocks. Again this is something only experienced encoders look for. People using stuff for everyday playback generally expect there to be at least some blocking and will ignore it. Hell even my cable gets a little blocky once in awhile and I spend a good amount of cash on it.

As for the second part of your answer, kinda all the more reason they shouldn't support it. Once again why have a workaround for something only illegal material have. Since they are a legitimate business their focus is legal material and therefore they should only support what the specs say it should.

I actually have quite a bit more discussion on this floating in my head but it would take me about an hour to type up something coherent and well that doesn't quite work for me lol.

Dark Shikari
4th February 2008, 05:20
As for the second part of your answer, kinda all the more reason they shouldn't support it. Once again why have a workaround for something only illegal material have. Since they are a legitimate business their focus is legal material and therefore they should only support what the specs say it should.Real businesses are smart.

Apple for example knew that when they released the iPod, almost none of their customers owned enough music to nearly fill it--they knew the only reason it could possibly be a success is if people pirated boatloads of music.

And they did, and Apple made billions upon billions. If not for music piracy, the iPod would have been a complete flop. This was not coincidence. Apple took this fully into account before releasing the iPod.

BetaBoy
4th February 2008, 06:43
Real businesses are smart.

Apple for example knew that when they released the iPod, almost none of their customers owned enough music to nearly fill it--they knew the only reason it could possibly be a success is if people pirated boatloads of music.

And they did, and Apple made billions upon billions. If not for music piracy, the iPod would have been a complete flop. This was not coincidence. Apple took this fully into account before releasing the iPod.

Come now DS.... Your point is taken 3x over now but you are not understanding the points I made x pages back (or are for arguements sake). Stacking non-compliant features and bloat related to them over time is what we don't want/need... But did so in this case in the short term because of the demand.

Dark Shikari
4th February 2008, 06:46
Come now DS.... Your point is taken 3x over now but you are not understanding the points I made x pages back (or are for arguements sake). Stacking non-compliant features and bloat related to them over time is what we don't want/need... But did so in this case in the short term because of the demand.Yes, I understand what you mean. This point has been beaten to a pulp.

In terms of "bloat supporting non-compliant features," one has to remember the issue isn't that its non-compliant; the issue is bloat. As I said earlier, there are many restrictions in the standard that actually take more code to abide by, and therefore CoreAVC doesn't abide by them.

In the MV case, it obviously depends on how CoreAVC is coded, which I don't expect to know ;)

While you're here, can you answer my question about "skip deblocking when safe"?

Shinigami-Sama
4th February 2008, 06:49
Real businesses are smart.

Apple for example knew that when they released the iPod, almost none of their customers owned enough music to nearly fill it--they knew the only reason it could possibly be a success is if people pirated boatloads of music.

And they did, and Apple made billions upon billions. If not for music piracy, the iPod would have been a complete flop. This was not coincidence. Apple took this fully into account before releasing the iPod.

that and they allowed for normal files to exist on the ipod
I know a lot of people that use their failpod for moving files around as well
usually pirated movies though

ChronoCross
4th February 2008, 06:51
Real businesses are smart.

Apple for example knew that when they released the iPod, almost none of their customers owned enough music to nearly fill it--they knew the only reason it could possibly be a success is if people pirated boatloads of music.

And they did, and Apple made billions upon billions. If not for music piracy, the iPod would have been a complete flop. This was not coincidence. Apple took this fully into account before releasing the iPod.

That's kind of a different scenario. They didn't have to alter their product based on piracy. in fact they altered AAC to try and prevent piracy.

Similarly Core could do the same by removing support for out of spec videos. Granted this will only stop older material but it will show a higher moral fiber since you stated that a majority of material is in fact pirated. The only way to truly be against piracy is to stop making your product. The same could go for x264, is x264 a success because of piracy?

Simply knowing that your product will in some way be used for illegal means doesn't mean you should support it simply because you will make a few extra bucks.

Dark Shikari
4th February 2008, 06:53
That's kind of a different scenario. They didn't have to alter their product based on piracy. in fact they altered AAC to try and prevent piracy of their own music. They did nothing for music anyone else sold.Fixed that for you.

Also, you might be interested to know that people don't only encode TV show rips with x264. They also use it for perfectly legitimate videos. Many corporations do, in fact; I helped one the other day who was using x264 Core 50 in mencoder for distributing streaming video--which would indeed have had the bug.

Google also uses x264, from what I've heard.

ChronoCross
4th February 2008, 07:46
Fixed that for you.

Also, you might be interested to know that people don't only encode TV show rips with x264. They also use it for perfectly legitimate videos. Many corporations do, in fact; I helped one the other day who was using x264 Core 50 in mencoder for distributing streaming video--which would indeed have had the bug.

Google also uses x264, from what I've heard.

So what your suggesting is the only music that products should allow are DRM ones correct as that would be the only viable way to say you are against piracy? Kinda defeats the mindset of these forums.

As for the people using core 50, they should probably update. It's like not applying a service pack update to your OS, you know the risks and must accept the consequences when you get exploited or something doesn't work right.

As for "can do no evil" Google (the Mozilla spell checker actually capitalized it, crazy) using it, if I see it I'll believe it. Honestly I think they would be in favor of following the standards. Else we end up in the IE paradox, having to write every piece of software thereafter to support the problems of old non-standard webpages.

Dark Shikari
4th February 2008, 07:47
As for the people using core 50, they should probably update. It's like not applying a service pack update to your OS, you know the risks and must accept the consequences when you get exploited or something doesn't work right.But you run into the classic problem: people use Debian. :p

Or moreso, since x264 has no stable version, distributions create their own stable versions as part of policy. As such, it takes up to 12 months, or even more, for a fix to backpropagate to all users.

Its even worse for x264, because people use libx264 through mencoder/ffmpeg, and as a result they don't realize how old their libx264 is. I've run into people with the latest SVN build of mencoder... and a 2006 libx264.

Disabled
4th February 2008, 11:42
I think not including non-spec-mv-support because of the pirates is a ridiculous idea. Pirates usually are the first to use new builds, because they aim for maximum quality and don't mind updating their software every day. So I would say, illegal material has a lower percentage of out of spec files, than legally (x264 encoded) files has. (#illegal in spec/#illegal out-ofspec > #legal in spec/#legal out-spec) Or your argument is: x264 has a small legal userbase, let's not support them.
And then again, as the computers decoding h264 get faster every day, Core has less and less a selling point, so I can't understand why they are trying to play the format police to enforce the law.
And once again: There won't be a run to create out of spec files. I agree it WAS a good thing Core did not support it, because else the error would probably not have been detected. But now there is no good reason to remove support.

Rectal Prolapse
4th February 2008, 17:06
ChronoCross: CoreAVC's biggest fanboy. :P

Anyways, thanks for putting in more options for 1.6.5. And the removal of DRM is very nice too (from 1.6).

Thank you for listening to your customers and not just the fanboys!

ChronoCross
5th February 2008, 06:34
ChronoCross: CoreAVC's biggest fanboy. :P

Anyways, thanks for putting in more options for 1.6.5. And the removal of DRM is very nice too (from 1.6).

Thank you for listening to your customers and not just the fanboys!

Or perhaps someone that enjoys discussion rather than blindly following the masses. but then again someone with a name like yours must make an ass of himself quite often.

Momber
5th February 2008, 17:50
Just curious... What is your fav for 1080i and why?
Either Elecard or, for the few files it doesn't work with, Cyberlink, Gabest or Sonic.
Playback is smoother on my machine with Elecard in comparison to Haali.

molitar
6th February 2008, 05:50
Well someone needs to get their act together at CoreCodec! 2 days after I purchased my CoreAVC Pro 1.6.5 my serial is no good! It wouldn't register just gave an initialization error! After NEARLY destroying my system removing all codecs and running all types of registry software (might end up having to do a repair install not sure if I recovered it from all the attempts) to only find out they sold me an invalid serial number! What the heck?

After finding this out on the CoreCodec forums I went and downloaded a pirated version to test what I read and sure enough.. I have a working CoreAVC 1.6.5! Pretty sorry that I have to find a pirated version to run a software that I paid for!
You all really need to get your act together or people won't purchase software from you when it's easier to download and get working a pirated version.

And BETTER fix the damn error message because I nearly DESTROYED my entire Operating System thinking it was a registry error or something and not an invalid serial number! That is not acceptable at all for any software to not install and not inform you why causing a near destruction of your customers operating system!

ChronoCross
6th February 2008, 05:51
Well someone needs to get their act together at CoreCodec! 2 days after I purchased my CoreAVC Pro 1.6.5 my serial is no good! It wouldn't register just gave an initialization error! After NEARLY destroying my system removing all codecs and running all types of registry software (might end up having to do a repair install not sure if I recovered it from all the attempts) to only find out they sold me an invalid serial number! What the heck?

After finding this out on the CoreCodec forums I went and downloaded a pirated version to test what I read and sure enough.. I have a working CoreAVC 1.6.5! Pretty sorry that I have to find a pirated version to run a software that I paid for!
You all really need to get your act together or people won't purchase software from you when it's easier to download and get working a pirated version.

And BETTER fix the damn error message because I nearly DESTROYED my entire Operating System thinking it was a registry error or something and not an invalid serial number! That is not acceptable at all for any software to not install and not inform you why causing a near destruction of your customers operating system!

Did you open a support ticket with them? I would gather you didn't.

molitar
6th February 2008, 05:56
Did you open a support ticket with them? I would gather you didn't.

Yes I did.. but the point is that their error message doesn't say it's an invalid serial.. and I end up wasting hours of my precious time almost destroying my system! Half a day gone and not able to watch my shows because it just stopped working and gave no reason why! If it would said something informative about serial or registration I could of contacted support sooner and been most likely back in business without almost destroying my entire setup.

Dark Shikari
6th February 2008, 05:56
Did you open a support ticket with them? I would gather you didn't.Though I suspect those people with problems should have opened a ticket, I have noticed a proliferation of posts on other forums where people have had similar problems (though it was merely an annoyance, not "destroying one's operating system" as the poster claims). One really interesting thing I've found is on very piracy-oriented forums, many people still pay for CoreAVC. This struck me as somewhat odd, given that they hardly pay for anything else.

A post from a private tracker forum:
I have a legal license to use CoreAVC Pro. I installed the 1.6.5 update the other day. It worked fine. Until today when I tried to play something and saw it was not loading the filter. I tried to re-register the filter. It gave me an error about LoadLibrary failing. I uninstalled and reinstalled. No good. I did a chkdsk and sfc /scannow. No dice. I eventually found something in the CoreCodec forums about it and someone said that they must be entering their serial number wrong. Mine is correct and I even cut and pasted it bit by bit from the email I got ages ago to make sure. It installed fine but again it failed to register. So on that basis I went and downloaded the EDGE version. Installed and used their keygen. Voila! It works again!

So I dunno. Maybe my key got blacklisted or something. DRM surely sucks balls. I have a legal licence to use it so I have no remorse over doing this.
I doubt this will be a big problem for CoreAVC even if many people switch to pirated copies, as they will likely switch back when the next update comes around.

molitar
6th February 2008, 06:02
Though I suspect those people with problems should have opened a ticket, I have noticed a proliferation of posts on other forums where people have had similar problems (though it was merely an annoyance, not "destroying one's operating system" as the poster claims). One really interesting thing I've found is on very piracy-oriented forums, many people still pay for CoreAVC. This struck me as somewhat odd, given that they hardly pay for anything else.

I paid for it and I found out what the problem was on the corecodec forum I just registered at. But the first place I looked was in their own knowledge base which is TOTALLY and UTTERLY useless since it only has 5 items listed for coreavc and not a single one is about the initialization error! Who would suspect a software would just stop working and blow up 2 days after purchasing the new version?

Two really stupid things by CoreCodec.. A very undescriptive erro message making me think it was a system error and not my serial being invalid just after 2 days of receiving it! Second no mention of this problem on the knowledge base for CoreCodec. The two places that I should look first and neither has the problem detailed.. Software should be first.. knowledge base should be second.

ChronoCross
6th February 2008, 06:02
Though I suspect those people with problems should have opened a ticket, I have noticed a proliferation of posts on other forums where people have had similar problems (though it was merely an annoyance, not "destroying one's operating system" as the poster claims). One really interesting thing I've found is on very piracy-oriented forums, many people still pay for CoreAVC. This struck me as somewhat odd, given that they hardly pay for anything else.

A post from a private tracker forum:

It's much cheaper than replacing an entire system. I can spend $15 or $1500.

I suspect you would see a similar trend on those same forums if other software were cheaper as a majority of good software is incredibly overpriced.

ChronoCross
6th February 2008, 06:05
I paid for it and I found out what the problem was on the corecodec forum I just registered at. But the first place I looked was in their own knowledge base which is TOTALLY and UTTERLY useless since it only has 5 items listed for coreavc and not a single one is about the initialization error! Who would suspect a software would just stop working and blow up 2 days after purchasing the new version?

Two really stupid things by CoreCodec.. A very undescriptive erro message making me think it was a system error and not my serial being invalid just after 2 days of receiving it! Second no mention of this problem on the knowledge base for CoreCodec. The two places that I should look first and neither has the problem detailed.. Software should be first.. knowledge base should be second.

if you had opened a ticket this probably would have been resolved without you having to touch a thing on your machine other than maybe reinstalling CoreAVC.

How does one go about adding something to the knowledge base if the only thing they see are random people flaming on various forums? If a support ticket is raised then all they have to do is narrow down the issue, and provide you with a fix.

molitar
6th February 2008, 06:16
if you had opened a ticket this probably would have been resolved without you having to touch a thing on your machine other than maybe reinstalling CoreAVC.

How does one go about adding something to the knowledge base if the only thing they see are random people flaming on various forums? If a support ticket is raised then all they have to do is narrow down the issue, and provide you with a fix.

Yes but this issue should have already been in the knowledge base and not having me almost destroying my system trying to figure out why it won't register.. this happened back in version 1.5 I have found on corecode forum.. posted on August 17, 2007.. So this old issue SHOULD have been in the knowledge base! I wouldn't have wasted half a day.. I would of emailed them immediately for a fix knowing it was not a system problem with file registration. What good is a knowledge base if they are not putting known issues in it?

ChronoCross
6th February 2008, 06:29
Yes but this issue should have already been in the knowledge base and not having me almost destroying my system trying to figure out why it won't register.. this happened back in version 1.5 I have found on corecode forum.. posted on August 17, 2007.. So this old issue SHOULD have been in the knowledge base! I wouldn't have wasted half a day.. I would of emailed them immediately for a fix knowing it was not a system problem with file registration. What good is a knowledge base if they are not putting known issues in it?

so your alternative because it wasn't in the knowledge base was to rip your own machine apart? Also did you confirm that your issue is indeed the serial key problem? Just because it looks like a coke can doesn't mean there is coke inside. Perhaps instead of using a pirated copy you could get your legitimate and legal copy working (as what your currently using is considered a violation of the DMCA Chapter 121 Section 1201).

Shinigami-Sama
6th February 2008, 06:29
Yes but this issue should have already been in the knowledge base and not having me almost destroying my system trying to figure out why it won't register.. this happened back in version 1.5 I have found on corecode forum.. posted on August 17, 2007.. So this old issue SHOULD have been in the knowledge base! I wouldn't have wasted half a day.. I would of emailed them immediately for a fix knowing it was not a system problem with file registration. What good is a knowledge base if they are not putting known issues in it?

your fault for thrashing your system
core's fault for not being descriptive
core's fault for not keeping their info updated ( I check every month or so to see whats going and if I want to buy it yet )

or is not the best for support - but remember they're a very small company
they are getting better

also
many people I know buy a license of coreavc and just use a cracked version after a while due to the idiotic activation scheme

molitar
6th February 2008, 06:48
Yes it is pretty sorry for a legal serial to just crap out.. didn't even last 2 days. It isn't like I can wait a day or two everytime it decides to crap out for no reason whatsoever. Also sorry they don't say what is wrong but instead just say it can not be registered making me believe it was a bad registry or or some dll needed to be re-registered.. who is going to believe their serial is invalid 2 days after activating it?

Who is going to believe that it is a serial issue when it acts like a registration error instead.. if it looks like a duck, walks like a duck, and quacks like a duck the common census is going to be it's a duck.. not a chicken. But in this case it's not a duck but a chicken all because they were too lazy to put in descriptive error messages like invalid serial number. After all when you look up initialization errors are often shlwapi.dll as well as a few other dlls.. or registry permissions or bad keys.. so first thing someone is going to try is to re-register dlls and run registry cleaners and repair softwares.

foxyshadis
6th February 2008, 08:15
You can spend anywhere from 2 to 200 hours waiting for core to reply to your ticket, or you can spend some time researching your own problem and fix it on your own so you can actually watch the movie some time tonight, right? c'mon, CC, people can reasonably expect support for self-fixable issues, and given core's track record with personal support you'd think they'd want to have the best knowledgebase they could make.

On the other hand, we do have a thread dedicated to bitching about core already, this is getting a little full.

BlackSun
6th February 2008, 10:21
Molitar, can you PM me your Paypal email address please ? I will check your serial.

ChronoCross
6th February 2008, 17:15
You can spend anywhere from 2 to 200 hours waiting for core to reply to your ticket, or you can spend some time researching your own problem and fix it on your own so you can actually watch the movie some time tonight, right? c'mon, CC, people can reasonably expect support for self-fixable issues, and given core's track record with personal support you'd think they'd want to have the best knowledgebase they could make.

On the other hand, we do have a thread dedicated to bitching about core already, this is getting a little full.

your making an assumption foxyshadis. Just because you've heard of peoples tickets not being answered quickly does not mean that is the way it is. You could spend some time researching your own problem but at the same time would you really want to screw with the windows registry? There are usually big warnings that say "if you don't know what changing x does, don't"

clsid
6th February 2008, 17:37
So you claim all those people are liars? Anyway, I think you are failing to understand the point that foxyshadis is trying to make. Why contact support at all if you can fix something yourself?

And given proper instructions even retards can safely edit the registry.

ChronoCross
6th February 2008, 18:11
So you claim all those people are liars? Anyway, I think you are failing to understand the point that foxyshadis is trying to make. Why contact support at all if you can fix something yourself?

And given proper instructions even retards can safely edit the registry.

What I'm claiming is just because those few had issues doesn't mean that's how it is with every issue.

I understand his point but obviously he didn't fix his issue without breaking the law.

BlackSun
6th February 2008, 18:45
After investigation, the reseller (ejunkie) was sending the wrong file to new customer. If you get the "A dynamic link library (DLL) initialization routine failed" error, please visit the following URL:

http://www.coreavc.com/retrieve

Type your Paypal email address that you used to buy CoreAVC, an email will be sent to that address that contain:

- Your serial number
- A download link which is not from e-junkie and that provide the proper file.

I added an entry in our knowledge base about it.

Romario
6th February 2008, 20:17
people in China doesn't even know what is serial number, or in Albania.

Disabled
6th February 2008, 20:31
After investigation, the reseller (ejunkie) was sending the wrong file to new customer.
Unfortunately it wasn't just new customers. I got a wrong version too that stopped working yesterday, but thanks to Viper Zx and Dr.Penix I came up with the idea that it might be a wrong version and got a corrected one from your link posted.
Would have been great if you would have mailed your customers, as the error message given was not very descriptive. And as molitar shows, ppl got confused.

Shinigami-Sama
6th February 2008, 21:09
What I'm claiming is just because those few had issues doesn't mean that's how it is with every issue.

I understand his point but obviously he didn't fix his issue without breaking the law.

I'm fairly certain foxy is a girl ( Remembers that 'how did you get your nick' thread from a while back )

anyways...


foxy also said 2 to 200 hours, so some people do get speedy service, while sadly, what looks like more than a handful do not speedy service


and back on topic
is there an ETA for the next release?

KoD
7th February 2008, 10:19
people in China doesn't even know what is serial number, or in Albania.

I think you meant to say: "People in China don't need serial numbers. They reverse engineer the software and make serial number generators for themselves." Self-help taken to the extreme. What's so expert in editing the registry when you can help yourself like that !

PS: for people that have no sense of humour, I'll say I'm quite aware CoreAVC is the best h264 software decoder out there and that reply above is not meant to be rude.

BetaBoy
7th February 2008, 17:36
Hi!

Thanks for re-introducing the deblocking options. With them it's indeed possible to shave a few percent off CPU usage, which is my main concern.

However, 1.6.5 doesn't seem to make good use of both my (logical) CPU threads. Previous versions fared better in that regard.

Here is a comparison with a late build of ffdshow (rev1803_20080120_xxl), used on a high bitrate 720p x264 file.

http://img85.imageshack.us/img85/5127/core165xu2.jpg

Regards
S.


I had this on my todo to answer....

The likely cause for such a CPU condition started with the 1.6 release of CoreAVC NG (Next Generation) filter.

CoreAVC has frame based SMP and iirc ffmpeg is splitting the tasks at a lower level. In our case it could be several factors... 'frames' can produce an uneven preformance or the OS thread handling... but when CoreAVC is loaded it should start to use the other core at full load right away.

We will test this above internally by making a version that doesn't have "hints" for which cpu decoding thread it should use and see if there is a diff.

foxyshadis
8th February 2008, 07:34
foxy also said 2 to 200 hours, so some people do get speedy service, while sadly, what looks like more than a handful do not speedy service

That was my point. I'm not bagging specifically on core here, but ANYTIME you email support at any company, you're taking a chance that it's going to take hours or days to get a human answer, if ever. I'm a professional in another field, I deal with this, and even I forget to answer every email and request that comes my way. (Apologies to anyone who PMs me unanswered, btw, nothing personal.) I always prefer self-support options, since I might fix it myself long before support gets back to me. Five minutes beats five hours, you know?

Core is probably infinitely grateful that they had the foresight not to post a phone number on their web site. :p

And yes, I even have the icon there, but it never seems to help~ oh well~!

BetaBoy
8th February 2008, 08:25
We actually have two numbers on the sites to call.... and in about 2 weeks an 800 number for support and licensing questions.... but yes we agree that ppl want self serve options... this is what we are striving for. Not to get too OT... but we are also going the same route with CorePlayer, but with it (and for more obvious reasons) because of features like IM, Sharing, Purchasing we will have a more 'connected' approach, especially as we move outwards to platforms like the iPhone...

http://img405.imageshack.us/img405/4033/snap023225pr3.th.jpg (http://img405.imageshack.us/my.php?image=snap023225pr3.jpg)
and
http://img169.imageshack.us/img169/8582/snap023334mw1.th.jpg (http://img169.imageshack.us/my.php?image=snap023334mw1.jpg)

While those pics on the iPhone don't show the CoreAccount integration... in the next few milestones it will.

sbcale
8th February 2008, 20:25
Hello, I am trying to convert an IronMan trailer that is in h.264 to WMV using zambelli's wmcmd.vbs. Here is my graph and here is the resulting log from the encode that doesn't work.

Please help. I have tried using the Sonic h.264 decoder but it introduced green and purple blocky parts to the wmv.

:thanks:

http://scale.smugmug.com/photos/252189354_8bUYS-L.jpg

Microsoft (R) Windows Media Encoder Command Line Script Utility
Copyright (C) Microsoft Corporation. All rights reserved.

Warning: Encoder failed to retrieve duration attribute from source plug-in.
.

Warning: Encoder failed to retrieve source duration again.
Encode process might not continue or progress report may be inaccurate.



======== Encoding Completed ========

Audio :
Codec: Windows Media Audio 10 Professional
Expected bit rate: 384000 bps
Average bit rate: 384000 bps
Expected sample rate: 5859
Average sample rate: 5859
Dropped byte count: 0 bytes
Dropped sample rate: 0
Total bytes: 7151616 bytes

Video :
Codec: Windows Media Video 9 Advanced Profile
Average bit rate: 49408 bps
Expected fps: 24
Dropped frame count: 1
Total coded frames: 238
Average sample rate: 24.001
Dropped bytes: 39 bytes
Total bytes: 78468 bytes

Overall:
Encoding time: 18 seconds
Average bit rate: 433408 bps
File size: 7481135 bytes
File duration: 148.735 seconds

qyqgpower
9th February 2008, 07:48
First, thank you for adding support for MV out of specs, letting me play old buggy files without artifacts. But today I come up with serious artifacts when playback some m2ts files decrypted from BD.

http://www.image-load.eu/out.php/t23969_snapshot20080209142447.png (http://www.image-load.eu/out.php/i23969_snapshot20080209142447.png)

http://www.image-load.eu/out.php/t23970_snapshot20080209142602.png (http://www.image-load.eu/out.php/i23970_snapshot20080209142602.png)

I have made several tests:
CoreAVC 1.6.5.0 -> artifacts
CoreAVC 1.6.0.0 -> artifacts
ffdshow tryouts 080115 -> fine
ffdshow tryouts 080206 -> fine
Elecard -> fine
Cyberlink -> fine

so apparently it should be a CoreAVC issue.

here is a small logo clip, you can download it and reproduce the problem
http://www.live-share.com/files/304750/00001.m2ts.html

BetaBoy
9th February 2008, 08:35
Thx for the report.... we found this issue the other day and have already fixed it... its in cue for the next release.

ACrowley
10th February 2008, 09:43
@Momber ,I can report the same Issues.
CoreAVC 1.6.5 decoding doesnt use both Cores as as good as older Versions or ffdshow or Cyberlink.
The Core Usage is async.

Oh, and its not a DualCore Optimizer etc Problem here

CruNcher
10th February 2008, 10:58
@BetaBoy
http://cruncher.mufflastig.com/x264/webtest/h264-progressive-test.htm ;)

bob0r
10th February 2008, 15:24
TCPMP:
[-] Continue buffering when press pause.
[+] Easy double click on video for full screen.
[+] Video completely widescreen in full screen mode.

FLASH:
[+] Continue buffering when press pause.
[-] Video completely widescreen in full screen mode. (more like 4:3)

[-] Easy double click on video for full screen

Found the button :)

BetaBoy
10th February 2008, 17:02
@BetaBoy
http://cruncher.mufflastig.com/x264/webtest/h264-progressive-test.htm ;)

Nice.... again not too OT. But we are releasing our RTP/RTSP components into CPM and CPP on the 21st. Once thats out we will finish the progressive download work and alpha blending afterwards so i'll have a stand alone demo version for you to post like that.

BetaBoy
11th February 2008, 16:09
First, thank you for adding support for MV out of specs, letting me play old buggy files without artifacts. But today I come up with serious artifacts when playback some m2ts files decrypted from BD.

http://www.image-load.eu/out.php/t23969_snapshot20080209142447.png (http://www.image-load.eu/out.php/i23969_snapshot20080209142447.png)

http://www.image-load.eu/out.php/t23970_snapshot20080209142602.png (http://www.image-load.eu/out.php/i23970_snapshot20080209142602.png)

I have made several tests:
CoreAVC 1.6.5.0 -> artifacts
CoreAVC 1.6.0.0 -> artifacts
ffdshow tryouts 080115 -> fine
ffdshow tryouts 080206 -> fine
Elecard -> fine
Cyberlink -> fine

so apparently it should be a CoreAVC issue.

here is a small logo clip, you can download it and reproduce the problem
http://www.live-share.com/files/304750/00001.m2ts.html

We had a closer look at the file.... and there is something else going on.... can you pls tell us what was used to encode it... and more specifically...what build number. Upon looking at it is seems not to be spec compliant but we want to confirm this.

CruNcher
11th February 2008, 16:16
BetaBoy i doub't he knows with what this Blu-Ray was mastered (encoded) with ;)

BetaBoy
11th February 2008, 16:20
ok.... we see what the problem is now.... this is another file that has out of range Motion Vectors (even beyond the tolerence that we added). They mastered it this way? Wierd... I wonder what they used to encode it?

CruNcher
11th February 2008, 17:16
unless it's a X264 or something else Consumer transcode of course :D
But he clearly states I come up with serious artifacts when playback some m2ts files decrypted from BD.
so it was obviously a pro Encoder that did this then hehe hmm maybe Mainconcepts (aka Sonic Cinevision) or Cinemacrafts CC-HDe or some Hardware Encoder, tough i think almost impossible to find out without knowing what the Studio that created this normaly uses, you could call them tough and ask ;) :D

Dark Shikari
11th February 2008, 18:23
ok.... we see what the problem is now.... this is another file that has out of range Motion Vectors (even beyond the tolerence that we added). They mastered it this way? Wierd... I wonder what they used to encode it?I did not see this coming. Oh the irony that it turns out the biggest problem with out of range motion vectors is on Blu-Ray discs! :eek:

CruNcher
11th February 2008, 18:30
I would really like to test this stream on my G92 core but i can't get it :D live-share is so crapy slow here that it brakes up the download.

BetaBoy
11th February 2008, 19:09
I did not see this coming. Oh the irony that it turns out the biggest problem with out of range motion vectors is on Blu-Ray discs! :eek:

Don't jump the gun yet.... we have no info if this is BR disc or if its mainstream or not.

bob0r
11th February 2008, 19:29
I would really like to test this stream on my G92 core but i can't get it :D live-share is so crapy slow here that it brakes up the download.

Yeah, hehehe i put it in flashget and let it run all night, anticipating this problem, here is the solution:

http://files.x264.nl/00001.m2ts :)

BlackSun
11th February 2008, 20:18
CoreAVC interoperability problems list:
Sonic HD Demuxer (EVO) (Hardware Deinterlacing Detection Fails frames get droped)
Sonic MPEG Demultiplexer (EVO) (No Connection Possible)
Mainconcept Mpeg Demultiplexer (EVO) (No Connection Possible)
Arcsoft MPEG Demux (EVO) (No Connection Possible)

Practicly all of those Decoders from these Companies are interoperable to each others Splitter/Demulitplexer, only CoreAVC has major problems here.

Mainconcept Mpeg Demultiplexer:
Mainconcept H264 Decoder = OK
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK (old Mainconcept Decoder)
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Sonic HD Demuxer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = Hardware Deinterlacing Problems (frames skipped)

Sonic MPEG Demultiplexer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Arcsoft MPEG Demux:
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Cruncher, can you build a working graph in MPC, and send me text in Pin Info page for the demuxer output pin? (for each demuxers). Thanks.

Inventive Software
11th February 2008, 20:29
I did not see this coming. Oh the irony that it turns out the biggest problem with out of range motion vectors is on Blu-Ray discs! :eek:

+1. This is astonishing! :devil:

ChronoCross
12th February 2008, 02:05
I did not see this coming. Oh the irony that it turns out the biggest problem with out of range motion vectors is on Blu-Ray discs! :eek:

Once again the reason that standards need to be used.

BetaBoy
12th February 2008, 04:15
Point is we still know nothing about the file, if it was a Blu-Ray disc or not and what was used to encode it (we determined it was not x264)... yet assumptions are being made... -1.

Note that today we...
- Fixed: AVCHD M2TS blockiness
- Fixed: DS deinterlacing
- Fixed: INI for missing crop1088 and the value

We looked into the CPU core unbalanced issue and found that it is not caused by CoreAVC NG as we first thought but looks to be libcoreavc and an artifact of the windows scheduler... we'll continue to work on it.

We are also looking into a report by `md on a potential high FPS issue as it relates to CPU usage.

BlackSun
12th February 2008, 08:40
- Fixed: INI for missing crop1088 and the value


No that has already been fixed in the 1.6.5, I just forgot to commit the fix after doing the release :)

Inventive Software
12th February 2008, 08:53
No that has already been fixed in the 1.6.5, I just forgot to commit the fix after doing the release :)

Doh! :D

BlackSun
12th February 2008, 13:09
Doh! :D

Oh don't worry the fix was in the 1.6.5 :D

Momber
12th February 2008, 18:52
I had this on my todo to answer....

The likely cause for such a CPU condition started with the 1.6 release of CoreAVC NG (Next Generation) filter...

@BetaBoy: Thanks for the reply. I will follow further development with much interest.

S.

odditory
12th February 2008, 19:38
When is there going to be a CoreAVC ENCODER?

ADude
12th February 2008, 22:22
We looked into the CPU core unbalanced issue and found that it is not caused by CoreAVC NG as we first thought but looks to be libcoreavc and an artifact of the windows scheduler... we'll continue to work on it.
Please keep us posted on this one.

This could make a big difference in performance on dual core PCs...

Shinigami-Sama
12th February 2008, 23:08
When is there going to be a CoreAVC ENCODER?

when coreavc 2.0 comes out
so...
when pigs fly?

BetaBoy
13th February 2008, 05:42
/me notes to remind Shinigami-Sama to take pictures of our flying pigs then.

BetaBoy
13th February 2008, 05:50
Please keep us posted on this one.

This could make a big difference in performance on dual core PCs...

I'm not too sure of this... we have been testing the CPU load and even though its uneven, the performance (other then in high FPS case) seems to be about the same.

But give us a few days to continue to work on it... in the meantime Haali is looking into the directhshow pin issue.

ADude
13th February 2008, 06:58
I'm not too sure of this... we have been testing the CPU load and even though its uneven, the performance (other then in high FPS case) seems to be about the same.

But if the load on one core hits 100% at any point, then it is a problem.

Sure, if the total load is low enough that a single core is close to sufficient, then it won't matter.

The graphs posted earlier seemed to indicate that one of the cores was hardly being used at all...

Momber
13th February 2008, 17:22
The graphs posted earlier seemed to indicate that one of the cores was hardly being used at all...
True, but this may depend on the video stream, too. The graphs I posted earlier were captured during a fast-moving scene in a high bitrate 720p x264 re-encode.

Last night however, I tried Core 1.6.5 on a 1080i H.264 TV cap ("Contact" H.264, remuxed to mkv) and for the first time ever with my "antiquated" CPU I was able to watch such a cap smooth and stutter free without resorting to DXVA (Cyberlink).
Used Core, deblocking "skip always", deinterlacing "off", Overlay Mixer, YUY2. Zoom Player 5.00.

I'm fairly ecstatic about that, actually.

http://img227.imageshack.us/img227/4928/coreh2641080imf1.th.jpg (http://img227.imageshack.us/my.php?image=coreh2641080imf1.jpg)

As you can see, the load-balancing is better there. Always keeping in mind that my CPU only has "virtual" multithreading, as it's a P4 Prescott 3.0 GHz.

Greets
S.

Sasovics
13th February 2008, 17:49
Guys,

I must say the compatibility problem with AviSynth still persist even with the new version of CoreAVC 1.6.5

Still getting the annoying:

"CAVIStreamSynth: System exception - Access Violation at 0x0, reading from 0x0"


My graph is as follows:

Haali Splitter(EVO file) -> CoreAVC Video Decoder

Then my AVS script is as follows:

Code:

DirectShowSource("feature.grf",video=true,audio=false,fps=23.976,framecount=xxxx)
ConvertToYV12 ()

NOTE: I have no problem with above setup if I use the CoreAVC v1.5.0.1

Can you please guys try to focus little more on this issue too ? ... as I am not the only one complaining about this
, and unfortunately so far did not see any answer to this issue from CoreCodec guys :(

BetaBoy
13th February 2008, 23:37
Sasovics... I know its alot to keep up.... but this has been discussed several times over the past few pages and is planned to be fixed with the next release.

Sasovics
13th February 2008, 23:59
Sasovics... I know its alot to keep up.... but this has been discussed several times over the past few pages are will be fixed with the next release.

Thanks a lot BetaBoy. At least I know you are aware of this issue and are planning to fix it in the next release ;) Fair enough!

I can still use the 1.5.0.1 version in the meantime!

CruNcher
17th February 2008, 16:43
Point is we still know nothing about the file, if it was a Blu-Ray disc or not and what was used to encode it (we determined it was not x264)... yet assumptions are being made... -1.

Note that today we...
- Fixed: AVCHD M2TS blockiness
- Fixed: DS deinterlacing
- Fixed: INI for missing crop1088 and the value

We looked into the CPU core unbalanced issue and found that it is not caused by CoreAVC NG as we first thought but looks to be libcoreavc and an artifact of the windows scheduler... we'll continue to work on it.

We are also looking into a report by `md on a potential high FPS issue as it relates to CPU usage.


Betaboy does this means you fixed the problem of that sample, because i now tested it on my G92 core in Hardware Decoding and couldn't see any issues but the issue is clearly visible with CoreAVC especialy before that frame that's shown here you can see something even more strange Slice Decoding problems it seems also.

molitar
24th February 2008, 04:34
Question.. Is their any real purpose in CoreAVC when I now have an ATI 3870 video card? Since I now can run it in DXVA mode for x264 and use NO CPU USEAGE at all! It seems to me but I could be wrong their is no need for CoreAVC anymore until it supports Hardware GPU. I mean what advantages if any does CoreAVC have?

Dark Eiri
24th February 2008, 04:37
Well, I guess the 3870 cards have the same problem every other DXVA2 card has till now. It doesn't decode "out-specs" x264/H264, which happens to be 90% of the encodes out there.
So, yeah.

oddball
24th February 2008, 14:20
For it to decode it needs to be flagged with profile 4.1 and BluRay and HDDVD are. x264 is but only on a few encodes. Most people do not use it. Shame really. It makes no difference to size or quality.

Threedcoder
24th February 2008, 15:07
BetaBoy,

I see you work for CoreAVC. Well, I just spent my $7.95 to download the decoder only to discover it doesn't work with AviSynth. :) I see Sasovics has the same problem, only he has the older 1.5.0.1 version to fall back to.

However, I don't since I just purchased. Is there anyway I can download an older version (specifically 1.5.0.1) from the CoreAVC site so that I can continue working until a fix for this AviSynth issue is fixed?

Thanks.

richardlynn
24th February 2008, 15:31
Betaboy,

Could you please explain the options in the version1.6.5,like deinterlacing and deblocking?I'm puzzled about the new options and can't find any instructions about them.

BetaBoy
24th February 2008, 15:59
It doesn't decode "out-specs" x264/H264, which happens to be 90% of the encodes out there.
So, yeah.


1) Where did you get the 90% info from? From our demographic studies you are way off... that is unless your talking about open source and consumer, but even then your % is not even close. In any case pls posts facts not speculations.
2) You are wrong again.... If you have not followed this thread or the last release (which at times is alot too follow) we support out of range MV. There was one post from one persons saying he had an issue with non-standard BV with MV, but never a) sent info on the sample b) never stated a title c) never stated what was used to encode it with. So without more info...

BetaBoy
24th February 2008, 16:00
Betaboy,

Could you please explain the options in the version1.6.5,like deinterlacing and deblocking?I'm puzzled about the new options and can't find any instructions about them.

I will update the first post in this thread with the 1.6.5 changes...

nm
24th February 2008, 16:32
1) Where did you get the 90% info from? From our demographic studies you are way off... that is unless your talking about open source and consumer, but even then your % is not even close. In any case pls posts facts not speculations.
2) You are wrong again.... If you have not followed this thread or the last release (which at times is alot too follow) we support out of range MV. There was one post from one persons saying he had an issue with non-standard BV with MV, but never a) sent info on the sample b) never stated a title c) never stated what was used to encode it with. So without more info...
I think that with "out-specs" Dark Eiri was referring to the Blu-ray/HD DVD levels that most x264 encodes don't follow, not to the out of range MV problem. If you read his post again, you may notice that he was arguing against HW decoding and in favor of CoreAVC ;)

Sasovics
24th February 2008, 19:32
BetaBoy,

Any ETA for the new release fixing our AviSynth problem ??

Shinigami-Sama
24th February 2008, 21:11
I think that with "out-specs" Dark Eiri was referring to the Blu-ray/HD DVD levels that most x264 encodes don't follow, not to the out of range MV problem. If you read his post again, you may notice that he was arguing against HW decoding and in favor of CoreAVC ;)

yeah I think he was talking about the level 4.1 profile error, when the buffer(VBV?) gets out of range

BetaBoy
24th February 2008, 23:22
BetaBoy,

Any ETA for the new release fixing our AviSynth problem ??

Next release.

BetaBoy
24th February 2008, 23:23
I think that with "out-specs" Dark Eiri was referring to the Blu-ray/HD DVD levels that most x264 encodes don't follow, not to the out of range MV problem. If you read his post again, you may notice that he was arguing against HW decoding and in favor of CoreAVC ;)

Re-read it... gotcha... thx ;-)

Dark Eiri
25th February 2008, 01:00
1) Where did you get the 90% info from? From our demographic studies you are way off... that is unless your talking about open source and consumer, but even then your % is not even close. In any case pls posts facts not speculations.
2) You are wrong again.... If you have not followed this thread or the last release (which at times is alot too follow) we support out of range MV. There was one post from one persons saying he had an issue with non-standard BV with MV, but never a) sent info on the sample b) never stated a title c) never stated what was used to encode it with. So without more info...

I was talking about the HD3870 card.

ADude
25th February 2008, 03:43
Any ETA for the new release fixing our AviSynth problem ??
Several weeks after the last AviSynth user gives up on reading this thread. ;)

Digiface
27th February 2008, 13:02
Should i use any deinterlacing with CoreAVC? I watch avc/h264 encoded videos with it. I mean is there any need to use deinterlacing?

Sharktooth
27th February 2008, 14:25
sorry but your question is a bit of a nonsense... what you mean?

Digiface
27th February 2008, 14:32
Ok, let me ask this way: Why i should use DI? Is there any advantages to use it? What if i don't use it?

nm
27th February 2008, 14:46
You should deinterlace only if the video is interlaced, which is not very likely unless you have a TV tuner card and receive H.264 channels.

Digiface
27th February 2008, 19:00
Ok. Thanks.

molitar
28th February 2008, 06:02
Just got a brand new 512MB Radeon 3870 video card.. Now I just want to know when can we expect GPU support? Currently I am not even using CoreAVC but MPC Home Cinema version with H264 DXVA.

HowlerX
28th February 2008, 07:51
You mean you are using a FREE media player with WORKING hardware-accelerated GPU decoding of h.264 content? I use MPC Home Cinema all the time. You mean to tell me that a few MONTHS since the last release of this great update to Media Player Classic, that the dude behind it has added GPU-decoding of h.264? Still free? All in a few months of work?!

Gee, maybe CoreAVC should hire the guy...

Rectal Prolapse
28th February 2008, 18:17
No please don't! Then MPC-HC DXVA will no longer be supported! :P :)

Besides, I like the idea of CoreAVC being software-only - h/w accel still has lots of issues with non-compliant streams.

Sharktooth
28th February 2008, 19:46
MPC HC doesnt do any h.264 decoding. it supports EVR and DXVA 2.0 interface.
in case you have a decoder which supports HW acceleration, MPC HC can "talk" to it. Just that.

MatMaul
28th February 2008, 20:09
MPC HC doesnt do any h.264 decoding. it supports EVR and DXVA 2.0 interface.
in case you have a decoder which supports HW acceleration, MPC HC can "talk" to it. Just that.
not anymore, casimir also wrote a DXVA decoder ;)

the last beta version can use hardware acceleration with its own internal filters if your card support full hardware decoding (VC1 and H264 for ATI cards, H264 only for nvidia cards)

Sharktooth
28th February 2008, 20:11
link?

EDIT: Nevermind, found it. it uses ffmpeg.

BetaBoy
29th February 2008, 00:47
Related to CoreAVC... we have just released CorePlayer Pro for Windows and OS X. It has CoreAVC Professional integrated into it as well as all our other decoders (CoreASP, CoreAAC v2.0, etc.).

This initial release is NOT for everyone... its not MPC, it not WPM, Zoom, PowerDVD and the like... no way even close. However like us, we think that you might find that CorePlayer Pro is likely the most efficient desktop media player out there and will continue to grow as the entire mobile and in this case desktop platform grows. So with that there are a few things to mention to for those that might want to give it a spin...

- Our new CoreAC3 filter will be added in next Thursdays version 3/6.
- We will add a filter properties access page in 2-3 releases
- CoreAVC Pro does not feature deinterlacing with this initial release
- CoreASP post processing is not included at this time
- The CoreTheque Media Library interface is changing by v1.2.5 to make it less 'mobile' like.
- No mouseovers support
- No subtitle support till a v1.3.x release
- We will add an external directshow interface in a later 1.2.x version
- We will add YouTube support (mobile) into CE/Windows Mobile/Win32/OS X in next Thursdays version 3/6... sure its mobile and the quality of many of those videos are not that great but hey, its not Flash video either!

We have however included our advanced networking stack udp/rtp/rtsp/sdp/unicast/multicast/http tunneling/rtcp (keep alive only) in the current release (in 2-3 releases we will also include our new UPNP additions with DLNA to follow soon afterwards). We have also tested our new streaming component against, Darwin, Live555, VLC, MS, Real, Shoutcast, and Icecast servers. However since this is our initial release we still have a few things that need to be added including proxy authentication.

I know I will be asked... Do we plan on releasing a Linux version? Short answer is yes. Our OEM version of CorePlayer Pro is already available on Linux using QT, Qtopia, GTK, CoreUI, and X11 just around the corner. (The big project for us on Linux atm is our new native CorePlayerAPI (similar to GStreamer but we include all the codecs). So how does this relate to our consumer version on Linux? Alot actually... as we will use the current Windows and OS X versions to integrate more features before choosing which UI to use for the public (although CoreUI and x11 are looking to be the winners there).

More info here:
http://www.corecodec.com/forums/index.php?topic=758.0

lexor
29th February 2008, 18:21
We have however included our advanced networking stack udp/rtp/rtsp/rtcp (keep alive only) in the current release and in 2-3 releases we will also include our new UPNP additions with DLNA to follow soon afterwards.

Is that DLNA two way like WMP11, which can serve content to the network or is it play back only?

BetaBoy
29th February 2008, 19:29
Yes, DLNA will be as well as our current UPNP stack in CP is both client and server.

popper
1st March 2008, 06:26
Related to CoreAVC... we have just released CorePlayer Pro for Windows and OS X. It has CoreAVC Professional integrated into it as well as all our other decoders (CoreASP, CoreAAC v2.0, etc.).

This initial release is NOT for everyone... its not MPC, it not WPM, Zoom, PowerDVD and the like... no way even close. However like us, we think that you might find that CorePlayer Pro is likely the most efficient desktop media player out there and will continue to grow as the entire mobile and in this case desktop platform grows. So with that there are a few things to mention to for those that might want to give it a spin...

- Our new CoreAC3 filter will be added in next Thursdays version 3/6.
- We will add a filter properties access page in 2-3 releases
- CoreAVC Pro does not feature deinterlacing with this initial release
- CoreASP post processing is not included at this time
- The CoreTheque Media Library interface is changing by v1.2.5 to make it less 'mobile' like.
- No mouseovers support
- No subtitle support till a v1.3.x release
- We will add an external directshow interface in a later 1.2.x version
- We will add YouTube support (mobile) into CE/Windows Mobile/Win32/OS X in next Thursdays version 3/6... sure its mobile and the quality of many of those videos are not that great but hey, its not Flash video either!

We have however included our advanced networking stack udp/rtp/rtsp/sdp/unicast/multicast/http tunneling/rtcp (keep alive only) in the current release (in 2-3 releases we will also include our new UPNP additions with DLNA to follow soon afterwards). We have also tested our new streaming component against, Darwin, Live555, VLC, MS, Real, Shoutcast, and Icecast servers. However since this is our initial release we still have a few things that need to be added including proxy authentication.

I know I will be asked... Do we plan on releasing a Linux version? Short answer is yes. Our OEM version of CorePlayer Pro is already available on Linux using QT, Qtopia, GTK, CoreUI, and X11 just around the corner. (The big project for us on Linux atm is our new native CorePlayerAPI (similar to GStreamer but we include all the codecs). So how does this relate to our consumer version on Linux? Alot actually... as we will use the current Windows and OS X versions to integrate more features before choosing which UI to use for the public (although CoreUI and x11 are looking to be the winners there).

More info here:
http://www.corecodec.com/forums/index.php?topic=758.0

very nice BetaBoy.

but you still dont compile for the PowerPC Linux do you, and so cant use it on the likes of the PPC based PS3 while running for instance Gentoo PPC linux (with Lu-Zero VLC etc Altivec optimisations) can we?

regarding the UI, id like to use rebol/View http://www.rebol.net/ to interface with any HTML/TCP:IP/UDP based IO


ideally, id like to see a combined Multicast tunnel and streaming video app in one unit (so as to bypass the worlds ISPs refusal to re-activate the upload bandwidth saving IP Multicast/IP broadcast on all their kit to and from the end users) with Multicast P2p DHT (bambooDHT) doing the hard interconnecting work, and rebol view scripting interfacing to it all and making your End user prefered GUI on what ever OS you like.

BetaBoy
1st March 2008, 06:53
Man popper... you went 20 levels passed what I thought anyone would reply to on this thread ;-)

Rebol.... nice concept I had studied that a few years ago and on how info is stored... not sure it would work with our current framework however.

PPC Linux? Not gonna happen ;-( Noting however that CPP on OS X is optimized for both Intel and Altivec.

Not to get to OT again... but We are working on a P2P component in CP that will obfuscate past ISP's blocks that works in conjunction with our 'Seek and Share' technology. This links individual CorePlayer/CoreAccount's... but this is not planned to be released till later this year.

bambooDHT is intresting especially when handling the hashes... and perms... but from a legal perspective I have read that it is flawed on liabilities. Plus its written is Java :-P

popper
1st March 2008, 07:45
LOL, only 20 levels , must try harder :)

well you must remember BB, iv been advocating PPC (thats PowerPC remember) Multicasting and tunnels to bypass the inept ISPs deactivation of generic Multicast for a long time (remember the old MBONE network).

but from a company and long term profits/Market share POV , it seems someone will take my points seriously one day (as the Unicast streaming grows and kills the net throughput)and make a finantial killing in these markets.

lets take the PPC based PS3, its now the defacto HD platform in the worlds homes, now that HD-DVD is being sidelined.

so theres a MASSIVE potential for a Codec/Video app vendor to make some good profits in that ever growing HD market.

you obviously have your reasons not to compile coreAVC and the other codecs and apps for that near untouched PPC market.

i hope that you do take my point about the PS3 as the HD platform of choice today for many people, as its cheap, can be software (firmware)re-programed with any Codec should the need arise, and many people want and are trying PPC Linux on it every day to expand its abilitys even more ?

next: the Multicast part and the most important and long needed ability in my mind at least.

and as for 'obfuscate past ISP's blocks' then why mess around from a commercial POV, just build for the long term future, and make an Encypted Muticasting tunnel and throw all the content through that client/server or P2p model from day one, sidestepping in one leap all your competitors.

its clear when you look at the likes of the UK BBC Unicast Iplayer reports coming out that the ISPs are not liking its bandwidth growth, not to mention your partners again, Unicast JOOST contibution to the masive one to one Unicast traffic.

its clear with the new Docsis3 (bronze) Multicast, and later this year, the (silver) Qos Multicast in the compulsary spec ,plus the BT 21 ST network also mandating Multicast as a generic option that even the worlds ISP will sometime soon ( but alas not soon enough)need to finally take advantage of Multicast capabilitys.

its always been my stance that some company or Open source vendor will one day make a very good name and profits for themselves if they are the first to bring the worlds end users this required Multicasting streaming video.

they need something thats easy to use, yet saves them lots of their precious upload bandwidth and still make it effective for the their sharing of their data streams, Multicast and (tempory, while the ISPs get their acts together, if ever)tunnels are the clear way forward ,all the better if its P2p Multicast DHT in some form.

Unicasting video is so last decade, Multicasting and tunnels to push it through if needs be over the interweb will save vast amounts of data throughput when more than a single user per stream is connected.

we are there on AVC/H264 codec, we are nearly there with the old Unicast P2p , we need the next step and thats multicast swarms.

as for Rebol View , as iv told you before ,go ask carl the creator of Rebol (and Amiga OS) if he's interested in working on a simple small experimental (commercial ?)collaberation, the new rebol R3 is in the process of being built, see the API, and you might find it to your commercial advantage if you simply ask him and his team.

we dont mind you making a profit betaBoy, as long as we get some real innovation and the things we want to pay for, its a real shame your not thinking of PPC compiling though, all those PS3s going begging for a good and effective codec base and related PPC apps.

guess its up to the likes of Lu_zero and the other Alivec coders, to continue the work of optimising the FFMpeg and other open code bases , AND thanks you very much lads for your dedication and commitment.

madshi
4th March 2008, 11:51
Our new CoreAC3 filter will be added in next Thursdays version 3/6.
Maybe slightly out of topic. But can you tell us a bit more about this CoreAC3 filter?

(1) Will it be available as a standalone DirectShow filter usable in e.g. MPC/ZoomPlayer etc?
(2) Will it support E-AC3? If yes is 7.1 decoding supported?
(3) Does it output the same data as Dolby's reference decoder?

Same questions about your CoreDTS filter:

(1) Will it be available as a standalone DirectShow filter usable in e.g. MPC/ZoomPlayer etc?
(2) Will it support DTS-HD High Resolution and DTS-HD Master Audio? If yes is 7.1 decoding supported?
(3) Does it output the same data as DTS' reference decoder?

Thanks! :)

Selur
4th March 2008, 20:07
Note that today we...
- Fixed: AVCHD M2TS blockiness
- Fixed: DS deinterlacing
- Fixed: INI for missing crop1088 and the value
Any ideas when a new version with this fixes will be released?
(a quick release for cebit would be nice)

BetaBoy
4th March 2008, 20:17
Any ideas when a new version with this fixes will be released?
(a quick release for cebit would be nice)

We'll know more on Sunday night as we are planning working on 1.7 some more over the weekend.

BetaBoy
4th March 2008, 20:22
(1) Will it be available as a standalone DirectShow filter usable in e.g. MPC/ZoomPlayer etc?
A: Later on yes

(2) Will it support E-AC3? If yes is 7.1 decoding supported?
A: Next phase adds support for "E".

(3) Does it output the same data as Dolby's reference decoder?
A: It has too ;-) but as with all our decoders we coded this frm scratch. Our initial testing shows it better in many ways compared liba52 as well as weak is some areas like volume levels, but there is still plenty of room for ASM optmizations and speed improvements.

I cannot comment on CoreDTS atm....

Also... we have listened to the feedback and it apparent that releasing AC3 without digital output support for suck for alot of ppl.... so we are going to push out adding AC3 now in Pro to support this feature as well as add our filter properties now rather then later.

dimzon
5th March 2008, 08:45
Who need CoreAC3/CoreDTS since we have free AC3Filter and ffdshow? I think speed is not so critical for AC3/DTS like for AVC.
So, I really doesn't understand why to waste your time for such development, sorry.

BetaBoy
5th March 2008, 09:35
Our decoders are internal towards our CorePlayer efforts atm.... but as I stated last year ago we do plan on seling 'all' our decoders as a directshow bundle. I agree however, that for many liba52/AC3Filter will be good enough.

I would disagree with the performance as a waste of time even as it relates to AC3/DTS (you ever see the spec for E-AC3?). Bundle the performance of Audio with Video and Player Platform and its the reason why CorePlayer Pro is at times 30% faster then VLC. Not caring about performance for even 'one' codec or component would not match our overall objectives.

dimzon
5th March 2008, 11:21
I would disagree with the performance as a waste of time even as it relates to AC3/DTS
I think AC3/DTS encoding doesn't eat more then 1-2 % comparing to 1080p AVC decoding. And I doesn't think You can improve AC3/DTS decoding performance more than 30%. In this case overall decoding speed gain (for 1080p AVC + AC3) will be (0.3 - 0.5 %). I believe such optimization is waste of time at all (sorry).

you ever see the spec for E-AC3?
By the way, I really don't understand current E-AC3 isteria. I believe AC3 @ 640kbps provide transparent sound...

Bundle the performance of Audio with Video and Player Platform and its the reason why CorePlayer Pro is at times 30% faster then VLC.
Dont' take me wrong, I prefer to spent my 50$ for better HW (by better CPU) and achieve same performance (or even better) than by your player. Cheap CoreAVC Basic/Pro is good compromise, but complete player for 50$ is not. Just think about it.

100$ - CPU AMD Athlon 64 X2 5000+ (ADA/ADO5000*) Socket AM2 OEM dual core
150$ - CPU AMD Athlon 64 X2 6000+ (ADA/ADX6000IAA6*) Socket AM2 OEM dual core

Inventive Software
5th March 2008, 12:46
Bear in mind, AFAIK CorePlayer is aimed at the portable devices market, PDAs and the like. So for them, a fast, clean player is essential. :)

dimzon
5th March 2008, 13:09
Bear in mind, AFAIK CorePlayer is aimed at the portable devices market, PDAs and the like. So for them, a fast, clean player is essential. :)
I'm talking about DirectShow bundle and Core Player for windows

CruNcher
5th March 2008, 14:05
dimzon how about users that want to use this on their Laptops that can't be updated neither GFX wise nor CPU i think Core Products are a nice solution and the price of every solution i saw today is fair but granted alot of work has still to go into CorePlayers current UI, currently it's the pure horror usability wise for a Desktop Application and also what they did with the Icons (giving icons that are used for years in other Windows UIs another meaning) is wrong. But else it is a nice coded App with a startup memory usage behaviour alot of Windows Players nowdays can dream of (including MPC), and there will also be a OpenSource version soon www.betaplayer.com wich for sure will be enhanced also in different directions like MPC :).

madshi
10th March 2008, 17:38
I would disagree with the performance as a waste of time even as it relates to AC3/DTS (you ever see the spec for E-AC3?). Bundle the performance of Audio with Video and Player Platform and its the reason why CorePlayer Pro is at times 30% faster then VLC. Not caring about performance for even 'one' codec or component would not match our overall objectives.
One good target for you might be DTS-HD Master Audio decoding. The Sonic DTS-HD decoder is *PAINFULLY* slow with decoding DTS-HD Master Audio. There you could really make a difference.

I'm talking about DirectShow bundle and Core Player for windows
But if they need to write the decoders for their portable platform, anyway, why not making them available on the PC platform, too? Shouldn't cost them much time and some people might value such a decoder collection. If you don't like the idea, nobody forces you to use/buy the DirectShow bundle... ;)

By the way, I really don't understand current E-AC3 isteria. I believe AC3 @ 640kbps provide transparent sound...
If you have a source which has an E-AC3 audio track, how are you planning to play it? It's not about whether E-AC3 or AC3 is better. It's just about being able to play the audio tracks in their original format. Of course you can transcode E-AC3 tracks to AC3. But you wouldn't have any benefit from doing that. Directly decoding the original audio format is simpler and better.

nm
12th March 2008, 22:53
But i don't see that use DXVA and i also interesting in full deinterlace support , maybe when these features are included , it would be more interesting.
Nowadays it's best to leave deinterlacing for the graphics card on Windows. DirectShow decoders just need to ask for it and I think CoreAVC has supported that for a long time already.

MPC Home Cinema should have working DXVA support for the latest GPU generations, so you don't necessarily need to buy filters for that. However, CoreAVC is still quite useful for H.264 streams that can't be properly decoded with current hardware solutions.

Yo
14th March 2008, 00:37
and there will also be a OpenSource version soon www.betaplayer.com

Is that a joke or what? What is your definition of "soon"? How many decades? Centuries?

When Coreplayer first came out (I forget now exactly when, but more than a year ago), the open-source Betaplayer was supposed to follow very soon. It has never been released. Go to the URL above, and it says nothing, other than the egotistical ad about "never be the same". No impending release date.

Also, when Coreplayer Mobile first came out, it was said, on the Corecodec forums, by Corecodec management, that a trial version would be released shortly. Also, more than a year later, no trial version has been released. (How difficult could it be, to slap a 30 day restriction on an app?) Even though, just about every other commercial mobile app (look at sites like handango.com, for instance) has a freely downloadable trial version, "try before you buy".

Why is it taking so long for a trial version of Coreplayer to be released? Could it be that they are afraid, that if people try it, they will decide NOT to buy it? I have read many reports on forums, of people who have bought Coreplayer, had problems with it, not liked it, and gone back to TCPMP (definitely an excellent product), or gone to a different commercial mobile media player. If Core has confidence in their products, why still no trial versions, of any of their products?

I'll stick with TCPMP.

molitar
14th March 2008, 00:52
My surprise is they have no GPU support yet someone can write a DXVA for MPC and make it work. Why can't Core get GPU support out now?

BetaBoy
14th March 2008, 13:53
Yo... keep it OT... If you goto the CoreCodec Forums you know about our plans for BP and why there is no trial available atm for CP but will be once we add all the mainstream features into it (we have said this since day 1). Same with CoreAVC... as soon as we get the next release out we finally consider it 'feature complete' (as we move towards our 2.0 release) for the mainstream and will then release a trial version... and 'yes' you can hold me to that.

CiNcH
14th March 2008, 13:53
My surprise is they have no GPU support yet someone can write a DXVA for MPC and make it work. Why can't Core get GPU support out now?

A standalone DirectShow filter is provided too. So use this one instead of CoreAVC...

Disabled
14th March 2008, 14:33
My surprise is they have no GPU support yet someone can write a DXVA for MPC and make it work. Why can't Core get GPU support out now?

MPC cant do DXVA with any card besides the very last generation of Nvidia (>8000 series, but NOT 8800 GTS(320/640)/GTX) and ATI cards (HD series). (Correct me if I'm missing something).

With those cards its pretty simple to do DXVA, as you just have to pass the bitstream to the GPU and thats it. And it only works with streams encoded to Level 4.1.

Even if Core would add GPU like MPC does, there would be no added reason to buy Core, as you would get exactly the same acceleration as with MPC.

(I hope this post made sense)

Yo
15th March 2008, 17:06
Yo... keep it OT... If you goto the CoreCodec Forums you know about our plans for BP and why there is no trial available atm for CP but will be once we add all the mainstream features into it (we have said this since day 1). Same with CoreAVC... as soon as we get the next release out we finally consider it 'feature complete' (as we move towards our 2.0 release) for the mainstream and will then release a trial version... and 'yes' you can hold me to that.

It's been a while since I've looked at the Corecodec forums, but why don't you give the reasons here--for the absence of the new Betaplayer, and the lack of a trial version for Coreplayer, both of which were promised to be available soon, well over a year ago.

I don't know why you would wait until you have "added all the mainstream features" to Coreplayer, before you have a trial version. If Coreplayer is not really ready yet, then shouldn't it be beta, available for free? However, since you are selling it commercially (and have done so for some time), shouldn't a trial version (time-limited, not crippled) be available now, of the current version, so that users can "try before they buy", as is available with EVERY OTHER COMMERCIAL MOBILE APP?

Why would you need to wait until "all features are added into CP", before releasing a trial version of the currently available commercial version? Software is always under development, it is never perfect, new features are always being added. But people should be able to try out your product RIGHT NOW, with its current features, to decide if they want to purchase it now or not.

Therefore, although I have been a longtime user of TCPMP, and the original Betaplayer before that, and highly admire and am appreciative of Picard's work on those projects (is he still with you?), and would have therefore been interested in your newer development of Coreplayer, I have not purchased it, because I would not want to do so without trying it first. I'm sure I am not alone in that, you have probably lost many potential sales, due to not having a trial version available. And apparently, from comments of people who did go ahead and purchase Coreplayer on blind faith, many regret that they did, some even regressing to TCPMP.

Perhaps, if Coreplayer really isn't ready yet, it should still be in beta, rather than selling it, while not providing a trial version (fearing that people who try it won't want to buy it).

molitar
15th March 2008, 17:32
MPC cant do DXVA with any card besides the very last generation of Nvidia (>8000 series, but NOT 8800 GTS(320/640)/GTX) and ATI cards (HD series). (Correct me if I'm missing something).

With those cards its pretty simple to do DXVA, as you just have to pass the bitstream to the GPU and thats it. And it only works with streams encoded to Level 4.1.

Even if Core would add GPU like MPC does, there would be no added reason to buy Core, as you would get exactly the same acceleration as with MPC.

(I hope this post made sense)

No GPU support does work with 8800 just fine too. Problem is most use ffdshow and you can't have any other filter working for DXVA. Now their would still be a reason to use CoreCodec if it had GPU support and that is because it has some leniancy built in so even if the format is not 100% proper it will still play the file.

BetaBoy
16th March 2008, 03:56
Yo... I'm not gonna waste my time on your continued OT rants and attacks... Bring some CoreAVC talk or move it over to the CC forums... Moderator anyone?

Inventive Software
16th March 2008, 08:37
If memory serves, there's a CoreAVC rant thread I started up a couple years ago....

Found it! About 18 months ago, I started this:

http://forum.doom9.org/showthread.php?t=118775

About a year since the last post. Not bad considering I started the thread and the issue at the time was activation! :D

If a mod wants to split non-topical / ranting / unhelpful posts to that thread, feel free, I'm sure CC employees would rather their tech support thread was populated with tech issues, and not moaning about no GPU support. :)

grumpy
16th March 2008, 10:27
Yo... keep it OT... If you goto the CoreCodec Forums you know about our plans for BP and why there is no trial available atm for CP but will be once we add all the mainstream features into it (we have said this since day 1). Same with CoreAVC... as soon as we get the next release out we finally consider it 'feature complete' (as we move towards our 2.0 release) for the mainstream and will then release a trial version... and 'yes' you can hold me to that.

could you point to that thread. I've been searching CC forum for 40 minutes and haven't come across the discussion your talking about.

bond
16th March 2008, 12:36
guys, be nice to each other and use the ranting thread!!! ;)

BetaBoy
16th March 2008, 12:59
Thx bond.... grumpy, on the CoreAVC discussions... the trial discussions are spread over the past few dozen pages. ATM... we just fixed some 'core' bug fixes for AVCHD and some .M2TS related ones... but as I stated the last big issue is the registry connectivity for pin output before we release the trail.

As far as anything else... go to CC and we can talk over there.

madshi
17th March 2008, 09:17
With those cards its pretty simple to do DXVA, as you just have to pass the bitstream to the GPU and thats it. And it only works with streams encoded to Level 4.1.
And the image quality is not as good as CoreAVC's software decoding, I've been told (haven't really compared myself yet, though). I hope that CoreAVC's hardware decoding support will be implemented in a way which doesn't change image quality compared to software decoding. I guess that maybe the hardware decoding of the latest ATI/NVidia cards have cut a few corners to make things easier? Don't know...

@BetaBoy, do you have an idea why image quality with ATI/NVidia's hardware decoding looks slightly different (worse?) than your software decoder? Do you think that you will be able to add hardware acceleration without losing any image quality?

Thanks!

Shinigami-Sama
17th March 2008, 09:24
And the image quality is not as good as CoreAVC's software decoding
lol whut?

a decoder will output the same image as the next
its just DXVA doesn't allow for post processing

nm
17th March 2008, 11:55
a decoder will output the same image as the next
its just DXVA doesn't allow for post processing
You mean inloop deblocking, since H.264 decoders rarely do any actual postprocessing? If a decoder doesn't do inloop deblocking, it will produce broken output, which is not the same as output from a proper H.264 decoder.

However, the latest GPU generations from NVIDIA and ATI should have no problems with deblocking, even through DXVA. On earlier GPUs, some decoders skipped deblocking because it slowed down hardware decoding too much (http://forum.doom9.org/showthread.php?p=1007475&highlight=cyberlink#post1007475) (either because of drivers or the hardware itself).

CruNcher
17th March 2008, 12:53
I think he means the Visually different Representation of the Colorimetry and Brightness Levels compared to other Decoders (without render dependency on either TV or PC Source VMR7/VMR9). (It seems (not sure here) to set it from the Streams VUI information and will always set it accordingly, you gonna never see compression artifacts in the luminance with CoreAVC but wrongly calibrated with another Decoder you will). You could say the Decoder doesn't need any calibration from the Renderer it calibrates the renderer to the source or itself to the renderer for optimal source presentation :)

Shinigami-Sama
17th March 2008, 20:20
You mean inloop deblocking, since H.264 decoders rarely do any actual postprocessing? If a decoder doesn't do inloop deblocking, it will produce broken output, which is not the same as output from a proper H.264 decoder.

However, the latest GPU generations from NVIDIA and ATI should have no problems with deblocking, even through DXVA. On earlier GPUs, some decoders skipped deblocking because it slowed down hardware decoding too much (http://forum.doom9.org/showthread.php?p=1007475&highlight=cyberlink#post1007475) (either because of drivers or the hardware itself).

mpc-hc uses full(bitstream) acceleration
so I'd assume the UVD does the in-loop deblocking, because I can't see them being able to brand it as an AVC accellerator without being able to decode properly

now DXVA2 sure, 'cause you can break up the decoding into different parts I can see parts being missed there

but not in bitstream mode

Jay Bee
18th March 2008, 00:37
because I can't see them being able to brand it as an AVC accellerator without being able to decode properly

That's exactly what they do, both ATI and Nvidia. Not only for cards that don't do deblocking, even for cards that don't do any acceleration at all (x1950 vc-1).

ADude
18th March 2008, 20:21
FYI, I just upgraded to Vista SP1 (downloaded from Microsoft Download Center) and no problems whatsoever. Definitely a lot faster, the lag in opening a folder has gone.

CoreAVC Professional 1.6.5 still working fine.

madshi
21st March 2008, 22:24
lol whut?

a decoder will output the same image as the next
its just DXVA doesn't allow for post processing
Get your facts straight before laughing at other people. You'll get 100% the same results only when you're talking about lossless compression (and bug free decoders, obviously). With lossy decoders it's absolutely usual that different decoders are outputting slightly different results. Granted, the differences are not very big, but there are differences. You can compare for yourself: Try different decoders, make screenshots and then run a hash (e.g. MD5) over the screenshots. You can even do it multiple times. The screenshots of the same decoder will always have the same hash. But screenshots of other decoders usually differ.

Dark Shikari
21st March 2008, 22:46
With lossy decoders it's absolutely usual that different decoders are outputting slightly different results.At least for H.264, any decoder that does so is in blatant violation of the standard and should not be used.

What you are saying is only true of standards that do not specify an exact DCT approximation, such as MPEG-4 ASP and MPEG-2.

Rectal Prolapse
22nd March 2008, 00:42
I would love to run CoreAVC (and other decoders) through an AVC compliance checker - there are several such tools available (for $$$) that can be used to evaluate decoder quality.

I recall reading somewhere that all AVC decoders have to have identical output compared to the official reference decoder, in order to be allowed the AVC label.

I wish it were true - it seems everyone gets away with making an AVC decoder that breaks the rules. :)

Ranguvar
22nd March 2008, 00:43
Lossy decoders?? Thank dog I have not run up against such a malformed piece of code yet ;)

me7
22nd March 2008, 04:34
I used the CoreCodec on my Vista SP1 system and I'm pleased with the decoding speed. Today I installed PowerDVD for Blu-Ray playback and now Windows Media Player uses the CyberLink decoder instead of CoreCodec. The CyberLink codec has issues with some of my mkv files and stutters extremely, so I'd like to deactivate it and use CoreCodec instead. The problem is I can't find any option to turn it off. Neither in WMP, nor in the codec settings. Google didn't come up with anything helpful either (only a tip for XP that doesn't work anymore).

Dark Shikari
22nd March 2008, 04:41
I used the CoreCodec on my Vista SP1 system and I'm pleased with the decoding speed. Today I installed PowerDVD for Blu-Ray playback and now Windows Media Player uses the CyberLink decoder instead of CoreCodec. The CyberLink codec has issues with some of my mkv files and stutters extremely, so I'd like to deactivate it and use CoreCodec instead. The problem is I can't find any option to turn it off. Neither in WMP, nor in the codec settings. Google didn't come up with anything helpful either (only a tip for XP that doesn't work anymore).1. Download the CCCP Insurgent (http://www.cccp-project.net/).

2. Run a Test Render on the problem file.

3. Find the problematic Cyberlink codec in the test render results.

4. Find the same codec on the list of installed DirectShow filters on your system.

5. Go to advanced mode, and unregister the problematic Cyberlink filter.

clsid
22nd March 2008, 15:28
Is it save to disable the Cyberlink filter without breaking PowerDVD?

The latest version of CoreAVC (1.6.5) has an option to increase its merit. Use that and WMP should start using CoreAVC again.

Dark Shikari
22nd March 2008, 15:29
Is it save to disable the Cyberlink filter without breaking PowerDVD?

The latest version of CoreAVC (1.6.5) has an option to increase its merit. Use that and WMP should start using CoreAVC again.That could work also; I didn't realize such an option had been added.

clsid
22nd March 2008, 15:55
Yes, I believe it was added specifically for this Cyberlink problem.

me7
22nd March 2008, 18:39
Is it save to disable the Cyberlink filter without breaking PowerDVD?

The latest version of CoreAVC (1.6.5) has an option to increase its merit. Use that and WMP should start using CoreAVC again.

I guess you mean the "Preferred decoder" setting? I just found out that it works, but only if you run the configurator in admin mode (right-click on app\run as admin). Yesterday I tried the same option in normal mode but nothing happened. I guess it's a bug that should be fixed in the next version.

clsid
22nd March 2008, 19:55
That setting simply requires administrator privileges for the registry changes that it needs to make.

ADude
23rd March 2008, 00:16
In Vista, you can't change anything unless you are in Administrator mode.

I have changed things in User mode, and then the next day, Vista decided that an evil unauthorized force had made the changes, and reverted them to their original values.

me7
23rd March 2008, 12:09
I am loged in as admin, but apps still need permission from you to change sysem critical data like the registry. Normally a UAC dialog comes up and asks you whether you want to allow the app to mess with your system.
In this case, no UAC dialog came up. The CoreCodec configurator didn't ask for the admin's permission, it just ignored the setting I've set. I had to give it my permission manually via "right-click\run as admin". I'd say this is a feature that roughly 1% of windows users are aware of, so something needs to be done here.

madshi
24th March 2008, 17:37
At least for H.264, any decoder that does so is in blatant violation of the standard and should not be used.

What you are saying is only true of standards that do not specify an exact DCT approximation, such as MPEG-4 ASP and MPEG-2.
Ok, I didn't know that the h264 specification was stricter than other comparable specifictions. Thanks for the information.

However, I read in another thread (on another forum, IIRC) that people ran an MD5 over screenshots produced by different h264 decoders and the MD5 was different with each decoder - except for those decoders which were based on the same source code.

Lossy decoders?? Thank dog I have not run up against such a malformed piece of code yet ;)
So why do the open source AC3 decoders output different results compared to what Dolby reference AC3 decoders output? Same with DTS. Also the MPEG2 decoders output different results. As I said, the differences are not very big, but they are there.

DigitalDeviant
24th March 2008, 19:03
Ok, I didn't know that the h264 specification was stricter than other comparable specifictions. Thanks for the information.

However, I read in another thread (on another forum, IIRC) that people ran an MD5 over screenshots produced by different h264 decoders and the MD5 was different with each decoder - except for those decoders which were based on the same source code.

Probably the decoders were doing some sort of postprocessing, like TV->PC levels conversion.

ADude
25th March 2008, 01:18
I am loged in as admin, but apps still need permission from you to change sysem critical data like the registry. Normally a UAC dialog comes up and asks you whether you want to allow the app to mess with your system.
In this case, no UAC dialog came up. The CoreCodec configurator didn't ask for the admin's permission, it just ignored the setting I've set. I had to give it my permission manually via "right-click\run as admin". I'd say this is a feature that roughly 1% of windows users are aware of, so something needs to be done here.

Yes, I find that Vista requires applications to be aware of new methods, and to use them in installation. For example, Zoom Player never really grasped that or researched it (the developer did not even acquire Vista), and that was one of the reasons I changed to Media Player Classic - Home Cinema.

By the way, in Vista, when you are running an account that quote "is an Administrator", you still don't have full priveleges - do a web search for Vista Super Administrator.

BetaBoy
3rd April 2008, 01:37
All.... a quick update.... we are on QA for CoreAVC 1.7 atm and found a few small bugs and one major bug (related to the NG Filter SMP code) that testers have come across.

I'll keep everyone posted on where were at later in the week.

Sasovics
3rd April 2008, 01:43
Is 1.7 version fixing our long-lasting AviSynth compatibility problem ?

BetaBoy
3rd April 2008, 03:05
Yes... all pin connector bugs are fixed... we also found a bug in Avisynth that was related to CoreAVC connecting to it. We were however able to create a work around for it in 1.7... and we sent off a report to them about it.

BetaBoy
4th April 2008, 07:37
Major bug fixed.... also SMP core load distribution should be improved against i-frames.... moving on to the last of the smaller issues.

chrislynch
4th April 2008, 19:19
Major bug fixed.... also SMP core load distribution should be improved against i-frames.... moving on to the last of the smaller issues.

I am eagerly waiting for this release! :thanks:

Ice =A=
5th April 2008, 13:35
Thanks for the info!

Sasovics
14th April 2008, 20:40
Any ETA for releasing 1.7 version ? Can't wait to have it ;)

HowlerX
14th April 2008, 22:55
Please don't give an ETA. This thread is long enough. Don't wanna read useless posts regarding long, long overdue ETAs.

Just wait till it's done.

Disabled
16th April 2008, 17:59
1.7 is out:
CoreAVC H.264 Video Codec - Version 1.7.0.0 (20080415)
- Add: Support for Mainconcept and ArcSoft demuxers.
- Add: Workaround for broken DirectShowSource in AviSynth
- Add: Installer improved
- Add: Better multiple CPUs/Cores balance
- Fix: Others internal fixes

Haali Media Splitter (20080329)
- Add: Added support for muxing FLAC audio as A_FLAC to the muxer
- Add: Added support for parsing recovery point SEIs in H.264 streams in PS and TS containers
- Add: Added an automatic colorspace selection option to the renderer, it switches to BT.709 when video width is 1024 or more
- Fix: Added a workaround for some broken matroska files with trailing 0s
- Fix: Disabled the PS3 upscaler since it doesn't work properly on all hardware
- Fix: Fixed handling of VC-1 with changing sequence headers in PS and TS containers
- Fix: Fixed VC-1 aspect ratio detection
- Fix: Added support for PCM audio with 7 and 8 channels
- Fix: Fixed channel mapping for PCM in M2TS container
- Fix: Added a workaround to make MS VC-1 DMO decoder accept formats with included aspect

ratio information
- Fix: Fixed the misbehaving Apply button in color planes shift dialog in the renderer

BlackSun
16th April 2008, 18:00
omg, you guys are too fast for me !

BetaBoy
16th April 2008, 18:00
We have just released our Milestone build for CoreAVC 1.7 Standard and Professional Editions. This is by far our fastest, and most polished version to date. We are sending update notifications now.

We have fixed all reported issues here at D9 but we are also aware of 'other' things we are looking into now. The biggest of which is in Vista the 'preferred decoder' does not register properly but can be manually set if the config panel is allowed to be run by an admin.

Pls post anything else you find... Thanx!

BetaBoy
16th April 2008, 18:05
Also... as promised with 1.7 we have now posted the CoreAVC Professional Edition 14 day Trial Version @ http://www.coreavc.com

Jay Bee
16th April 2008, 18:18
I'll save my energy, no opinion, just facts:

-EVR on Win XP doesn't work. The image freezes and has the wrong Aspect Ratio. Worked in v1.5. Seems to work when YV12 is disabled.

-The field order is wrong when hardware deinterlacing is on, no matter which renderer (do I really need to link to the sample clips at x264.nl AGAIN?).

-Some videos (Blu Ray remuxes) that are smooth with v1.5 stutter severely.

-This is the third release in about six months that is so broken that I have to go back to an older version.

juGGaKNot
16th April 2008, 18:31
Also... as promised with 1.7 we have now posted the CoreAVC Professional Edition 14 day Trial Version @ http://www.coreavc.com

will give it a try ! THANKS.

Cheers.

juGGaKNot.

BetaBoy
16th April 2008, 19:01
Jay Bee... I'm not go into this again... EVR on XP is a hack.... and field order tests fine here but we'll look into it. As far as your BR 'remux'... Do you have a sample?

ADude
16th April 2008, 19:18
1.7 working fine on 1080p mkv files, two cores look very well balanced, thanks !

ADude
16th April 2008, 19:22
Since CoreAVC installs Haali Splitter, I thought I would ask here:

Is there any reason not to let Haali Splitter do AVI as well ?

CiNcH
16th April 2008, 19:23
Tried the trial with DVBViewer. Hardware deinterlacing operates at 50fps but VMR9 shows a jitter of over 10ms which manifests itself in clearly visible stuttering.

bob0r
16th April 2008, 19:36
Tried the trial with DVBViewer. Hardware deinterlacing operates at 50fps but VMR9 shows a jitter of over 10ms which manifests itself in clearly visible stuttering.

Dvbviewer coder was unable to reproduce our problems, maybe BlackSun or BetaBoy should contact him again, and give him coreavc 1.7 so he can try again and update dvbviewer.

Since i got my Quad core, coreavc works flawlessly with dvbviewer, ALL H.264 satellite channels (http://en.kingofsat.net/hdtv.php) work perfectly, so yeah issues issues issues, if only EVERYONE would work with FIXED standards, all our lives would be easier :D

CiNcH
16th April 2008, 20:06
CPU usage is not much below the MainConcept which requires quite some CPU time...

http://members.inode.at/762450/coreavc/coreavc_dvbv.jpg

MainConcept runs with 0ms jitter (also hardware deinterlacing).

Jay Bee
16th April 2008, 20:29
Tried the trial with DVBViewer. Hardware deinterlacing operates at 50fps but VMR9 shows a jitter of over 10ms which manifests itself in clearly visible stuttering.

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

gbates
16th April 2008, 22:27
"Download limit reached !" when trying to download trial version...

BlackSun
16th April 2008, 22:29
That's because you excedeed the download limit. Maybe you have used a download accelerator.

gbates
16th April 2008, 22:56
No download accelerators, I'm using Opera and I get this message after first click on download link...

BlackSun
16th April 2008, 23:52
Please pm the download url you got and I'll check if there is a bug.

BlackSun
17th April 2008, 10:03
Thanks for the two reports about the trial, the bug is fixed. You can ask for the trial again and you will get a working link :)

CiNcH
17th April 2008, 16:47
DVBViewer (VMR-Fix off) and BOB-Deinterlacing within CoreAVC mostly results in a framerate of about 40 fps. The renderer however does not skip frames. The DVB Source Filter frequently triggers a graph rebuild due to buffer overflow.

May this be caused by the nature of the DVBViewer graph being a push scenario instead of a pull scenario?

BetaBoy
17th April 2008, 17:42
iirc Haali had pointed out a limitation of DVBV to the developer that he needed to work on. I'll ping him on it.

ACrowley
17th April 2008, 18:05
@Betaboy

I have no CoreAVC 1.7 upgrade Email ?
Where can i download it?

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.

lexor
4th May 2008, 14:26
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!

clsid
4th May 2008, 15:34
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.

clsid
4th May 2008, 17:26
No, FLV is a whole different container than MP4. Hence my question.

wyrd
4th May 2008, 21:33
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.

wyrd
5th May 2008, 02:56
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

MfA
5th May 2008, 05:30
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).

MfA
5th May 2008, 16:48
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.

nm
6th May 2008, 08:56
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

Dark Shikari
15th May 2008, 07:59
Anyone want to have a shot at comparing to see if DivX H.264 claims of speed to their new decoder are correct on their page? As they are boasting they beat CoreAVC. My initial tests in a small comparision says otherwise.
See: http://labs.divx.com/ProjectRemouladeIt'll be interesting to see the actual speed values here in real tests. One thing I'm noticing is that their assembly code is drastically worse than CoreAVC's, at least at first glance (see my analysis comments in their thread).

CiNcH
16th May 2008, 12:21
I have just realized that jitter is not just high with DVBViewer:

http://members.inode.at/762450/coreavc/jitter.jpg

Same graph with MainConcept and VMR Deinterlacing (or hardware deinterlacing) produces 0 jitter.

TheShadowRunner
16th May 2008, 16:22
hey all, I have an issue with the "Output level" colorspace set to "Autodetect" and Directvobsub.
I use VMR9.
When I disable Directvobsub, all is fine, CoreAVC detects VMR9 and sets PC levels. Autodect works.
If I insert DirecvobSub in the graph, it breaks Autodetect. Although the renderer is VMR9 alright, CoreAVC sets TV levels.

I'm guessing CoreAVC works as follows; if its "video out pin" is directly connected to VMR renderders, Autodect sets PC levels. In any other case it uses TV levels.
But inserting Directvobsub breaks this behavior even if the renderer is VMR, it will set TV levels.

I hope this can be fixed in order to be able to use "Autodetect" at all times. (when using Vobsub or not)

Also, there is an issue with CoreAVC 1.7 when changing resolutions.
I use Reclock and VMR9.
With CoreAVC 1.6.5, no problem; when Reclock changes resolution, the video resumes just fine.
With 1.7, after Reclock resolution change, the display is flashing/full of artifacts and the only way to correct it is to fake a change in the CoreAVC property page and hit "apply". Very odd.
Again, no problem with previous CoreAVC versions.
See you,

TSR

BetaBoy
17th May 2008, 22:24
I need to address something.... and this is a direct response to DivX's Project Remoulade speed claims at CoreAVC with the beta 1 release of their H.264 decoder as well as the current challenges to DivX's claims in their Project Remoulade thread, so I think it best to be stated here.

Over the past few years Doom9 himself has done many codec comparisons and the best thing as he has learned from his mistakes in going from one codec comparison to the next is to include as many details as possible (yes it was mostly encoding related but it is still relevant). As DivX stated in their Labs post they have decided it was best to directly compare CoreAVC's speed to that of their new decoder. Now that is nothing short of 'great' for us and the community at large as I have already stated, but my point of this post is that such claims were done in more of a 'PR' context, and only explains about half of the details of why they claim it is faster and that it simply falls short of providing true details (aside from the 8 core support) and has only left more confusion here at D9 and in general.

ATM we will not respond to such speed claims (other then what I stated that it being slower against all my local QA content.) till later Beta stages of their decoder release leading to the final release. But in the end as it matures with each release (and it will) if its better, great! It will be an awesome challenge for us in our current CoreAVC 2.0 development (and even upcoming 1.8.x and 1.9.x releases).

So DivX post more info next time, not for us... but for the community to verify and decide for themselves.

CiNcH
17th May 2008, 23:15
I for my part will not take the decoder using 1% less CPU time, but the decoder that delivers a well deinterlaced and judder free image...

bob0r
17th May 2008, 23:33
@BetaBoy

They basically say their decoder can do more than 4 cores (threads), maybe you should take a hint from that.

BetaBoy
18th May 2008, 00:17
@BetaBoy

They basically say their decoder can do more than 4 cores (threads), maybe you should take a hint from that.

I'm not referring to that but hint taken and we already need to know what to do for 2.0.

BetaBoy
18th May 2008, 00:19
I for my part will not take the decoder using 1% less CPU time, but the decoder that delivers a well deinterlaced and judder free image...

CiNcH I noted your issue but there were still outstanding issues with DVBViewer we had addressed with developers last time I checked with Haali.

Shinigami-Sama
18th May 2008, 00:33
CiNcH I noted your issue but there were still outstanding issues with DVBViewer we had addressed with developers last time I checked with Haali.

maybe its time for CoreDBV?
lord knows theres problems with it everywhere in this forum, and dozens of work arounds...

BetaBoy
18th May 2008, 00:41
maybe its time for CoreDBV?
lord knows theres problems with it everywhere in this forum, and dozens of work arounds...

lol... we squashed that idea about 3 years ago ;-) on work arounds we added a few for DVBViewer to the last 2 releases. On ping the guys here to get a update on where we are atm.

TheShadowRunner
18th May 2008, 01:24
being ignored sucks.

bob0r
18th May 2008, 11:55
being ignored sucks.

Thats a generic core trademark :)
Anyways, if you put some reproducable files online in a zip file or something, we can reproduce and confirm the problem.

However the AUTO option should be taken very lightly i think, its best to set your own levels.

Most bluray/hddvd/satellite(some are pc level) are TV level.
On my DELL LCD screen output is PC level.
So i simply set input:TV ouput:PC

But i still agree bugs are bugs and being ignored is horribly annoying!

BetaBoy
18th May 2008, 13:01
Note.... _nothing_ is ignored we add any potential bugs posted here and the ones that get emailed to us.

CiNcH
18th May 2008, 13:04
CiNcH I noted your issue but there were still outstanding issues with DVBViewer we had addressed with developers last time I checked with Haali.

Well, latest issue does not seem to be related to DVBViewer at all but more to VMR deinterlacing (hardware / DirectShow deinterlacing or whatever you want to call it). I have the same jitter with GraphStudio/GraphEdit when using Haali Media Splitter.

But it is quite cool you are addressing DVBViewer issues. Hope you inform DVBViewer developers about issues that you have found...

Ice =A=
18th May 2008, 17:00
bob0r: They basically say their decoder can do more than 4 cores (threads), maybe you should take a hint from that. I really can see no sense in supporting more than 4 cores.
Will there ever be an 8 core cpu that is too slow to decode even the most demanding videos with "just" 4 of its cores?!? I hardly doubt that...

LoRd_MuldeR
18th May 2008, 17:39
I really can see no sense in supporting more than 4 cores.
Will there ever be an 8 core cpu that is too slow to decode even the most demanding videos with "just" 4 of its cores?!? I hardly doubt that...

A few years ago, when everybody was watching SD video, nobody would have expected that you need more than one core for video playback.
Then HD video was born and new complex video formats (e.g. H.264) became popular. Suddenly 2 or even 4 cores are needed for smooth video playback!
You can expect the same to happen again: At the moment we use 720p or 1080p, but what if 2k or 4k resolutions become popular?
Also keep in mind that future CPU's won't get improved performance from higher clock speed in first case, but from higher number of cores...

IgorC
18th May 2008, 17:52
Then HD video was born and new complex video formats (e.g. H.264) became popular. Suddenly 2 or even 4 cores are needed for smooth video playback!
Can you show 1080p H.264 (up to 50 mbit) content that would stutter on decent dual core? I have a very low budget dual core and every 1080p video plays fine on it.


You can expect the same to happen again: At the moment we use 720p or 1080p, but what if 2k or 4k resolutions become popular?
Also keep in mind that future CPU's won't get improved performance from higher clock speed in first case, but from higher number of cores...
2k 4k are still very futuristic. I don't see it coming at least for 2 years.

LoRd_MuldeR
18th May 2008, 18:02
Can you show 1080p H.264 (up to 50 mbit) content that would stutter on decent dual core? I have a very low budget dual core and every 1080p video plays fine on it.

CABAC plus enough Bitrate should be able to push every CPU to it's limits :p

2k 4k are still very futuristic. I don't see it coming at least for 2 years.

Well, 1080p was "futuristic" too only a few years ago...

lexor
18th May 2008, 18:13
CABAC plus enough Bitrate should be able to push every CPU to it's limits :p
bleh, P4 decoded HD DVD perfectly fine in the first gen players. So for practical purposes, CABAC and enough bitrate is not a problem.


Well, 1080p was "futuristic" too only a few years ago...
Yes, 10y+ at least for 2k and up, Igor was definitely way too optimistic. Still to require higher number of cores would suggest that each core isn't going to noticeably increase in performance, which I think is highly unlikely.

Manao
18th May 2008, 19:37
1080p was futuristics a few years back, but HD DVD / bluray were already planned. Nothing equivalent to those two are planned for 4K yet. (2K == 1080p, btw).

LoRd_MuldeR
18th May 2008, 19:48
1080p was futuristics a few years back, but HD DVD / bluray were already planned. Nothing equivalent to those two are planned for 4K yet. (2K == 1080p, btw).

Not exactly :p

AR 4K 2K
1.66 4096 × 2464 2048 × 1232
1.78 4096 × 2300 2048 × 1150
1.85 4096 × 2212 2048 × 1106

And AFAIK they already use it in cinmea production, because it's they only way to keep nearly the same amount of information as "classical" film cameras do...

DigitalDeviant
18th May 2008, 20:14
1080p was futuristics a few years back, but HD DVD / bluray were already planned. Nothing equivalent to those two are planned for 4K yet. (2K == 1080p, btw).

Nothing? (http://www.nhk.or.jp/digital/en/super_hi/index.html)

Manao
18th May 2008, 20:27
LoRd_MuldeR : 2K and 1080p are close enough. As for 4K, it's barely used in the cinema yet, so it won't come anytime soon for us.
DigitalDeviant : I'm more talking about format accessible to average Joe. SHD isn't for tomorrow (NHK themselves doesn't expect it before 2018~2020)

HDDVD/Bluray came roughly 12 years after DVD. Unless Bluray utterly fails commercially, I don't think the next standard will come before 6 to 10 years. Airwave numeric TV will stop at 1080i because of bandwidth issue, so will satellite. I'm less sure about cable/IPTV, but I don't think there'll be a market for >1080p TV only for cable/iptv. So I really don't expect anything over 1080 for us anytime soon.

ADude
18th May 2008, 20:57
I don't expect anything over 1080 ever.

Note that MP3 players have significantly poorer sound quality than the preceding generation - CD players.

Many surveys show that the average HD TV owner thinks that stretched, upconverted SD progamming is "HD". The group of people who have not yet upgraded to HD, have (as a whole) an even lower quality standard.

And, studies have shown that with the normal sitting distance from the home TV, the human eye cannot discern resolution greater than 720p with the most common HD TV screen sizes (32-50 inches).

So, 2k is not ever going to happen.

Manao
18th May 2008, 21:08
Sorry for OT...Note that MP3 players have significantly poorer sound quality than the preceding generation - CD players.Strange analogy. The players got more portable, able to store more music, which was what people wanted. Quality degradation came as an inevitable but acceptable tradeoff.Many surveys show that the average HD TV owner thinks that stretched, upconverted SD progamming is "HD". The group of people who have not yet upgraded to HD, have (as a whole) an even lower quality standard.Sadly, that is mostly true. Though i hope they'll see the difference when actual HD programs become mainstream and their eyes get used to it.

LoRd_MuldeR
18th May 2008, 21:20
So, 2k is not ever going to happen.
Wait until the market is saturated with Blue Ray players and "Full HD" screens in a few years. They will come up with a new "technology" for sure :rolleyes:

I guess it will be 4K, since 2K would be too close to 1080p. Whether it will still be delivered on optical media is a different question ...

Dreassica
18th May 2008, 21:29
U would need 80 inch screens to even see the difference anymore, as to see 1080p u already need 50"to see a real difference. I doubt many people will ever want a 80 incher in their living room.

LoRd_MuldeR
18th May 2008, 21:47
U would need 80 inch screens to even see the difference anymore, as to see 1080p u already need 50"to see a real difference. I doubt many people will ever want a 80 incher in their living room.
Maybe a canvas and a beamer then? Takes almost no room, unless you unroll the canvas. And it's bigger than any screen...

(BTW: This is really getting off-topic ^^)

Revgen
19th May 2008, 07:59
I have a 24 inch screen on my computer, and I absoutely see the difference between 720p and 1080i. I can even see a difference in 1080i content even when my desktop resolution is at 1200x800.

Sorry, but there is a difference. At least to my eyes anyway.

TEB
19th May 2008, 11:17
Its all about viewing distance. Our eyes need to be able to differentiate the different pixels..
There are alot of discussions on this on avsforum and other equivilent forums regarding how close one need to sit vs. screen size.
Other factors like correct 24p handelig, high contrast, deinterlacing is at large the main factos to what customer see as the "wow" effect..

just my 2cents..

smok3
19th May 2008, 12:34
if you look at red, then it appears that 4k is allready here;
http://www.red.com/

Ice =A=
19th May 2008, 12:45
And, studies have shown that with the normal sitting distance from the home TV, the human eye cannot discern resolution greater than 720p with the most common HD TV screen sizes (32-50 inches).
So, 2k is not ever going to happen. Exactly what I was thinking.
So there are only two options left: Decreasing the distance to the TV, which obviously makes not much sense. Or increasing the screen size, which is very limited in "normal" living rooms.

smok3
19th May 2008, 15:21
i can certainly imagine screens being sold/cut by meters to fit on certain wall in the not-so-near future, i guess that would be the time to include DPI as marketing :)

so what you are saying is that for example 16:9 82 cm diagonal screen is nonsense for the full-HD res?

the_corona
19th May 2008, 15:41
Kinda getting off-topic, no? :-)

Anyways, in their update Divx say that they think the problem stems from a diff. color-space being used and that the "problem" would be resolved swiftly. I'm wondering, no, hoping that CoreAVC will respond quickly as well and we consumers are in for a treat :-) Any statement from CoreAVC regarding this matter?

ChronoCross
19th May 2008, 18:46
Kinda getting off-topic, no? :-)

Anyways, in their update Divx say that they think the problem stems from a diff. color-space being used and that the "problem" would be resolved swiftly. I'm wondering, no, hoping that CoreAVC will respond quickly as well and we consumers are in for a treat :-) Any statement from CoreAVC regarding this matter?

cept if you read the divx thread even when coreavc outputs the same colorspace Coreavc is still beating Divx. Most people are seeing that it's slower than even ffdshow

MatMaul
20th May 2008, 22:53
hey !
any chance to have NV12 as output format ?
I have chroma upsampling problems with YV12 and the VMR9 renderer, and NV12 solved them.

CiNcH
8th June 2008, 15:39
0 jitter with CoreAVC Trial + DVBViewer + ORF 1 HD (720p50). Seems they can work together. As I pointed out, problem is with interlaced content, where output is jittery.

CiNcH
8th June 2008, 18:49
Watching Austria - Croatia in 720p50 now. CoreAVC seems to introduce some kind of aliasing effect at the white lines of the soccer/football pitch, which is pretty weird for progressive material. Deinterlacing is explicitly set to 'None'. MainConcept is fine..

[EDIT]
Due to the color space, forced it to YUY2 now.

Seraphic-
8th June 2008, 19:53
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.

BetaBoy, will the upcoming CoreAVC Encoders support High 4:2:2 Profile 480p/720p/1080p encoding?
And what price are we talking about for the encoder software?

IgorC
9th June 2008, 02:40
Sorry for offtopic


Note that MP3 players have significantly poorer sound quality than the preceding generation - CD players.

The situation is totally oposite. Good mp3 encoder is transparent on midle/high bitrate.

LAME at -V 5 (135 kbits) had 4.6/5 points in public test.
-V 2 (192 kbits) officialy transparent even on good Hi Fi system.

People wouldn't accept mp3 if it had low quality.

Shinigami-Sama
9th June 2008, 07:53
People wouldn't accept mp3 if it had low quality.

you don;t know many people then
I've seen many people that are amazed when they hear an mp3 that even sounds like fmradio...

BetaBoy
9th June 2008, 10:05
Kinda getting off-topic, no? :-)

Anyways, in their update Divx say that they think the problem stems from a diff. color-space being used and that the "problem" would be resolved swiftly. I'm wondering, no, hoping that CoreAVC will respond quickly as well and we consumers are in for a treat :-) Any statement from CoreAVC regarding this matter?

Well... we have a few more updates to release over the next few months before we publish our 2.0 Alpha.

On the OT discussions.... I am enjoying them, really ;-)

deekey777
9th June 2008, 11:33
Watching Austria - Croatia in 720p50 now. CoreAVC seems to introduce some kind of aliasing effect at the white lines of the soccer/football pitch, which is pretty weird for progressive material. Deinterlacing is explicitly set to 'None'. MainConcept is fine..

[EDIT]
Due to the color space, forced it to YUY2 now.

Actually all games are produced in 1080i50 by UEFA, HD Suisse and ORF HD (and nl1 HD) do downscale them to 720p50.

News in Geman: http://www.heise.de/newsticker/Fussball-EM-Gewaehltes-HDTV-Ausstrahlungsformat-bringt-nur-Nachteile--/meldung/108493

CiNcH
9th June 2008, 11:39
Actually all games are produced in 1080i50 by UEFA, HD Suisse and ORF HD (and nl1 HD) do downscale them to 720p50.

I know that much. But deinterlacers and scalers used by ORF are not that bad. It was a colorspace problem...

Hardware decoding currently fails for 720p50 under XP (for both nVIDIA and ATi in bitstream mode). Pretty jerky playback. No problem under Vista with EVR. MainConcept and CoreAVC and software decoding is fine too.

BetaBoy
11th June 2008, 07:49
Ok guys.... As many of you know I have mentioned this before but we are about to finally go into beta phase of CoreAVC 64, and are looking for a few elite D9 testers that have 64 bit systems that can test and provide feed back on.

Now this does not feature our upcoming 2.0 branch changes, but it does feature many of the things not in 1.7 like our levels slider (brightness, contrast, saturation).

PM me you system specs.... thx

JohnnyFu
12th June 2008, 23:18
What is the recommended software setup for CoreAVC 64, e.g. MPC HomeCinema - x64 ? wich renderer should be used, wich not ?

BetaBoy
19th June 2008, 05:36
Along with CoreAVC 64 we are bundling 64 bit versions of TimeCodec as well as the Haali Media Splitter. Everything else is on a per user system basis and for them to report back on.

Shinigami-Sama
19th June 2008, 06:59
betaboy
will the 64bit be only for vista or xp64 as well?

BetaBoy
19th June 2008, 14:00
ATM XP/Vista 64 yes..... Were you thinking Linux? If so, OEM wise it will now also be available as a licensable library for it (Linux) as well. One thing to note.... Haali will include both the 32 bit and the 64 bit versions in the same installer package so there is no need for two diff installers.

Shinigami-Sama
19th June 2008, 21:12
no I was just wonder if it'd be vista 64 only for now, which doesn't fly on my laptop, but xp64 is doing well so far

and nice to know a linux solution is in the tube

ADude
19th June 2008, 22:30
Along with CoreAVC 64 we are bundling 64 bit versions of TimeCodec ...

Interesting... I'm guessing that you enter a time, and it plays videos from that day and time ?

Can I enter "1 January 2020" ?

:eek:

LoRd_MuldeR
19th June 2008, 22:33
Interesting... I'm guessing that you enter a time, and it plays videos from that day and time ?

Can I enter "1 January 2020" ?

:eek:

:p

TimeCodec is a tool for benchmarking video decoders. The existing x86 version is here:
http://haali.cs.msu.ru/mkv/timeCodec.exe

the_corona
20th June 2008, 06:50
Ok guys.... As many of you know I have mentioned this before but we are about to finally go into beta phase of CoreAVC 64, and are looking for a few elite D9 testers that have 64 bit systems that can test and provide feed back on.

Now this does not feature our upcoming 2.0 branch changes, but it does feature many of the things not in 1.7 like our levels slider (brightness, contrast, saturation).

PM me you system specs.... thx

Will CoreAVC 64 be free for existing customers?

For me I'll def. need a 32 bit version because my Mediacenter software is 32 bit, on the other hand if the 64bit Ver. is faster, it might just make it for some demanding videos and so one could use diff. player software (64 bit) for those.

Of course if it's not really faster theres hardly any point. So is it (free/faster)? :-)

Thnx

BetaBoy
20th June 2008, 18:20
No, as CoreAVC 64 is a new product. As far as faster, yes.

JohnnyFu
20th June 2008, 18:38
BetaBoy, did you read my pm ? I don't expect you to answer but confirming would be nice.

Will there be a trial versoin of CoreAVC 64 as well ? Since it's not free for existing customers.... I'm not gonna buy without testing it, sorry.

BetaBoy
20th June 2008, 18:43
BetaBoy, did you read my pm ? I don't expect you to answer but confirming would be nice.

Will there be a trial versoin of CoreAVC 64 as well ? Since it's not free for existing customers.... I'm not gonna buy without testing it, sorry.

No trial for CoreAVC 64 is planned. I'll jump into the PM's now.

todaystudy
20th June 2008, 19:47
I am not saying that they must make it more complicated! The site funcionality is very good! I am saying that they must make it more beautiful!!!

We are speaking about a VIDEO DECODER here (people want to see something with style)!!! They have to use nicer colors and buttons! You can't just use 3-4 very basic colors for a website that sell a VIDEO DECODER!!!!! It is so....... Linux!!!

Anyway, I hope to see something cool in it!!!

the_corona
20th June 2008, 20:18
I am not saying that they must make it more complicated! The site funcionality is very good! I am saying that they must make it more beautiful!!!

We are speaking about a VIDEO DECODER here (people want to see something with style)!!! They have to use nicer colors and buttons! You can't just use 3-4 very basic colors for a website that sell a VIDEO DECODER!!!!! It is so....... Linux!!!

Anyway, I hope to see something cool in it!!!

What the hell? When did the discussion about their website start? I could give a * what their site looks like tbh, but for the record I personally find it kinda stylish. But seriously, I'm shocked how rude some people can be....

BetaBoy, not free and no trial.....I don't know. Better be some kick-ass perf. numbers then to convince people to shell out money again :-) I will patiently await such results

BetaBoy
20th June 2008, 20:21
Well as in anything a trial version is an option.... but we figure if you like the trial of the 32 bit version... and we state the 64 bit version is faster, isn't that enough? But point taken... we are listening to the feedback for sure.

BetaBoy
20th June 2008, 20:25
I also wanted to state that we are also adding 4:2:2 support to CoreAVC Professional (and 64) as well. Will it make it into 1.8 or 1.9? That depends on QA and our release time frames going into 2.0.

the_corona
20th June 2008, 21:20
Well as in anything a trial version is an option.... but we figure if you like the trial of the 32 bit version... and we state the 64 bit version is faster, isn't that enough? But point taken... we are listening to the feedback for sure.

Well, on second thought I guess you're right. I just meant for me (if you think about the "complexity of 64 bit" ... finding a player, finding audio codecs, splitters (ok you got that one covered) etc. and all that in stable enough form) and the added cost for another decoder is something that I would only consider if indeed it was notcably faster so that I can play files I am unable to currently, or use some postprocessing with noticably saved cpu cycles.

And, well, I can only find that out one way (or caluclate based on your perf figures and hope it scales as well on my machine). Well you know.

On the other hand, its not like its $100 and I've bought more expensive things in the past I ended up not being able to use, hehe.

So point being, if its much work, I guess I'd rather you spend time optimizing the decoder itself than build a trial (remember you got/will have competition now too).

Thank you for listening.

cyberbeing
20th June 2008, 22:19
Well as in anything a trial version is an option.... but we figure if you like the trial of the 32 bit version... and we state the 64 bit version is faster, isn't that enough? But point taken... we are listening to the feedback for sure.

What I think would make sense would be to sell the x64 version as a $5 (or maybe half-price) addition for owners of the x86 version of CoreAVC Pro (or vise versa), bundle x86 and x64 together for something like $20, and offer them separately for $15 each if someone just wanted one or the other.

BetaBoy
20th June 2008, 22:42
Well.. the long term plan with CoreAVC 64 is to feature 4:4:4 support as well (to match the Enterprise version)... so the price point is a moving target. Thanks all for the feedback... keep it coming ;-)

cyberbeing
20th June 2008, 23:03
Moving target is fine. The idea is just to bundle them together at a price point to encourage people to buy both when they might not need both versions currently but they buy both just in case there is a future need because it's value priced and saves them money (i.e. you can buy both together for $20 but if you decide to buy both later it will cost you $30). You would then want to add a limited time period where existing customers before the x64 version was introduced could buy it for the reduced bundle price.

By doing this you will likely increase revenue with more sales of the x64 version while keeping people happy with a reasonable price point. If you price them at full price and only sell them separately then people would probably only buy one or the other and it kind of screws existing customers who may have only wanted the x64 version if it had existed at the start.

BetaBoy
30th June 2008, 21:15
From the DivX thread....


If I had to give a single big reason CoreAVC is fast, its because of the SSE2 deblocking, which exists in x264 but hasn't been ported to ffmpeg.
We contain no SSE2 deblocking..... that's for CoreAVC 2.0 (IE; we have a lot of room for CPU specific improvements).

Dark Shikari
30th June 2008, 21:17
From the DivX thread....

We contain no SSE2 deblocking..... that's for CoreAVC 2.0 (IE; we have a lot of room for CPU specific improvements).Color me surprised--I thought CoreAVC already had that.

In that case, I'll rephrase it:

"If I had to give a single big reason CoreAVC is faster than ffmpeg, its because of ffmpeg's lack of SSE2 deblocking, which exists in x264 but hasn't been ported to ffmpeg."

:p

BetaBoy
30th June 2008, 21:19
np ;-)

Maksee
13th August 2008, 15:16
I have a question regarding decoding on different Celeron and Pentium processors. This comes from the fact that I want real-time decoding of 720p30 files made by Sanyo Xacti HD700. I downloaded some videos made by an owner of the camera and all my computers didn't manage to keep up using CoreAVC codec. But I also notice that while cache, chip frequency and bus frequency affect the results, one example shows that even generation change do maybe even more that other parameters.
This example included two computers:
- Celeron 1.7 GHz(F.1.3.5) L2:128k, 400 MHz bus could decode 15 frames per second
- underclocked Celeron 630 MHz (6.D.8.20) appeared in Asus EEE Pc with 512k cache, 400 Mhz bus can manage to do just the same 15 frames. Moreover, "rightclocked" to factory 900 MHz Eee pc performed better that the big computer and almost could manage 720p25, but failed to do 720p30.
So I'm interested particulary what processor on (maximum) 533 Mhz bus and 478 socket can manage to do 720p30 or what should I look at when choosing between parameters of different used processors (as I see only 3 GHz 800 bus options is available at the moment as new for 478 socket)

Thanks!

foxyshadis
15th August 2008, 05:49
Get a P4 2.8 or 3.06, which both come in 533MHz for 478. Scour ebay or craigslist if you want it on the cheap. A bonus with that 3.06 is that it comes with Hyperthreading, giving you a little extra boost with coreavc. The most powerful Celeron D that fits is a 3.2.

The Eee PC's Celeron M is much more powerful, as you've found, and you can actually upgrade it to a Pentium M up to 2.1 GHz. The speed would actually still be faster than the fastest 478 Pentiums in that case, though power use and heat would increase. (You can also get less powerful and less power-hungry ones.) Laptop chip replacement is much more difficult, but tutorials for it exist online.

Shinigami-Sama
15th August 2008, 05:52
Get a P4 2.8 or 3.06, which both come in 533MHz for 478. Scour ebay or craigslist if you want it on the cheap. A bonus with that 3.06 is that it comes with Hyperthreading, giving you a little extra boost with coreavc. The most powerful Celeron D that fits is a 3.2.


you can OC the northwoods up to 3.4ghz easy on pc2700ram
and 3.6 on pc3200 ram
I have to do that time to time on some more complex encodes
should be able to find them pretty easy

JohnnyFu
17th August 2008, 22:58
Hey there BetaBoy,

It has been quiet around here lately, any news on the x64 version ?
You wanted to get me a copy, remember ? :)

Another thing, I actually don't want to ask about this at all... but, in view of what my new HD3850 card's Vista-UVD-technic does on h.264 decoding. Is there a plan for hardware decoding in version 2.0 or so ? :D

greetz
Jofu

Jay Bee
18th August 2008, 19:57
Any news on DVBViewer microstutter problems? Only happens on 1080i, not 720p. Cyberlink doesn't stutter in DVBViewer and using CoreAVC to play the same streams outside of DVBViewer also doesn't stutter.

CiNcH
19th August 2008, 08:56
Any news on DVBViewer microstutter problems? Only happens on 1080i, not 720p.

What does the video renderer say? Check within DVBViewer under 'View' -> 'Filers'. Try the VMR renderer as I do not trust the EVR skipped frames/jitter values.
For me it seems that the deinterlacer introduces quite some jitter. But here it also happens with file (captured from 1080i DVB source) playback and a Haali -> CoreAVC graph (built with GraphStudio/GraphEdit). Think that the combination of the DVBSource filter and CoreAVC works quite well by now.

I am using CyberLink with DXVA bitstream acceleration and currently can't test that further as I ran out of the CoreAVC trial period for the current Windows installation on the test PC.

BetaBoy
23rd August 2008, 09:23
Hey there BetaBoy,

It has been quiet around here lately, any news on the x64 version ?
You wanted to get me a copy, remember ? :)

Another thing, I actually don't want to ask about this at all... but, in view of what my new HD3850 card's Vista-UVD-technic does on h.264 decoding. Is there a plan for hardware decoding in version 2.0 or so ? :D

greetz
Jofu

We are finishing up a few things for the CoreAVC 1.8 Editions including the CoreAVC 64 launch (QA, helpfiles, website, etc.). There has been a fair amount of decoder property changes we are testing to add flexibility that people have been asking for (its also things we wanted to do before CoreAVC 2.0).

JohnnyFu.... Hardware support is coming but not in the way you may think. I will elaborate on this in a future post.

Ranguvar
23rd August 2008, 14:59
Can't wait for 64-bit support :D

In encoding, 64-bit support seems to provide quite a significant gain. But, not in general apps.

Do you think decoding will offer similar gains, or no?

Gleb Egorych
25th August 2008, 14:03
Hi all.
I found that CoreAVC 1.7 was incompatible with "remember file position" features in Zoom Player and MPC-HC. If I play file from remebered position that coreavc produces visual artifacts which could be fixed by 1) closing the player and 2) clearing file position history. CoreAVC 1.6.5 does not have the problem at all.

Attached screenshot was made in Zoom Player. Picture is doubled and colors are broken.

Has anybody noticed the same problem?

BetaBoy
25th August 2008, 14:59
Gleb... other then splitting, "remember file position" should have nothing to do with CoreAVC. Ping the ZP Crew to see what's going on there.... But I'll have a chance to test tomorrow to see if I can duplicate it in ZP.

Gleb Egorych
25th August 2008, 15:55
BetaBoy, it's not ZP only bug, MPC-HC doesn't work too. And only with 1.7.0.0. So I consider it's rather CoreAVC bug.

BetaBoy
25th August 2008, 18:43
Gleb.... first report here in this thread on it as far as I know. I just tried ZP with both 1.6.5 and 1.7.0 and don't get the results you do... You do have the latest Haali splitter, right?.... but we'll take a look into it more.

rickardk
26th August 2008, 01:40
... Hardware support is coming but not in the way you may think. I will elaborate on this in a future post.

I guess (and hope) that you are going to use CUDA, so there will be no need to connect directly to the renderer as with DVXA2...?

BetaBoy
26th August 2008, 02:06
I have already addressed our concerns for the myopic focus of DXVA and that a greater global effort from GPU companies has to made. We love CUDA from NVIDIA its great although not a universal solution but a step towards a more open approach.

soresu
26th August 2008, 03:04
Betaboy, do you intend to use openCL standard for gpu acceleration then? this also seems to fit in with parallel threading on the cpu from what khronos is saying...

CiNcH
26th August 2008, 10:31
I don't believe that there is a market in DXVA anyway. There is nothing special anymore about it. All decoders perform equally and have the same limitations. MPC Video Decoder gets better and better, only lacking proper interlaced support (another con currently is that it expects a whole H.264 frame within one DirectShow sample, only working with Haali and MPC splitter, which have to parse the bitstream already).

DirectX 11/OpenCL/CUDA could really have an impact by enabling hardware assisted decoding with Haali Renderer for example, enabling the possibility to even use it for transcoding with CoreAVC acting as the H.264 decoder or using ffdshow as a PostProcessor...

Gleb Egorych
26th August 2008, 14:39
BetaBoy, I'm using Haali Media Splitter ver. 1.8.122.18. Made some explorations, here are results.

System: WinXP SP3, 8800GT + Forceware 177.83.

In MPC-HC only VMR9 renderers are effected, VMR7, EVR, overlay and Haali are OK. In MPC-HC the problem appears on ALL videos I have, for example da_vinci_code-tsr2_h720p.mov. If I enter CoreAVC settings window, change any setting, change it to the initial value and press OK then video becomes normal without artifacts.

In ZP the problem appears on VMR7, VMR9, overlay and EVR renderers. Haali is unaffected. But in ZP SOME H.264 files play CORRECTLY. I can't find the reason. If I change any CoreAVC setting during playing, zplayer.exe just crashes. ZP has the problem with da_vinci_code-tsr2_h720p.mov too.

Also tried on another computer, WinXP SP3, Radeon 9500 pro + Catalyst 7.10 (pretty old, I know :)). On that system everything plays great, without any artifacts. So, I have the bug only on my nvidia system and only when using CoreAVC 1.7.0. With CoreAVC 1.6.5 both systems play correctly.

the_corona
27th August 2008, 14:16
Now I'm nervous :-(

I'm about to build a new HTPC and of course if any form of hardware acceleration is coming I'd like to take advantage of it.

I'm leaning towards ATI, but CUDA won't work with it, will it? If it's not using DXVA, it will have to favour NVIDIA or ATI, wrong?

Should I buy ATI or NVIDIA (all other things set aside)? Will it most likey work with either recent generation's card?

Too early...if its not coming for 2 years I'm not too worried as its ok if I have to buy a new one by that time.

TheShadowRunner
27th August 2008, 14:48
I have the same issue as Gleb.
And, very possibly related, if I use Core 1.7 with Reclock, i'm getting a screen full of artefacts after resolution change. Exactly the same setup with 1.6.5 doesn't exhibit the problem.
When that occurs, with 1.7, just opening the setting page and faking a change in there then hitting apply corrects the issue...
Edit, i'm also using ZP & VMR9.

Ranguvar
27th August 2008, 18:16
@the_corona: I'd just get a reasonably fast dual or quad core and forget about it. Those should handle 1080p H.264 content fine. If the next generation of codecs won't run properly on your HTPC, then get a fast videocard then, since DXVA will be more mature.

BetaBoy
30th August 2008, 06:11
In preparation for the CoreAVC 1.8 release, I have updated the first post to match the current filter properties.

CoreCodec / CoreAVC H.264 Decoder Configuration Properties Guide

Input Formats
This setting controls which DirectShow Media Types the decoder accepts on input. Uncheck only if you are troubleshooting problems with CoreAVC incorrectly decoding some variant of H.264, or want to use another decoder for it.
- avc1 / AVC1 - Accept streams with avc1 / AVC1 FourCCs.
- h264 / H264 - Accept streams with h264 / H264 FourCCs.
- x264 / X264 - Accept streams with x264 / X264 FourCCs.
- VSSH - Accept streams with VSSH FourCC.
- Mainconcept H.264 - Accept H.264 streams from the Mainconcept splitter.
- ArcSoft H.264 - Accept H.264 streams from the ArcSoft splitter.

Output Formats
This setting determines the preferred output color space. The decoder tries each enabled format in order from top to bottom until it is accepted by the Video Renderer filter.
- YV12 - YUV 4:2:0 planar format.
- I420 - YUV 4:2:0 planar format with chroma planes in reverse order.
- YUY2 - YUV 4:2:2 packed format.
- UYVY - YUV 4:2:2 packed format with different sample ordering.
- RGB24 - 8 bits per channel RGB format.
- RGB32 - 8 bits per channel RGB format with an extra padding byte.
- RGB16 - RGB format with 6 bits per green sample and 5 bits each for red and blue samples.
- RGB15 - 5 bits per channel RGB format.

- Up Arrow - Increases the priority of the selected format by moving it towards to the top.
- Down Arrow - Decreases the priority of the selected format by moving it towards the bottom.

Input Levels
- TV (16-235) - always assume the stream uses TV levels
- PC (0-255) - always assume the stream uses PC levels
- Auto detect - use the full range flag in the stream to determine Luminance range
- Output levels, this also affects conversion to RGB color space when it is done by the decoder.

Output levels
- TV (16-235) - assume the Video Renderer expects TV levels
- PC (0-255) - assume the Video Renderer expects PC levels
- Auto detect - use PC levels when VMR is used as a Video Renderer, and TV levels for all others.

Deinterlacing
This setting specifies how interlaced material is handled by the decoder.
- None (Weave) - Each output frame contains two fields, flagged as progressive.
- Single Field - Each output frame contains one field. Only one frame is produced for each field pair.
- Bob - Each output frame contains one field. Two frames are produced for each field pair.
- Hardware - Each output frame contains two fields, flagged as interlaced to allow the video renderer to perform deinterlacing.

Deblocking
This setting controls how the deblocking step of H.264 specification is executed by the decoder. Deblocking is a complex process that consumes significant processing resources. If your machine is not fast enough, you might want to turn off deblocking for some frames, but it will degrade visual quality.
- Standard deblocking - do deblocking exactly as specified by H.264
- Skip when safe - skip deblocking step when decoding B-frames.
- Skip always - does not perform any deblocking.

Aggressive deinterlacing
This option determines how the decoder detects interlacing in source stream.
- Off - use only picture timing SEI and POC numbers to detect interlaced video. Unfortunately not all encoders properly flag material as interlaced.
- On - in addition to SEI and POC, assumes source is interlaced if any interlaced coding tools are used in encoding the frame (MBAFF, PAFF).

Crop 1088 to 1080
H.264 encoded video size is always a multiple of 16, and sequences that are 1080 pixels high are encoded as 1088 padded at the bottom. Also H.264 specifications provides a set of cropping parameters to signal that parts of the encoded picture are not important and should not be displayed. Some H.264 encoders fail to specify cropping parameters when encoding 1080 video.
- Off - do not crop video
- On - when input video is exactly 1088 pixels high, crop 8 pixels off the bottom

Force VMR AR correction
This option can be used if you are working with the decoder outside the normal player environment.
- Off - does not change VMR settings.
- On - instructs VMR filter to maintain aspect ratio of the video that it displays. Normally this AR correction is the responsibility of a video player. This option should normally be off.

Preferred Decoder
Overrides any system AVC directshow decoders and uses CoreAVC.
- Off - does not change system merit.
- On - enables the highest merit on the PC. This option should be se to ‘On’.

Picture Levels
Picture level slider adjustments can be made in ‘real time’ so you see the effects of the changes as you make them. Once the adjustments are made, ensure that you press ‘Apply’ to save changes or they will be lost.
- Brightness - Adjusts the overall brightness level.
- Contrast - Adjusts the difference between light and dark areas.
- Saturation - Adjusts the vibrancy of colours.
- Restore Defaults - Reset all picture level adjustments. It is not necessary to click Apply after this option.



Barring any major bugs in the AM we expect 1.8 to be released at some point later today.

Dark Shikari
30th August 2008, 06:12
- Skip when safe - skip deblocking step when decoding B-frames.Do you mean NAL units designated as disposable (unreferenced B-frames), or do you really mean all B-frames? If the latter, its certainly not safe.

Selur
30th August 2008, 08:14
btw. a little filter like deband (gradfun2db) would be nice,...

qyqgpower
30th August 2008, 10:25
About the auto detection of output levels.
Since Nvidia & AMD both have adjusted their drivers to display full range in certain resolution(mainly 720p&1080p) while using VMR, so I think CoreAVC should also adapt this change. Otherwise, we would get over-ranged output in this certain condition.

CruNcher
30th August 2008, 10:50
Yep CoreAVC needs also to detect when this was set from the Drivers Control Panel (manualy) i guess checking the changed registry entry would be enough to get it right (input is xxx -> Driver State is xxx -> Output should be xxx unless overriden by user) :)

bob0r
30th August 2008, 13:08
For both: What driver versions are we talking about here?

qyqgpower
30th August 2008, 15:05
for Nvidia, I noticed this change since 175series, and Nvidia have added a option in video section to change the output scale since 177series(may not appear for older cards).
for AMD, I have just bought a 4850 so I don't know exactly which version made the change, but apparently catalyst 8.8 would scale 16~235 to 0~255 correctly(BT709 matrix) at 720p&1080p while using VMR9 Renderless.

BetaBoy
30th August 2008, 15:35
mmm... I'm gonna ping the guys on the output level and filter. But we also found out that:
- there's a field order bug with hardware deinterlacing that only affects either VMR7 or VMR9 (TBD), that has the field order flipped when seeking, resulting in juddering motion.

With the above aside... I would prefer us not to delay 1.8 any further as this could potentially interfere with our 2.0 plans.

I'll fill everyone in as we go along.

Gleb Egorych
30th August 2008, 19:36
About color range: I'm using the latest official beta Forceware 177.92 @ 8800GT. In "Nvidia CP" range is set to "Full (0-255)". CoreAVC input and output level are set to auto. And on my monitor (DVI connection) colors are correct.

cyberbeing
30th August 2008, 21:49
About color range: I'm using the latest official beta Forceware 177.92 @ 8800GT. In "Nvidia CP" range is set to "Full (0-255)". CoreAVC input and output level are set to auto. And on my monitor (DVI connection) colors are correct.

This is also the case on my computer with 177.89 and "Full (0-255)" set with my monitor connected via DVI-A.

Input/Auto + Output/Auto = Correct Full Levels
Input/Auto + Output/TV = Correct Full Levels
Input/PC + Output/PC = Correct Full Levels
Input/TV + Output/TV = Correct Full Levels
Input/TV + Output/Auto = Correct Full Levels

Input/TV + Output/PC = Incorrect Overextended Levels
Input/Auto + Output/PC = Incorrect Overextended Levels

bob0r
31st August 2008, 00:15
This seems correct; most H.264 sources are TV level (satellite, bluray, hddvd, avchd).

On my system, with old(er) nvidia drivers, black is grey when i set output to TV.

If nvidia indeed fixed it, your list is correct and input TV (and auto which is then the same) + output PC = Overextended Levels

Even Haali renderer can set the levels for you, so what you simply do, is start with the brightest video you can get, and if black is black, your levels are correct, you can use the brightness slider if it's too bright for you :)


A side note: All encodes should be same level as the source, let the decoder, renderer or player change levels (c) pengvado.
(so if some x264 encode has another level than the source, something went wrong)


My idea is: If anyone can find any H.264 video file, which can't be set to use the correct levels report it here, but if CoreAVC always can find a proper solution, then we should leave it as is.


Edit:
I just installed Nvidia 177.92 and INDEED FULL range on VMR9 is working, its a miracle!

However for PowerDVD 7 and 8:
http://x264.nl/powerdvd.7.3.3319a.nvidia.177.92.beta.fail.jpg

DOH!

Mangix
31st August 2008, 05:33
try 177.83

shon3i
31st August 2008, 11:16
Or install lastest PowerDVD 8 build 2018

bob0r
31st August 2008, 13:37
try 177.83

Did. same result.

Or install lastest PowerDVD 8 build 2018

Think i have?
http://www.cyberlink.com/multi/download/dl_patch_623_1_ENU.html
CyberLink.2021U_DVD080729-02(Ultra).exe or is there any newer?


Sorry for being off topic, but it seems i am the only one with this problem??


Edit:
I guess this issue could be split to here: http://forum.doom9.org/forumdisplay.php?f=15

BetaBoy
31st August 2008, 15:38
Thx for the feedback all! We are gonna let the debate go on for the moment and get 1.8 out the door. So with that, below is the changelog for CoreAVC 1.8. We will be releasing CoreAVC Standard and Professional Editions for now.
CoreAVC H.264 Video Codec - Version 1.8.0.0 (20080831)
- Add: About tab
- Add: Help tab (describing filter options)
- Add: Picture levels adjustment tab
- Add: System Tray icon
- Add: Support for AVC Lossless 4:2:0 (officially)
- Add: Support for new standard aspect ratios
- Fix: Rearranged options tab
- Fix: Renamed Blend deinterlace to Single Field
- Fix: Fix Bob deinterlacing with Matroska files
- Fix: Fixed Aggressive Deinterlace function
- Fix: Better recovery point handling
- Fix: Improved filter stability (lots of changes)

On CoreAVC 64.... its done as well, however Haali still need to do work on the 64 bit splitter. A 64 bit version of 'Time Codec' is done however, but we won't release that till the splitter is as well.

So this begs the question... release CoreAVC 64 with the 32 bit splitter? Thoughts?

cyberbeing
31st August 2008, 18:13
Is the 64bit splitter going to be free and posted on Haali's site (http://haali.cs.msu.ru/mkv/) or is it only going to be bundled with CoreAVC and require registration or something?

If it's the former then I wouldn't see any issue with releasing CoreAVC 64bit with the 32bit splitter as long as it works considering that someone could easily grab the 64bit splitter when it's released. If it's the latter and the splitter isn't going to be freely available then I think you should wait and release them together.

amango
31st August 2008, 19:13
Question: Do I need a 64 Bit-application to use the 64 Bit-edition of CoreAVC ?

For example, Mediaportal is only available in 32 Bit. Do I have to use the 32 Bit-version of CoreAVC or can I use the 64 Bit-version? (I have Vista x64).

BetaBoy
31st August 2008, 19:16
Haali's splitter has always been free... nothing is gonna change that (Also if you did not know Haali is one of the lead CoreAVC Filter developers). To take advantage of 64bit everything should be 64bit within the playback chain. IE: codec, splitter, player.

ChronoCross
31st August 2008, 19:47
Haali's splitter has always been free... nothing is gonna change that (Also if you did not know Haali is one of the lead CoreAVC Filter developers). To take advantage of 64bit everything should be 64bit within the playback chain. IE: codec, splitter, player.

I thought you couldn't connect a 64 bit app to a 32-bit app. Isn't that the reason you need to use 64-bit filters with avisynth 64-bit? or 64-bit apps with megui 64-bit?

cyberbeing
31st August 2008, 19:50
I knew you had hired Haali awhile back but I thought he was only dealing with splitter and possibly player issues but not the CoreAVC decoder itself.

I'm assuming you probably have access to an alpha 64bit splitter. Is there a noticeable performance hit between the 32bit and 64bit splitter? Are the 32bit Haali splitter and 64bit decoder fully compatible and stable with each other? How does it behave with say the 64bit Gabest (granted I far prefer Haali's) MKV splitter which can be found via the MPC-HC project?

Also how much time are you talking about for the 64bit splitter to be ready? 1 month? 3 months? 6 months? 1 year? More/Less?

If you released CoreAVC 1.8 64bit now, would you be able to release CoreAVC 1.8.1 with some sort of minor feature addition or bugfix by the time the 64bit splitter is ready?

Emilot
31st August 2008, 20:42
Thx for the feedback all! We are gonna let the debate go on for the moment and get 1.8 out the door. So with that, below is the changelog for CoreAVC 1.8. We will be releasing CoreAVC Standard and Professional Editions for now.


On CoreAVC 64.... its done as well, however Haali still need to do work on the 64 bit splitter. A 64 bit version of 'Time Codec' is done however, but we won't release that till the splitter is as well.

So this begs the question... release CoreAVC 64 with the 32 bit splitter? Thoughts?

So, where can we download it???:thanks:

kemuri-_9
31st August 2008, 21:00
I thought you couldn't connect a 64 bit app to a 32-bit app. Isn't that the reason you need to use 64-bit filters with avisynth 64-bit? or 64-bit apps with megui 64-bit?

that's right, windows doesn't allow cross talk between 32bit and 64bit apps unless you actually do bistream piping between them.

i use MPC-HC x64, so i could see some coreavc x64 usage by adding it as an external filter.

clsid
31st August 2008, 21:14
i use MPC-HC x64, so i could see some coreavc x64 usage by adding it as an external filter.MPC-HC can use external filters without the need to explicitly add them in the options. Simply disabling the internal decoder is enough.
Is there a noticeable performance hit between the 32bit and 64bit splitter?The splitter uses very little resources. So performance is a non-issue.
If you released CoreAVC 1.8 64bit now, would you be able to release CoreAVC 1.8.1 with some sort of minor feature addition or bugfix by the time the 64bit splitter is ready?No need for that. CoreAVC and Haali Media Splitter are two separate items.

BetaBoy
31st August 2008, 21:14
Correct... was just talking with the guys here and they confirmed it as well. So I'll ping Haali on his 64 bit version.

cyberbeing
1st September 2008, 07:00
Is there a noticeable performance hit between the 32bit and 64bit splitter?The splitter uses very little resources. So performance is a non-issue.I assumed this to be the case but I forgot that you had to use a 64bit splitter with the 64bit decoder so my question was kind of pointless.

If you released CoreAVC 1.8 64bit now, would you be able to release CoreAVC 1.8.1 with some sort of minor feature addition or bugfix by the time the 64bit splitter is ready?
No need for that. CoreAVC and Haali Media Splitter are two separate items.

Well the point was that CoreCodec bundles Haali Splitter with the installer for ease of use and it goes back to the question of whether it makes sense to release CoreAVC 64bit now or wait for Haali's 64bit splitter. If they released it without Haali's 64bit splitter then it likely wouldn't get bundled with the installer until the release of CoreAVC 1.8.1 and less tech savvy people might not realize how to get Haali's splitter by itself and blame CoreCodec for any splitter or lack-of-splitter issues they are having.

Now if they could have 1.8.1 ready by the time Haali's 64bit splitter is ready then it would probably make sense just to wait and release CoreAVC 64bit then. If Haali's 64bit splitter would be ready in the next month or so it would also make sense to probably just wait and release CoreAVC 1.8 64bit then. If the wait is longer then that and 1.8.1 in nowhere in sight, then it wouldn't really make sense to delay CoreAVC 64bit any longer.

BlackSun
1st September 2008, 10:15
We are proud to announce that we are sending emails containing your personal download link for the new CoreAVC 1.8! I am updating the trial version in about five minutes.

Changelog:

- Add: About tab
- Add: Help tab (describing filter options)
- Add: Picture levels adjustment tab
- Add: System Tray icon
- Add: Support for AVC Lossless 4:2:0
- Add: Support for new standard aspect ratios
- Fix: Rearranged options tab
- Fix: Renamed Blend deinterlace to Single Field
- Fix: Fix Bob deinterlacing with Matroska files
- Fix: Fixed Aggressive Deinterlace function
- Fix: Better recovery point handling
- Fix: Improved filter stability

bob0r
1st September 2008, 14:52
Issue for 2.0 or 1.8.1:

[02:01] * jarod wonders...
[02:01] (jarod): why Some.Video.HDTV-x264-2008 Framerate..[ 59.940 fps ]
[02:01] (jarod): drops so many frames in MPC, while CPU is not even feeling it
[02:01] (jarod): 15% usage
[02:02] (jarod): sounds like a bug to me
[02:27] (ChronoCross): ffdshow results?
[02:27] (ChronoCross): any stutter?
[15:44] (jarod): ffdshow does the same
[15:44] (jarod): drop frames, and ofcourse not use all cores
[15:45] (jarod): this is a serious coreavc bug

Most frames are dropped when the buttom menu in MPC is opened by mouse over, or when i switch to fullscreen and back.

So this could be some serious Windows and/or DirectShow bug aswell, maybe we need a work around.

Fact remains: CPU is hardly doing anything, and its still dropping frames.

This video is 1280x720, the same issue i reported before to BlackSun with World in Conflict Nuke (1080p60).mkv, i figured that was just too much, but it seems its a general bug with 50+ frames?

CruNcher
1st September 2008, 15:19
do you experience any dropouts in the Exclusive VMR9 Rendering Mode (this should prevent any GUI stuff interfering on XP) ?
tough the droping when caling GUI stuff in XP seems absolutely normal i also experience that guess one thing that has been fixed in Vista ;)

CiNcH
1st September 2008, 15:24
This video is 1280x720, the same issue i reported before to BlackSun with World in Conflict Nuke (1080p60).mkv, i figured that was just too much, but it seems its a general bug with 50+ frames?

When I tested the trial back at the Euro 2008 I also noticed frame drops with 720p50 ORF 1 HD. But most of the time the glitches were not very well visible.

D.A.S.
1st September 2008, 15:52
- Add: System Tray icon
Add: Show tray icon.
Value - yes:no

BetaBoy
1st September 2008, 17:37
D.A.S. welcome.... with a newb post like that, how about adding something of value yourself? Adding CoreAVC as tray icon _IS_ of value (and requested) as sometimes ppl have multiple windows open and want an easy way to get back to the filter properties (alt+tab) once they make a change.

Guest
1st September 2008, 17:43
I think he was asking you to add an option to enable/disable the tray icon, not dissing the feature.

DigitalDeviant
1st September 2008, 17:57
I think he was asking you to add an option to enable/disable the tray icon, not dissing the feature.

Seems a poor way of requesting it, so I'll properly request it.

Could you please add a feature to turn off/on the tray icon since some of us don't need it. I have too many tray icons as is w/ ffdshow audio/video and haali's splitter and I don't need to access any of CoreAVC's properties during playback.

BetaBoy
1st September 2008, 18:25
Got it.... me bad... wondered why he regged a year ago only to post now. But yes, an icon disabling feature is planned in the next release.

I had also discussed with Haali a more universal means for 'current' Codec access (codecs that are currently in use) with the splitter (that's the intent of the current tray icon). I'll ping him again on this.

BetaBoy
1st September 2008, 18:31
I just published the CoreAVC Filter properties Guide: http://www.coreavc.com/index.php?option=com_content&task=view&id=42&Itemid=1

We have more planned to add to it including links, pics, etc. with each release leading to 2.0.

Disabled
1st September 2008, 18:44
I just published the CoreAVC Filter properties Guide: http://www.coreavc.com/index.php?option=com_content&task=view&id=42&Itemid=1


You got a small error there. The screenshot around "Input Formats" shows the "Input Levels". But nice overview - about the same as in the help screen...
You might also want to have a link in the properties dialog pointing to that website.

TheShadowRunner
1st September 2008, 18:51
So forced tray icon in 1.8 huh.. what the hell :/

BetaBoy
1st September 2008, 18:51
Disabled... thx for the catch/suggestion... Change has been made.

D.A.S.
1st September 2008, 18:55
I think he was asking you to add an option to enable/disable the tray icon, not dissing the feature.Yes. Something alike as in Haali Media Splitter.

Guest
1st September 2008, 18:58
Hey Dan, a while ago I asked about an SDK for using CoreAVC programmatically in DGAVCDec. You referred me to your engineers but they have failed to follow up with me. Do I take it then that you have no interest in this idea?

BetaBoy
1st September 2008, 19:03
neuron2.... It must have gotten lost in the shuffle here. I just sent you a followup email CC'd the guys here about it.

dead_screem
1st September 2008, 20:12
I experience a few bugs with 1.8 and WMP 6.4. When opening AVC video files (mkv, avi etc..) with WMP 6.4 the new tray icon disappears as soon as I mouse over it. In addition, opening the new help tab in codec properties, all the text is highlighted and the text window is scrolled all the way down. None of this happens if I try to play the file with WMP11 or MPC for example.

And possibly related to the WMP 6.4 icon bug, If Haali's splitter is set to Enable Thumbnail Extraction, when I click on a file in explorer it loads the thumbnail in the side pane just fine but as soon as I click on the file the tray icon shows for a split second. so if I doubleclick the file real fast it won't open, instead it acts as if I only clicked on the file once to perform a file rename. It's as if that coreavc tray icon blocks the file from being doubleclicked? If I click the file once, and wait for the trayicon to disappear I can then doubleclick to open the file.... disabling thumbnail extraction in haali can workaround this, but only for mkv files. The few avi AVC files I have exhibit this problem as well. And windows has no disable thumbnail extaraction option for AVI AFAIK...

None of this nonesense happened with 1.7. Thumbnail extraction worked fine and didn't cause any double click problems.

TheShadowRunner
1st September 2008, 23:45
The "resolution change" bug is still there.
how to reproduce: open any video with h264 stream and simply change the monitor resolution: -> the video will be frozen with crazy artefacts under the new resolution. (really bad when using Reclock)
This problem started after 1.6.5.
It can be fixed by opening Coreavc properties, making a fake change in there and press "Apply". the video will then be refreshed.
please fix. also don't forget to add a feature to HIDE the tray icon.
Thanks.

BetaBoy
2nd September 2008, 02:19
Great work guys keep the reports coming!

Snowknight26
2nd September 2008, 04:36
Was a 64-bit version of Haali Media Splitter released with CoreAVC 1.8.0.0? Only pertains if an x64 version of CoreAVC was released though.

BetaBoy
2nd September 2008, 06:15
No.... only Haali's 32bit version from March was included. What we plan to release with CoreAVC 64 is the filter and 64 bit versions of Haali's Splitter and TimeCodec.

Also with 1.8... I am keeping a list of the CoreAVC reported/confirmed bugs at the CoreCodec forums ( http://www.corecodec.com/forums/index.php?topic=1266.0 ), but it looks like 1.8.1 will be coming pretty soon so no need to add them to the tracker.

3ngel
2nd September 2008, 17:09
@Betaboy
I would like to go from standard to pro. I have to pay the entire price or there can be an "upgrade" option (paying the difference or whatever)?

Moreover i second definetivly the option to remove the tray icon. Too much of them indeed.

BetaBoy
5th September 2008, 00:21
ok all... 1.8.1 is in QA... so a few things....

- We have fixed all the reported bugs (although WMP 6.4 still needs testing)
- We have disabled the tray icon and added an option to enable it
- We have also enabled the 'Preferred decoder' by default (as we assume you have purchased it and want to use it by default)

I'll let you all know how things are going.

Dark Shikari
5th September 2008, 00:34
ok all... 1.8.1 is in QA... so a few things....

- We have fixed all the reported bugs (although WMP 6.4 still needs testing)
- We have disabled the tray icon and added an option to enable it
- We have also enabled the 'Preferred decoder' by default (as we assume you have purchased it and want to use it by default)

I'll let you all know how things are going.Any update on Predictive Lossless support?

BetaBoy
5th September 2008, 04:38
Dark Shikari.... You have a few samples?

Dark Shikari
5th September 2008, 05:09
Dark Shikari.... You have a few samples?Only the sample I originally uploaded, but here's a 7zip file with that sample, a patch for ffmpeg to add (hopefully) compliant decoding, and an mplayer executable using that patch. Download (http://www.mediafire.com/?etqtcziuwyt).

BetaBoy
5th September 2008, 06:15
Got it thx... 4:4:4 will be in 2.0 (including predictive) but I'll see what we can do.

G_M_C
5th September 2008, 08:54
Any update on Predictive Lossless support?

Got it thx... 4:4:4 will be in 2.0 (including predictive) but I'll see what we can do.

DS: When's that (and 4:4:4 / High10 support etc.) gonna be in x264 ;) ?

Dark Shikari
5th September 2008, 09:06
DS: When's that (and 4:4:4 / High10 support etc.) gonna be in x264 ;) ?Predictive will be in as soon as a publicly available decoder supports it ;)

4:4:4 will be in as soon as someone volunteers to write that mess.

High10... ugh... anyone want to rewrite all the intra pred, DCT, iDCT, and MC? :eek:

G_M_C
5th September 2008, 09:25
Predictive will be in as soon as a publicly available decoder supports it ;)

4:4:4 will be in as soon as someone volunteers to write that mess.

High10... ugh... anyone want to rewrite all the intra pred, DCT, iDCT, and MC? :eek:

:p

That's why i asked;
4:4:4 / High10 support in CoreAVC would not be very usefull when there are no (reguarly used) encoders to actually build such files. ;) Mainstream video doesnt even work with "xvYCC" / Deep Color yet (Even if you have hardware that supports it, there are no actual disks/sources "in the wild"), so from that point of view it's not really usefull implementing stuff like that at all.

I imagine that 4:4:4 etc. will mostly be used on (very) high end equipment, for ex. in movie studio's, and I really doubt that those studio's would have need for something like CoreAVC.

So all in all; I cannot see the real need for that support in CoreAVC yet, DXVA might be a much more usefull time-investment.

Dark Shikari
5th September 2008, 09:31
4:4:4 I can imagine would be very useful for graphics, 8-bit games, etc.

BetaBoy
5th September 2008, 12:03
Dark Shikari.... I should have also said off the bat that that we 'do' support Predictive Lossless in the current CoreAVC 1.8 (unofficially)... and that sample is the same as the last one you had posted (its 4:2:0 not 4:4:4).

Also... We feel here at CoreCodec that you can see more use for 4:4:4 then 4:2:2.

G_M_C
5th September 2008, 15:14
[...]
Also... We feel here at CoreCodec that you can see more use for 4:4:4 then 4:2:2.

True, offcourse you can see that difference. But i have not seen 4:4:4 in the wild yet, and I have no idea when those clips will become more mainstream. That why i asked myself about the usefullness of developing a decoder for such clips, and DS responded to my thoughts ;)

BetaBoy
5th September 2008, 16:09
Well I agree 'Now/Short term', No. I'm thinking 1+ years from now. Imho, the key for its initial adoption is 'when' x264 supports it, and as Dark Shikari mentioned its gonna require a lot of work as it is for us with CoreAVC 2.0 as well. But decoding is cakewalk compared to encoding ;-)

Dark Shikari
5th September 2008, 16:43
Dark Shikari.... I should have also said off the bat that that we 'do' support Predictive Lossless in the current CoreAVC 1.8 (unofficially)... and that sample is the same as the last one you had posted (its 4:2:0 not 4:4:4).

Also... We feel here at CoreCodec that you can see more use for 4:4:4 then 4:2:2.Ah, well that's even better, then I can get around to committing predictive lossless sometime soon. And as I said, it is the same as the last one I posted.

I do see more use for 4:4:4 than 4:2:2, simply because 4:2:2 is mostly an "interlaced thing," and I'm not a big fan of interlacing... :cool:

G_M_C
5th September 2008, 16:45
Well I agree 'Now/Short term', No. I'm thinking 1+ years from now. Inmo, the key for its initial adoption is 'when' x264 supports it, and as Dark Shikari mentioned its gonna require a lot of work as it is for us with CoreAVC 2.0 as well. But decoding is cakewalk compared to encoding ;-)

HAs the look and feel of "chicken & the egg" situation. But good that at least someone is thaing the lead.

Because after interlacing (and I do hope that finally dies allready), colormetry-differences and NTSC vs. PAL situations are finally starting to die out, it's the colorspaces where the advancement in better quality lies imho.

allouh
6th September 2008, 03:23
wrong place for me to post.
sorry

Ranguvar
6th September 2008, 03:45
The problem is most likely not CoreAVC, but your encode. Either your source is VFR, the framerate was set improperly, or something screwed with the audio.

Gleb Egorych
6th September 2008, 16:49
Here is some new information about the bug I described here (http://forum.doom9.org/showthread.php?p=1175251#post1175251). CoreAVC 1.8.0 is affected too. And it appears only in WinXP (SP3) on my nvidia system (8800GT + ForceWare 177.92). In Vista x64 SP1 on the same computer (8800GT + ForceWare 177.92) using ZP + EVR and MPC-HC + EVR with CoreAVC 1.8.0 everything is OK.

BetaBoy
9th September 2008, 13:06
ok.... a new day, a new CoreAVC build to QA. We have now fixed ALL and confirmed bugs in 1.8 as well as a few that we found. We are however looking into Gleb Egorych's report. If all goes well look for 1.8.x later this week ( it might even be 1.8.5 if we officially add 'Predictive Lossless' and a few more things).

BetaBoy
10th September 2008, 07:48
From a few pages back... we had a report of a Weighted prediction problem. Well we have a sample file now and indeed it needs to be fixed (for fades in/out) so we are working on it now... In the meantime I have updated the Filter Guide on CoreAVC.com with some new screen caps and updated text, take a look:
http://www.coreavc.com/index.php?option=com_content&task=view&id=42&Itemid=1

Dark Shikari
10th September 2008, 07:49
From a few pages back... we had a report of a Weighted prediction problem. Well we have a sample file now and indeed it needs to be fixed (for fades in/out) so we are working on it now... In the meantime I have updated the Filter Guide on CoreAVC.com with some new screen caps and updated text, take a look:
http://www.coreavc.com/index.php?option=com_content&task=view&id=42&Itemid=1Explicit weighted-P, or implicit weighted-B prediction?

BetaBoy
10th September 2008, 07:53
Explicit weighted-P

BetaBoy
10th September 2008, 08:33
fixed... now to QA.

MatMaul
10th September 2008, 11:04
any news on NV12 support ?

BetaBoy
10th September 2008, 12:54
When the time is right I'll post news on CUDA support.

Inventive Software
10th September 2008, 14:13
NV12 is not the same as CUDA. ;) NV12 is a slightly different colourspace to YV12. http://www.fourcc.org/yuv.php#NV12

THX-UltraII
10th September 2008, 15:51
What is a good deinterlacing setting for playing 1080p material?

None (Weave)
Single field
or
Bob

(I know what HW deinterlacing does and I cannot use that one)

Guest
10th September 2008, 15:59
If it's progressive, then it does not need deinterlacing, so choose none.

BetaBoy
10th September 2008, 18:34
NV12 is not the same as CUDA. ;) NV12 is a slightly different colourspace to YV12. http://www.fourcc.org/yuv.php#NV12
I know.... I was trying to avoid not saying anything more... so as you may have guessed from my post that what we are working on for NV12 is CUDA atm. So if that tells you anything... then ;-)

MatMaul
10th September 2008, 19:10
any chance to have NV12 (not the CUDA thing only the output colorspace :) ) in the 1.8.x ?
on ATI it allows the use of hardware deinterlacing and proper chroma upsampling made by the video card (at least on my card ^^) without eating the cpu with an expensive YV12=>RGB high quality conversion

Sulik
10th September 2008, 21:41
I'm surprised there aren't more decoders and encoders that use NV12 natively, since it is inherently faster than YV12 for all chroma processing (allows 128-bit wide SSE2 operations on chroma).

DigitalDeviant
11th September 2008, 00:40
any chance to have NV12 (not the CUDA thing only the output colorspace :) ) in the 1.8.x ?
on ATI it allows the use of hardware deinterlacing and proper chroma upsampling made by the video card (at least on my card ^^) without eating the cpu with an expensive YV12=>RGB high quality conversion

What card is that because I have a HD3650 and NV12 chroma upsampling still sucks :(

bob0r
13th September 2008, 23:36
BUG: coreavc.marvel.bug.png (http://x264.nl/coreavc.marvel.bug.png)
Sample: marvel.m2ts (http://x264.nl/marvel.m2ts)

Extra info:
[00:32] (CruNcher): jarod
[00:32] (CruNcher): i saw alot of these problems with CoreAVC and X264 streams
[00:32] (jarod): but this is not x264
[00:33] (CruNcher): oh

So look into it please!
People encoding bluray movies are still using CoreAVC instead of DGAVCDEC because CoreAVC is faster.

BetaBoy
15th September 2008, 02:03
as far as I can tell this was related to the fade in/out bug we fixed as in the new internal version I am using does not have the bug shown.

bob0r
15th September 2008, 05:42
Ok so not the version i have then :)

Also BetaBoy do you still plan to give Neuron2 some SDK to use CoreAVC for his tools? He is on a coding spree now and it would be awesome to use the best decoder for the best indexer! (Well nothing is best on doom9 and truely so, bugs are always present :D)

Please give him a clear answer and don't apply the old Core methods on him!!

Dark Shikari
15th September 2008, 05:47
x264 cannot possibly produce videos that would trigger the CoreAVC bug because it doesn't use weighted P-frame prediction.

BetaBoy
15th September 2008, 11:44
Ok so not the version i have then :)

Also BetaBoy do you still plan to give Neuron2 some SDK to use CoreAVC for his tools? He is on a coding spree now and it would be awesome to use the best decoder for the best indexer! (Well nothing is best on doom9 and truely so, bugs are always present :D)

Please give him a clear answer and don't apply the old Core methods on him!!
Don't worry... We have been talking by email and we will let everyone one know the outcome.

G_M_C
15th September 2008, 11:50
Don't worry... We have been talking by email and we will let everyone one know the outcome.

I'm not worried ... just anxious, since i'm a long-time user of DGAVCIndex :)

BetaBoy
15th September 2008, 12:44
as far as I can tell this was related to the fade in/out bug we fixed as in the new internal version I am using does not have the bug shown.
I take that back... for some reason I must have skipped the frames with the blocking. We are looking at it more.

BetaBoy
16th September 2008, 13:36
any news on NV12 support ?

NV12 has now been added for the next release.

BetaBoy
19th September 2008, 22:21
Since you all are gonna find out soon enough (and I'm being PM'd/Emailed about it)... 'after' the next bug fix release, we are set to unleash an NVIDIA CUDA compatible version of CoreAVC Professional. Our results atm shows a pretty impressive performance increase. But I'll save that talk for when we release it.

tomos
20th September 2008, 00:26
what about hardware acceleration for ATi cards?

xW0Lf
20th September 2008, 19:13
anyway.. using CUDA is similar/same as "using shaders" to offload part of hard CPU work to GPU...
if "programing shaders" is same/compatible between nvidia/ati... we can expect same for ATI..

it's great way to invrease performance avoiding limitation of dedicated chips in latest ati/nvidia cards (that have some limitation, 1080p number of referenced frames as example)
i hope that using shaders instead of dxva calls is great way to override limitations....
i'm right or not?

TheShadowRunner
20th September 2008, 19:18
xWOLf, I wonder the same and hope so as well ;)

xW0Lf
20th September 2008, 19:34
i can ask betaboy for more info..
as we know, in all new nvidia/ati cards shaders is quick as hell, and can, if properly used, to decode h.264 streams must quicker than cpu...

actually, ATI add h.264 support to 2900 cards, even they not have UVD chip, guess how? ofcourse, using shaders!

Mangix
20th September 2008, 23:24
recently found a bug. if i use CoreAVC with VMR9, the output levels will be PC levels instead of being TV levels if i have it on autodetect. makes the colors look brighter if i have VMR9 set to "full range" through the nvidia control panel. selecting tv levels instead of autodetect fixed the problem :)

Disabled
21st September 2008, 00:32
Cuda 2.0 offers access to the chip doing the DXVA, so you can decode h264 without the use of shaders using the decoder engine provided only by cards like 8800 GTS512 & GT, 86xx, 84xx, 9xxx and GT260/280 and not 8800 GTS640/320 and GTX or even 7xxx cards.
neuron2 is doing the same with DGAVCIndex...

xW0Lf
21st September 2008, 00:57
this is nice, but what about ATI.. ATI customers/fanbase is pretty big too... we want something similar for us TOO :)

BetaBoy
21st September 2008, 01:00
xW0Lf... I am going to ask that you stop the ATI flaming in this thread. Your point has been taken, next.

xW0Lf
21st September 2008, 01:21
hmmm , you are a bit nervous...
it's not good at all, with or without your power to change things. in good or in bad way...

sorry because i disturb/upset you in any way, but you can choose other way to say your line, don't be arrogant!

BetaBoy
21st September 2008, 01:43
Ugh... arrogant? Please... every time you 'poke' a comment in this thread for the past year+, you have nothing of value to add. DXVA? Not anytime soon as far as I'm concerned. ATI sure we want to support it... Do they have anything like CUDA? Nuff said... any moderator want to handle this?

xW0Lf
21st September 2008, 01:57
not needed.. i will stop with comments here (this post)...
about ATI, i'm not expert for software, but know that nvidia and ati have shaders that can be programed... not only for visual FX in games.... just trying to ask for posibility to use it for some strong math/calcs needed for h.264 streams... not have bad itentions at all....
it's all

Disabled
21st September 2008, 02:20
ATI sure we want to support it... Do they have anything like CUDA? Nuff said...
I always thought they had the Stream SDK, but with a short search I could not make clear if it only supports the Firestream cards or not. Then there are other solutions like Rapidmind, but I again don't know how feasable that is.

I was hoping you jumped on my last post to say youre not using the hardware decoder with cuda 2.0, but you didn't, so I'll just ask: What cards will be supported?
Since you all are gonna find out soon enough...

ChronoCross
21st September 2008, 02:56
Ugh... arrogant? Please... every time you 'poke' a comment in this thread for the past year+, you have nothing of value to add. DXVA? Not anytime soon as far as I'm concerned. ATI sure we want to support it... Do they have anything like CUDA? Nuff said... any moderator want to handle this?


lol Dan your right. I clicked his profile and checked all of his posts and there isn't a single one that isn't in a DXVA related thread.

I'm an ATI Fan as well but I haven't seen anything related to CUDA for ATI. Hopefully they have somethign similar in the works if people start clamoring for it. I know their Linux drivers have come a long way since they got involved and their drivers outclass nvidia on linux so there is hope for community pressure

Keiyakusha
21st September 2008, 03:02
Maybe this is some bug in CoreAVC 1.7.0.0 & 1.8.0.0 ...

When I have a file that contain two or more h264 video streams with different FPS (1st stream 29.97 and 2nd 23.976 for example) and when I switch between them, I see this thing (http://img255.imageshack.us/img255/8152/snapshot20080921033931yx1.jpg). Colors (in this case Yellow) is shifted too.
When I get this strip over video, it can be removed only if I switch any option in CoreAVC settings durring playback. mp4 and mkv works the same way.

I'm thinking this is a bug, because when I use FFDshow or MPC's internal decoder - this is not happens.
Usually I do not have such files, so it is only now being noticed. I'm using Haali splitter & MPC-HC on WinXP SP3 32bit

P.S.
Sorry for bad English...

AVmaniac
21st September 2008, 03:13
I always thought they had the Stream SDK, but with a short search I could not make clear if it only supports the Firestream cards or not.

I did some search to because i was a bit interrested in the developement of using GPUs for computing non graphical infomation these days.


Found this at AMD's website:http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=95060&enterthread=y

Q: Will the AMD FireStream SDK work on previous generation hardware?

A: To run the CAL/Brook+ SDK, you need a platform based on the AMD R600 GPU or later. R600 and newer GPUs are found with ATI Radeontm HD2400, HD2600, HD2900 and HD3800 graphics board.

professor_desty_nova
21st September 2008, 09:49
From what I have been reading, ATI is thinking of abandoning their current GPGPU software/interface solution in favour of OpenCL. So if NVidia in the future also suports it, you could have GPU accelaration on any graphics card without the problem of proprietary solutions.

STaRGaZeR
21st September 2008, 12:42
ATI sure we want to support it... Do they have anything like CUDA? Nuff said...

Yes, they're supporting OpenCL instead of CUDA. In their own words this is because CUDA is a propietary solution and they don't want to be NV's puppet.

CiNcH
21st September 2008, 12:51
Yes, they're supporting OpenCL instead of CUDA.

And DirectX 11. But those IMHO won't provide something similar to the CUDA Video API which allows accessing the PureVideo CoProcessor. It is just for general purpose computation via shader units.
Dunno whether CoreCodec will use the CUDA Video API or just source out some algorithms onto the shaders...

STaRGaZeR
21st September 2008, 15:03
And DirectX 11. But those IMHO won't provide something similar to the CUDA Video API which allows accessing the PureVideo CoProcessor. It is just for general purpose computation via shader units.
Dunno whether CoreCodec will use the CUDA Video API or just source out some algorithms onto the shaders...

Maybe BetaBoy could answer that one, but IMO using only shaders is the best solution. Much more flexible as they are general purpose that can do virtually everything instead of a fixed video processor unit with certain limitations. The same goes to ATI, they have the UVD processor but it has obvious limitations.

Keiyakusha
21st September 2008, 15:08
Maybe this is some bug in CoreAVC 1.7.0.0 & 1.8.0.0 ...

When I have a file that contain two or more h264 video streams with different FPS (1st stream 29.97 and 2nd 23.976 for example) and when I switch between them, I see this thing (http://img255.imageshack.us/img255/8152/snapshot20080921033931yx1.jpg). Colors (in this case Yellow) is shifted too.
When I get this strip over video, it can be removed only if I switch any option in CoreAVC settings durring playback. mp4 and mkv works the same way.

I'm thinking this is a bug, because when I use FFDshow or MPC's internal decoder - this is not happens.
Usually I do not have such files, so it is only now being noticed. I'm using Haali splitter & MPC-HC on WinXP SP3 32bit

P.S.
Sorry for bad English...

Ok, I found out that if output in CoreAVC is set to RGB, this is not happens. And as I said this happens only if streams have different FPS. Any suggestions?

deekey777
21st September 2008, 17:53
From what I have been reading, ATI is thinking of abandoning their current GPGPU software/interface solution in favour of OpenCL. So if NVidia in the future also suports it, you could have GPU accelaration on any graphics card without the problem of proprietary solutions.




I don't think it was that press release, rather a conference held before HD 4870 X2's launch - there was an element of sensationalism in the headline. In reality CTM evolved into CAL some time ago, and CAL will remain as the enabler for our Stream compute ecosystem by being the interface to the hardware - OpenCL, Cobra, Brook+, 3rd party toolsets will layer on top of this.
...
http://forum.beyond3d.com/showpost.php?p=1207463&postcount=11

Cyber-Mav
22nd September 2008, 04:10
Maybe BetaBoy could answer that one, but IMO using only shaders is the best solution. Much more flexible as they are general purpose that can do virtually everything instead of a fixed video processor unit with certain limitations. The same goes to ATI, they have the UVD processor but it has obvious limitations.

its not that simple to "just use the shaders" for the video processing. you need to interface with the streamprocessors/shaders on the graphics cards. Shader programming language is more complex to deal with compared to CUDA which uses the standard C language to communicate with the shaders and makes them do what the programmer wants to achieve.

CUDA really does make it much easier to use hardware like graphics cards to do complex processing without having to create a custom engine or api to interface with the shaders and means that programmers dont have to learn shader language to get the shaders to do what the programmer requires.

have a read up on here: http://www.nvidia.co.uk/object/cuda_what_is_uk.html

ati do have a method/api for interfacing with the shaders on thier graphics cards, i believe its called CTM and like OpenCL, its no where near as far developed and supported as CUDA is though.

one thing to remember, CUDA support is provided for free by Nvidia, even ATi are allowed to have their cards support CUDA with no royalty payments or catches. It has also been shown that 3rd party modified drivers bring working CUDA support to ATi graphics cards, so it is possible for ATi to adopt CUDA, but if they do or dont, well its up to them.
One thing to take into account is that CUDA is very large in its user base, many specialist companies are using it for thier specific applications, e.g the hospital in my city uses a CUDA accelerated system for tomographic scans (some sort of 3D x-rays).

Cyber-Mav
22nd September 2008, 04:21
Ugh... arrogant? Please... every time you 'poke' a comment in this thread for the past year+, you have nothing of value to add. DXVA? Not anytime soon as far as I'm concerned. ATI sure we want to support it... Do they have anything like CUDA? Nuff said... any moderator want to handle this?

wanted to ask you a question betaboy, how hard did you find it to program using CUDA? i personally have done some work on shader programming in the past using high level shading language (HLSL), but when i started using CUDA i found it to be much easier to understand and use compared to hlsl.

Dark Shikari
22nd September 2008, 04:34
wanted to ask you a question betaboy, how hard did you find it to program using CUDA? i personally have done some work on shader programming in the past using high level shading language (HLSL), but when i started using CUDA i found it to be much easier to understand and use compared to hlsl.Odd, I found the opposite; CUDA was a total nightmare for me, and I wince every time someone says "its just like standard C," since that's an unbelievably obvious lie to anyone who has ever used it. After the amount of effort I put into it trying to do something as basic as a series of SADs, and then later my company hiring a CUDA expert to try to implement a simple motion search and that failing too.

Hell, I would rather learn GPU assembly than program in that nightmare.

BetaBoy
22nd September 2008, 05:02
Ok, I found out that if output in CoreAVC is set to RGB, this is not happens. And as I said this happens only if streams have different FPS. Any suggestions?

That's already fixed for the next release. Thanx for the report.

Cyber-Mav
22nd September 2008, 15:14
Odd, I found the opposite; CUDA was a total nightmare for me, and I wince every time someone says "its just like standard C," since that's an unbelievably obvious lie to anyone who has ever used it. After the amount of effort I put into it trying to do something as basic as a series of SADs, and then later my company hiring a CUDA expert to try to implement a simple motion search and that failing too.

Hell, I would rather learn GPU assembly than program in that nightmare.

hmm, it could be more complex to implement video codec/decoder with CUDA, i found for my purposes features like scattered writes were very beneficial to me.
although im using CUDA for 3D design purposes and your using it for video purposes so the type of data we deal with is different.