CoreCodec/H.264 Codec "CoreAVC" [Archive] - Page 68

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

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

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.