CoreCodec/H.264 Codec "CoreAVC"

[TheShadowRunner]

bob0r, which version of the Cyberlink H.264 Decoder?
Also i assume those numbers are for software mode?
Later,

TSR

[bob0r]

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

[TheShadowRunner]

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]

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

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

[TheShadowRunner]

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]

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]

Rule 6, you're fired!

[lexor]

Originally Posted by BetaBoy

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]

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-r...ecrets-071119/

[BetaBoy]

lexor... If you go back over this thread I stated:

Originally Posted by BetaBoy

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...

Originally Posted by BetaBoy

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]

Originally Posted by BetaBoy

...

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]

Originally Posted by BetaBoy

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]

Originally Posted by BetaBoy

...

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]

Originally Posted by bob0r

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]

Originally Posted by bkman

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]

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]

Originally Posted by bob0r

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]

Originally Posted by BetaBoy

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]

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]

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