CoreCodec/H.264 Codec "CoreAVC"

[ADude]

Along with CoreAVC 64 we are bundling 64 bit versions of TimeCodec ...

Interesting... I'm guessing that you enter a time, and it plays videos from that day and time ?

Can I enter "1 January 2020" ?

:eek:

[LoRd_MuldeR]

Interesting... I'm guessing that you enter a time, and it plays videos from that day and time ?

Can I enter "1 January 2020" ?

:eek:

:p

TimeCodec is a tool for benchmarking video decoders. The existing x86 version is here:
http://haali.cs.msu.ru/mkv/timeCodec.exe

[the_corona]

Ok guys.... As many of you know I have mentioned this before but we are about to finally go into beta phase of CoreAVC 64, and are looking for a few elite D9 testers that have 64 bit systems that can test and provide feed back on.

Now this does not feature our upcoming 2.0 branch changes, but it does feature many of the things not in 1.7 like our levels slider (brightness, contrast, saturation).

PM me you system specs.... thx

Will CoreAVC 64 be free for existing customers?

For me I'll def. need a 32 bit version because my Mediacenter software is 32 bit, on the other hand if the 64bit Ver. is faster, it might just make it for some demanding videos and so one could use diff. player software (64 bit) for those.

Of course if it's not really faster theres hardly any point. So is it (free/faster)? :-)

Thnx

[BetaBoy]

No, as CoreAVC 64 is a new product. As far as faster, yes.

[JohnnyFu]

BetaBoy, did you read my pm ? I don't expect you to answer but confirming would be nice.

Will there be a trial versoin of CoreAVC 64 as well ? Since it's not free for existing customers.... I'm not gonna buy without testing it, sorry.

[BetaBoy]

BetaBoy, did you read my pm ? I don't expect you to answer but confirming would be nice.

Will there be a trial versoin of CoreAVC 64 as well ? Since it's not free for existing customers.... I'm not gonna buy without testing it, sorry.

No trial for CoreAVC 64 is planned. I'll jump into the PM's now.

[todaystudy]

I am not saying that they must make it more complicated! The site funcionality is very good! I am saying that they must make it more beautiful!!!

We are speaking about a VIDEO DECODER here (people want to see something with style)!!! They have to use nicer colors and buttons! You can't just use 3-4 very basic colors for a website that sell a VIDEO DECODER!!!!! It is so....... Linux!!!

Anyway, I hope to see something cool in it!!!

[the_corona]

I am not saying that they must make it more complicated! The site funcionality is very good! I am saying that they must make it more beautiful!!!

We are speaking about a VIDEO DECODER here (people want to see something with style)!!! They have to use nicer colors and buttons! You can't just use 3-4 very basic colors for a website that sell a VIDEO DECODER!!!!! It is so....... Linux!!!

Anyway, I hope to see something cool in it!!!

What the hell? When did the discussion about their website start? I could give a * what their site looks like tbh, but for the record I personally find it kinda stylish. But seriously, I'm shocked how rude some people can be....

BetaBoy, not free and no trial.....I don't know. Better be some kick-ass perf. numbers then to convince people to shell out money again :-) I will patiently await such results

[BetaBoy]

Well as in anything a trial version is an option.... but we figure if you like the trial of the 32 bit version... and we state the 64 bit version is faster, isn't that enough? But point taken... we are listening to the feedback for sure.

[BetaBoy]

I also wanted to state that we are also adding 4:2:2 support to CoreAVC Professional (and 64) as well. Will it make it into 1.8 or 1.9? That depends on QA and our release time frames going into 2.0.

[the_corona]

Well as in anything a trial version is an option.... but we figure if you like the trial of the 32 bit version... and we state the 64 bit version is faster, isn't that enough? But point taken... we are listening to the feedback for sure.

Well, on second thought I guess you're right. I just meant for me (if you think about the "complexity of 64 bit" ... finding a player, finding audio codecs, splitters (ok you got that one covered) etc. and all that in stable enough form) and the added cost for another decoder is something that I would only consider if indeed it was notcably faster so that I can play files I am unable to currently, or use some postprocessing with noticably saved cpu cycles.

And, well, I can only find that out one way (or caluclate based on your perf figures and hope it scales as well on my machine). Well you know.

On the other hand, its not like its $100 and I've bought more expensive things in the past I ended up not being able to use, hehe.

So point being, if its much work, I guess I'd rather you spend time optimizing the decoder itself than build a trial (remember you got/will have competition now too).

Thank you for listening.

[cyberbeing]

Well as in anything a trial version is an option.... but we figure if you like the trial of the 32 bit version... and we state the 64 bit version is faster, isn't that enough? But point taken... we are listening to the feedback for sure.

What I think would make sense would be to sell the x64 version as a $5 (or maybe half-price) addition for owners of the x86 version of CoreAVC Pro (or vise versa), bundle x86 and x64 together for something like $20, and offer them separately for $15 each if someone just wanted one or the other.

[BetaBoy]

Well.. the long term plan with CoreAVC 64 is to feature 4:4:4 support as well (to match the Enterprise version)... so the price point is a moving target. Thanks all for the feedback... keep it coming ;-)

[cyberbeing]

Moving target is fine. The idea is just to bundle them together at a price point to encourage people to buy both when they might not need both versions currently but they buy both just in case there is a future need because it's value priced and saves them money (i.e. you can buy both together for $20 but if you decide to buy both later it will cost you $30). You would then want to add a limited time period where existing customers before the x64 version was introduced could buy it for the reduced bundle price.

By doing this you will likely increase revenue with more sales of the x64 version while keeping people happy with a reasonable price point. If you price them at full price and only sell them separately then people would probably only buy one or the other and it kind of screws existing customers who may have only wanted the x64 version if it had existed at the start.

[BetaBoy]

From the DivX thread....


If I had to give a single big reason CoreAVC is fast, its because of the SSE2 deblocking, which exists in x264 but hasn't been ported to ffmpeg.
We contain no SSE2 deblocking..... that's for CoreAVC 2.0 (IE; we have a lot of room for CPU specific improvements).

[Dark Shikari]

From the DivX thread....

We contain no SSE2 deblocking..... that's for CoreAVC 2.0 (IE; we have a lot of room for CPU specific improvements).Color me surprised--I thought CoreAVC already had that.

In that case, I'll rephrase it:

"If I had to give a single big reason CoreAVC is faster than ffmpeg, its because of ffmpeg's lack of SSE2 deblocking, which exists in x264 but hasn't been ported to ffmpeg."

:p

[BetaBoy]

np ;-)

[Maksee]

I have a question regarding decoding on different Celeron and Pentium processors. This comes from the fact that I want real-time decoding of 720p30 files made by Sanyo Xacti HD700. I downloaded some videos made by an owner of the camera and all my computers didn't manage to keep up using CoreAVC codec. But I also notice that while cache, chip frequency and bus frequency affect the results, one example shows that even generation change do maybe even more that other parameters.
This example included two computers:
- Celeron 1.7 GHz(F.1.3.5) L2:128k, 400 MHz bus could decode 15 frames per second
- underclocked Celeron 630 MHz (6.D.8.20) appeared in Asus EEE Pc with 512k cache, 400 Mhz bus can manage to do just the same 15 frames. Moreover, "rightclocked" to factory 900 MHz Eee pc performed better that the big computer and almost could manage 720p25, but failed to do 720p30.
So I'm interested particulary what processor on (maximum) 533 Mhz bus and 478 socket can manage to do 720p30 or what should I look at when choosing between parameters of different used processors (as I see only 3 GHz 800 bus options is available at the moment as new for 478 socket)

Thanks!

[foxyshadis]

Get a P4 2.8 or 3.06, which both come in 533MHz for 478. Scour ebay or craigslist if you want it on the cheap. A bonus with that 3.06 is that it comes with Hyperthreading, giving you a little extra boost with coreavc. The most powerful Celeron D that fits is a 3.2.

The Eee PC's Celeron M is much more powerful, as you've found, and you can actually upgrade it to a Pentium M up to 2.1 GHz. The speed would actually still be faster than the fastest 478 Pentiums in that case, though power use and heat would increase. (You can also get less powerful and less power-hungry ones.) Laptop chip replacement is much more difficult, but tutorials for it exist online.

[Shinigami-Sama]

Get a P4 2.8 or 3.06, which both come in 533MHz for 478. Scour ebay or craigslist if you want it on the cheap. A bonus with that 3.06 is that it comes with Hyperthreading, giving you a little extra boost with coreavc. The most powerful Celeron D that fits is a 3.2.


you can OC the northwoods up to 3.4ghz easy on pc2700ram
and 3.6 on pc3200 ram
I have to do that time to time on some more complex encodes
should be able to find them pretty easy

[JohnnyFu]

Hey there BetaBoy,

It has been quiet around here lately, any news on the x64 version ?
You wanted to get me a copy, remember ? :)

Another thing, I actually don't want to ask about this at all... but, in view of what my new HD3850 card's Vista-UVD-technic does on h.264 decoding. Is there a plan for hardware decoding in version 2.0 or so ? :D

greetz
Jofu

[Jay Bee]

Any news on DVBViewer microstutter problems? Only happens on 1080i, not 720p. Cyberlink doesn't stutter in DVBViewer and using CoreAVC to play the same streams outside of DVBViewer also doesn't stutter.

[CiNcH]

Any news on DVBViewer microstutter problems? Only happens on 1080i, not 720p.

What does the video renderer say? Check within DVBViewer under 'View' -> 'Filers'. Try the VMR renderer as I do not trust the EVR skipped frames/jitter values.
For me it seems that the deinterlacer introduces quite some jitter. But here it also happens with file (captured from 1080i DVB source) playback and a Haali -> CoreAVC graph (built with GraphStudio/GraphEdit). Think that the combination of the DVBSource filter and CoreAVC works quite well by now.

I am using CyberLink with DXVA bitstream acceleration and currently can't test that further as I ran out of the CoreAVC trial period for the current Windows installation on the test PC.

[BetaBoy]

Hey there BetaBoy,

It has been quiet around here lately, any news on the x64 version ?
You wanted to get me a copy, remember ? :)

Another thing, I actually don't want to ask about this at all... but, in view of what my new HD3850 card's Vista-UVD-technic does on h.264 decoding. Is there a plan for hardware decoding in version 2.0 or so ? :D

greetz
Jofu

We are finishing up a few things for the CoreAVC 1.8 Editions including the CoreAVC 64 launch (QA, helpfiles, website, etc.). There has been a fair amount of decoder property changes we are testing to add flexibility that people have been asking for (its also things we wanted to do before CoreAVC 2.0).

JohnnyFu.... Hardware support is coming but not in the way you may think. I will elaborate on this in a future post.

[Ranguvar]

Can't wait for 64-bit support :D

In encoding, 64-bit support seems to provide quite a significant gain. But, not in general apps.

Do you think decoding will offer similar gains, or no?

[Gleb Egorych]

Hi all.
I found that CoreAVC 1.7 was incompatible with "remember file position" features in Zoom Player and MPC-HC. If I play file from remebered position that coreavc produces visual artifacts which could be fixed by 1) closing the player and 2) clearing file position history. CoreAVC 1.6.5 does not have the problem at all.

Attached screenshot was made in Zoom Player. Picture is doubled and colors are broken.

Has anybody noticed the same problem?

[BetaBoy]

Gleb... other then splitting, "remember file position" should have nothing to do with CoreAVC. Ping the ZP Crew to see what's going on there.... But I'll have a chance to test tomorrow to see if I can duplicate it in ZP.

[Gleb Egorych]

BetaBoy, it's not ZP only bug, MPC-HC doesn't work too. And only with 1.7.0.0. So I consider it's rather CoreAVC bug.

[BetaBoy]

Gleb.... first report here in this thread on it as far as I know. I just tried ZP with both 1.6.5 and 1.7.0 and don't get the results you do... You do have the latest Haali splitter, right?.... but we'll take a look into it more.

[rickardk]

... Hardware support is coming but not in the way you may think. I will elaborate on this in a future post.

I guess (and hope) that you are going to use CUDA, so there will be no need to connect directly to the renderer as with DVXA2...?

[BetaBoy]

I have already addressed our concerns for the myopic focus of DXVA and that a greater global effort from GPU companies has to made. We love CUDA from NVIDIA its great although not a universal solution but a step towards a more open approach.

[soresu]

Betaboy, do you intend to use openCL standard for gpu acceleration then? this also seems to fit in with parallel threading on the cpu from what khronos is saying...

[CiNcH]

I don't believe that there is a market in DXVA anyway. There is nothing special anymore about it. All decoders perform equally and have the same limitations. MPC Video Decoder gets better and better, only lacking proper interlaced support (another con currently is that it expects a whole H.264 frame within one DirectShow sample, only working with Haali and MPC splitter, which have to parse the bitstream already).

DirectX 11/OpenCL/CUDA could really have an impact by enabling hardware assisted decoding with Haali Renderer for example, enabling the possibility to even use it for transcoding with CoreAVC acting as the H.264 decoder or using ffdshow as a PostProcessor...

[Gleb Egorych]

BetaBoy, I'm using Haali Media Splitter ver. 1.8.122.18. Made some explorations, here are results.

System: WinXP SP3, 8800GT + Forceware 177.83.

In MPC-HC only VMR9 renderers are effected, VMR7, EVR, overlay and Haali are OK. In MPC-HC the problem appears on ALL videos I have, for example da_vinci_code-tsr2_h720p.mov. If I enter CoreAVC settings window, change any setting, change it to the initial value and press OK then video becomes normal without artifacts.

In ZP the problem appears on VMR7, VMR9, overlay and EVR renderers. Haali is unaffected. But in ZP SOME H.264 files play CORRECTLY. I can't find the reason. If I change any CoreAVC setting during playing, zplayer.exe just crashes. ZP has the problem with da_vinci_code-tsr2_h720p.mov too.

Also tried on another computer, WinXP SP3, Radeon 9500 pro + Catalyst 7.10 (pretty old, I know :)). On that system everything plays great, without any artifacts. So, I have the bug only on my nvidia system and only when using CoreAVC 1.7.0. With CoreAVC 1.6.5 both systems play correctly.

[the_corona]

Now I'm nervous :-(

I'm about to build a new HTPC and of course if any form of hardware acceleration is coming I'd like to take advantage of it.

I'm leaning towards ATI, but CUDA won't work with it, will it? If it's not using DXVA, it will have to favour NVIDIA or ATI, wrong?

Should I buy ATI or NVIDIA (all other things set aside)? Will it most likey work with either recent generation's card?

Too early...if its not coming for 2 years I'm not too worried as its ok if I have to buy a new one by that time.

[TheShadowRunner]

I have the same issue as Gleb.
And, very possibly related, if I use Core 1.7 with Reclock, i'm getting a screen full of artefacts after resolution change. Exactly the same setup with 1.6.5 doesn't exhibit the problem.
When that occurs, with 1.7, just opening the setting page and faking a change in there then hitting apply corrects the issue...
Edit, i'm also using ZP & VMR9.

[Ranguvar]

@the_corona: I'd just get a reasonably fast dual or quad core and forget about it. Those should handle 1080p H.264 content fine. If the next generation of codecs won't run properly on your HTPC, then get a fast videocard then, since DXVA will be more mature.

[BetaBoy]

In preparation for the CoreAVC 1.8 release, I have updated the first post to match the current filter properties.

CoreCodec / CoreAVC H.264 Decoder Configuration Properties Guide

Input Formats
This setting controls which DirectShow Media Types the decoder accepts on input. Uncheck only if you are troubleshooting problems with CoreAVC incorrectly decoding some variant of H.264, or want to use another decoder for it.
- avc1 / AVC1 - Accept streams with avc1 / AVC1 FourCCs.
- h264 / H264 - Accept streams with h264 / H264 FourCCs.
- x264 / X264 - Accept streams with x264 / X264 FourCCs.
- VSSH - Accept streams with VSSH FourCC.
- Mainconcept H.264 - Accept H.264 streams from the Mainconcept splitter.
- ArcSoft H.264 - Accept H.264 streams from the ArcSoft splitter.

Output Formats
This setting determines the preferred output color space. The decoder tries each enabled format in order from top to bottom until it is accepted by the Video Renderer filter.
- YV12 - YUV 4:2:0 planar format.
- I420 - YUV 4:2:0 planar format with chroma planes in reverse order.
- YUY2 - YUV 4:2:2 packed format.
- UYVY - YUV 4:2:2 packed format with different sample ordering.
- RGB24 - 8 bits per channel RGB format.
- RGB32 - 8 bits per channel RGB format with an extra padding byte.
- RGB16 - RGB format with 6 bits per green sample and 5 bits each for red and blue samples.
- RGB15 - 5 bits per channel RGB format.

- Up Arrow - Increases the priority of the selected format by moving it towards to the top.
- Down Arrow - Decreases the priority of the selected format by moving it towards the bottom.

Input Levels
- TV (16-235) - always assume the stream uses TV levels
- PC (0-255) - always assume the stream uses PC levels
- Auto detect - use the full range flag in the stream to determine Luminance range
- Output levels, this also affects conversion to RGB color space when it is done by the decoder.

Output levels
- TV (16-235) - assume the Video Renderer expects TV levels
- PC (0-255) - assume the Video Renderer expects PC levels
- Auto detect - use PC levels when VMR is used as a Video Renderer, and TV levels for all others.

Deinterlacing
This setting specifies how interlaced material is handled by the decoder.
- None (Weave) - Each output frame contains two fields, flagged as progressive.
- Single Field - Each output frame contains one field. Only one frame is produced for each field pair.
- Bob - Each output frame contains one field. Two frames are produced for each field pair.
- Hardware - Each output frame contains two fields, flagged as interlaced to allow the video renderer to perform deinterlacing.

Deblocking
This setting controls how the deblocking step of H.264 specification is executed by the decoder. Deblocking is a complex process that consumes significant processing resources. If your machine is not fast enough, you might want to turn off deblocking for some frames, but it will degrade visual quality.
- Standard deblocking - do deblocking exactly as specified by H.264
- Skip when safe - skip deblocking step when decoding B-frames.
- Skip always - does not perform any deblocking.

Aggressive deinterlacing
This option determines how the decoder detects interlacing in source stream.
- Off - use only picture timing SEI and POC numbers to detect interlaced video. Unfortunately not all encoders properly flag material as interlaced.
- On - in addition to SEI and POC, assumes source is interlaced if any interlaced coding tools are used in encoding the frame (MBAFF, PAFF).

Crop 1088 to 1080
H.264 encoded video size is always a multiple of 16, and sequences that are 1080 pixels high are encoded as 1088 padded at the bottom. Also H.264 specifications provides a set of cropping parameters to signal that parts of the encoded picture are not important and should not be displayed. Some H.264 encoders fail to specify cropping parameters when encoding 1080 video.
- Off - do not crop video
- On - when input video is exactly 1088 pixels high, crop 8 pixels off the bottom

Force VMR AR correction
This option can be used if you are working with the decoder outside the normal player environment.
- Off - does not change VMR settings.
- On - instructs VMR filter to maintain aspect ratio of the video that it displays. Normally this AR correction is the responsibility of a video player. This option should normally be off.

Preferred Decoder
Overrides any system AVC directshow decoders and uses CoreAVC.
- Off - does not change system merit.
- On - enables the highest merit on the PC. This option should be se to ‘On’.

Picture Levels
Picture level slider adjustments can be made in ‘real time’ so you see the effects of the changes as you make them. Once the adjustments are made, ensure that you press ‘Apply’ to save changes or they will be lost.
- Brightness - Adjusts the overall brightness level.
- Contrast - Adjusts the difference between light and dark areas.
- Saturation - Adjusts the vibrancy of colours.
- Restore Defaults - Reset all picture level adjustments. It is not necessary to click Apply after this option.



Barring any major bugs in the AM we expect 1.8 to be released at some point later today.

[Dark Shikari]

- Skip when safe - skip deblocking step when decoding B-frames.Do you mean NAL units designated as disposable (unreferenced B-frames), or do you really mean all B-frames? If the latter, its certainly not safe.

[Selur]

btw. a little filter like deband (gradfun2db) would be nice,...

[qyqgpower]

About the auto detection of output levels.
Since Nvidia & AMD both have adjusted their drivers to display full range in certain resolution(mainly 720p&1080p) while using VMR, so I think CoreAVC should also adapt this change. Otherwise, we would get over-ranged output in this certain condition.

[CruNcher]

Yep CoreAVC needs also to detect when this was set from the Drivers Control Panel (manualy) i guess checking the changed registry entry would be enough to get it right (input is xxx -> Driver State is xxx -> Output should be xxx unless overriden by user) :)

[bob0r]

For both: What driver versions are we talking about here?

[qyqgpower]

for Nvidia, I noticed this change since 175series, and Nvidia have added a option in video section to change the output scale since 177series(may not appear for older cards).
for AMD, I have just bought a 4850 so I don't know exactly which version made the change, but apparently catalyst 8.8 would scale 16~235 to 0~255 correctly(BT709 matrix) at 720p&1080p while using VMR9 Renderless.

[BetaBoy]

mmm... I'm gonna ping the guys on the output level and filter. But we also found out that:
- there's a field order bug with hardware deinterlacing that only affects either VMR7 or VMR9 (TBD), that has the field order flipped when seeking, resulting in juddering motion.

With the above aside... I would prefer us not to delay 1.8 any further as this could potentially interfere with our 2.0 plans.

I'll fill everyone in as we go along.

[Gleb Egorych]

About color range: I'm using the latest official beta Forceware 177.92 @ 8800GT. In "Nvidia CP" range is set to "Full (0-255)". CoreAVC input and output level are set to auto. And on my monitor (DVI connection) colors are correct.

[cyberbeing]

About color range: I'm using the latest official beta Forceware 177.92 @ 8800GT. In "Nvidia CP" range is set to "Full (0-255)". CoreAVC input and output level are set to auto. And on my monitor (DVI connection) colors are correct.

This is also the case on my computer with 177.89 and "Full (0-255)" set with my monitor connected via DVI-A.

Input/Auto + Output/Auto = Correct Full Levels
Input/Auto + Output/TV = Correct Full Levels
Input/PC + Output/PC = Correct Full Levels
Input/TV + Output/TV = Correct Full Levels
Input/TV + Output/Auto = Correct Full Levels

Input/TV + Output/PC = Incorrect Overextended Levels
Input/Auto + Output/PC = Incorrect Overextended Levels

[bob0r]

This seems correct; most H.264 sources are TV level (satellite, bluray, hddvd, avchd).

On my system, with old(er) nvidia drivers, black is grey when i set output to TV.

If nvidia indeed fixed it, your list is correct and input TV (and auto which is then the same) + output PC = Overextended Levels

Even Haali renderer can set the levels for you, so what you simply do, is start with the brightest video you can get, and if black is black, your levels are correct, you can use the brightness slider if it's too bright for you :)


A side note: All encodes should be same level as the source, let the decoder, renderer or player change levels (c) pengvado.
(so if some x264 encode has another level than the source, something went wrong)


My idea is: If anyone can find any H.264 video file, which can't be set to use the correct levels report it here, but if CoreAVC always can find a proper solution, then we should leave it as is.


Edit:
I just installed Nvidia 177.92 and INDEED FULL range on VMR9 is working, its a miracle!

However for PowerDVD 7 and 8:
http://x264.nl/powerdvd.7.3.3319a.nvidia.177.92.beta.fail.jpg

DOH!

[Mangix]

try 177.83

[shon3i]

Or install lastest PowerDVD 8 build 2018