Official Sandy Bridge / LGA1155 for HTPCs Thread - Page 65

A good DI comparison is really missing. Most video quality tests so far relied on HQV scores which are very biased by rare film cadences (who cares about these anyway) and a lot of synthetic material which doesn't reflect well on real world performance. The cheese slice test for instance would only work well on a high end motion compensated DI.
The only real world screen shot was a blurry sail boat image and in it, the AMD outcome had broken sail lines/ropes and detail was lost completely.
As a journalist, you can ask AMD, Nvidia and Intel for real world testing material, or even better contact tier-1 TV makers like Panasonic, Sony, Samsung, etc for their testing material - they have excellent video quality assessment clips.
Unfortunately video is subjectively measured (in most cases) but you can consult an industry expert for this.
Image quality items should be (random importance order - subjective):
- Pleasing colors without over saturation. Image can be colorful without losing color detail.
- Contrast is high without producing a flat or milky image (under contrast) or lose detail in highs and lows (over contrast).
- Skin tones are accurate and pleasing to the eyes. Need to check on multiple skin colors. Pleasing skin tones are culture dependent so this is very subjective.
- Scaling 480p --> 1080p should keep the image as sharp as possible with minimum artifacts.
- Scaling 1080p --> 720p - image should be sharp without aliasing.
- Image should be stable during static and dynamic scenes - no flickering and close to zero noise.
- Digital noise algorithms exist and work well (deblocking, deranging, etc).
- Analog noise is handled well with little or no detail loss. Check several noise levels on static and dynamic scenes.
- Sharpness algorithm produces a natural looking image - not posterized. Should not oversharpen on max settings.
- Deinterlacer:
--- Detects motion properly. Preferably has MC.
---Moving diagonals are reconstructed well. The flatter, the better.
--- DI must output full frame rate (e.g. 50/59.94Hz)
--- Film detection should work well on 3:2 and 2:2. The rest of the cadences are rare and not very interesting to most of the world.
- Frame rate conversion - test if it exists and look for artifacts.
- Image stabilization - stabilize a shaky video (e.g. hand held video cam)

I'm not sure we need samples from anyone; our world is full of excellent content for testing DI (and other VPP) performance. I am suspicious of samples provided by anyone with skin in the game (IDT).

If you're looking for some real world e.g. I included some here.


For all of this I think the important part is that the user can decide how much, if any, extra mangling they want. Personally, I don't understand image "improvements" like skin tone correction and dynamic color especially for high quality video sources (like BD); more often than not the GPU is messing with things it doesn't understand and altering the content in an undesirable way (e.g. watch Black Swan w/ default settings on an AMD GPU).

Most of the interlaced content that I watch is 1080i ATSC broadcasts. And for this content, Intel does noticeably better than AMD/ATI. It is obvious when I'm watching shows that have news ticker scrolling at the bottom of the screen. Intel always stays locked on, but AMD/ATI loses its lock from time to time causing the text to be deinterlaced into the wrong frames.

I don't care too much about the obscure interlaced cadences that isn't used by any of the media I watch. If it can do it, great, but if it can't, I'm not missing anything.

My favorite test bed for SD DI is the beginning of the "It's A Charlie Brown Christmas" DVD . Seriously, give it a try.

In Sandy Bridge GPU is there HW frame rate conversion? And if yes is it also for HD video or just for SD? What about Ivy Bridge GPU?
It would be great if on a laptop you can convert on the fly 23,976 -> 60 fps.

And about 23,976 that no GPU vendor locks exactly to it. Is it possible this to be because there is no GPU preemtion. In Windows 8 there is new WDDM 1.2 and DirectX 11.1 there will be GPU preemtion. But is it only software or there are hardware requirements for saving context states? And is there someting that deserves to be expected about video prosessing. If there is some body to help me understand?

The MSDK supports frame rate conversion, but I doubt that it's done in hardware. Unless a device is interpolating it just needs to drop or repeat frames.

If there would have been full HW acceleration it would have been advertised. There are many accelerators that can be used (e.g. motion detection from the decoder) so a sw/shader/HW solution is possible to some degree. Frame rate conversion is a very hard problem and the artifacts from a misprediction are too much for my taste. Regarding accurate 23.97, this is really a mystery why it doesn't work well (or at all) on all GPUs. Maybe it requires a large expensive PLL to synthesize the pixel clock this accurately... I really don't know.

Video processing is expected to make the video look better using various algorithms. Usually divided into 2 groups:
* Reconstruction - fix the image so it looks as close to the real world as possible. Make it accurate. This includes deinterlacing, scaling, noise reduction, some sharpness, gain or contrast corrections, frame rate conversion, color space conversion, super resolution, etc.
* Enhancement - make it better looking than the original. Accuracy is not a factor, just subjective opinions. This includes skin tone correction, skin smoothing, vivid colors enhancement, local contrast, strong sharpness, etc.

And now 0131 (like 0128) has been pulled with BIOS 0125 listed as the latest. I did grab it while it was available. My system didn't like the windows based updater, so I had to use the recovery method to update from 0128 to 0131. So far, things still seem to be working fine for me.

There have been some reports of 0131 bricking DH67CF motherboards (I put it on a DH67BL just fine). I think that's why it was pulled.

I suspect this is closest. In my experience, in the typical chip you find PLLs attached to a series of clock dividers of various sorts, and these dividers are usually small round numbers (2, 3, 5, 8, etc.) or "near round" numbers (2.5, 7.5) from which you can take a base clock of, say, 25 MHz and accurately derive every other clock the chip needs.

Since 23.976 (or 59.994 for that matter) are effectively reached by dividing a round number clock by 1001, you essentially have to dedicate circuitry to that clock fraction which will be used for nothing else in the chip. Since virtually no-one in customer-space was looking at this until the advent of Blu-ray (because 23.976 fps consumer content did not, for all intents and purposes, exist before then), and since the difference at 59.994 vs 60.000 Hz is visually imperceptible, I would wager no one was looking into the issue until it became obvious.

Thanks for the answers!

Doh! I guess I should clarify that it installed fine on my DH67BL.

Not sure if people noticed, but exactly the same thing happened with 0032 on the -61 boards. They posted it (most recent before that was 0028), it stayed a few days, then it got pulled with 0028 now being the latest.

I have a friend that bricked his DL board with 0032.

They really need to improve their process - it aint going all that well for them lately :-)

New and improved version. Zip files contains installer and documentation, please read.

Download version 0.15 alpha:
32 bit http://www.multiupload.com/SW88AXIEAR
64 bit http://www.multiupload.com/3QH5R6N6CD
Source code http://www.multiupload.com/GQBEQ161DB

Revision highlights:
v1.15:
* Rewrote time stamp handling code. Decoder now calculates frame rate if missing, corrects for splitters reporting double frame rate for interlaced content. Handles PTS and DTS time stamps. Broken streams that alternate frequently between telecined and interlaced frames are not handles perfectly (yet!).
* Handled unsupported H264 formats by reverting to libavcodec silently within ffdshow. HW acceleration is limited to H264 simple, main and high profiles. Previous version would crash on unsupported formats.
* Added support for WMV3 (part of the VC1 HW decoder).
* Various bug fixes and better decoder error handling. As reported by various users for the 0.14 release.
* Cleaned up minor memory leaks.

Hi all

Is there a usage meter for the HD2000/HD3000 GPUs in the SnB chips? I'm trying out some codecs, and that would be a good objective number - well, it'd be reassuring at least - for seeing the CPU offload. And I'm very happy indeed to see a 64bit codec at last.

I found that HWInfo shows temps separately for the IA and GT cores, which is a good start.

GPU-Z shows GPU (basically EUs) usage. You can't see CPU offload by GPU-Z because decode/post-processing is mainly done by fixed functions (decode by MFX, deinterlacing by Media Sampler etc.).

thanks renethx

The million dollar question is now that they are looking into it, will they fix it?

From bit-tech.net's write up on IVB.

So they acknowledge the issue but the justification is that "you'd have to look real hard to catch it", lol

Yeah, we'll have to see where it ends up. Hopefully that just means they can do 23.976X instead of 23.9760000

Hey Guys,

I have a quick Audio question.

I have a Gigabyte GA-Z68A-D3H-B3 / Intel i5-2500K HTPC setup. I just bought a Yamaha RX-A2000 receiver that I'm in the process of setting up.

If I understand correctly, when I connect my HDMI cable from the HTPC --> Receiver, I should be able to get surround sound audio, blu-ray audio, 7.1, DTS-HD, TruHD etc through the receiver, correct?

Now - The receiver also has an Optical (SPDIF TOSLink) output. I have Sony wireless surround sound headphones that have an Optical input. I'd like to connect the wireless headphones to the receiver's Optical out. For this, as I'm told (in the RX-A2000 Receiver's Forum), I need to pass audio via Optical to the receiver! In other words - the HDMI connection will not pass on the surround sound audio to the Optical Output port on the Receiver - I need to run the Optical wire separately from the Source (HTPC) to the Receiver in order to provide audio to the Wireless Headphones.

The problem is, in Windows, you can either define HDMI as your default device or the Realtek Optical as your default device; so audio can only be passed out through one or the other.

Is there anyway to pass audio through both? Most regular devices, like XBOX 360 or Blu-ray Players, even HD Cable Boxes, will pass audio through both HDMI & Optical Ports simultaneously. How can I make my HTPC do the same?

Thanks!!

Windows 7 doesn't include this feature. It is possible for an application to implement the feature, it could be addressed with a custom audio renderer or at the hardware level but I'm not aware of anything that does it.

I use MediaPortal as the GUI for the HTPC; I did come across an "Audio Renderer Changer" plugin - I think that might be it.

Thanks - Did want to see if there was something simpler I was missing.

Yeah, I didn't love that answer. Fortunately, the bit-tech article posted the presenters' names... which means I can email them directly through corporate mail. Not that it will necessarily help.

Man, I was really hoping Intel would get it perfect with ivy bridge.

Any improvement is great, ReClock can fix the remaining issues, as its done with every other GPU. No-one hits 23.976023976 perfectly (24/1.001)
At least they did confirm that there is improvement, not like SandyBridge which was still stuck with the same PCH bug as the previous generation.

The GPU's display pipeline doesn't generate a clock for the vsync frequency (e.g. 23.976Hz) it generates a pixel clock. Both hsync and vsync are derived from it but this is very simple - just need a counter - count X ticks to create an hsync and another counter to count the hsync in order to create a vsync.
The display performs the opposite if it wasn't given a clock (e.g. VGA connection). So you need an accurate PLL to generate a pixel clock from the bclk (100MHz). Theoretically the HW should be able to do this as it supports both lower and higher pixel clocks.

BTW, the math for 23.976 frame rate is 29.97 * 4 / 5 = 23.976 (exactly).
29.97 is the frame rate (half field rate) of the NTSC standard. Since film content is shot at 24Hz, a 3:2 field cadence is produced as well as slightly slowing (by ~1000/1001) the video so it fits the 29.97 frame rate. The audio is slowed as well to keep in sync.
PAL systems has an opposite correction where the 24Hz film is sped up to 25Hz. That's why PAL version of DVDs are a few minutes shorter...

How ever you do the math to get to 23.976, you end up at more precision then 23.976 (and its not 23.9760000). NTSC is 30/1.001 (or 30000/1001), which translates to 29.9700299700. The result of your formula is exactly the same as 24/1.001.

Anyhow, if you manage to hit 29.9700 or 23.9760 exactly, the remaining error is so small that its negligible.