CoreCodec/H.264 Codec "CoreAVC"

[Chainmax]

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]

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]

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]

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]

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]

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]

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]

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]

ofcourse

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

[bmnot]

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]

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]

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]

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]

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]

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]

The world does not need VC-1 at all...

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

[ChronoCross]

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]

Oh ! I'm way too slow ;) Updates are being sent per email.

I hope to finish the trial version soon.

[Kurtnoise]

How can I retrieve my serial number ? I lost the email which including it...:o

[Jay Bee]

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]

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

- Add: RGB656 and RGB555 Output format support

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

[nm]

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]

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]

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]

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]

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]

How are you guys creating these stats?

[Disabled]

I'm using timecodec from here (http://haali.cs.msu.ru/mkv/timeCodec.exe).

[Jay Bee]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

We are looking into the reported issue and will likely have 1.6.1 pushed out soon.

[JohnnyFu]

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]

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]

@ 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]

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]

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]

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]

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]

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]

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.