CoreCodec/H.264 Codec "CoreAVC"

[drmpeg]

Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.

Almost every 1080i pay TV channel in the US has IVTC enabled on their encoders.

Ron

[BetaBoy]

madshi... we are on the fence here about your post. It's our general opinion that this is not a bug and that it's more of a feature request. So to that...

CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other so the flags are then useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set.

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.

The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.

[madshi]

we are on the fence here about your post.
"On the fence" isn't too bad, it means you're still open for discussion... :D

CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set.

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.
You're saying that users would get an interlaced picture if you set the telecine flags. But I don't think that's true. Anyway, can you describe a setup for me where setting the telecine flags would result in a loss of quality? The LAV Video Decoder does (always) set the telecine flags, so it should be easy to test. If you're right then LAV Video Decoder should show soft-telecined content at a lower quality compared to CoreAVC with some renderers.

The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.
And that is exactly what I'm working on. But CoreAVC is making things harder than necessary. CoreAVC sets the media type information to 30fps, but for soft-telecined sections only sends 24fps, without telecine flags. So basically CoreAVC is lying. If you remove the telecine flags then you should set the media type information to 24fps. Of course that will make problems with content that has hard-telecine sections, so that brings me back to my argument that there's no reason not to set the telecine flags.

If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless.
I'm sorry to say but this is just not true. If you look at such mixed hard-/soft-telecined streams, if you honor the soft-telecine flags you always end up with exactly 60 fields per seconds, no matter how often the stream switches between soft- and hard-telecine. If you silently drop the telecine flags, the deinterlacer will neither get 48 fields per second, nor 60 fields per second, but something in between, every time the stream switches between soft <-> hard telecine. If you have ever tried writing an IVTC algorithm then you should know that this is not a good situation. Getting exactly 60 fields per second is a requirement of most IVTC algorithms. How else can you detect a 3:2 pattern in the stream? If you get e.g. 55 fields per second, the 3:2 cadence will be broken several times and applying IVTC will become extremely hard to do.

[06_taro]

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.

Then you can provide an option for end users to decide whether to maintain pulldown flags and handle them after decoding, or to drop the flags with 24fps film content output directly as in the present version. Those who never meet mixed soft/hard telecined films and don't use any IVTC/deinterlacing postprocessing can still choose the second one to avoid getting interlaced content, but for those who prefer a more reliable IVTC algorithm which can handle mixed soft/hard telecined contents, the first one is much better for most ( if not all ) IVTC algorithms.

[dead_screem]

CoreAVC already removes soft pulldown by itself.

define remove?

lav and other decoders I used as well (mpeg-2 decoders mostly), leave the indicated output framerate alone at 29.97 so hard telecine parts of a mixed stream play back at 29.97 (or 59.94) but soft telecine parts of the stream play back at 23.976. In coreavc soft telecine plays back at 29.97, the same as hard telecine.

at the very least, this should be an option to do it as in lav, so users can (when madshi's ivtc renderer is done) play back 29.97 hard and soft telecine streams as well as mixed hard/soft at 23.976

[v_spec]

In version 3.01 I noticed a new output option '9/10 bit', but whenever I check the box then hit Apply and OK the box is unchecked when I go back into decoder properties. What does that mean? Is it a problem with CoreAVC or my hardware?

[cyberbeing]

It's neither a problem with CoreAVC or your hardware. The '9/10 bit' check-box is only a toggle for showing/hiding P010 & P016 in the output format box. The '9/10 bit' check-box does not affect anything but the GUI.

The real options to enable/disable high bitdepth output are the P010 & P016 check-boxes. As long as they are checked, they are enabled and available for use with 9/10 bit h264 video and a supporting video renderer. (Currently only madVR supports P010/P016 input).

[v_spec]

Thanks for clearing that up. I've been reading up on madVR for the past couple of hours and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?

[cyberbeing]

There is a noticeable quality difference between 10-bit x264 and 8-bit x264.

Yet there is hardly any quality difference between CoreAVC outputting 10-bit x264 as dithered 8-bit YV12 vs 10-bit P010. Both ways are eventually output to your display as 8-bit.

If you are using madVR there is a minor technical benefit of outputting P010, since madVR can then do other processing gamut/gamma/yuv->rgb using the full 10-bit data and dither to 8-bit for your display as the last step. Would you notice the difference of madVR processing 8-bit input vs 10-bit input, probably not. But depending how close you look, you may notice a difference in dithering quality & noise pattern.

[Keiyakusha]

and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?
You should think of 10bit as "yet another switch in x264 that improves quality during encoding" And resulting 10bit file is "yet another video format"
^very simplified explanation
The switch in the coreavc and other decoders tells what they should do, leave 10bit format as is so it will be dithered to 8bit later (by madvr for example) or dither it by itself. So nothing is wrong if you don't see the difference.

[NikosD]

@BetaBoy

Hello.

Is there any plan of supporting resolutions beyond 1920 x 1088, like 4K x 2K (3840 x 2160) in DXVA mode and suitable hardware of course ?

Thanks!

[hajj_3]

I doubt there is any hardware that can accelerate 4k out there.

The Cortex A8 Allwinner A10 ARM has built-in support for hardware decode of 2k but i'm not aware of anything with 4k.

If Intel/AMD/Nvidia comes out with 4k hardware decode support i'm sure CoreAVC/DiAVC will support it.

[Keiyakusha]

i doubt there is any hardware that can accelerate 4k out there.


gt 520

[wanezhiling]

http://www.mediafire.com/?7vc5zl5tbm9y55p
GF119, dxva 2160p. :D

[NikosD]

Radeon 5000 series with UVD 2.2 are capable of 4K since April 2010 with Catalyst 10.4
But there were no suitable decoders/players to support it due to Nvidia restrictions.

As I have proved here http://forum.doom9.org/showthread.php?t=163110 even UVD 2.2 is more capable than most people think.
UVD3 supports 4K too.

I thought now that there is VP5 which seems capable of 4K, Nvidia should be more flexible to allow 4K in general and pull back the pressure of not allowing 4K decoding on ATI hardware.

[rica]

Still waiting for CoreMVC.

[NikosD]

http://www.mediafire.com/?7vc5zl5tbm9y55p
GF119, dxva 2160p. :D

For me - 5750 UVD2.2 - it's not working even though DXVA checker says about the Device decoders:

"ModeH264_VLD_NoFGT: DXVA2, 720x480 / 1280x720 / 1920x1080 / 3840x2160"
"ModeH264_VLD_NoFGT_Flash: DXVA2, 720x480 / 1280x720 / 1920x1080 / 3840x2160"

So from the side of hardware and driver, UVD 2.2 is capable of 4K x 2K and if CoreAVC DXVA is capable of 4K x 2K, as it is clearly seen by your screenshots, then the problem must be an artificial restriction in everything else but VP5 inside the code of CoreAVC DXVA.

DXVA checker reports for clips beyond 1080p and CoreAVC DXVA the following:

"ModeUnknown (NV12): DXVA1 (VMR)"

and of course it's not working.

@BetaBoy

I would like to check my "fused" 5750-6750 card in 4K x 2K DXVA with its "supernatural" video decoding capabilities as I have clearly demonstrated here:
http://forum.doom9.org/showthread.php?t=163110

[Cyber-Mav]

Radeon 5000 series with UVD 2.2 are capable of 4K since April 2010 with Catalyst 10.4
But there were no suitable decoders/players to support it due to Nvidia restrictions.

what restrictions are these you speak of imposed by nvidia?

[NikosD]

Because VP4 is very slow at high bitrate clips as you can see here http://forum.doom9.org/showthread.php?t=163110, UVD2.2 was forced to be incapable too for 4K x 2K in order to have comparable performance with VP4.

Nvidia had always a few ways to do things like "The Way it's meant to be played"

UVD2.2 in 5xxx series was too fast when introduced back in October 2009 and with Catalyst 10.4 - on April 2010 -it was ready for H.264 L5.1 including 4K, as it is written in Catalyst 10.4 Release Notes.
I can send you the file if you can't find it with google.

As you can see at the above link, UVD2.2 is more powerful than it seems and the reason that is lowered is not Nvidia only, but ATi too, mainly ATi I could say.

ATI wanted to sell UVD3 for MPEG2_VLD, MPEG4ASP_VLD and 4K H.264 playback.

All of them are features of UVD2.2, that have never activated in order to "push" you to buy the next generation card.

Even now if you force MPEG2_VLD, MPEG4ASP_VLD and 4K H.264 playback in UVD2.2, you get a normal playback mode with a GREEN FRAME covering the picture of the video file.

They don't want you to see the clip! :)

Of course all of the above are a joke, just a conspiracy theory I invented with my vivid imagination...

[Cyber-Mav]

if ati uvd 2.2 is so fast then why doesnt it show so in the benchmarks? looks like its either more of a hardware limitation or a driver lmitation. nothing is showing that its being held back by nvidia. last time i checked its the standard dxva mode that ati uses for hardware acceleration, and there is nothing nvidia can do to influence dxva acceleration.

unless you mean that the uvd2.2 is being held back by not having cuda support?

if you get green frame during playback its usually a sign that your hardware cant decode properly due too an out of spec input file. i get that a lot on my old mkv media player if i encode files with too many reference frames.

[clsid]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?

[robpdotcom]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?

I'm interested to know this as well.

[nevcairiel]

Whatever happend to CoreMVC? Wasn't it supposed to be released right after CoreAVC 3?
It seems to have a big marketing advertisement page on their website, but no download/purchase possibility.

[BetaBoy]

Whatever happend to CoreMVC? Wasn't it supposed to be released right after CoreAVC 3?
It seems to have a big marketing advertisement page on their website, but no download/purchase possibility.
It has been out since last February, but only for OEM licensing in both library and directshow forms. Based on feedback we opted to push out a consumer directshow decoder till after we added 4:2:2 and 4:4:4 in CoreAVC. We will revisit a possible release afterwards.

[BetaBoy]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?
The fix will be included in the next CoreAVC release.

[CruNcher]

@Dan
i hope it isn't to late yet, though maybe this is already fixed then you can ignore it :)

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

the issue is after the glitch Lav Splitter,Haali Splitter,MPC-HC splitter (Lav Audio) doesn't Recover with CoreAVC it begins to stutter (frames are dropped) (Software,DXVA,cuvid not tested) it works fine with Lav Video (any mode, cuvid not tested) see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

[NikosD]

@BetaBoy

Is it possible to clarify which path do you enable in order to HW accelerate H.264 files on Intel's QuickSync HW ?

There are a lot of confusing and contradicting issues regarding Intel's HW acceleration.

For example CoreAVC 2.x has DXVA support which utilises ModeH264_VLD_NoFGT but not for Intel.
It doesn't work.
It was Core AVC 3.x which added Media SDK and GMA support.
Do you use ModeH264_VLD_NoFGT or ModeH264_VLD_NoFGT_ClearVideo in order to HW accelerate H.264 files in CoreAVC 3.x ? Or something else ?
Because the performance of CoreAVC DXVA with QuickSync HW, indicates that it uses some direct mode of DXVA and not copy-back like QuickSync decoder by Egur.
At the same time using Intel's Media Checker tool, I saw that CoreAVC 3.x during HW accelerated playback on QS HW doesn't use Media SDK decode operations.
No HW calls, no SW calls of Media SDK.

So what is the mystery of CoreAVC 3.x and what's missing from CoreAVC 2.x ?

Is it a direct use of Media SDK - without copy-back- that Media Checker is not capable to catch ?

Thanks in advance.

[CruNcher]

it uses the ClearVideo mode like any other ISV does, copy back makes no sense for a On screen Decoder if you have Native DXVA support why the heck you would want to use copy back for playback ?
Copy Back makes sense to be used in a Decoding(DSP,GPU)->Encoding(Software,DSP,GPU) scenario where you balance both out so the CPU overhead can be compensated efficiently so the Encoding stays lower Power and Faster then without Copy Back (Software Decoding) :)
Or if you still need acceleration and lower power and combine it with a 3D renderer (for example a Broadcast Editing system with complex layer setups) :)
But for a consumer Playback system it makes no sense and isn't beneficial @ all @ least on Windows

[NikosD]

I didn't say CoreAVC uses copy-back.
I said the opposite, that they don't use it.

But CoreAVC supports Media SDK after CoreAVC 3.x.
ClearVideo support was there in CoreAVC 2.x, but QS HW support in CoreAVC 2.x wasn't.

You put PotPlayer and MPC-HC in ISV's too ?

What do they (PotPlayer and MPC-HC) use with their internal codecs in order to accelerate in QS HW the H.264 video ?

[CruNcher]

I didn't say CoreAVC uses copy-back.
I said the opposite, that they don't use it.

But CoreAVC supports Media SDK after CoreAVC 3.x.
ClearVideo support was there in CoreAVC 2.x, but QS HW support in CoreAVC 2.x wasn't.

You put PotPlayer and MPC-HC in ISV's too ?

What do they (PotPlayer and MPC-HC) use with their internal codecs in order to accelerate in QS HW the H.264 video ?

The same ClearVideo DXVA interface, though CoreAVC uses some clever workarounds the same as Mirillis does for several special decoding issues :)

Not every DXVA decoder is the same only because its using the same interface :)

Arcsoft and Cyberlink are currently also going this way trying to fix issues with workarounds

[NikosD]

Apparently MPC-HC doesn't have access to ClearVideo documentation because they have disabled DXVA acceleration for QS HW.

It doesn't work for them and they haven't found those clever workarounds you mention.

Splash and PotPlayer work fine with QS HW.
But I think PotPlayer doesn't have access to ClearVideo too, like MPC-HC.

How did they do it ?

[nevcairiel]

How did they do it ?

Probably stole it somewhere, like all their other stuff.
Also, PotPlayer uses Erics QS decoder.

[NikosD]

Probably build it by themselves, because there is no free code accessible for that task.
Erics QS decoder is an alternative mode for PotPlayer, like many others.

But their own internal codecs provide native DXVA acceleration for H.264 and MPEG-2, without using quicksync.dll

@Cruncher
If PotPlayer had access to ClearVideo documentation, they would have added VC-1 DXVA acceleration for QS HW, too.
Which is ClearVideo only.

So PotPlayer doesn't use ClearVideo for H.264, either.
They do it natively.

And what about MS DS/MFT ?
Do they use ClearVideo too?

[CruNcher]

they think practical why reinvent if someone did it already though they try to fix things no one tackled yet but give nothing back that's the shame of it :(
Though they don't do very advanced workarounds their workarounds are mostly container analyze based (MediaInfo) and just turning stuff on and off (still they have no automatic QS fallback for some of these issues which is the easiest way to fix them) when they think its better todo so but the other go into the bitstream level itself ;)

[TheShadowRunner]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.

[BetaBoy]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.

We are looking into it, thx for the sample.

[CruNcher]

@Dan

https://forum.doom9.org/showpost.php?p=1554111&postcount=6977

[BetaBoy]

CruNcher.. got it... fixed, thx.

[BetaBoy]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.
Fixed. Thx again for the report!

[dead_screem]

Care to comment on when the next version will be out? Twitter says "Feburary" but that is kinda vague, especially since there was going to be a quick turnaround 3.0.2 bug fix only release, but you guys decided to wait for 3.1 to release those fixes, and 3.1 was supposed to start finalizing last Dec 12... So, when's it coming out?

[BetaBoy]

As with all of our releases its a moving target based on feedback and where we are at with it, so its ready when its done. As you can see above we are also addressing other reported bugs as they are being reported as well as doing some work on Haali's Splitter so this has also affected our timeline.

At the moment it is looking like we are gonna push out adding 422 (444 will likely make it) with the next release to make sure the newer changes are solid before committing it. We will however likely still stick with it as a milestone in calling it 3.1 though considering all the work we have done on it.

We have a few smaller todo's with include Chroma MC ASM and 444 filter work, so we are close.

[kerman]

Doesnt CoreAVC supports VC-1? I have it as the main external filter on mpc-hc but doesnt run on VC-1 streams. It does on h.264/x264, but never with VC-1. I use MPC-HC x32 with madVR and Haali media source. OS Win7x64.

Also, on h.264 decoding doesnt enable dxva2 (tray icon is always blue), although I have dxva checked on properties. I have an AMD HD6950. Should I check/uncheck anything on CCC or mpc-hc?

[nevcairiel]

CoreAVC is only for ... AVC1, as the name suggest, also known as H.264. VC-1 is a different codec entirely, and not supported by CoreAVC.
I'll admit that the "AVC1" and "VC-1" might be confusing at times, but AVC1 is just an alternate name for H.264.

[kerman]

Thanks, yes I just got confused. BTW, is there any "champ" on VC-1 codec performance? Mainconcept, Arcsoft, Cyberlink...? I mean, similar to CoreAVC with H.264

[betaking]

Thanks, yes I just got confused. BTW, is there any "champ" on VC-1 codec performance? Mainconcept, Arcsoft, Cyberlink...? I mean, similar to CoreAVC with H.264

Microsoft>Cyberlink>Arcsoft>Mainconcept!

[Midzuki]

Microsoft>Cyberlink>Arcsoft>Mainconcept!

I agree, Mainconcept's VC-1 decoder is sluggish as hell :p

BUT maybe it's good enough for accurate frameserving via DirectShowSource() :D

[CruNcher]

yep normaly Mainconcept does excellent work but the VC-1 Decoder is far from that and it's funny seeing Cyberlink and Arcsoft beating it but i guess Mainconcept doesn't invest much resources into it's Developing ;)

[robpdotcom]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?The fix will be included in the next CoreAVC release.

I'd also like to request that Haali change the way it deals with subtitle streams - right now it loads default subs automatically, but I think everyone would be happier if it only loaded forced subs.

Also, is there a way to allow the video renderer to do the deinterlacing? I only see the option to set:

None (weave)
Single Field
Bob
Hardware

There is no option to output interlaced frames.

[Thunderbolt8]

I think everyone would be happier if it only loaded forced subs.not me ;)

[Shevek]

not me ;)


me neither!

If you don't want a sub stream to be default then make sure the default flag isn't set when you mux the file.