Most stable Ubuntu for XBMC?
#16
Sure thing. Here's my Xorg.0.log:

http://pastebin.com/bL4VqjKN

and here's my xorg.conf:

http://pastebin.com/EvCBB6Tc

I really appreciate the help.

Rob
Reply
#17
Your X server seems to be configured correctly and able to generate 24Hz output:

Quote:[ 13.900] (II) NVIDIA(0): --- Modes in ModePool for SAMSUNG (DFP-1) ---
[ 13.900] (II) NVIDIA(0): "nvidia-auto-select" : 1920 x 1080 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "1920x1080" : 1920 x 1080 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "1920x1080_60" : 1920 x 1080 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "1920x1080_60_0" : 1920 x 1080 @ 59.94/60 Hz (CEA-861B Format 16) (from: EDID)
[ 13.900] (II) NVIDIA(0): "1920x1080_30" : 1920 x 1080 @ 29.97/30 Hz (CEA-861B Format 34) (from: EDID)
[ 13.900] (II) NVIDIA(0): "1920x1080_24" : 1920 x 1080 @ 23.97/24 Hz (CEA-861B Format 32) (from: EDID)
[ 13.900] (II) NVIDIA(0): "1920x1080_60i" : 1920 x 1080 @ 59.94/60 Hz (CEA-861B Format 5) (from: EDID)
[ 13.900] (II) NVIDIA(0): "1280x720" : 1280 x 720 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "1280x720_60" : 1280 x 720 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "1280x720_60_0" : 1280 x 720 @ 59.94/60 Hz (CEA-861B Format 4) (from: EDID)
[ 13.900] (II) NVIDIA(0): "720x480" : 720 x 480 @ 59.9 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "720x480_60" : 720 x 480 @ 59.9 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "640x480" : 640 x 480 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): "640x480_60" : 640 x 480 @ 60.0 Hz (from: EDID)
[ 13.900] (II) NVIDIA(0): --- End of ModePool for SAMSUNG (DFP-1): ---

So this is probably a XBMC problem. As I do not see any difference between 24hz and 3:2pulldown I never bothered with configuring XBMC's auto-switching feature. So I can't help you there. You should have a look at XBMC's debug logfile to see if it actually tries to switch the refresh rate at all.

You can also try to set the refresh rate manually using "xrandr" to see if it actually works. Most of the security checks are disabled in your xorg.conf, so there is still a chance that your X configuration might be the problem. Verifying that a 24hz mode can actually be enabled might save you some time when debugging XBMC.However from the logfile your X configuration looks fine.

Reply
#18
(2012-06-14, 16:34)Temar Wrote:
(2012-06-14, 02:11)Plaguester Wrote: It makes a huge difference on pans. And yes, I do have a hell of an eye. Others may not pick up the lines (tearing) but will notice that pans seem significantly smoother when the refresh rate is synced with the video frame rate.

Tearing is a totally different problem which of course is notable, but tearing can easily be fixed by turning on vsync.

For the effect to be visible on pans, you'd need a really fast pan. After all, the frame delay is only 1/120 of a second with a 60Hz refresh rate! So for the eye to actually notice it, the camera would have to move at least 1 foot in this 1/120 of a second so you could actually see a wobbling effect. This would equate to a camera movement of 120 foot/s or about 36m/s.

Um... no. 3:2 pulldown introduces awkward motion due to showing consecutive frames for differing amounts of time. Motion sequences look significantly more natural when shown at an integer multiple of 24 (48, 72, 96, 120, and 240 are common). If you can't see a difference, fine. Many people can and generally describe it as "judder". Some people just don't ever see anything other than 3:2 pulldown and thus equate that to "normal" rather than the smoother film motion.

Skeeto, there's a post in the How-To forum on getting judder free playback on NVidia hardware. Give that thread a shot. Worked perfectly for me.
HTPC 1 - Zotac ZBOX ID80U | 4GB RAM | 64GB SSD | Openelec | Confluence
HTPC 2 - Zotac ZBOX ID41U | 4GB RAM | 60GB SSD | Openelec | Confluence
Server - unRAID Server | 3 x 2TB WD Green HDD, 1TB WD Black HDD (Cache) | Sabnzbd | CouchPotato | Sickbeard
Reply
#19
Plaguester,

I may have already seen the how to. If it is the same post you are talking about, I have run the nvidia script successfully but I am running into the issue of xbmc not being able to switch my LCD tv mode to 24 hz. I'll take a look at the debug next time I run xbmc.
Hey Temar,

One other strange thing I have noticed is that on my Eden install under video output settings I am not even shown the option to change refresh rate. Am I going crazy or is this option missing? Does it matter that I installed Eden before I added in the other refresh options using the Nvidia.sh script?
Reply
#20
Temar,

Here is a snippet of my debug log while trying to play 300 with the screen synching option on. You can see all the discontinuities that cause my judder. Any clues as to why the screen isn't switching to 24hz?

http://pastebin.com/EKTsJFgN

Or perhaps this is the audio struggling to sync up with the unstable video.
Reply
#21
After you ran the script in that thread, what does your /etc/X11/xorg.conf look like?
HTPC 1 - Zotac ZBOX ID80U | 4GB RAM | 64GB SSD | Openelec | Confluence
HTPC 2 - Zotac ZBOX ID41U | 4GB RAM | 60GB SSD | Openelec | Confluence
Server - unRAID Server | 3 x 2TB WD Green HDD, 1TB WD Black HDD (Cache) | Sabnzbd | CouchPotato | Sickbeard
Reply
#22
(2012-06-15, 02:05)Plaguester Wrote:
(2012-06-14, 16:34)Temar Wrote: For the effect to be visible on pans, you'd need a really fast pan. After all, the frame delay is only 1/120 of a second with a 60Hz refresh rate! So for the eye to actually notice it, the camera would have to move at least 1 foot in this 1/120 of a second so you could actually see a wobbling effect. This would equate to a camera movement of 120 foot/s or about 36m/s.

Um... no.

Um...yes. Do you even understand what happens when the player does a 3:2 pulldown? Just do the math yourself.

Quote:3:2 pulldown introduces awkward motion due to showing consecutive frames for differing amounts of time.

That's basically correct, but the effect can only be visible on very fast movements:

60 Hz / 24 FPS = 2.5

So basically the player would have to switch frames after 2.5 monitor frames. Though it's possible, noone will want that because of the tearing you get. So everybody turns on vsync. With vsync on the player will still display 2 movie-frames within 5 monitor-frames but one frame will be displayed for 3 monitor-frames and the other one for 2 monitor frames. Every second frame is therefore displayed half a monitor-frame longer than it should (3 monitor frames instead of 2.5), which happens to be (1/60)s/2 = 1/120s = 8.4ms.

If there is no movement between the two frames, you obviously will not notice the 3:2 pulldown at all. If there is movement you can notice it, but only if the camera moves very fast. That's because 8 ms is a very short time and you need to cover a lot of distance within this 8ms for your brain to actually notice that the object it is tracking should already be at a different position. Of course if you have such a scene, you will notice the judder. However these scenes are very rare and most of the people who claim to see a difference in normal day to day movies with slow pannings, would probably not pass in a blind test.


(2012-06-16, 17:21)skeeto2010 Wrote: Temar,

Here is a snippet of my debug log while trying to play 300 with the screen synching option on. You can see all the discontinuities that cause my judder. Any clues as to why the screen isn't switching to 24hz?

http://pastebin.com/EKTsJFgN

Or perhaps this is the audio struggling to sync up with the unstable video.

Your XBMC seems to try to switch the resolution:
Quote:10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: nvidia-settings -nt -q RefreshRate3 produced no output

But the command does not seem to return the expected output. Still it seems to have worked as randr reports a 24 Hz refresh rate:

Quote:10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Using RandR for refreshrate detection
10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Detected refreshrate: 24 hertz
10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Vblank counter has reset
10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Detaching glX context
10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Attaching glX context
10:08:46 T:2799651648 DEBUG: CVideoReferenceClock: Clock speed 100.100000%
10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Received RandR event 124
10:08:46 T:2808044352 DEBUG: CVideoReferenceClock: Detected refreshrate: 24 hertz

Looks good to me. But I never configured it myself, so basically I don't know which settings XBMC expects to activate auto-switching. From your logfile however it seems to have worked fine.
Reply
#23
(2012-06-17, 02:02)Temar Wrote: That's basically correct, but the effect can only be visible on very fast movements:

60 Hz / 24 FPS = 2.5

So basically the player would have to switch frames after 2.5 monitor frames. Though it's possible, noone will want that because of the tearing you get. So everybody turns on vsync. With vsync on the player will still display 2 movie-frames within 5 monitor-frames but one frame will be displayed for 3 monitor-frames and the other one for 2 monitor frames. Every second frame is therefore displayed half a monitor-frame longer than it should (3 monitor frames instead of 2.5), which happens to be (1/60)s/2 = 1/120s = 8.4ms.

If there is no movement between the two frames, you obviously will not notice the 3:2 pulldown at all. If there is movement you can notice it, but only if the camera moves very fast. That's because 8 ms is a very short time and you need to cover a lot of distance within this 8ms for your brain to actually notice that the object it is tracking should already be at a different position. Of course if you have such a scene, you will notice the judder. However these scenes are very rare and most of the people who claim to see a difference in normal day to day movies with slow pannings, would probably not pass in a blind test.

All the math in the world (and yours is correct) won't change the fact that I can see it plainly. The motion judder inherent in 24 fps filming is bad enough without playing it in a jerky fashion. In most cases it isn't terrible (I actually don't have refresh rate matching on right now due to an XBMC audio bug). Anyone who really wants to get rid of judder for good needs to convince the film industry to shoot at a modern framerate (30 or 60 fps) instead of something they picked back in the 1920s.

Skeeto, you may be doing all this work just to discover that the audio sync gets worse the the more a video is played with a 24hz refresh rate (so you can't just set the delay correctly and be done with it). This is a documented bug on these forums and I believe it has been addressed in the AudioEngine work.
HTPC 1 - Zotac ZBOX ID80U | 4GB RAM | 64GB SSD | Openelec | Confluence
HTPC 2 - Zotac ZBOX ID41U | 4GB RAM | 60GB SSD | Openelec | Confluence
Server - unRAID Server | 3 x 2TB WD Green HDD, 1TB WD Black HDD (Cache) | Sabnzbd | CouchPotato | Sickbeard
Reply
#24
My revo experiences the slight audio delay issue so I'm fully prepared to deal with that. The issue that I am facing with this Foxconn build is different entirely. When trying to sync the display to content at 24fps, the video becomes unwatchably juddery but the audio (appears) to be lined up. The video codec info shows no dropped frames during this judder but the Samsung LCD most definitely stays at 60hz. Is it possible that the audio errors in the debug log are xbmc attempting to get the sound matched to the epileptic video?

Plaguester,
I posted a link to my xorg.conf after the script was run earlier in the thread.
Reply

Logout Mark Read Team Forum Stats Members Help
Most stable Ubuntu for XBMC?0