|
|
| Line 40: |
Line 40: |
| **Opens the [[System Settings#Audio Hardware|Audio Configuration Menu]] | | **Opens the [[System Settings#Audio Hardware|Audio Configuration Menu]] |
| *'''Render Method''' | | *'''Render Method''' |
| **Controls the method used by the player to process and display the video, (which is called [[rendering]]). The three options are: | | **Controls the method used by the player to process and display the video, (which is called [[rendering]]). [[rendering|See Here for more information on the different options.]] |
| ***'''High Quality Pixel Shader''' - This is the default render which also provides highest quality of the output methods. It uses 44bits/pixel of memory, plus a further 512kB of memory for lookup textures. It does the YV12->RGB conversion in 2 passes, using a lookup texture to maintain 100% accuracy, (making screenshot and alpha-blending work perfectly using the High Quality Pixel Shader). This uses bilinear filtering to double the chroma data both horizontally and vertically. The first pass runs on the source resolution using 3 tex ops and 2 arithmetic ops, the second pass runs on the output resolution and uses 4 tex ops and 3 arithmetic ops. 3 of the tex ops are dependent texture reads, which are likely slower than plain tex ops. It has no losses at all. The error is for all intents and purposes identical to what would be expected of an implementation using 64bit floating point, rounded to 8bit output (which RGB is). It is the slowest of the renderers, but for most material this will have no effect whatsoever, the speed of the renderer only effects videos with very high resolution (which the Xbox struggles to decode anyway) such as native 720p material. Anyway, memory is also a problem when you are dealing with very high native resolution videos (such as 720p), so the low quality pixel shader is then often the only option.
| |
| ***'''Low Quality Pixel Shader''' - This is the most memory efficient output method, using only 12bits/pixel. It uses a fast pixel shader to do the YV12->RGB conversion which while reasonably accurate, is not 100% accurate. It may suffer from slight colour-banding in softly graduated scenes, (this is due to the internal precision of the pixel shader's temporary registers). It is almost as fast as the Hardware Overlays method, and should be used whenever memory is a priority, (such as playback of very high resolution video, like 720p). Screenshot + alpha blending work perfectly with the Low Quality Pixel Shader.
| |
| ***'''Hardware Overlays''' - This uses a dedicated path on the GPU for optimal performance speed-wise. It is the fastest of the renderers, and generally provides very good quality (equivalent to the High Quality Pixel Shader) but it does have some problems/limitations. It is the most memory hungry renderer (56 bits/pixel), and may get some extreme colours quite incorrect, due to the fact that it doesn't clamp the YV12->RGB conversion. These show up as extremely strong green/cyan colours appearing as red/magenta. This does NOT tend to happen with good source material, it usually only shows up with material captured + digitized using sub-standard equipment. With Hardware Overlays you also lose support for alpha-blending, so the video on screen display may appear to have black blobs around it rather than nice drop-shadows. Lastly, you also lose support for accurate screenshots – the screenshots are only approximations of what occurs on screen, and will not exhibit any of previously described problems.
| |
| *'''Resolution''' | | *'''Resolution''' |
| **Controls the resolution at which video is displayed. It causes XBMC to upsample / downsample the video to the selected format. | | **Controls the resolution at which video is displayed. It causes XBMC to upsample / downsample the video to the selected format. |
