[Linux] Judder-free 24p playback
#1
This little howto will demonstrate how to solve problems with judder when the automated script from this great guide doesn't work. I've been able to solve many judder problems with this procedure, so you I thought I'd share it with you.

First, make a backup of your current xorg.conf and replace it with this bare xorg.conf:

http://pastebin.com/tUrd26eX

It puts X in debug mode so we can see what's going on. Then start X(BMC), look if it starts properly and then close the X session.

Now let's have a look at the log of this last session, located in /var/log/Xorg.0.log. Search for "Building ModePool for" and scroll down from there until you see something like this for 1920 x 1080 @ 24 Hz:

Code:
[293848.093] (II) NVIDIA(0):   Validating Mode "1920x1080":
[293848.093] (II) NVIDIA(0):     1920 x 1080 @ 24 Hz
[293848.093] (II) NVIDIA(0):     For use as DFP backend.
[293848.093] (II) NVIDIA(0):     Mode Source: EDID
[293848.093] (II) NVIDIA(0):       Pixel Clock      : 74.16 MHz
[293848.093] (II) NVIDIA(0):       HRes, HSyncStart : 1920, 2558
[293848.093] (II) NVIDIA(0):       HSyncEnd, HTotal : 2602, 2750
[293848.093] (II) NVIDIA(0):       VRes, VSyncStart : 1080, 1084
[293848.093] (II) NVIDIA(0):       VSyncEnd, VTotal : 1089, 1125
[293848.093] (II) NVIDIA(0):       H/V Polarity     : +/+
[293848.093] (WW) NVIDIA(0): The EDID for ONK TX-NR509 (DFP-2) contradicts itself: mode
[293848.093] (WW) NVIDIA(0):     "1920x1080" is specified in the EDID; however, the EDID's
[293848.093] (WW) NVIDIA(0):     valid VertRefresh range (48.000-62.000 Hz) would exclude
[293848.093] (WW) NVIDIA(0):     this mode's VertRefresh (24.0 Hz); ignoring VertRefresh
[293848.093] (WW) NVIDIA(0):     check for mode "1920x1080".
[293848.093] (II) NVIDIA(0):     Mode is valid.

There may be more than one; it may also look like this:

Code:
[293848.102] (II) NVIDIA(0):   Validating Mode "1920x1080":
[293848.102] (II) NVIDIA(0):     1920 x 1080 @ 24 Hz
[293848.102] (II) NVIDIA(0):     Mode Source: EDID
[293848.102] (II) NVIDIA(0):       Pixel Clock      : 74.16 MHz
[293848.102] (II) NVIDIA(0):       HRes, HSyncStart : 1920, 2558
[293848.102] (II) NVIDIA(0):       HSyncEnd, HTotal : 2602, 2750
[293848.102] (II) NVIDIA(0):       VRes, VSyncStart : 1080, 1084
[293848.102] (II) NVIDIA(0):       VSyncEnd, VTotal : 1089, 1125
[293848.102] (II) NVIDIA(0):       H/V Polarity     : +/+
[293848.102] (WW) NVIDIA(0): The EDID for ONK TX-NR509 (DFP-2) contradicts itself: mode
[293848.102] (WW) NVIDIA(0):     "1920x1080" is specified in the EDID; however, the EDID's
[293848.102] (WW) NVIDIA(0):     valid VertRefresh range (48.000-62.000 Hz) would exclude
[293848.102] (WW) NVIDIA(0):     this mode's VertRefresh (24.0 Hz); ignoring VertRefresh
[293848.102] (WW) NVIDIA(0):     check for mode "1920x1080".
[293848.102] (II) NVIDIA(GPU-0):     BestFit Scaled and BestFit AspectScaled are identical;
[293848.102] (II) NVIDIA(GPU-0):         collapsing BestFit AspectScaled.
[293848.102] (II) NVIDIA(GPU-0):     BestFit Centered and BestFit Scaled are identical;
[293848.102] (II) NVIDIA(GPU-0):         collapsing BestFit Scaled.
[293848.102] (II) NVIDIA(GPU-0):     Native Scaled and Native AspectScaled are identical;
[293848.102] (II) NVIDIA(GPU-0):         collapsing Native AspectScaled.
[293848.102] (II) NVIDIA(GPU-0):     Native Centered and Native Scaled are identical;
[293848.102] (II) NVIDIA(GPU-0):         collapsing Native Scaled.
[293848.102] (II) NVIDIA(GPU-0):     BestFit Centered         1920x1080
[293848.102] (II) NVIDIA(GPU-0):       Horizontal Taps        0
[293848.102] (II) NVIDIA(GPU-0):       Vertical Taps          0
[293848.102] (II) NVIDIA(GPU-0):       Base SuperSample       x4
[293848.102] (II) NVIDIA(GPU-0):       Base Depth             32
[293848.102] (II) NVIDIA(GPU-0):       Distributed Rendering  1
[293848.102] (II) NVIDIA(GPU-0):       Overlay Depth          32
[293848.102] (II) NVIDIA(GPU-0):     Native Centered          1920x1080
[293848.102] (II) NVIDIA(GPU-0):       Horizontal Taps        0
[293848.102] (II) NVIDIA(GPU-0):       Vertical Taps          0
[293848.102] (II) NVIDIA(GPU-0):       Base SuperSample       x4
[293848.102] (II) NVIDIA(GPU-0):       Base Depth             32
[293848.102] (II) NVIDIA(GPU-0):       Distributed Rendering  1
[293848.102] (II) NVIDIA(GPU-0):       Overlay Depth          32
[293848.102] (II) NVIDIA(0):     Mode is valid.

First calculate if this mode is correct by using the following formula:

PixelClock / HTotal / VTotal * 1.000.000

This number has to be close to 24000/1001, i.e. ~23,976.

The warning about the VertRefresh is probably harmless, but let's get rid of it anyway. Add the line
Code:
Option "ModeValidation" "NoVesaModes, NoXServerModes, NoVertRefreshCheck"
to the Device section. This disables the VertRefresh checks and gets rid of all the modes we don't need anyway.

Then start and close X again and look at the log. Look for "Modes in ModePool for". It should look similar to this (the modes for 1920 x 1080 anyway):

Code:
[295635.531] (II) NVIDIA(0): --- Modes in ModePool for ONK TX-NR509 (DFP-2) ---
[295635.531] (II) NVIDIA(0): "nvidia-auto-select" : 1920 x 1080 @  60.0 Hz  (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080"          : 1920 x 1080 @  60.0 Hz  (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_60"       : 1920 x 1080 @  60.0 Hz  (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_60_0"     : 1920 x 1080 @ 59.94/60 Hz (CEA-861B Format 16) (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_50"       : 1920 x 1080 @  50.0 Hz  (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_30"       : 1920 x 1080 @ 29.97/30 Hz (CEA-861B Format 34) (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_25"       : 1920 x 1080 @ 25 Hz (CEA-861B Format 33) (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_24"       : 1920 x 1080 @ 23.97/24 Hz (CEA-861B Format 32) (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_60i"      : 1920 x 1080 @ 59.94/60 Hz (CEA-861B Format 5) (from: EDID)
[295635.531] (II) NVIDIA(0): "1920x1080_50i"      : 1920 x 1080 @ 50 Hz Interlace (CEA-861B Format 20) (from: EDID)

What we want to do is give Nvidia, X and XBMC as little room as possible to make mistakes. So what you should do is make a subsection in the Screen section whitelisting the modes that are permitted:

Code:
Section "Screen"
        Identifier      "screen"
        Device          "nvidia"
        SubSection "Display"
                Modes "1920x1080_60_0" "1920x1080_50" "1920x1080_24"
        EndSubSection
EndSection

Like I said we only want the modes that are really necessary. In particular I think you should not pick nvidia-auto-select or any interlaced modi. CEA-861B Formats 16, 33 and 32 should suffice. In my case this translates to

Code:
Modes "1920x1080_60_0" "1920x1080_50" "1920x1080_24"

Also, make sure these modes are enforced as strictly as possible by adding the following line to the Device section:

Code:
Option          "ExactModeTimingsDVI"   "true"

Finally, we don't want the GPU to try and interfere with the video. It will mess up our nice 24p stream, so add this to the Device section as well:

Code:
Option      "FlatPanelProperties"   "Scaling = Native, Dithering = Disabled"

The resulting should look VERY familiar to this:

http://pastebin.com/wBaFGANU.

You can also copy the final version, but ALWAYS verify whether the modes are correct via the xorg log. For instance, sometimes "1920x1080_24" is called "1920x1080_24_0" or "1920x1080_24_1" or something. Always pick the mode "CEA-861B Format 32".

So now you have a good xorg.conf. Now modify your XBMC as following:

- In Settings => System => Video output, set the refresh rate to 60Hz for the most fluid GUI experience and set "Vertical Blank Sync" to "always enabled".
- In Settings => Video => Playback, enable "Adjust display refresh rate to match video" and "Sync display to playback" and set "A/V Sync method" to "Audio Clock". When you're there anyway also enable "VDPAU Studio level colour conversion". It doesn't have anything to do with judder, but it might prevent some chroma smear on TVs that accept 4:4:4 input, but don't really handle it well.

If everything went ok, you shouldn't have any judder anymore!
Reply
#2
Thanks for this. Going to give it a try on my ION system.
Reply
#3
If I only have a 1280x720 capable Plasma, do I still want to specify the 1920x1080 modes? It's my understanding my TV will still accept the 1080p mode, and just render it down. Also, the HDMI is going through a Onkyo receiver first (similar to the one you have above).
Reply
#4
Robdeep Wrote:If I only have a 1280x720 capable Plasma, do I still want to specify the 1920x1080 modes? It's my understanding my TV will still accept the 1080p mode, and just render it down. Also, the HDMI is going through a Onkyo receiver first (similar to the one you have above).
Well you can send all signals that your Onkyo accepts, i.e. the ones in the ModePool in the X debug log.

But whether or not 1080p works, depends entirely on how your Onkyo and your TV operate. Maybe Onkyo will just passthrough the signal and your TV will display an out-of-bounds. Or maybe Onkyo will just passthrough the signal and your TV will downscale. Or Onkyo knows your TV is not 1080p capable, so it downscales it to the native resolution of your TV automatically. I don't know how it works.

I would suggest, though, to just go with your TV's native mode, although you may be losing 24p capability. But I'm not at all sure that HD Ready TVs actually have 24p. My Onkyo doesn't advertise 720p24 in its ModePool in any case.

And if you don't have 24p my whole guide is close to useless for you, since there's only one refresh rate you should be using anyway: 60Hz.
Reply
#5
LB06 Wrote:Well you can send all signals that your Onkyo accepts, i.e. the ones in the ModePool in the X debug log.

But whether or not 1080p works, depends entirely on how your Onkyo and your TV operate. Maybe Onkyo will just passthrough the signal and your TV will display an out-of-bounds. Or maybe Onkyo will just passthrough the signal and your TV will downscale. Or Onkyo knows your TV is not 1080p capable, so it downscales it to the native resolution of your TV automatically. I don't know how it works.

I would suggest, though, to just go with your TV's native mode, although you may be losing 24p capability. But I'm not at all sure that HD Ready TVs actually have 24p. My Onkyo doesn't advertise 720p24 in its ModePool in any case.

And if you don't have 24p my whole guide is close to useless for you, since there's only one refresh rate you should be using anyway: 60Hz.


Thanks. I'm pretty sure my older 720p Plasma doesn't support 24p anyway. I just went with the 1280x720_60_0 mode, which I think is pretty close to what was being auto-detected before. I was getting occasional "juddering" of video and I thought your guide may have been applicable. I wasn't dropping frames. It's just at times the video would slightly slow down momentarily, then resume at it's normal pace.

So far since I made that custom xorg.conf I haven't had any delays, so perhaps it still improved this for me? Hard to say. I'm still fairly novice at tweaking this stuff Oo

Thanks
Reply
#6
i've got a xorg.conf that seems to work better than this for me. I'll post it later.
Reply
#7
neil.j1983 Wrote:i've got a xorg.conf that seems to work better than this for me. I'll post it later.
That'd be great! I'm always interested in ways to improve my configuration!
Reply
#8
LB06 Wrote:When you're there anyway also enable "VDPAU Studio level colour conversion". It doesn't have anything to do with judder, but it might prevent some chroma smear on TVs that accept 4:4:4 input, but don't really handle it well.

AFAIK, the colour conversion simply remaps the colours to simulate limited range output when using full range output from graphics card (the default and probably better mode and only one offered in older drivers). I believe in fact this remapping is only configured to work properly for HD files, so SD will be remapped slightly incorrectly (giving incorrect colours that you may notice if you have a keen eye).
Reply
#9
Thank you LB06 for writing this howto.

I´m struggeling with overscan, can this be fixed with modifying the xorg.conf? I have a Samsung TV, and I can fix the overscan issue with the ´Just Scan´setting. But if I suspend or shutdown my HTPC the TV forget this setting and goes back to 16:9 with overscan back again.
Reply
#10
TheSwissKnife Wrote:AFAIK, the colour conversion simply remaps the colours to simulate limited range output when using full range output from graphics card (the default and probably better mode and only one offered in older drivers). I believe in fact this remapping is only configured to work properly for HD files, so SD will be remapped slightly incorrectly (giving incorrect colours that you may notice if you have a keen eye).
Yes that's possible. In any case, it prevents blacks and whites from getting crushed if you use a TV and HDMI (VGA will always accept full RGB; in fact, it IS full RGB).

proson Wrote:Thank you LB06 for writing this howto.

I´m struggeling with overscan, can this be fixed with modifying the xorg.conf? I have a Samsung TV, and I can fix the overscan issue with the ´Just Scan´setting. But if I suspend or shutdown my HTPC the TV forget this setting and goes back to 16:9 with overscan back again.
Isn't this a bug in your TV? Such settings should be remembered, preferably per input.
Reply
#11
LB06 Wrote:Yes that's possible. In any case, it prevents blacks and whites from getting crushed if you use a TV and HDMI (VGA will always accept full RGB; in fact, it IS full RGB).

Yes for vdpau decoding...but there is an alternative, like setting xorg.conf so that nvidia controller output limited range if you have new enough version of drivers (I think 260.xx onwards). However when I have tested this a long time ago I found that this method clips outside the limited range so you lose super-whites that are present in streams, but on the plus side at least the GUI and picture viewer are then at correct levels, and SD would be correct colour.
Reply
#12
TheSwissKnife Wrote:Yes for vdpau decoding...but there is an alternative, like setting xorg.conf so that nvidia controller output limited range if you have new enough version of drivers (I think 260.xx onwards). However when I have tested this a long time ago I found that this method clips outside the limited range so you lose super-whites that are present in streams, but on the plus side at least the GUI and picture viewer are then at correct levels, and SD would be correct colour.
Yes but don't most people use VDPAU decoding exclusively? I do. Besides, when I set my HDMI output to limited levels the GUI was showing heavy banding instead of a smooth gradient, probably because the GUI is rendered in 4:4:4 / RGB. But it's also possible that this merely shows that my TV accepts RGB on its HDMI input and that therefore, the VDPAU Studio Color Conversion wouldn't have any effect. So maybe that means I should turn it off for SD purposes (not that I have a lot of SD)
Reply
#13
LB06 Wrote:Yes but don't most people use VDPAU decoding exclusively? I do. Besides, when I set my HDMI output to limited levels the GUI was showing heavy banding instead of a smooth gradient, probably because the GUI is rendered in 4:4:4 / RGB. But it's also possible that this merely shows that my TV accepts RGB on its HDMI input and that therefore, the VDPAU Studio Color Conversion wouldn't have any effect. So maybe that means I should turn it off for SD purposes (not that I have a lot of SD)

I mean there is an alternative when using vdpau. Output is always RGB 4:4:4 as xbmc does not support YCbCr format AFAIK. The issue is how RGB mapping from YUV (range should be 16-235 Y but with overshoot and unershoot possible for example) is done. Either map into RGB full range output (eg black = 0,0,0) and have the driver keep as is, or map into RGB full range output but tell driver (eg via xorg.conf) to convert to limited range (eg black becomes 16,16,16) (and this process loses super-whites of course), or map into RGB limited range output (eg black = 16,16,16) and have driver keep as-is. The last option maps without clipping but treats SD and HD the same when it should not - this is a bug as far as I can tell.

Then the issue of any files with vdpau might not be able to decode will be treated differently (ie not mapped like that) - picture viewer is good example. I am not suggesting a solution at present just pointing out what is going on given the lack of documentation.
Reply
#14
TheSwissKnife Wrote:I mean there is an alternative when using vdpau. Output is always RGB 4:4:4 as xbmc does not support YCbCr format AFAIK. The issue is how RGB mapping from YUV (range should be 16-235 Y but with overshoot and unershoot possible for example) is done. Either map into RGB full range output (eg black = 0,0,0) and have the driver keep as is, or map into RGB full range output but tell driver (eg via xorg.conf) to convert to limited range (eg black becomes 16,16,16) (and this process loses super-whites of course), or map into RGB limited range output (eg black = 16,16,16) and have driver keep as-is. The last option maps without clipping but treats SD and HD the same when it should not - this is a bug as far as I can tell.

Then the issue of any files with vdpau might not be able to decode will be treated differently (ie not mapped like that) - picture viewer is good example. I am not suggesting a solution at present just pointing out what is going on given the lack of documentation.
Thanks for the explanation, but aren't pictures always 0-255? I.e. there's no problem there? Or at least none that software could solve? If there is a problem, the problem is with the TV/hdmi inputs not accepting a full colour space. So that's more or less hardware problem. No amount of 'correction' can solve that.

With videos you can do colour correction simply because the video itself has a limited colour space. Mapping limited to full (I assume this is what VDPAU studio color correction does?) is much less of a problem than mapping from full to limited.

So in concreto, is it accurate to say that you should enable studio colour correction if your display accepts full input and that you should disable it if it doesn't? In the latter case, the TV will truncate 0-15 and 236-255, but without colour remapping there's nothing there anyway. Correct?
Reply
#15
LB06 Wrote:Thanks for the explanation, but aren't pictures always 0-255? I.e. there's no problem there? Or at least none that software could solve? If there is a problem, the problem is with the TV/hdmi inputs not accepting a full colour space. So that's more or less hardware problem. No amount of 'correction' can solve that.

With videos you can do colour correction simply because the video itself has a limited colour space. Mapping limited to full (I assume this is what VDPAU studio color correction does?) is much less of a problem than mapping from full to limited.

So in concreto, is it accurate to say that you should enable studio colour correction if your display accepts full input and that you should disable it if it doesn't? In the latter case, the TV will truncate 0-15 and 236-255, but without colour remapping there's nothing there anyway. Correct?

Pictures are full range yes. But the TV will be configured/calibrated so that level 16 is the blackest it can go - so that the video looks good. You will then miss detail in the shadow of your pictures. Also the whites above 235 will either look too bright or will be clipped by your display making no detail gradation in the highlight areas.

vdpau studio colour option is as I see it: mapping limited range YUV source data into limited range RGB output but without clipping values that started outside the normal range. The conversion appears to assume HD YUV coefficents when it should actually has 2 different sets and switch based on picture size - but I have not checked the matrix myself yet.

When your TV is configured to accept to an RGB 4:4:4 signal it will often not be clear what is doing regarding levels. It may look at some of the HDMI flags that are available and automatically decide the input range, or it may perhaps look for values outside nominal range to decide (not sure I have ever heard of that case), or it may be manually selectable. Once it has decided on a limited input range it may clip anything outside the limited range (though it is a fault to do so). Finally you will then calibrate (via contrast/brightness/RGB gains/cutoffs etc which input level refects black (no pixels enabled) and how bright is white at the source white level of 235 (you may or may not be able go brighter with higher input levels).

So without trying to take this thread away from its main subject I would add that the only way to check what you equipment is doing is get a video sample with range 0-255 encoded in it (super-blacks and super-whites) and play it through vdpau decoder with nvidia driver set to full range RGB (default), and studio colour enabled. If you can adjust your TV to see the difference between white levels each side of 16, and also between values each side of 235 then you know that your TV is accepting full range input in this case. Then you calibrate your screen so that 16 is blackest (no pixel lit), and you should hopefully see at least 18 or 19 level as slightly lit, and level 235 as a comfortable max white (eg around 80-100cd/m2 if you have a meter) - and not like LCDs out the box being really too bright here for night time viewing. Then see if you can still distinguish whites above 235 - if yes then great. Anyway now look at a photo via picture viewer and you should find the dark areas are too dark and the bright areas are too bright.
Reply

Logout Mark Read Team Forum Stats Members Help
[Linux] Judder-free 24p playback1