CoreCodec/H.264 Codec "CoreAVC"

[madshi]

What that thread was about was really conversion from 8bit to 10bit (for encoding), not the other way around.

For 10 to 8, there really is only one proper way to do it, and that is dithering, with saturation/clipping.
Agreed.

(Of course ideally no downconversion should be done at all, passing the full bitdepth downstream, but only very few DirectShow filters accept high bitdepth content.)

[mandarinka]

However, doesn't x264's upconversion match swscale's downconversion? I was under the impression that when x264 converts 128 to 514, swscale will convert the 514 back to 128, which is why nobody noticed this shift in 10bit, initially.
While the proper process would be 128 -> (x264) -> 512 -> (swscale) -> 128. Dithering only makes the conversion higher quality, but doesn't help when the conversion uses wrong relation, does it?

[nevcairiel]

The downconversion in swscale uses dithering and shifting, there is nothing special there.

[cyberbeing]

However, doesn't x264's upconversion match swscale's downconversion? I was under the impression that when x264 converts 128 to 514, swscale will convert the 514 back to 128, which is why nobody noticed this shift in 10bit, initially.
For 10-bit -> 8-bit conversion it seems to be a swscale implementation problem, rather than a swscale problem.

Implentation #1: madVR, MPlayer (swscale), and FFMS2 (lav?) overall match the color/hue of each other.

Implentation #2: FFDShow (swscale) and LAV Video (swscale) match the color/hue of each other.

Implemation #1 is assumed to be correct way, but nobody on the FFDShow/LAV-Video side has taken the time to figure out why their swscale results differ from MPlayer swscale results and others...


The downconversion in swscale uses dithering and shifting, there is nothing special there.

The nothing-special 10-bit -> 8-bit near-matching downconversion of swscale implementation in FFDShow/LAV-Video, does come much closer to reversing the skewed encoded levels of x264 swscale 8-bit -> 10-bit than the 10-bit -> 8-bit near-matching downconversion of madVR, ffms2, and the swscaled implementation in MPlayer.

Since nobody seems to have any desire to fix swscale in x264 anytime soon, I think this is a valid question for CoreCodec.

A) For the time being does CoreAVC assume all 10-bit x264 encodes have skewed levels, and actively attempt to reverse the problem in 10-bit -> 8-bit conversion? When x264 is fixed, a quick 3.0.x release is pushed out with proper 10-bit -> 8-bit conversion?

B) Does CoreAVC support both a skewed x264 10-bit levels correction as well as proper conversion from the start, and add a toggle in the settings dialog?

C) Does CoreAVC only do proper 10-bit -> 8-bit conversion and show the skewed levels in the source as madVR, ffms2, and MPlayer do?

D) Does CoreAVC do none of the above and just mimic FFDShow/LAV-Video 10-bit -> 8-bit?

[nevcairiel]

I looked at the conversion in swscale that was used before, and it does use some scaling logic that trys to avoid overflows, maybe that logic was tuned against a broken encode - on the first glance it didn't look all that special, but i didn't double check the math, as its not needed for my case.

The next LAV Video will do proper 10bit -> 8bit conversion, because i implemented my own algorithm for dithering (which is much faster then swscale, because i wrote it using SSE2, and avoids overflows automatically).
If the source is broken, then the source is broken. For the best quality, you shouldn't convert it to 8-bit anyway (which means you'll see the encoder error with madVR, too)

You should instead pressure x264 to fix it, rather then trying to get every 10-bit capable decoder out there to implement hacks to work around bugs in the encoder.

[cyberbeing]

You should instead pressure x264 to fix it

I just did a Google search, and it looks as if today, a libav dev finally took interest in fixing the problem. So maybe this actually will get resolved in the near-future:

http://thread.gmane.org/gmane.comp.video.libav.devel/9285

[JEEB]

Implentation #1: libav swscale (by BBB)

Implentation #2: ffmpeg swscale (by michaeln)
And they are both broken at the moment, as you have found out (at least when comparing to BT.709 and MS's limited YUV range implementations) :)

Also, it would be possible to use the borked algorithm based on the SEI encoder version information in case it exists in the stream, but the possibility of this should only be thought about after x264 gets fixed in this sense :) .

[mandarinka]

That would however try to "fix" the skew in all encodes from affected x264 revisions, which could be wrong - for example, if you feed x264 with video that already is 10bit, it won't run its conversion (I assume?), video will have the proper levels and thus the workaround will mess it up.

[nevcairiel]

Indeed, the conversion to 10bit needs to be fixed to match native 10bit material as closely as possible, so that one playback processing path can be devised that works perfectly, no matter what was the source.

[madshi]

@BetaBoy, allow me to follow up on the discussion about RGB output levels we had in the other thread. Please have a look at this sample file:

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

It's a smooth 8bit gray ramp. Now please playback that ramp with CoreAVC, by outputting NV12 to madVR and switch madVR to PC levels. Afterwards switch CoreAVC to RGB output and use any renderer you like. Compare image quality. Here are screenshots for a quick comparison:

screenshot 1: (http://madshi.net/levelsChange1.png) CoreAVC outputs NV12 (video), madVR converts to RGB (PC)
screenshot 2: (http://madshi.net/levelsChange2.png) ffdshow outputs RGB (video), madVR converts to RGB (PC)
screenshot 3: (http://madshi.net/levelsChange3.png) CoreAVC outputs RGB (PC), madVR displays the result untouched
screenshot 4: (http://madshi.net/levelsChange4.png) ffdshow outputs RGB (PC), madVR displays the result untouched

You see the problem?

Changing levels in 8bit is a very bad idea, and that's what CoreAVC is doing (and ffdshow, too). The same banding artifacts will occur with YUV output, too, of course, if you modify the input/output levels. IMHO the default configuration of CoreAVC should be to leave levels untouched. If the source is encoded in limited range (16-235) then CoreAVC should output both YUV and RGB as limited range by default. If the source is encoded in full range (0-255) then CoreAVC should output both YUV and RGB as full range by default. Only this way gradients will stay smooth. madVR performs any necessary levels conversions in floating point math and dithers the result down to 8bit, which is of course much higher quality. So levels changes should best be left to the renderer, at least by default.

Of course this is just my personal opinion. If you want to implement a better quality algorithm for changing levels (using higher internal bitdepth, with a final dithering pass), that'd be fine with me, too.

Ideally, whatever you do with the levels, it would be great if you could inform the downstream filters about it. That way the renderer would be able to automatically adjust. The easiest way to pass this information along would be to use the DXVA_ExtendedFormat structure (which is an optional part of the VIDEOINFOHEADER2 structure), as mentioned in the other thread. For the output levels information you'd just have to fill the "NominalRange" part of the structure. Of course if you want to fill the other parts, too, that'd be nice. You'll find more information about how to convert the h264 header elements into DXVA_ExtendedFormat values in the following post:

http://forum.doom9.org/showthread.php?p=1519740#post1519740

[BetaBoy]

Madshi.... Thx again. We cannot do much for CoreAVC 3.0 considering we are about to go 'gold' and release it but we are looking at the suggestions for followup releases.

[madshi]

That's just fine, BetaBoy. After all CoreAVC works well with its default settings. So my suggestions are not urgent.

[TheFluff]

IMHO the default configuration of CoreAVC should be to leave levels untouched. If the source is encoded in limited range (16-235) then CoreAVC should output both YUV and RGB as limited range by default. If the source is encoded in full range (0-255) then CoreAVC should output both YUV and RGB as full range by default.

Excuse me for a second here, but how is it that the phrase "limited range RGB" makes any sense whatsoever to you? I'd very much like to be enlightened, because you seem to be in the possession of some truly Lucy-in-the-Sky-with-Diamonds-level shit and I'd like to try it.

[mandarinka]

I was under the impression that projectors (and maybe some TVs) commonly expect limited range in rgb too, meaning that if you feed them full range, you'll get overcontrasted image with darks and brights clipped to black/white.
In any case ffdshow (and other decoders) do have a setting to output 16-235 range RGB, apparently for this reason...

(please correct me if that's not true...)

[madshi]

Excuse me for a second here, but how is it that the phrase "limited range RGB" makes any sense whatsoever to you? I'd very much like to be enlightened, because you seem to be in the possession of some truly Lucy-in-the-Sky-with-Diamonds-level shit and I'd like to try it.
There are 2 types of displays:

(1) Computer monitors, mostly LCD.
(2) CE (Consumer Electronics) displays, like LCD TVs, plasma TVs, projectors etc.

In the computer world, black has historically always been RGB(0,0,0). So if you send RGB to a (1) display, the display expects black to be at RGB(0,0,0). However, in the CE world, things are quite different. There we have things like BTB (blacker than black) and WTW and black is usually expected to be at RGB(16,16,16). Standalone hardware DVD players and Blu-Ray players usually output black at RGB(16,16,16), if you switch them to RGB output. Some DVD/Blu-Ray players and some TVs/projectors can be switched between limited range (black = 16) and full range (black = 0) mode, but not all. The PS3 and Xbox360 can be switched between limited and full range, too, AFAIK. There are different names for that switch, e.g. Limited vs. Full, or Studio vs. Computer, or TV vs. PC, or Normal vs. Extended etc...

99.9% of all h264 consumer content is encoded in YCbCr 4:2:0 with black at Y = 16 and white at Y = 235. If you switch the h264 decoder to output RGB, the decoder can either output black at RGB(0,0,0) or at RGB(16, 16, 16). The latter requires less processing. Outputting black at RGB(0,0,0) means that after YCbCr -> RGB conversion you need to perform a stretch operation to get black from 16 to 0 and white from 235 to 255. This stretch operation introduces visible banding if you perform it in 8bit. That's why I'm asking Core to skip this stretch operation and to inform the downstream filters about whether the CoreAVC RGB output has black at 0 or 16.

All cleared up now?

[fastplayer]

All cleared up now?
By the way, you explain technical "stuff" very comprehensible. :)

[madshi]

Thanks. :)

[Stephen R. Savage]

Outputting black at RGB(0,0,0) means that after YCbCr -> RGB conversion you need to perform a stretch operation to get black from 16 to 0 and white from 235 to 255. This stretch operation introduces visible banding if you perform it in 8bit.

This is a completely illogical claim. Conversion between YUV and RGB and from limited to full-range are both linear processes, so there is no reason that they must be done in two steps.

[madshi]

This is a completely illogical claim.
You could have left this sentence away, you know. No need to be impolite.

Conversion between YUV and RGB and from limited to full-range are both linear processes, so there is no reason that they must be done in two steps.
Doing it in two steps is how it's usually done, and probably done by CoreAVC. You're right, though, in that it could be done in one step. But even if you do it in one step, you'll still get banding, if you use simple rounding. The only way to avoid banding would be to use dithering or to output a higher bitdepth than 8 bit.

[Stephen R. Savage]

Doing it in two steps is how it's usually done, and probably done by CoreAVC. You're right, though, in that it could be done in one step. But even if you do it in one step, you'll still get banding, if you use simple rounding. The only way to avoid banding would be to use dithering or to output a higher bitdepth than 8 bit.

Everything that you say here is correct, and yet it still doesn't logically follow that "limited-range" RGB is a preferable output format. Even if the default output range in CoreAVC were changed, it would still be rounded (probably truncated, actually), etc. Further, a direct conversion from limited YUV to full-range RGB does not add any more rounding error than a conversion from limited YUV to limited RGB, since both involve the same number of 8-bit multiply/divide operations.

The only thing that will change is that suddenly everyone will have broken levels in something that used to work just fine.

[madshi]

Everything that you say here is correct, and yet it still doesn't logically follow that "limited-range" RGB is a preferable output format. Even if the default output range in CoreAVC were changed, it would still be rounded (probably truncated, actually), etc. Further, a direct conversion from limited YUV to full-range RGB does not add any more rounding error than a conversion from limited YUV to limited RGB, since both involve the same number of 8-bit multiply/divide operations.
I'm sorry, but I disagree. Let's look at a simple gray ramp:

Y: 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, ...
Cb: 128, 128, 128, ...
Cr: 128, 128, 128, ...

Try to convert that to full range RGB and to limited range RGB with rounding. You'll get smooth output with no banding with limited range RGB, but you'll get banding with full range output. The simple reason for that is that with a gray ramp the Y values map directly to the limited range RGB output. E.g. YCbCr 16,128,128 converts to exactly RGB 16.0,16.0,16.0. Of course it would be preferred to perform dithering after the YCbCr -> RGB conversion. When dithering is used, both limited and full range output should be banding free.

If you don't believe me, just look at the screenshots I posted. Compare ffdshow limited vs. full range RGB output. These screenshots undeniably proof what I just said. Unless you believe that I faked the screenshots or made a mistake? If so, it should be easy for you to double check yourself.

The only thing that will change is that suddenly everyone will have broken levels in something that used to work just fine.
All renderers (other than madVR) passthrough RGB untouched. If CoreAVC always outputs PC levels, users which have a projector/TV which needs TV levels will get broken levels, while users with a computer type monitor will get correct levels. IMHO this behaviour is already broken right now. CoreAVC has three switches for output levels, "PC", "TV" and "Auto detect". All I'm asking for is to honor these switches for RGB output, too. If users need CoreAVC to output RGB with PC levels, like it does now, it should be no problem for them to manually change the CoreAVC settings accordingly.

[Stephen R. Savage]

All renderers (other than madVR) passthrough RGB untouched. If CoreAVC always outputs PC levels, users which have a projector/TV which needs TV levels will get broken levels, while users with a computer type monitor will get correct levels. IMHO this behaviour is already broken right now. CoreAVC has three switches for output levels, "PC", "TV" and "Auto detect". All I'm asking for is to honor these switches for RGB output, too. If users need CoreAVC to output RGB with PC levels, like it does now, it should be no problem for them to manually change the CoreAVC settings accordingly.

Shocking! Computer software is written to specifications that match typical computer hardware!

[Audionut]

Shocking! Computer software is written to specifications that match typical computer hardware!

That might have made sense 10 years ago. Now it just goes to show that your a typical user who thinks his setup is default and anything else shouldn't be accounted for.

[robpdotcom]

Isn't the fact that madVR does things differently from "all other renderers" one of the things that makes it better than all other renderers?

[Stephen R. Savage]

That might have made sense 10 years ago. Now it just goes to show that your a typical user who thinks his setup is default and anything else shouldn't be accounted for.

What about my typical user?

As for this meaningless ad hominem attack, what madVR and CoreAVC do make no difference to me, seeing as I use neither. I merely wanted to point out the delusion required to claim that "limited-range RGB" as a default made any sense.

[Nevilne]

Honestly adding a menu choice of how to handle RGB input seems to be the best option for madvr, you can see some valid points from both camps.

But back to coreavc, are there any benchmarks from 3.0 beta or is it under NDA?

[madshi]

Shocking! Computer software is written to specifications that match typical computer hardware!
In case you didn't know, a key market for both CoreAVC and madVR is HTPCs. And if you look up "HTPC" at wikipedia, it says:

> Standard PC units are usually connected to
> a CRT or LCD display, while HTPCs are designed
> to be connected to a television

And "televisions" typically expect limited range RGB, not full range RGB. So designing CoreAVC to forcefully always output full range RGB doesn't make much sense.

I merely wanted to point out the delusion required to claim that "limited-range RGB" made any sense.
Delusion? You want to ignore the fact that (rounded or truncated) full range RGB output results in visible banding, while limited range RGB output does not (see screenshots)? You want to ignore the fact that TVs and projectors need limited-range RGB? Ok, I give up. If you choose to ignore hard proof and facts then there's really no point in discussing this any further.

[Stephen R. Savage]

Delusion? You want to ignore the fact that (rounded or truncated) full range RGB output results in visible banding, while limited range RGB output does not (see screenshots)? You want to ignore the fact that TVs and projectors need limited-range RGB? Ok, I give up. If you choose to ignore hard proof and facts then there's really no point in discussing this any further.

If some esoteric hardware requires a different, obscure RGB format, the answer is not to change the default behavior and break compatibility with the majority of end-users. As for your claim regarding banding, first of all, essentially no end-user cares about quality; this is a verifiable fact. More importantly, if you really cared about quality, you would only use the YV12/NV12 format anyway, since any RGB, regardless of range, will already be rounded or truncated to 8-bit.

When someone chooses RGB output, especially in something like CoreAVC which doesn't even pretend to have high-quality conversion, chances are they aren't concerned about banding or anything like that, but merely want to quickly display something in some application that requires RGB. And chances are, such legacy applications will require full-range RGB, the standard format.

Besides, even if the default behavior for RGB conversions were changed, you would still be on here telling people to use YV12 and trust in the Magic Power (TM) of madVR color conversions. So, really, I don't see why it's such a big deal to you.

[ranpha]

If some esoteric hardware requires a different, obscure RGB format, the answer is not to change the default behavior and break compatibility with the majority of end-users. As for your claim regarding banding, first of all, essentially no end-user cares about quality; this is a verifiable fact. More importantly, if you really cared about quality, you would only use the YV12/NV12 format anyway, since any RGB, regardless of range, will already be rounded or truncated to 8-bit.


Since when TVs and projectors has been categorized as 'esoteric hardware'? I bet that TV/projectors that supports limited range will greatly outnumber those that support full range RGB. And since when limited range RGB has become a 'different,obscure RGB format'? Engineers from AMD (the champion of limited range RGB) will want to have a word with you about that.

BTW, 'quality' and 'RGB' are not mutually exclusive options even in the context of CoreAVC. All CoreCodec needs to do is to fix the bug mentioned in this thread before. You can have your cake and eat it too you know.

When someone chooses RGB output, especially in something like CoreAVC which doesn't even pretend to have high-quality conversion, chances are they aren't concerned about banding or anything like that, but merely want to quickly display something in some application that requires RGB. And chances are, such legacy applications will require full-range RGB, the standard format.

If one of the 'applications that requires RGB' (which definitely is not mainstream video players like MPC-HC or WMP or KMPlayer et. al.) can actually use CoreAVC, you can definitely subvert its requirements and make it output YV12 or NV12.

Oh BTW, can you give an example of an 'application that requires RGB' that can also use CoreAVC? I cannot think of one.

[ryrynz]

I believe this argument has gone beyond logical debate.
I think your time could be much better spent doing something other than arguing the merits of implementing a feature for which the both of you have successfully proven the benefits of implementing. ;)

[BetaBoy]

We just went 'gold' with CoreAVC 3.0. We will release CoreAVC 2.6 later today and have set a release date of Tuesday Sept 6th for CoreAVC 3.0.

[BetaBoy]

The release is being sent now...


CoreAVC H.264 Video Codec - Version 2.6.0.0 (20110830)
- ADD: DXVA fallback to software
- ADD: Improved DXVA handling for interlaced streams
- ADD: DXVA 2 Long slice support
- CHG: Use container AR when there is no stream AR
- FIX: Improved Frame order handling
- FIX: Hardware deinterlacing field order

Haali Media Splitter - Version 1.11.233.7 (20110830)
- FIX: Various DTS Audio bugs
- ADD: Improved DTS support
- ADD: Support for MVC 3D videos

[BetaBoy]

As you can see we also pushed out a new Haali splitter that addresses some (not all) of the leading issues as well as adding support for MVC. This is ahead of of releasing CoreMVC 3D which we expect to do after the CoreAVC 3.0 dust settles.

[TheShadowRunner]

If/Since CoreAVC 2.x won't support decoding of Hi10P/10-bit video, would it be possible for you to please do a maintenance release for 2.x so that it automatically won't be used when a 10-bit video is played?

Guess not :/

[BetaBoy]

Try it and see.

[nevcairiel]

Try it and see.

I did, and 2.6 does infact not refuse, it trys to decode, and ends up with a black screen. It doesn't fallback to a decoder that is 10-bit capable.

[TheShadowRunner]

Try it and see.

Oh an unadvertized feature? This sounds promising ;)
A somewhat related question, I'm stuck with nvcuvid.dll version 266.58 because of a nVidia bug that has Windows XP BSOD when playing flash videos with certain cards (8x00 / 9x00) and any drivers above 266.58.
Does the nvcuvid.dll version make a difference when it comes to decoding with CUDA? (I guess I could replace my current nvcuvid.dll 266.58 by one from the latest 280.26 driver package if it does)

[BetaBoy]

You beat me too it (on the feature) ;-)

nevcairiel... correct 2.6 will not fallback to another codec, but show a black screen for hi10 content.

TheShadowRunner... From our discussions internally, no it should not matter what DLL you are using.

betaking... Sorry about that... the accounts are a 'rolling' update and sometimes emails get ahead of the update to your account. Check back in a lil bit, it should be there.

[betaking]

Hi.betaboy I received e-mail prompted me to go to the website to update to 2.6, but I found that after landing, or you can still download version 2.5.5!
and i can not found Haali Media Splitter - Version 1.11.233.7 (20110830) in haali's website!

[TOM_SK]

[Off-topic]
@Marlin: Hi, is there any affiliate/reseller program for CoreAVC Professional Edition ? I looked everywhere on CoreCodec website but can't find any.

Thanks.

[BetaBoy]

TOM_SK... sure.... once you login to your account... Under 'Corporate' you'll see 'Affiliates', just hi the 'activate' button to enable it for your account. It will then give you the info you need.

RE: https://customers.corecodec.com/affiliates.php

[CiNcH]

2.5.5 broke DXVA with DVBViewer DVBSource filter

2.6 breaks compatibility with DVBViewer DVBSource filter "completely". Tray icon is blue (indicating no DXVA) and picture inside the DVBViewer stays black. It seems as if no data arrives at the renderer.

You promised us to look into the thing!?

[BetaBoy]

and i can not found Haali Media Splitter - Version 1.11.233.7 (20110830) in haali's website!
You will not find this version on Haali's site yet as its only in CoreAVC 2.6 and 3.0 because of all the work we have done to it.

I'll sync with him on updating his site.

[BetaBoy]

CiNcH.... the testers we had for DVBViewer did not indicate anything was broken. We are looking into it (again).

[BetaBoy]

A note... we are rolling out the 2.6 update to current customers first. We will list it's availability to the public next.

[nussman]

2.5.5 broke DXVA with DVBViewer DVBSource filter

2.6 breaks compatibility with DVBViewer DVBSource filter "completely". Tray icon is blue (indicating no DXVA) and picture inside the DVBViewer stays black. It seems as if no data arrives at the renderer.

You promised us to look into the thing!?

Same here ...
Maybe you need some new testers for dvbviewer? :rolleyes:

[BetaBoy]

We also found that some people are getting the error: Error loading C:\Program Files\CoreCodec\CoreAVC Professional Edition/CoreAVCDecoder64.ax
The specified module could not be found.

Added to the todo.

[TOM_SK]

We also found that some people are getting the error: Error loading C:\Program Files\CoreCodec\CoreAVC Professional Edition/CoreAVCDecoder64.ax
The specified module could not be found.

Added to the todo.

Got the same error when installing CoreAVC on 32-bit Windows 7 HP. Btw, pls. check your pm.

[BetaBoy]

yeah.... everything installs fine. It just looks like for some 32bit users they get the error.

[nussman]

I got the same message @Win7 32bit, but thats not the main problem with coreavc 2.6! ;)

[CiNcH]

Happened to me too. Did not mind either. There are indeed more important things to fix... still... things that have been called showstoppers within this thread.

[nussman]

Deinterlacing issue:

Seems to work with haali splitter, but the field order is still wrong with mpc-hc splitter (and i guess with all other splitters too?)!

[CiNcH]

So we have to find out what Haali Splitter does differently and how CoreAVC determines field order.

[BetaBoy]

32bit installer bug fixed for the next release.

[BetaBoy]

CiNcH.... Can you try and play local files in DVBViewer and see if u get the same results. Since we dont have any DVB service we just tested local content and it plays fine.

[betaking]

32bit installer bug fixed for the next release.

Next week or tomorrow?Another new version of coreaac planned it?

[CiNcH]

Local file does not work either...

http://members.inode.at/762450/coreavc/dvbsource_coreavc.jpg

Do you use latest version?

[BetaBoy]

Yes... and it works on 2 different systems.

[BetaBoy]

Next week or tomorrow?Another new version of coreaac planned it?

We are gonna push out a silent update for the installer issue in the next few hours.

[betaking]

We are gonna push out a silent update for the installer issue in the next few hours.

Thanks!

[CiNcH]

Yes... and it works on 2 different systems.
I have done some further tests with the DVBViewer 4.8.1 stock DVBSource version 3.5.5.

Additionally I tried various CoreAVC settings, I tried different renderers (EVR-CP, EVR Standard, VMR9 Renderless, VMR9 Standard, Overlay with Aero off under W7). No chance to get a picture.

[Guest]

I received this in email from Core:

---
This is a free upgrade. To get the 2.6 update, log in to your account
at https://customers.corecodec.com <https://customers.corecodec.com/>
and download it from the 'My Products' area.
---

But when I try to download there is no download offered and instead I get this in email:

---
We have received your order and will be processing it shortly. The details of the order are below:

Order Number: 8321699570

Upgrade Software: CoreAVC 2.5 (Free Upgrade from 2.0) => CoreAVC 2.6 (Free Upgrade from CoreAVC 2.5)
Billing Cycle:
Total Due Today: $0.00 USD

You will receive an email from us shortly once your account has been setup. Please quote your order reference number if you wish to contact us about this order.
---

I already have an account! I just want to download my free update. Why is this happening and when will I be able to download my update?

Thank you.

[nussman]

CiNcH.... Can you try and play local files in DVBViewer and see if u get the same results. Since we dont have any DVB service we just tested local content and it plays fine.
As far as i know there is no difference between "LiveTV" and "Playfile" when using dvbvsource filter.

Are you sure that dvbvsource filter was used in your tests?
Could you tell us your CoreAVC / DVBViewer settings?

[Romario]

What about 3.0 final, when we can expect it ?

[Chumbo]

I don't see 2.6 under My Products & Services on web site. What's the point of the email being sent out BEFORE the product is actually available?

[clokkevi]

The new CoreAVC 2.6.0 itself seems to work very well (for all the files I have),
however, after I installed the new Haali Media Splitter 1.11.233.7
most of my .mp4 files were not handled properly anymore.
The audio-streams were OK, but not the video-streams.
Haali would not connect to any of my AVC/H.264 decoders;
neither CoreCodec CoreAVC 2.6, MPC-HC's built-in H264/AVC (DXVA/FFmpeg) 6.4.0.2 , nor FFDShow 1.1.3611
(I always set the "Output" -> "Use custom media type for H.264" option in Haali Media Splitter to "no")

So I re-installed the old Haali Media Splitter 1.11.96.14,
and now all the .mp4 files are working again.

(The only .mp4 files I had that still continued to work with 1.11.233.7 installed,
were some that had "mp4v" / "MP4V" instead of "avcC" / "avc1" video-streams.)

[Chumbo]

I don't see 2.6 under My Products & Services on web site. What's the point of the email being sent out BEFORE the product is actually available?
Not very intuitive, but I figured it out. You have to click on your existing 2.x purchase and then there's a link to the "there's an upgrade available" at the top. Not the most obvious. It would be more helpful to have an "upgrade available" icon or something on the main products page.

[CiNcH]

@ BetaBoy,

did you actually play a TS/M2TS file via the DVBViewer with DVBSource in use? Please check 'View' -> 'Filters' within the DVBViewer to check which DirectShow filters are being used. Just to make sure that both, DVBSource and CoreAVC, are in the graph...

As far as i know there is no difference between "LiveTV" and "Playfile" when using dvbvsource filter.
Not quite. It's push vs. pull. Anyway, file playback (pull) is also affected.

[pankov]

BetaBoy,
you should consider finding a beta tester who actually has a DVB Service ... or at least somebody else with good upload speed who can share his existing one using the DVB Recording Service. It's pretty easy to do it but sadly my international upload speed won't be enough to sustain a HDTV channel (which is the one I have the deinterlace issues with)
:(
if you can't find one just PM me and we can try to clear the connection details and try with SD channel

[CiNcH]

I think that all problems so far were (or could have been) sorted out with files...

A push scenario can also be simulated BTW.

[mkanet]

I just upgraded to CoreAVC 2.6. I am currently use Cuda mode. It seems some of my videos have that screwed up green distortion issue I used to see only in DXVA mode. This issue is consistent with certain videos. If I were to guess, it looks like CoreAVC 2.6 is trying to use DXVA for certain videos; even though it doesnt work correctly and I have Cuda selected.

Any way I can fix this without reverting back to version 2.5.5?

PS: I'm sure you guys already know this, but there's a bug in the 2.6 installer, it complains that the 64bit coreavc decoder is missing. I'm using a 32bit OS.

Thanks

[josephwright]

Hi BetaBoy. I'm still experiencing the same hardware deinterlacing issue in 2.6 (with UK DVB in Mediaportal). Please let me know if I can provide any details to help get this fixed! Maybe a I could upload a test recording somewhere?

[BetaBoy]

The silent update to address the installer error is now live in the portal.

[BetaBoy]

Hi BetaBoy. I'm still experiencing the same hardware deinterlacing issue in 2.6 (with UK DVB in Mediaportal). Please let me know if I can provide any details to help get this fixed! Maybe a I could upload a test recording somewhere?
josephwright... yeah I will need a sample as all known hardware deinterlacing issues had been resolved.

[CiNcH]

josephwright... yeah I will need a sample as all known hardware deinterlacing issues had been resolved.
Just play the various samples that you already have within MediaPortal (or whatever player) with a different splitter than Haali (e.g. the MPC-HC MpegSplitter). You may still stumble over the field order issue...

[CiNcH]

Just for the records, plain and simple, field order for interlaced content is not fixed at all with splitters other than Haali:

Haali -> CoreAVC 2.6 (DXVA) -> EVR: OK
http://members.inode.at/762450/coreavc/haali_coreavc.jpg

MPC-HC MpegSplitter -> CoreAVC 2.6 (DXVA) -> EVR: FAILED
http://members.inode.at/762450/coreavc/mpcsplitter_coreavc.jpg

Just compare the station logo at the top right corner of the two above screenshots.

As I said, you have plenty of samples already. It should not be too hard to build a graph with MPC-HC MpegSplitter and EVR. Let me guess... it is a splitter bug? I am afraid it is not that simple. Haali is the only one who gets it straight? How about all the other decoders that manage to output a correct field order with all these buggy splitters?

So again, CoreAVC fixed nothing for me but only made things worse when it comes to the DVBViewer issue. So is this going to be the old game again? People post bug reports and samples and BetaBoy will leave the stage for a couple of months, finally returning to announce a new major version that fixes nothing at all? How nice you fixed the installer issue. A big one...

But I am sure you "will be looking into the issue"...

[BetaBoy]

@ BetaBoy,

did you actually play a TS/M2TS file via the DVBViewer with DVBSource in use? Please check 'View' -> 'Filters' within the DVBViewer to check which DirectShow filters are being used. Just to make sure that both, DVBSource and CoreAVC, are in the graph....

Yes, and we are not seeing any issue here.

[CiNcH]

Yes, and we are not seeing any issue here.
Try to get some 1080i content through. 720p seems to be working. But it is still SW only, no DXVA. This needs to be fixed too.

Summary:
- 1080i not working within DVBViewer with DVBSource and CoreAVC
- DXVA not working within DVBViewer with DVBSource and CoreAVC

[BetaBoy]

CiNcH... while I appreciate your feedback, I do not appreciate the remark but understand your issue. Simply put... Haali's is our official splitter and has always been and it works as it should. We will look into (as you say) and work with any other ones with reported issues.

[BetaBoy]

Try to get some 1080i content through. 720p seems to be working. But it is still SW only, no DXVA. This needs to be fixed too.

Summary:
- 1080i not working within DVBViewer with DVBSource and CoreAVC
- DXVA not working within DVBViewer with DVBSource and CoreAVC

We are trying now.

[CiNcH]

It seems as if the DVBViewer does not perform video pre-format detection anymore. Still I believe that you should not rely on the splitter propagating the correct values for the connection format.

Some versions back (before you added DXVA), CoreAVC worked happily with splitters propagation completely wrong information. Also format changes (720p <-> 1080i) worked. Now nothing works anymore.

[TheShadowRunner]

TheShadowRunner... From our discussions internally, no it should not matter what DLL you are using.

Thanks for the info!

[dansus]

2.5.5 broke DXVA with DVBViewer DVBSource filter

2.6 breaks compatibility with DVBViewer DVBSource filter "completely". Tray icon is blue (indicating no DXVA) and picture inside the DVBViewer stays black.


Ditto.

Wouldnt be so bad if we could downgrade.

[mkanet]

I just redownloaded 2.6 (after the silent update mentioned on this forum thread). The installer issue is still there (see below).

I also verified after a reboot that no matter what, CoreAVC 2.6 has a problem with a few of my ripped bluray files.

The best way I can describe the video problem is... I see a weird repetitive "1 second loop" from some parts of the video. So... Illl see someone's head nod up and down over and over again while the audio is going. Or someone swinging their arm back and forth over and over again. This happens when using DXVA, Cuda, and None. The problem goes away as soon as I revert back to CoreAVC 2.5.5 (or earlier).

I'm using the latest Nvidia drivers from their website and an Nvidia 8500GT display adapter. I dont see this problem with MPC-HC DXVA, ffdshow, or any other H.264 video decoders I have.

I have never been able to get DXVA to work with CoreAVC. I have no problems using DXVA with free MPC video decoder.

I only playback standard bluray spec files only (H.264).

http://i67.photobucket.com/albums/h283/mkanet/CoreAVC26-2.jpg

[BetaBoy]

I just redownloaded 2.6 (after the silent update mentioned on this forum thread). The installer issue is still there (see below).

This just means your account did not get the new version yet. Its takes a little time for it to be applied to all the accounts.

[CiNcH]

BTW, I reported the thing with the connection format some time back, see here (http://forum.doom9.org/showthread.php?p=1488503#post1488503).
As I said, in previous versions you did not rely on proper information from the splitter. Almost any decoder I tested so far doesn't. They are fine with some standard values. You again promised to have a look (http://forum.doom9.org/showthread.php?p=1488610#post1488610). I am sure you did. Guys, this is really getting ridiculous.

[BetaBoy]

As are your continued put downs. It would be easier if we simple state use Haai's splitter, but we won't. We have found on one of our dev boxes where we can duplicate the deinterlacing issue when not using HMS.

Haali: all frames are rendered correctly
MPC: two equal frames in a row (looks like deinterlaced first field)

It looks like Haali produces (first field, second field) and mpc (first field, first field).

[CiNcH]

Does a splitter even operate at such a deep level and know anything about fields? DVBSource for example knows nothing about this kind of stuff (like NALU's, fields and the like). It just propagates fixed size Elementary Stream chunks.

As are your continued put downs.
Another one of your standard phrases here at D9. Why don't you just bring it on? You have been putting us down for months or even years. We are willing to help as you see. Hope this time we can get some things sorted.

[CiNcH]

MPC-HC MpegSplitter -> CyberLink Video Decoder (PDVD11) -> EVR: OK
http://members.inode.at/762450/coreavc/cyberlink_interlaced.jpg

CyberLink gets the job done with MPC MpegSplitter.

[BetaBoy]

As always we are appreciative... and like with any product bug duplication is always the hardest part of support. As stated with the DVB issue, neither our testers or us could duplicate it till now.

[dansus]

Yes, and we are not seeing any issue here.

Not sure if it makes any difference, but im using DVB-T2 with DVBViewer in the UK and all i get is a black picture with 2.6
.

[betaking]

BUG REPORT,Last Haali Media Splitter 1.11.233.7 Haali MP4 Parser can not Connection some h.264 or x.264 videocodec(Including the latest version of the coreavc 2.6) to decoder mov mp4 (encoder by H.264 or X.264) use 1.11.96.14 no problem!

[Fadeout]

The problem I had in the previous version is still there: with some videos and DXVA (ATI, no matter the driver version and tested across different videocards models) the video freezes (the player is responsive and the audio goes on, but the image completely freezes, including the stats graph). CoreAVC CPU decoding works fine, DXVA in the internal MPC works fine. Only CoreAVC DXVA freezes. If I enable V-synch or frame correction the video doesn't freeze but I still get unusual stutters here and there (that aren't there with MPC internal DXVA).

So this is an issue specific to CoreAVC DXVA implementation.

Can't post a sample because it's an anime. If you want to look up the specific file, it's this:
[Commie] Tiger & Bunny - 01 [39E1E59A].mkv

One freeze happens at 00.44, and also usually happens 3-4 seconds before a different chapter in the file. The stutters instead happen every few seconds.

[CiNcH]

OK, it seems I was wrong. Today I also cannot get 720p working inside the DVBViewer with CoreAVC. Only black picture.

In an internal DVBViewer version, the video pre-format detection is fixed. So the DVBSource propagates correct values for the connection format. Still there is only a black picture with CoreAVC.

Maybe a random access problem?

[CiNcH]

I now tried to play a properly mastered m2ts (1080p) file via DVBSource -> CoreAVC. It does not play with video either.

[Tanuki]

What is the CRC of the corrected 2.6, because I can only download the one that have "bf806391", and it has the installation error message, and CoreAVC doesn't work anymore (makes Zoom player crash when loading)...

[BetaBoy]

We are working with CiNcH and have fixed the DVBViewer bug in software mode... Also we tracked down the issue with third party splitters and are working on that now.

What remains is a DXVA bug with DVBViewer... We will continue to work with CiNcH to test.

[CiNcH]

We now also know why DXVA does not work. It is because the DVBSource filter does not deliver the info (SPS/PPS) that CoreAVC needs in order to decide whether to use DXVA or not. So CoreAVC decides not to use DXVA. So either the DVBSource delivers this information or CoreAVC parses it from the stream by itself (which it does anyway). We made the experience that when the DVBViewer does this stuff, channel switching takes quite a bit longer as we have to serialize quite some work before we can actually build the graph and start playback (maybe this increased delay is more of perceptual nature because we can at least directly start playing audio). Most other DXVA decoders do not rely on this information.

[MOS-Marauder]

What remains is a DXVA bug with DVBViewer... We will continue to work with CiNcH to test.

Not only DXVA .. same if CUDA enabled.

Black Screen (DVBViewer 4.8.1)

Chris

[blaster00]

Coreavc 2.6 did not work with mpc-hc x64, no video output. Tried internal , haali and LAV splitter, both the same. But other h264 decoder and 2.5.5 works fine.

[betaking]

Coreavc 2.6 did not work with mpc-hc x64, no video output. Tried internal , haali and LAV splitter, both the same. But other h264 decoder and 2.5.5 works fine.

YES coreavc 2.6 can not Connection some mpc-hc internal standalone and LAV splitter,but use 2.5.5 no problem!:confused:

[Fadeout]

What remains is a DXVA bug with DVBViewer...

There's also the problem I reported in my previous post (stutters or video freeze in DXVA on specific videos), that was there already in 2.5.5 and will probably be there in 3 too.

[CiNcH]

We reviewed the cause of the DXVA/CUDA problem in the DVBViewer team in more detail now and came to the conclusion that it is a CoreAVC restriction. Taking actions inside the DVBSource filter would only be a workaround which may have bad side effects in a streaming environment. The DVBSource perfectly adheres to the MSDN H.264 streaming rules.

[devil-strike]

We reviewed the cause of the DXVA/CUDA problem in the DVBViewer team in more detail now and came to the conclusion that it is a CoreAVC restriction. Taking actions inside the DVBSource filter would only be a workaround which may have bad side effects in a streaming environment. The DVBSource perfectly adheres to the MSDN H.264 streaming rules.


Hmm whene using dvbviewer it wont work, like some say's here.

But here its goes back to microsoft codec, and ignore coreavc completly, whene i go back to old version of coreavc it works.

[CiNcH]

But here its goes back to microsoft codec, and ignore coreavc completly
Hmm, did you disable certain media subtypes or color spaces within the CoreAVC settings?

[BetaBoy]

The DVBSource perfectly adheres to the MSDN H.264 streaming rules.

CiNcH as we pointed out in email which you seem to now want to post to the public rather then continue our emails discussions (which is fine by us).

The SPS and PPS are normally sent as part of the AVC/H264 connection info. Is it mandatory? No but it is describe as the preferred method.

See: https://msdn.microsoft.com/en-us/library/dd757808(v=vs.85).aspx

DVBSource does NOT perform anything like the description on the MSDN page as the normal way to send SPS/PPS via the connection info is by using the dwSequenceHeader field of the MPEG2VIDEOINFO struct.

As stated, for local files this is fine but for live streams its not the proper behavior since the SPS/PPS may not be immediately available. RE: If there's a channel change, the connections need to be torn down and reconnected.

Our determination is that DVBSource doesn't do what it should and because it doesn't, CoreAVC can't be sure DXVA will work so it doesn't use it.

Breaking the proper methodology in DVBSource to save on perceived delays for end users when changing channels is not right, as decoding can't be start until the sps+pps are received anyway.

[devil-strike]

Hmm, did you disable certain media subtypes or color spaces within the CoreAVC settings?

No is on auto, like i said in 2.5 is working after install 2.6 is not working with same settings.

[CiNcH]

DVBSource does NOT perform anything like the description on the MSDN page as the normal way to send SPS/PPS via the connection info is by using the dwSequenceHeader field of the MPEG2VIDEOINFO struct.
In case of MEDIASUBTYPE_H264 a format block does not have to be appended. In this case there simply is no MPEG2VIDEOINFO.

Breaking the proper methodology in DVBSource to save on perceived delays for end users when changing channels is not right, as decoding can't be start until the sps+pps are received anyway.
But it will most likely happen that the splitter will wait for SPS/PPS and then the decoder waits again as it does not expect the SPS/PPS to be appended to the connection info as the MSDN states that you do not have to expect one in case of MEDIASUBTYPE_H264. This may result in >5s channel switching delays depending on the SPS/PPS frequency. SPS/PPS are pretty rare. We won't implement a workaround with such side effects to satisfy CoreAVC.

[BetaBoy]

As stated its not mandatory... and we will not use DXVA without it given the mixed live/local environments.

[nevcairiel]

I agree with CiNcH, the MSDN clearly states that H264 with Startcodes does not require a SPS/PPS block in the media type. It actually doesn't even list the possibility (or how to do it) for H264 with start codes.
It also does not name a preferred method.

DVBSource functions perfectly within the parameters as defined by the MSDN.

To quote the MSDN:
When the bitstream contains start codes, any of the format types listed here is sufficient, because the decoder does not require any additional information to parse the stream. The bitstream already contains all of the information needed by the decoder, and the start codes enable the decoder to locate the start of each NALU.

I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.

[CiNcH]

OK, so DXVA/CUDA won't be supported when using DVBSource together with CoreAVC. You guys told me via mail already that you are also not going to take further actions for the time being. I am fine with that. The reason why I made this public is because both sides won't do anything about it. I just wanted both, CoreAVC and DVBViewer users, to know about this restriction (leaving out the details) and our point of view. It was not meant to insult you. If you have another opinion or understand things differently, you can of course also state it (which you did) and I am fine with that too. We do not have to be of same opinion ;) . I am not using CoreAVC anyway. The only thing I am concerned with is customer/user satisfaction and that is why I went into all this debugging. (OK you can now hand me the medal of honor for special service ;) )

If people want to use CoreAVC within the DVBViewer they can still do so for content that does not make use of the DVBSource filter (obviously not for DVB) or simply give up on DXVA/CUDA.

[MOS-Marauder]

"If you want to use CoreAVC within the DVBViewer you can still do so for content that does not make use of the DVBSource filter. " ....


Witch makes it allmost unusable. I guess the same behaviour will be in CoreAVC 3.0.. so .. WHY should i buy this ?

For me.. i got CoreAVC for use @DVBViewer. Not its no longer possible..guess what?


Chris

[BetaBoy]

I don't understandNobody is in the wrong here... they do it one we, we another. But don't misunderstand us, we want DVBViewer w/DXVA to work and we are discussing on how best to handle it.

[BetaBoy]

We are releasing CoreAVC 2.6.1


CoreAVC H.264 Video Codec - Version 2.6.1.0 (20110906)
- FIX: Installer uses 32-bit filter for post-install configuration
- FIX: SPS/PPS identification regression
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams

Emails are about to be sent now. It will take a few hours for them all to go out.

[nussman]

Betaboy ... you want to stop the discussion right now? :eek:
At a point were we are very close to make CoreAVC useable?


I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.

Thats the point i dont understand too.
Could you explain it?

[CiNcH]

- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
Can you get into detail here too? We actually want to fix it inside the splitter. DVBSource also suffered from bad field order with hardware deinterlacing inside the renderer when using CoreAVC.

[squid_80]

But it will most likely happen that the splitter will wait for SPS/PPS and then the decoder waits again as it does not expect the SPS/PPS to be appended to the connection info as the MSDN states that you do not have to expect one in case of MEDIASUBTYPE_H264. This may result in >5s channel switching delays depending on the SPS/PPS frequency.
That's just silly. If the decoder expects SPS/PPS to be part of the connection info why would it then ignore it? If a filter doesn't know how to read the SPS/PPS data from the connection info, you could also prepend it to the first sample - thus preventing the decoder from discarding any NALUs due to them referencing non-present/inactive SPS/PPS (which would actually reduce the "perceived" latency rather than increase it).
OK, so DXVA/CUDA won't be supported when using DVBSource together with CoreAVC.
CUDA isn't affected at all, I don't know where you're getting that information from.
I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.
It can't be postponed - the renderer handles DXVA decoding and must be configured during pin connection. This happens before any samples are sent between the splitter and CoreAVC.For me.. i got CoreAVC for use @DVBViewer. Not its no longer possible..guess what?It works just fine, but won't use DXVA with DVBSource. Could be worse - try using MPC's decoder with DVBSource and see what happens.
Can you get into detail here too? We actually want to fix it inside the splitter. DVBSource also suffered from bad field order with hardware deinterlacing inside the renderer when using CoreAVC. Given that your splitter sends chunks of elementary stream, it would be virtually impossible to fix it there - you need to send a whole frame per sample with correct start and end times set. For unknown durations or end times, MS says it is allowable to set the end time to start time + 1, but it has been discovered that their renderers don't like this very much.

[CiNcH]

If the decoder expects SPS/PPS to be part of the connection info why would it then ignore it?
Hmm, seems my English is not good enough to explain myself properly... Sorry for that.

In case of MEDIASUBTYPE_H264 the decoder may not expect SPS/PPS to be part of the connection info as it is not really defined for H.264 with start codes. And also due to the fact that the format may have changed already, the decoder may be better off using the most recent info from the stream. So we end up waiting for SPS/PPS twice.

CUDA isn't affected at all, I don't know where you're getting that information from.
I was referring to user MOS-Marauder. But he of course was referring to the general issue within 2.6 where SPS/PPS was not properly read at stream time which is now fixed in 2.6.1. So CUDA may work then. Sorry for that.

It can't be postponed - the renderer handles DXVA decoding and must be configured during pin connection. This happens before any samples are sent between the splitter and CoreAVC.
So let us all just be happy that some other DXVA decoders are able to handle this case.

[hajj_3]

will CoreAVC 3.0 still be released today? Do you have a changelog for it yet?

p.s you should put changelogs for each version on your website.

thanks.

[CruNcher]

Dan do you also plan on implementing Intel (SB and newer) and AMD (APU,UVDx) Native API Hardware support @ the side of Nvcuvid or do you propose for Performance reasons DXVA for those 2 platforms :) ?

[dansus]

2.6.1

Emails are about to be sent now. It will take a few hours for them all to go out.

Is the download live? Still says 2.6 on the page.

[MOS-Marauder]

I was referring to user MOS-Marauder. But he of course was referring to the general issue within 2.6 where SPS/PPS was not properly read at stream time which is now fixed in 2.6.1. So CUDA may work then. Sorry for that..

Yep i tested yesterday 2.6.0 resulting in Black Screen with Audio.

Chris

[TOM_SK]

Is the download live? Still says 2.6 on the page.

Add me to the list, too (invoice number 33689).

[MOS-Marauder]

Add me to the list, too (invoice number 33689).

Well give them some Time... some Hrs more or less doesnt count...


Chris

Edit: ok some hrs later.. still no 2.6.1 @Account(s)

[BetaBoy]

Is the download live? Still says 2.6 on the page.

As we were releasing 2.6.1 we found a DXVA1 bug and pulled it from the portal. We finished compiling a new one and are signing it... releasing it will be next.

Then on to the CoreAVC 3.0 launch.

[BetaBoy]

Dan do you also plan on implementing Intel (SB and newer) and AMD (APU,UVDx) Native API Hardware support @ the side of Nvcuvid or do you propose for Performance reasons DXVA for those 2 platforms :) ?
I can comment more on our Intel efforts after we release CoreAVC 3.0 in a few hours.

[MOS-Marauder]

As we were releasing 2.6.1 we found a DXVA1 bug and pulled it from the portal. We finished compiling a new one and are signing it... releasing it will be next.

Then on to the CoreAVC 3.0 launch.

Ok, thx for Info.

Chris

[BetaBoy]

will CoreAVC 3.0 still be released today? Do you have a changelog for it yet?

p.s you should put changelogs for each version on your website.

thanks.
We post each changelog from each release, see:
http://corecodec.com/products/coreavc/changelog

[hajj_3]

ahh, there it is, silly me!

[Tanuki]

thanks god there are some alternative to CoreAVC, because I have been blocked with the buggy 2.6 for 3 days (with no possibility to downgrade to 2.5.5 since the license key isn't archived anywhere in my client area)...
I REALLY hope the Hi10P support won't be a disappointment.

[TheShadowRunner]

I REALLY hope the Hi10P support won't be a disappointment.

Don't we all ;)

[BetaBoy]

backing up.... gonna release 2.6.1 next... then take down 2.x purchasing in preparation for the CoreAVC 3.0 launch.

[hajj_3]

isn't it better to use new version numbers instead of silent updates as those people who downloaded the buggier versions of 2.6.0.0 and 2.6.0.1 may not be aware new versions are available. I'd name it 2.6.0.2 if i were you.

[BetaBoy]

CoreAVC 2.6.1.0 released on our customer portal. https://customers.corecodec.com

To upgrade to 2.6.1 (or any product) click 'My Products' and then click the product you purchased. At the top you will see an upgrade notification link, click through it and the updated product will then be in your account.

CoreAVC H.264 Video Codec - Version 2.6.1.0 (20110906)
- FIX: Installer uses 32-bit filter for post-install configuration
- FIX: SPS/PPS identification regression
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams

[TOM_SK]

coreavc 2.6.1.0 released on our customer portal. https://customers.corecodec.com

Thanks!

[BetaBoy]

Any feedback related to DVBViewer/DVBSource and third party splitters would be appreciated as this was the primary focus of this release. As noted in previous posts DXVA will not work with DVBViewer/DVBSource till we sort out the SPS issue (same goes for CoreAVC 3.0).

[nussman]

CoreAVC 2.6.1:

dvbviewer:
seems to work fine in software mode
no dxva as expected .... :mad:

deinterlacing:
Seems to work properly now with dvbviewer sourcefilter and mpc-hc splitter

installer:
64bit errormessage is gone


Not so bad at all.
Please take your time and think about the SPS/PPS issue!

[BetaBoy]

nussman... awesome... thx for the fast feedback!

[dansus]

Any feedback related to DVBViewer/DVBSource and third party splitters would be appreciated as this was the primary focus of this release. As noted in previous posts DXVA will not work with DVBViewer/DVBSource till we sort out the SPS issue (same goes for CoreAVC 3.0).

I can watch BBCHD now and globe is green, good enough for me.

[mkanet]

I totally didn't expect this (since I didnt notice anyone else report this issue), but the problem with 2.6.0 went away where a few of my videos would have this weird repetitive 1-sec video loop over and over again on certain parts of the video (for example a person's head nodding up and down or arm flapping back and forth). I can also confirm that the install error went away.

Both issues are fixed for me.

Thanks for all your hard work,
MKANET

[Chumbo]

Some feedback on 2.6.x. The hardware deinterlacing is working great. The 30fps media files from Hauppauge HD-PV4 1212 now play nice and smooth in both DXVA and None with Hardware deinterlacing (I use MPC-HC). Single field and Bob are better than they were but still unwatchable by the way.

[BetaBoy]

green = DXVA... nice.

We are tracking 3 potential issues... not show stoppers but we are working with the reporters on the issues.

- Haali .MP4 bug where the container is not supported (for some users)
- Interleave MP4 videos (might be field order related)
- ZoomPlayer having issues as well

[Fadeout]

The problem I had in the previous version is still there: with some videos and DXVA (ATI, no matter the driver version and tested across different videocards models) the video freezes (the player is responsive and the audio goes on, but the image completely freezes, including the stats graph). CoreAVC CPU decoding works fine, DXVA in the internal MPC works fine. Only CoreAVC DXVA freezes. If I enable V-synch or frame correction the video doesn't freeze but I still get unusual stutters here and there (that aren't there with MPC internal DXVA).

So this is an issue specific to CoreAVC DXVA implementation.

Can't post a sample because it's an anime. If you want to look up the specific file, it's this:
[Commie] Tiger & Bunny - 01 [39E1E59A].mkv

One freeze happens at 00.44, and also usually happens 3-4 seconds before a different chapter in the file. The stutters instead happen every few seconds.


This was also partially fixed in 2.6.1 in the sense that now the video doesn't freeze/stop anymore.

The problem that is left is that there are still stutters here and there, it seems especially on some scenes change. MPC-HC DXVA is instead always smooth.

[cyberbeing]

Haali .MP4 bug where the container is not supported (for some users)
I have this bug on WinXP SP3 x86 with the new Haali Splitter 1.11.233.7. All MP4 have no video with an empty video output pin.

[BetaBoy]

CoreAVC 3.0 is a major milestone for us here at CoreCodec and adds features like 9/10 bit support, Full DXVA 2, DXVA 1, GMA support, DXVA fallback, Intel Media SDK support, New Assembly 'Core', etc.

What's new in CoreAVC 3.0?
CoreAVC H.264 Video Codec - Version 3.0.0.0 (20110906)
- ADD: 9 bit support
- ADD: 10 bit support
- ADD: DXVA fallback to software
- ADD: Intel Media SDK Support (DXVA2)
- ADD: Intel GMA Support (DXVA2)
- ADD: 10 bit output format (P010)
- ADD: 16 bit output format (P016)
- ADD: Directshow dithering when filter output is downsampled
- ADD: Improved DXVA handling for interlaced streams
- ADD: Colorspace conversion from 10 bit formats to 8 bit formats
- ADD: DXVA 2 Long slice support
- ADD: Initial 4:4:4 integration (No decode support yet)
- ADD: New assembly engine
- ADD: New assembly IDCT
- ADD: New assembly motion compensation
- ADD: New assembly inter-prediction
- ADD: New assembly weighted prediction
- ADD: New assembly 9-bit
- ADD: New assembly 10-bit
- ADD: Improved assembly 8 bit performance
- CHG: Use container AR when there is no stream AR
- FIX: Improved Frame order handling
- FIX: Hardware deinterlacing field order
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams
- SDK: Updated xcode support for iOS and OS X
- SDK: Improved APIs
- SDK: Fix: Missing APIs
- SDK: Initial support for MVC (CoreMVC) integration

Haali Media Splitter - Version 1.11.233.7 (20110830)
- FIX: Various DTS Audio bugs
- ADD: Improved DTS support
- ADD: Support for MVC 3D videos


For current 2.x customers, if you have purchased CoreAVC within the past 60 days, you will automatically get 3.0 as a part of the purchase.

CoreAVC 3.0 can be purchased here:
https://customers.corecodec.com/cart.php

[BetaBoy]

Customers who purchased CoreAVC 2.x (not a 1.x upgrade) in the past 60 days get the update first.

After the emails are sent we will make it available for purchase.

[BetaBoy]

Also a heads up... although it did not make it into 3.0 before we went 'gold', we have also added:
- 4:4:4 profile support
- Intel AVX support (SandyBridge / IvyBridge)

You will likely see those in one of the next updates starting with 4:4:4 first.

[cyberbeing]

CoreAVC 3.0 software decoding has an extremely massive memory leak when used with madVR and MPC-HC. Every time a video is opened or re-loaded without closing the player, memory usage increases by the initial amount... For a 10bit 1080p video this means ~+250MB for every video you open until you are out of memory.

[BetaBoy]

cyberbeing... we cannot duplicate the memory leak here... can you provide versions numbers so we can dig deeper?

[BetaBoy]

We have taken down 2.x purchasing.... about to push 3.0 live for everyone.

[cyberbeing]

cyberbeing... we cannot duplicate the memory leak here... can you provide versions numbers so we can dig deeper?

The problem only seems to happen with when CoreAVC 3.0 is used with madVR 0.74. What seems to be happening is instead of old CoreAVC instances being killed or reused, a new CoreAVC instance is created for each new video opened while the old instance(s) just hang around idle, holding onto memory. That would explain why memory usage increases as it does.

MPC-HC r3677
madVR 0.74
Haali Splitter 1.11.96.14 (until MP4 bug is fixed)
WinXP SP3 x86


madshi would need to chime in, since for all I know this could be half a madVR bug. I rolled back to madVR 0.73 and the bug disappeared. The odd part is it only happens with CoreAVC and madVR 0.74. FFDShow or other decoders with madVR 0.74 are fine.

[Kurtnoise]

We have taken down 2.x purchasing.... about to push 3.0 live for everyone.
After selecting CoreAVC 3.0 and clicking in "order now", CoreAAC is selected instead...

[nevcairiel]

madshi would need to chime in, since for all I know this could be half a madVR bug. I rolled back to madVR 0.73 and the bug disappeared. The odd part is it only happens with CoreAVC and madVR 0.74. FFDShow or other decoders with madVR 0.74 are fine.

This is actually a madVR bug. It keeps a reference to the decoder around, and therefor its never properly destructed when the directshow graph is re-built.
madshi knows, and confirmed that its fixed for the next version (whenever that'll be)

To avoid huge memory leaks like this in CoreAVC, i would however recommend to free the memory buffers when the input pin is disconnected, and not wait until the filter is destructed. (Which is why it doesn't show up on other filters, they do exactly that)

[BetaBoy]

After selecting CoreAVC 3.0 and clicking in "order now", CoreAAC is selected instead...

Fixed... thx for the report. We are also about to 4x the VM resources since the load is high atm.

[cyberbeing]

BetaBoy, are 10bit optimizations for older AMD processors like my X2 4800+ (939) already in CoreAVC 3.0? Doing some benchmarks with VMR9, CoreAVC seems to struggle considerably more than FFDShow with sudden sudden bitrate fluctuations where my CPU is struggling to playback in real-time. Peak CPU is higher and Min FPS dips lower compared to FFDShow in such situations. Average FPS is usually marginally better with CoreAVC though, but that doesn't help much if Min FPS drops below real-time.

CoreAVC 3.0 compared to FFDShow r3978 (3-threads)
AMD X2 4800+ @ 2.64Ghz | WinXP SP3 x86
Various 1080p/720p 10bit H.264 samples

-5% to +10% Avg FPS (CoreAVC is better)
-2% to +1% Avg CPU (CoreAVC is better)

-15% to +5% Min FPS (FFDshow is better)
+2% to +10% Peak CPU (FFDshow is better)


Using 10bit (P010) or 16bit (P016) output to madVR is even worse, seemingly adding an additional 5-10% overhead to Avg and Peak CPU and worse FPS all-around.

Hopefully you can sort out these higher CPU spikes from sudden bitrate fluctuations in a future 3.x version. It's the difference between smooth playback (ffdshow) and dropped frames (coreavc) on some 10bit 1080p samples, especially once subtitles enter the picture.

[nevcairiel]

I would've thought P010 output uses less CPU (afterall, you don't need to apply dithering) - unless madVR itself uses more CPU with 10-bit input.

You should compare using a codec benchmark like in GraphStudio, taking the renderer out of the equation. If someone does, i would appreciate also including LAV Video in that comparison (both in 8-bit dithered and 10-bit native mode). ;)
I would do it, but i'm not sure i'll be buying 3.0, i have no need for it.

[ranpha]

You should compare using a codec benchmark like in GraphStudio, taking the renderer out of the equation.

I would have done so if GraphStudio doesn't crash when I tried to do benchmarking 10-bit clips with LAV Video. timecodec also cannot be used because of the same problem.

As a last resort, I tried using DXVA Checker to do the benchmarking, and there are some 'interesting results'. I don't really trust DXVA Checker as a benchmarking tools though. DXVA Checker and Graphstudio gives different results for the same clip when benchmarking with CoreAVC 3.

[CruNcher]

DiAVC kills both though the features of DiAVC are still limited so overhead might be lower still but it looks very good designed (and optimized for Intel) overall :)

http://img560.imageshack.us/img560/2003/comparex264performancei.png

[nevcairiel]

DiAVC kills both

How can it, it doesn't even play 10-bit files yet. :p

I would have done so if GraphStudio doesn't crash when I tried to do benchmarking 10-bit clips with LAV Video. timecodec also cannot be used because of the same problem.

With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p

[devil-strike]

I read here that the new coreavc is working again with dvbviewer? but here is not working at all, dvbviewer sees the codec in the cofig page, but it wont work and falls back to microsoft dtv codec, but if i disable ms codec it also wont work with coreavc2.6.1, if i install old 2.5.1 or 2.5.5 it working again.

btw, using win7 64bit.

[CruNcher]

How can it, it doesn't even play 10-bit files yet. :p



With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p


That's true but he seems to be optimizing it to the last drop schweinsz remembers me of Picard when everything started with CoreAVC, he is really fast for a 1 man machine (though CoreAVC is hardly that 1 man machine anymore) ;)
Also as you see i didn't compared with CoreAVC 3.0 yet and if you compare features vs overhead surely he would lose then currently ;)

also


- ADD: DXVA fallback to software
- ADD: New assembly engine
- ADD: New assembly IDCT
- ADD: New assembly motion compensation
- ADD: New assembly inter-prediction
- ADD: New assembly weighted prediction
- ADD: Improved assembly 8 bit performance


good feeling :)

And the 3.0 update is so evil huge (including all the DXVA2 improvements and additions) i hope alot of good beta tester where involved here :)

[ranpha]

With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p

It happened with all 10-bit clips I have, whether the ones I made myself or the ones 'made by others'.

[nevcairiel]

It happened with all 10-bit clips I have, whether the ones I made myself or the ones 'made by others'.

I think i found the cause, any follow up should be moved over to the appropriate thread, though.

http://forum.doom9.org/showthread.php?p=1524388#post1524388

[Fadeout]

Surely there's something wrong. I have at least twice the CPU usage with CoreAVC DXVA compared to native MPC-HC DXVA. Also some very high peaks.

CPU is being used somehow even if the video is in DXVA. I have almost the same CPU usage with DXVA and software (DXVA is enabled as it shows both the red icon and [DXVA] on MPC).

[Barlow]

I just noticed the same thing. This is with 3.0 btw.

[CruNcher]

I hope they don't enabled the 1080p 60 fps fallback to Software for every DXVA scenario (config), though that you see the RED icon would be strange :(

[Fadeout]

This CPU usage on DXVA seems to happen already in 2.6.1.

EDIT: Yep, 2.5.0 is fine. The problem shows up in 2.6.0 and continues in all following versions.

EDIT2: More things. I'm testing with this file: Planet_Earth_From Pole_to_Pole_1080p_sample_16ref.mkv

And DXVA can't produce smooth playback. Very stuttery. 2.5 worked fine, as well MPC-HC internal DXVA.

[CruNcher]

What OS and Card (DSP) ?

[Fadeout]

I'm on W7 64b and ati 4850 if you're asking me.

Tried to use a x32 version of MPC-HC but it seems to deliver the same problems. Playback isn't smooth in DXVA. Software mode instead performs similar to 2.5, but it also has the tendency to go crazier if you repeat tests. 2.5 was usually more constant.

Summarizing: it's a problem that shows up in 2.6. High CPU usage in DXVA, and very stuttery playback. Especially evident with this clip:
Planet_Earth_From Pole_to_Pole_1080p_sample_16ref.mkv

[Fadeout]

Also, testing the various version and codecs at the moment I get the best performance with MadVR internal codecs even compared to CoreAVC or DiAVC.

Very low CPU usage with MadVR and smooth playback with that sample.

[BetaBoy]

Thank you for the reports everyone.

[sawg]

Please forgive me if I make any errors; my English is a little weak.

http://i.imgur.com/fuckK.jpg
http://i.imgur.com/jrtX4.jpg
Open CUDA and 1080p video, EVR Buffers >17 will error.

[dansus]

I have this bug on WinXP SP3 x86 with the new Haali Splitter 1.11.233.7. All MP4 have no video with an empty video output pin.

Same here, XP SP3 x86.

[Stephen R. Savage]

CPU: Intel Core 2 Duo T7250 "Merom" (2.00 GHz)
OS: Microsoft Windows Server 2008 R2 Standard

GraphStudio 0.3.2.0 was used for all measurements.
Reported values are the average of three independent trials.
Standard deviation was below 1% of mean for all tested software.
Output accuracy was evaluated visually for each decoder.

All software used was 32-bit. 10-bit samples were decoded to
8-bit formats in all cases to better represent typical usage
scenarios.

Software Tested:
DiAVC 1.2.6
CoreAVC 3.0
ffdshow (CLSID) r3978
LAV Filters 0.34

1080p, 10-bit, 8750 kbps
========================
CoreAVC: 30.4 fps
ffdshow: 35.7 fps
LAV Filters: 38.2 fps

720p, 10-bit, 1850 kbps
========================
CoreAVC: 60.4 fps
ffdshow: 67.3 fps
LAV Filters: 77.5 fps

720p, 8-bit, 2620 kbps
======================
DiAVC: 157.6 fps
CoreAVC: 133.6 fps
ffdshow: 125.6 fps
LAV Filters: 129.4 fps

480p, 8-bit, 1830 kbps
======================
DiAVC: 390.4 fps
CoreAVC: 340.6 fps
ffdshow: 309.9 fps
LAV Filters: 335.0 fps


It's sad to see CoreCodec fall this low. What used to be cutting-edge software continues its trend into obsolescence. I mean, even I would be embarrassed at releasing a supposedly "high-performance" software that's 30% slower than a free offering. Claims for improved 8-bit performance are also unable to be verified, as CoreAVC 3.0 scores no higher than 2.5.5 (not shown in data, see previous).

What's more interesting is how far libavcodec development has come. Nevcairiel's optimized LAV Filters now lead CoreAVC in 10-bit decoding by as much as CoreAVC 1.0 lead the earliest versions of libavcodec. Another victory for open source software. No wonder CoreCodec has to try gouging its ever-dwindling customer base for repeated "upgrade" fees.

[Kurtnoise]

@Stephen : could you post/link the samples you use for your benchmark please ?

[SSH4]

hmm, cuda and dxva not work on CoreAVC 3.0?

oops no cuda/dxva on 10bit ?

[BetaBoy]

Stephan.... Please take the drama else where.

[Mixer73]

No wonder CoreCodec has to try gouging its ever-dwindling customer base for repeated "upgrade" fees.

You know what... I complained when Core announced that 3.0 would be a new license and not an upgrade on 2.0... Now they have offered a $3 discount for 2.0 owners, against a license that is what $12.95?

Can we really complain about such low priced software? I dunno that we can, really.

[Tanuki]

@BetaBoy
Can you elaborate on the Zoom Player problem (since I seem to have one myself) ?

[SSH4]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

[Barlow]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

I'm not sure about CUDA, but DXVA won't decode 10bit on any card yet.

[kerimcem]

my graphics card Ati HD 2600 PRO (UVD)+ 7300 gt (old card)

CoreAVC 2.5.5 DXVA works perfectly

CoreAVC 2.6.0 DXVA not working
CoreAVC 2.6.1 DXVA not working
CoreAVC 3.0.0 DXVA not working

[nevcairiel]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

Both CUDA and DXVA use the hardware decoder on your GPU, and that one is limited to 8-bit.

[CiNcH]

Having criticized CoreCodec for the way they do business a lot in the past (and I am not alone, I have never seen anyone getting more heat than they do), I can also give credit where it is due.

Version 2.6.1 is finally usable within the DVBViewer (not perfect though, and I am not talking about DXVA) and the eventualities in a streaming environment where decoders have to deal with fast channel hopping, random access, on-the-fly format changes, interlaced content a.s.o.

All my reports have successfully been processed (except for DXVA of course). Finally proper vector-adaptive deinterlacing when using NV12 is possible. I consider this being a much more critical task than hardware decoding.

Maybe it is better that DXVA is not supported within the DVBViewer as of yet. Who knows what would have happened if format changed on-the-fly or one would have switched between 720p and 1080i channels without the DVBViewer rebuilding the graph...

Looking back some years, it also took MPEG-2 decoder developers some time to embrace all the eventualities in a streaming environment. CyberLink has come a long way and this may be the reason why they still rock in this area (even with DXVA). I am pretty sure that others will arrive there too one day.

[Stephen R. Savage]

@Stephen : could you post/link the samples you use for your benchmark please ?

Stephan.... Please take the drama else where.

@Kurtnoise: I will try to make them available later today.

@BetaBoy: This is not the first time I've shown clear evidence of failings in CoreAVC. Each time you have summarily dismissed them as "drama" and have consistently failed to improve your software in any meaningful manner. The fact that you refuse to acknowledge shortcomings reflects poorly on both your company and on you personally. In fact, I am not the only user to have noticed that CoreAVC no longer lives up to the standard it once set.

To those in this thread: CoreCodec thrives off of uninformed users. Please don't be such a person. Every usage case that CoreAVC might have had is now supplanted by free software.

CPU Decoding: LAV Filters
CUDA (NVIDIA): LAV CUVID Decoder
DXVA (Intel/AMD): MPC-HC, ffdshow, Windows 7, all sorts of things

Let's not forget all the things CoreCodec promised but failed to deliver:

GPU Encoding: lol
Decoding 1080p on Intel Pentium 4: lol
MKV DVD-style menus: lol
Full support for High Profile: wait, what was that about weighted prediction?
GPU Decoding: on NVIDIA only, AMD and Intel users are stuck with useless DXVA

Edit:
@Mixer73: $12.95 is infinitely more than $0, and hence you are being infinitely ripped off.

@hajj_3: I don't know, extrapolating from my tests, and estimating that a 1.73 GHz Core Solo is 40% as fast as my 2.00 GHz Core 2 Duo, 3200 kbps 720p still decodes at over 50 fps with LAV, more than enough for viewing in a basic renderer like EVR (esp. w/ D3D Fullscreen).

Also, in case anybody is wondering, the free software I am mentioning is LAV Filters/LAV CUVID. I am not shilling for DiAVC, and I personally don't recommend anybody buy it unless you want to use neuron2tools for some reason.

[hajj_3]

well atleast they are getting pretty quick at fixing bugs, they have fixed the majority of bugs in 2.6.0 in a matter of days which is pretty impressive. Judging by reports it seems there are a ton of bugs in 3.0 so i'm sure it will be months until that is stable. Its better than nothing though, i can play 3200 bitrate 720p on a single core 1.73ghz core solo, haven't tried diavc as only the 64bit is free and the cpu is only 32bit.

[squid_80]

Come now Stephen, without the sample clips as evidence to back up your findings your comparison is useless and your statements have absolutely no merit. For all we know you specifically chose clips to make CoreAVC look bad or even worse, outright fabricated the results. At the very least, allow someone else to post their own comparisons (using an i5-661, null renderer, same filter versions/testing setup).

Let's try a monster clip that most people are familiar with:
Life in the Garden (http://www.youtube.com/watch?v=N0m1XmvBey8), 4096x2304, null renderer
==============================
CoreAVC: 109.1267 fps
FFDShow: 93.1857 fps
LAV Filters: 83.2946 fps

I noticed you didn't test any interlaced material. Should we believe this was on oversight on your behalf?
premiere-paff.ts (http://www.mediafire.com/?onyymjatwjq), 1080i, null renderer
==============================
CoreAVC: 95.5605 fps
LAV Filters: 74.6953 fps
FFDShow: 67.0859 fps

Now you can consider yourself informed. Although I wonder, since you already had such a poor opinion of CoreCodec/CoreAVC, what prompted you to purchase the 3.0 upgrade?

[CruNcher]

Come now Stephen, without the sample clips as evidence to back up your findings your comparison is useless and your statements have absolutely no merit. For all we know you specifically chose clips to make CoreAVC look bad or even worse, outright fabricated the results. At the very least, allow someone else to post their own comparisons (using an i5-661, null renderer, same filter versions/testing setup).

Let's try a monster clip that most people are familiar with:
Life in the Garden (http://www.youtube.com/watch?v=N0m1XmvBey8), 4096x2304, null renderer
==============================
CoreAVC: 109.1267 fps
FFDShow: 93.1857 fps
LAV Filters: 83.2946 fps

I noticed you didn't test any interlaced material. Should we believe this was on oversight on your behalf?
premiere-paff.ts (http://www.mediafire.com/?onyymjatwjq), 1080i, null renderer
==============================
CoreAVC: 95.5605 fps
LAV Filters: 74.6953 fps
FFDShow: 67.0859 fps

Now you can consider yourself informed. Although I wonder, since you already had such a poor opinion of CoreCodec/CoreAVC, what prompted you to purchase the 3.0 upgrade?

Something was wrong sorry (new results later) :(

[wanezhiling]

CoreAVC 3.0.......

Believe it or not , CPU Usage is still very high when dxva on.

[cyberbeing]

AMD X2 4800+ (939) @ 2.64Ghz
WinXP SP3 x86
Haali Media Splitter 1.11.96.14

Here are a few GraphStudio 10bit h264 tests with P010 vs YV12 (dithered) on CoreAVC 3.0.0 with NULL output:

Update: Added LAV Video 0.35 results, now that nevcairiel posted a fixed build.

33.9615 FPS NULL CoreAVC 3.0.0 YV12
33.0268 FPS NULL CoreAVC 3.0.0 P010 (2.8% slower)
34.0204 FPS NULL FFDSHOW r3978 YV12
37.9940 FPS NULL LAV Video 0.35 YV12
37.4290 FPS NULL LAV Video 0.35 P010

37.7804 FPS NULL CoreAVC 3.0.0 YV12
36.5628 FPS NULL CoreAVC 3.0.0 P010 (3.3% slower)
38.5740 FPS NULL FFDSHOW r3978 YV12
42.5697 FPS NULL LAV Video 0.35 YV12
41.7282 FPS NULL LAV Video 0.35 P010

43.3645 FPS NULL CoreAVC 3.0.0 YV12
41.6692 FPS NULL CoreAVC 3.0.0 P010 (4% slower)
42.6866 FPS NULL FFDSHOW r3978 YV12
47.8580 FPS NULL LAV Video 0.35 YV12
47.0682 FPS NULL LAV Video 0.35 P010

122.3882 FPS NULL CoreAVC 3.0.0 YV12
116.3716 FPS NULL CoreAVC 3.0.0 P010 (5.2% slower)
116.4711 FPS NULL FFDSHOW r3978 YV12
131.6452 FPS NULL LAV Video 0.35 YV12
128.0310 FPS NULL LAV Video 0.35 P010

Note: I didn't list them, but CoreAVC P016 results near-identical to P010 results.
__________

Here are the DXVAChecker 10bit h264 benchmarks I did with VMR9 yesterday (a bit messy):

Decoder: CoreAVC Video Decoder | Average FPS: 34.171 | Min/Max FPS: Min: 23 Max: 43 | Playback CPU Usage (%): Avg: 71 Max: 100
Decoder: ffdshow Video Decoder | Average FPS: 33.946 | Min/Max FPS: Min: 25 Max: 43 | Playback CPU Usage (%): Avg: 71 Max: 92
Decoder: LAV Video Decoder |Average FPS: 37.764 | Min/Max FPS: Min: 26 Max: 50 | Playback CPU Usage (%): Avg: 63 Max: 84

Decoder: CoreAVC Video Decoder | Average FPS: 38.281 | Min/Max FPS: Min: 30 Max: 55 | Playback CPU Usage (%): Avg: 63 Max: 80
Decoder: ffdshow Video Decoder | Average FPS: 38.685 | Min/Max FPS: Min: 32 Max: 49 | Playback CPU Usage (%): Avg: 62 Max: 75
Decoder: LAV Video Decoder | Average FPS: 42.336 | Min/Max FPS: Min: 33 Max: 54 | Playback CPU Usage (%): Avg: 55 Max: 68

Decoder: CoreAVC Video Decoder | Average FPS: 43.683 | Min/Max FPS: Min: 35 Max: 50 | Playback CPU Usage (%): Avg: 54 Max: 66
Decoder: ffdshow Video Decoder | Average FPS: 42.413 | Min/Max FPS: Min: 38 Max: 46 | Playback CPU Usage (%): Avg: 55 Max: 64
Decoder: LAV Video Decoder | Average FPS: 47.837 | Min/Max FPS: Min: 42 Max: 52 | Playback CPU Usage (%): Avg: 48 Max: 55

Decoder: CoreAVC Video Decoder | Average FPS: 84.311 | Min/Max FPS: Min: 70 Max: 107
Decoder: ffdshow Video Decoder | Average FPS: 87.385 | Min/Max FPS: Min: 74 Max: 111

Decoder: CoreAVC Video Decoder | Average FPS: 118.340 | Min/Max FPS: Min: 85 Max: 139
Decoder: ffdshow Video Decoder | Average FPS: 113.697 | Min/Max FPS: Min: 87 Max: 128

Decoder: CoreAVC Video Decoder | Average FPS: 45.284 | Min/Max FPS: Min: 37 Max: 62
Decoder: ffdshow Video Decoder | Average FPS: 41.258 | Min/Max FPS: Min: 36 Max: 54

Playback CPU usage = non-benchmark normal speed VMR9 playback in DXVAChecker

CoreAVC 3.0.0 was released late last night, so I went to sleep without doing Playback CPU usage for all of them, but you should be able to see the trend. CoreAVC 3.0.0 struggles with sudden high-complexity/high-bitrate fluxuations in the stream, making it not so good for older CPUs like my AMD X2 which risk falling below real-time. The test I listed on top is very representative of the problem I'm seeing. CoreAVC hits 100% CPU usage with a hard to decode section during normal playback and falls below real-time when benched, while FFDSHow doesn't go above 92% CPU usage and stays slightly above real-time when benched.

Update: LAV Video 0.35 results are surprisingly faster than both CoreAVC 3.0.0 and FFDShow.
Update: It looks like LAV Video 0.35 also has a P010 overhead, but it's half that of CoreAVC 3.0.0, so it seems there is room for improvement.

[TheFluff]

I've been seeing several reports of CoreAVC 3.0 exhibiting decoding errors with some 10-bit clips, as well.

Sample file (http://x264.fushizen.eu/encodan/10bit/railgun_op1_10bit.mp4)
The errors should be obvious, but here's a screenshot (http://vfrmaniac.fushizen.eu/OtherStuff/CoreAVC3.0_damages_railgun_op1_10bit.mp4.png) as well. The file works correctly when decoded with libavcodec, but I haven't tested any other decoders.

[cyberbeing]

Tested a few things and found another sample with similar corruption to what TheFluff posted:

Sample (http://www.mediafire.com/?bkdqlxuwmrxjfbx) | Screenshot (http://img696.imageshack.us/img696/7283/coreavc30corruption.png)

Edit: And another... I guess I should actually be watching things instead of benching, since the corruption problem must be semi-widespread

Sample2 (http://www.mediafire.com/?9830yforq4yc647) | Screenshot2 (http://img14.imageshack.us/img14/6517/coreavc30corruption2.png)

[mandarinka]

I noticed similar jumps in 10bit decoding cpu load with ffdshow /libavcodec in general/ when testing on an Athlon XP.
Maybe the decoders only have codepaths for cpus with better SSE performance. (Athlon XP would need MMX asembly since it lacks SSE compeltely, maybe some functions in ffh264 aren't SIMDed in MMX, in libavcodec; as for coreAVC, maybe it doesn't take the slowness of SSE2 on K8 into account?)

BTW, anyone tested on non-sse2 cpu?

[sneaker_ger]

Athlon XP would need MMX asembly since it lacks SSE compeltely

That is not true, Athlon XP has SSE(1).

[nevcairiel]

Did it occur to you that the Athlon XP is maybe just slow in general? :)

I can only speak for myself, but i will not waste time writing the code that i wrote in SSE2 already again in MMX, for some CPU thats around 10 years old. :D

[BetaBoy]

We are tracking a few annoying 10bit related bugs. Ones that stand out are the ones that affect Anime (of all things) and a few specific CPU's types.

[TheRyuu]

We are tracking a few annoying 10bit related bugs. Ones that stand out are the ones that affect Anime (of all things) and a few specific CPU's types.

Why does the content matter?

BTW, anyone tested on non-sse2 cpu?

No, just no.
Why should decade old hardware matter?

[eddman]

GPU Decoding: on NVIDIA only, AMD and Intel users are stuck with useless DXVA


You don't even know what you're talking about, and you expect everyone to take you seriously!

Coreavc is NOT a GPU decoder. It uses CUDA, only to access the built-in video decoder (Purevideo). It works almost like DXVA.

[BetaBoy]

Why does the content matter?
It doesn't It was meant to point out the Anime crowd being early adopters. RE: Hi10

[TheRyuu]

It doesn't It was meant to point out the Anime crowd being early adopters. RE: Hi10

And why exactly should that matter?

It's typical usage, you're watching a 10bit encoded video. Surely that's something that quality control should catch... It's not some obscure bug that takes some really weird set of steps to reproduce. From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.

[Stephen R. Savage]

Useless ad hominem and fabricated numbers.

I purchased CoreAVC 3.0 because my work requires evaluating decoding software. I am certainly not going to download gigabytes of special-case content (3840x2160? seriously?) to test as I have neither the CPU cycles nor the bandwidth. Moreover, I am only interested in scenarios that have a basis in reality. Your defensiveness betrays the weakness of your claims.

You don't even know what you're talking about, and you expect everyone to take you seriously!

Coreavc is NOT a GPU decoder. It uses CUDA, only to access the built-in video decoder (Purevideo). It works almost like DXVA.

Perhaps I should have put "GPU Decoding" in quotes. Rest assure that I know full well how the "GPU" decoding is implemented. Note that this entire thread was in an uproar when this was announced, as it was certainly not what CoreCodec had been advertising with their "GPU decoding" marketing claim. DXVA is useless because it doesn't do memory copies of frames, and if you just wanted to see a picture, there are dozens of free applications to do that.

And why exactly should that matter?

It's typical usage, you're watching a 10bit encoded video. Surely that's something that quality control should catch... It's not some obscure bug that takes some really weird set of steps to reproduce. From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.

If this is true, that puts CoreAVC's already low 10-bit performance under even more scrutiny. Not only is it slow, it's also wrong.

[BetaBoy]

I purchased CoreAVC 3.0 because my work requires evaluating decoding software.
:eek: I am truly speechless given your analyses and continued ignorance in posting biased opinions rather then well rounded evaluations like most d9's do.

Good or bad we want to hear whats going on so we can address it.... oh yeah we get the OSS argument in fact most of our developers here at CoreCodec are the ones working on libav and x264... there is room for all of us here.

[BetaBoy]

From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.
We are adding more regression videos to cover a wider range of 10bit content... but overflow errors are harder to catch naturally.

End result is each release as it relates to 10bit should be better then the last.... especially the next 2-3 releases as we are focusing in on performance (on top of bugs).

[TheRyuu]

We are adding more regression videos to cover a wider range of 10bit content... but overflow errors are harder to catch naturally.

End result is each release as it relates to 10bit should be better then the last.... especially the next 2-3 releases as we are focusing in on performance (on top of bugs).

No one thought to just watch a video?

Pretty much any 10bit video will break it (from what I hear) so I don't really understand your first statement.

[benus]

May I just ask, since there are some voices claiming poor performance of new CoreAVC 3.0

Is there any chance for implementing Cuda support in decoding 9 and 10-bit files to offload any given CPU?

If yes, will it still be a part of 3.x generation so I can safely purchase it now or are we talking about further development.

Please let me know. Thanks.

[Stephen R. Savage]

:eek: I am truly speechless given your analyses and continued ignorance in posting biased opinions rather then well rounded evaluations like most d9's do.

Good or bad we want to hear whats going on so we can address it.... oh yeah we get the OSS argument in fact most of our developers here at CoreCodec are the ones working on libav and x264... there is room for all of us here.

It's kind of hard to take you seriously when you complain about numbers being biased. It's also unclear what agenda you're trying to accuse me of promoting.

Edit: Actually, you are half right. My analyses are misleading and I should retract them. Just now, I opened a 10-bit file that I didn't use for my benchmark and found that CoreAVC shifted the image right by 16 pixels, with the right-most pixels reappearing on the left. If I had spent more time verifying the functionality of this alpha-quality software, I would not even have bothered to include it.

[BetaBoy]

It's...
Please reference my post to you:
http://forum.doom9.org/showpost.php?p=1524492&postcount=6678

[Stephen R. Savage]

Please reference my post to you:
http://forum.doom9.org/showpost.php?p=1524492&postcount=6678

Impersonating moderators is a bannable offense, BetaBoy. This isn't the first time someone has warned you about this behavior.

[TheRyuu]

Please reference my post to you:
http://forum.doom9.org/showpost.php?p=1524492&postcount=6678

Please forgive us for talking about broken software being broken in a thread specifically about said software.

Are you trying to pass blame to the user?
"Please avoid playing these files since it doesn't work with them."

[TheFluff]

:eek: I am truly speechless given your analyses and continued ignorance in posting biased opinions rather then well rounded evaluations like most d9's do.

Well, regardless of how much you complain about drama, the fact (or well rounded evaluation, if you prefer) is that until a bugfix release comes out, upgrading from 2.6 to 3.0 is definitely a bad idea. The killer feature most people were waiting for (10-bit decoding) is very broken, and for many testers I've spoken with the decoding performance is slower than in 2.6 (not to mention that in some cases it's actually slower than libavcodec as well).

oh yeah we get the OSS argument in fact most of our developers here at CoreCodec are the ones working on libav and x264... there is room for all of us here.

I'm not sure if you've realized the difference between you and libavcodec. People expect libavcodec to be broken. They expect libavcodec developers to be rude, hard to reach and slow to react to bug reports. That's just how open source is, after all.
However, when the same people encounter you, they tend to have different expectations, because you're a representative of a for-profit corporation. As such, you're expected to have certain QA standards, as well as have a customer support that consists of something more than whining about forum drama or blaming broken software on anime watchers.

[pirlouy]

Sorry to be such an ass-kisser, but even if you don't like this new version, you don't have to insult developers like that. It's not if there were a spyware... :/

[AzraelNewtype]

Sorry to be such an ass-kisser, but even if you don't like this new version, you don't have to insult developers like that. It's not if there were a spyware... :/

You're right, it's not spyware. It is, however, a product that they took our money for that does not work.

Oh, and I know BetaBoy has since backpedaled on his weird assertion that the bugs are anime related, but for reference this is not anime (http://i26.lulzimg.com/a864e7.png). If the developer is going to be this defensive of his product when it does not work (it should look like this (http://imgur.com/wcovB.png)), and is in fact shifting blame back onto the paying customers, there is little reason to be polite.

[mandarinka]

To be honest people sure seem to enjoy that ("paid-for"?) right to complain a bit too much. It could have been expressed less internet-like, imho. True that if CC tested a bit more thoroughly, they woudln't give the crowd the chance, but mistakes happen.

[BetaBoy]

Oh, and I know BetaBoy has since backpedaled on his weird assertion that the bugs are anime related
??? I was referencing Anime community as being early adopters and reporting the issues before anyone else.

and for many testers I've spoken with the decoding performance is slower than in 2.6 hearsay.. If you can provide us with content that shows this speed difference it would be appreciated.

Please forgive us..
Not at all.... I've said this 100x in this thread that we value everyone's support and awesome feedback. Having someone like Stephan however jump in and continue to post biased FUD brings nothing of value to the discussions.

That being said we are reacting faster the ever before to our customers as the past few releases show and we continue to do so with 3.x (and with the fact we are about to releases CoreMVC 3D as well).

[SEt]

BetaBoy, if you are started to fix bugs, please correct your wrong mediatype on DXVA2 connections: it should be subtype/compression 'NV12'/'dxva' not the 'NV12'/'NV12'. Sure I can detect it as DXVA2 later but it's still wrong and produce strange effects like the following one:

Set DXVA mode in CoreAVC, allow only YV12 output format. Now connect it to filter that rejects DXVA but accepts NV12 - result is connection with NV12.

PS: After writing for some time for DirectShow you understand that like every single filter has obvious bugs, haha (sad)... For example CyberLink that was in DXVA field forever won't work with you if you follow only standards.

[BetaBoy]

SEt... thx for the report I posted it for the devs to look into.

[TheShadowRunner]

A couple extremely simple questions as the 3.0 "what's new" doesn't make it clear ("CUDA" doesn't even appear anywhere!):

1. Is hi10 decoding in CoreAVC 3.0 strictly (=100%) done by the CPU?

2. If so, is it because CUDA acceleration CANNOT technically be implemented for hi10 sources or is it a limitation of the current 3.0 build?

3. If limitation of current build, can we imagine a scenario in the future where hi10 decoding gets hybrid: CPU + partial CUDA offloading?

Thanks for these infos..

[BetaBoy]

We just fixed the 'high depth bug' re: blockiness, for the next release.

[Keiyakusha]

If limitation of current build, can we imagine a scenario in the future where hi10 decoding gets hybrid: CPU + partial CUDA offloading?

Maybe a little OT but... do you know any decoders that do "partial CUDA offloading" which makes you expect something like that from CoreAVC? And why you asking only for 10bit but not for 8bit?

[TheShadowRunner]

Maybe a little OT but... do you know any decoders that do "partial CUDA offloading" which makes you expect something like that from CoreAVC? And why you asking only for 10bit but not for 8bit?

No, i certainly don't, just wondering.
And I don't ask for 8bit, because i know CUDA acceleration takes care of it already :P

Betaboy, please at least answer question 1/2!

A couple extremely simple questions as the 3.0 "what's new" doesn't make it clear ("CUDA" doesn't even appear anywhere!):

1. Is hi10 decoding in CoreAVC 3.0 strictly (=100%) done by the CPU?

2. If so, is it because CUDA acceleration CANNOT technically be implemented for hi10 sources or is it a limitation of the current 3.0 build?
Thanks,

TSR

[cyberbeing]

and for many testers I've spoken with the decoding performance is slower than in 2.6 hearsay.. If you can provide us with content that shows this speed difference it would be appreciated.

This had me a bit concerned, so I tested a few random 8bit videos. Thankfully I can say that CoreAVC 3.0.0 x86 is consistently about 1% faster than 2.6.1 on my old AMD X2. Nothing to write home about, but a speed-up is a speed-up. So if there is an issue, it doesn't seem to affect old AMD processors.

68.5356 CoreAVC 3.0.0
67.9791 CoreAVC 2.6.1

65.3254 CoreAVC 3.0.0
64.5945 CoreAVC 2.6.1

62.0784 CoreAVC 3.0.0
61.3808 CoreAVC 2.6.1

64.3769 CoreAVC 3.0.0
63.8261 CoreAVC 2.6.1

183.4490 CoreAVC 3.0.0
182.8061 CoreAVC 2.6.1

157.7797 CoreAVC 3.0.0
157.0646 CoreAVC 2.6.1

[LoRd_MuldeR]

The term "CUDA decoding" or "CUDA offloading" is misleading. Actually I am not aware of any H.264 decoder that is implemented as a CUDA kernel, i.e. running on the GPU. Instead all those "CUDA" enabled/accelerated decoders simply use the hardwired H.264 decoder chip that is integrated on the graphics card. That decoder chip is a dedicated piece of hardware. It may be accessed via the "CUDA Video API" (CUVID), but that is very different from a "real" CUDA kernel. The latter would be running on the programmable GPU (shader cores). Also the decoder chip is the very same one that would be used by a "DXVA" enabled/accelerated decoder. This also means: What can (or can not) be decoded "in hardware" does not depend on the individual decoder software (may it be CoreAVC or something else), but on the decoder chip on the graphics card! If, for example, the decoder chip on the graphics card does not support 10-Bit H.264, then there is nothing that the decoder software could do about that - except for falling back to pure software decoding, of course. Hardware decoder chips can not be updated. If you want new hardware decoder features, then you have to wait for the next generation of graphics cards...

[Keiyakusha]

And I don't ask for 8bit, because i know CUDA acceleration takes care of it already :P
Actually no... not really. What i mean is, you asked about partial acceleration (for weaker hardware i guess?), which means some real CUDA-based decoder should be created. Current implementation only passes video to the chip, located on the videocard and nvidia does the rest, so its nowhere near any partial stuff.
EDIT: oops i'm so slow... so much of good stuff was written before me...

[SEt]

If you are interested, I can also confirm DXVA2 cpu usage regression. GraphStudio speed test to Null Renderer, some random 720p anime (fps/cpu):

DXVA2:
86 13.5% CoreAVC 3.0.0
103 1% CoreAVC 2.5.5
103 1% FFDS

CUDA:
87 1.5% CoreAVC 3.0.0 and 2.5.5
102 2% LAV

Software:
1640 CoreAVC 3.0.0
1573 LAV

As you can see from software speed it's a lot of wasted CPU resources.

[ajp_anton]

But what if this 8-bit hardware decoder in fact does output *something* from a 10-bit clip that is not pure garbage, with enough real data that it's worth patching the bad spots in software.

[STaRGaZeR]

This thread is always so fun to read, specially after a release. :)

[TheShadowRunner]

This also means: What can (or can not) be decoded "in hardware" does not depend on the individual decoder software (may it be CoreAVC or something else), but on the decoder chip on the graphics card! If, for example, the decoder chip on the graphics card does not support 10-Bit H.264, then there is nothing that the decoder software could do about that - except for falling back to pure software decoding, of course.

Thank you very much, finally.
So CoreAVC 3.0's hi10 decoding cannot and never will be "CUDA accelerated" with the current nVidia cards in the market.
CoreAVC's 3.0 hi10 decoding is 100% CPU.

Actually no... not really. What i mean is, you asked about partial acceleration (for weaker hardware i guess?), which means some real CUDA-based decoder should be created. Current implementation only passes video to the chip, located on the videocard and nvidia does the rest, so its nowhere near any partial stuff.
EDIT: oops i'm so slow... so much of good stuff was written before me...

Roger that, I didn't know. I though CoreAVC's CUDA implementation just used the horsepower of the chip on the nVidia card but instructed it HOW to decode, which made it different from DXVA.

But what if this 8-bit hardware decoder in fact does output *something* from a 10-bit clip that is not pure garbage, with enough real data that it's worth patching the bad spots in software.

That was pretty much my question too, maybe I formulated it badly ^^;

[SEt]

Nothing useful can be done with wrong decoding result of h264. But you have good chances to find something in hardware that can do correctly part of algorithm (like, stream decoding, IDCT,...) and use that hardware part with the rest of software. It will be partial hardware acceleration. How much can it help to free cpu? Who knows...

[LoRd_MuldeR]

But what if this 8-bit hardware decoder in fact does output *something* from a 10-bit clip that is not pure garbage, with enough real data that it's worth patching the bad spots in software.

A hardware decoder chip either supports 10-Bit or it does not. In the latter case it would probably reject 10-Bit streams and not output anything at all. And, if it does not reject the unsupported stream for some reason, the output will simply be "undefined" (or in other words: random garbage). This cannot be "patched" in software, except by throwing away the hardware decoder's broken output and properly decoder the source in software! Also: Even if it was possible to recover the broken output somehow, why should anybody want to use a hardware decoder for something that it never was designed for (and therefore cannot handle correctly), just to spend a whole lot of CPU cycles for "repairing" the broken output afterwards? Sounds like a rather bizarre idea to me...

But you have good chances to find something in hardware that can do correctly part of algorithm (like, stream decoding, IDCT,...) and use that hardware part with the rest of software. It will be partial hardware acceleration. How much can it help to free cpu? Who knows...

Doesn't the whole decoding pipeline have to support 10-Bit precision to properly decode 10-Bit streams?

[SEt]

I'm not expert in h264 internals, but likely no. Decoder has to use >8 bit internal precision for decoding 8 bit content anyway and it means likely 16 bit precision that could be ok for 10 bit too.

[LoRd_MuldeR]

Decoder has to use >8 bit internal precision for decoding 8 bit content anyway.

I don't think so. H.264 uses integer math. And when decoding 8-Bit streams the decoder has to truncate everything to exactly 8-Bit internally for correct output.

(It is the other way around: Using more than 8-Bit internal precision is beneficial, even for 8-Bit sources. But it requires a "high bit-depth" capable H.264 encoder + decoder).

[TheShadowRunner]

BetaBoy, will decoding hi10p contents benefit from the current acceleration methods (CUDA, DXVA..) in CoraAVC 3.0, or will it be 100% software only?
I can imagine DXVA is a no go, but I wonder about CUDA..
Thanks for the info.

Ill comment once 3.0 is out, but you're not far off.

So, I guess I was REALLY far off after all...

[SEt]

Encoder/decoder be it software or hardware 'truncates everything' as rare as it can, likely only at the very last stage. And 8 bit is not enough for processing 8 bit with something more complex than inverse or average of two values.

[BetaBoy]

This had me a bit concerned, so I tested a few random 8bit videos. Thankfully I can say that CoreAVC 3.0.0 x86 is consistently about 1% faster than 2.6.1 on my old AMD X2.

You should see some additional 8-bit speed increases soon enough as we had been working on some more (8-bit) optimization's but because of time constraints they did not make it into 3.0.

[LoRd_MuldeR]

This is getting off-topic, but for proper output all decoders have to truncate all intermediate results in the same way. Otherwise it couldn't be guaranteed that all decoders deliver the identical (correct) output for a given input stream. So when decoding 8-bit streams, all intermediate results are truncated to 8-bit internally. That is also the reason why using an higher internal precision (e.g. 9-bit or 10-bit) gives better encoding efficiency, even if the source was "only" 8-bit: There are fewer rounding errors in the encoding/decoding pipeline. But, as encoder and decoder have to agree on the internal precision (and must truncate accordingly), 9-bit or 10-bit encoding also requires a 9-bit or 10-bit decoder. Moreover 8-bit internal precision mainly is a shortcut for speed improvement. So if the stream was encoded with 8-bit precision, you want to decode with 8-bit precision (and not some higher precision, even if you could), simply because it is faster. That's also the reason why hardware decoders that don't officially support more than 8-bit precision will probably not be prepared for 9-bit or 10-bit precision internally. Why would you waste silicon for something that you don't expose/sell as a feature?

[Fadeout]

Can we also have DXVA fixed since it was working fine in 2.5 and it's not involved in hi10?

Current problems: high CPU usage and non-smooth performance on some complex videos.

[BetaBoy]

We just fixed the DXVA memory resources bug.... We are onto the reports of high bitrate Hi10p videos next, but given that it might take some time to work on the assembly code (and address the Haali MP4 bug), we will likely release an update ASAP. CoreAVC 3.0.1 incoming ;-)

[eddman]

People, how about providing detailed bug reports? Simply saying that it's not working or it's slow for me won't really help. It should be something like this:

1. Describe the problem throughly and provide video sample if possible, if not then at least provide screenshots (if applicable)
2. OS - Win XP SP3
3. CPU - Core 2 Duo E6700
4. GPU - Geforce 9600 GT
5. Video Driver version - 260.89
6. Player - MPC-HC 1.5.0.2827
7. Renderer - VMR-9 windowed
8. Splitter - Haali 1.10.262.12
9. Codec - CoreAVC 2.6.1
10. Output - YV12
11. Acceleration - DXVA
12. Other specific things that might help.

[CruNcher]

@Dan
there are several bitstreams where the Full (Intel 2nd Generation) Performance (also in terms of Power output) of CoreAVC 3.0 8 bit 64 bit @ least is not that good in direct compare :(

Here is one of those examples (Yv12):

http://img35.imageshack.us/img35/5793/crysis2gb.png

and overall it losses to DiAVC 64 practically all the time (except some rare bitstreams 4k) and sometimes Lav Video (libav) can take over it too (though lav video never makes it to get to DiAVC Performance)

[hajj_3]

I'm quite suprised that CoreAVC haven't bought out DiAVC to be honest, he said he'd be willing to sell it for $200k and for the sourcecode to be opensourced, i would have thought that coreavc must be making quite a bit of money from commercial usage of their products to buy DiAVC, that would be a seriously fast decoder and there would be no real competition as people don't want to install all the junk divx bundles, they just want a codec to play xvid/x264 videos with low cpu utilisation.

With hd decoding on modern intel/amd/arm processors the uses of coreavc will reduce more and more. Divx could buy DiAVC too, that would be very lucrative for them seeing as thought divx is in so many devices, its a no-brainer for them.

[CruNcher]

The Decision to buy DiAVC IP would be up to Rovi ;) though Mainconcept/Elecard Engineers (which the core of the whole DivX H.264 Framework is based on + Matroska (CoreCodec)) aren't bad either and one of the oldest MPEG standard based digital video codec implementers in the World (they had 10 bit support much earlier then you might imagine) and most probably will reach that Performance soon (or maybe have reached it already) so not sure if they have a real interest in buying his code also buying his code would be not really efficient, employing him directly would be much better ;)

And to your other question, thats Graphstudio from Radscorpion (RadLight) though you have to know what you do as it's based on Directshow if you want to give it a try http://blog.monogram.sk/janos/tools/monogram-graphstudio/

[BetaBoy]

We have fixed the Haali Splitter Bug MP4 recognition and it will be included in our next CoreAVC 3.0.1 release.

[hajj_3]

i presume 2.6.2 will follow that?

[betaking]

We have fixed the Haali Splitter Bug MP4 recognition and it will be included in our next CoreAVC 3.0.1 release.
Next week or tomorrow?:thanks:

[BetaBoy]

i presume 2.6.2 will follow that?

Correct however out of respect for past purchasers we might release it before 3.0.1

[BetaBoy]

Next week or tomorrow?:thanks: Likely later today or tomorrow after we QA.

[betaking]

Likely later today or tomorrow after we QA.

:thanks:

[cyberbeing]

Likely later today or tomorrow after we QA.

To avoid huge memory leaks like this in CoreAVC, i would however recommend to free the memory buffers when the input pin is disconnected, and not wait until the filter is destructed. (Which is why it doesn't show up on other filters, they do exactly that)

Did what nevcairiel suggested make it into 3.0.1 to fix the memory leak issue with madVR 0.74? Would doing so break something else or be undesirable for some reason?

And then there is also the 10-bit to P010/P016 conversion being slower than it should be, at least on my AMD X2, to keep in mind.

[dead_screem]

A couple bugs. Haali will cause Graphstudio video decoder benchmark to crash on the last pass or when I press stop (when the graph is deconstructed I assume). I have to switch to the MPC-HC standalone filters.

When DXVA1 is used CoreAVC is using a weird output 4cc H¾ then two characters that cant render here on the forum, a middle dot and then a left pointing arrow. Instead of "dxva" like MPC-HC. I have no idea if this is really a bug or if it actually affects anything.

[BetaBoy]

Did what nevcairiel suggested make it into 3.0.1 to fix the memory leak issue with madVR 0.74? Would doing so break something else or be undesirable for some reason?

And then there is also the 10-bit to P010/P016 conversion being slower than it should be, at least on my AMD X2, to keep in mind.
The issue with madvr is that it should release the CoreAVC instance. We can add memory releases but the point is we shouldn't as it has the side effect of causing more bad then good, like:
- Having multiple monitors hang
- Causing multiple tray icons
- Possible setting conflicts

Was madshi doing a fix for this?

ok... on the noted conversion slowdown.