2009-05-15, 15:12
Since smoothvideo has been merged into linuxport and the old thread contains replies about the former implementation (which relied on opengl vsync for timing) the discussion will continue here.
What is it for?
Lots of people experience jerkiness when playing video on a computer, this has to do with the way video frames are presented, smoothvideo tries to fix this by syncing the video to the refreshrate of the monitor.
It's like the reclock directshow filter, only much better.
How does it work?
Usually video is referenced to the system clock, but with a little magic a clock can be made with information from the videocard, this makes sure every frame is presented right after a vblank. Also because the clock can now be controlled, the speed can be changed a little so the fps of the video playing matches the refreshrate.
What about audio?
Audio has to stay in sync, this can either be done by resampling, skipping/duplicating packets, or adjusting the clock if it gets out of sync too far.
Resampling has the advantage that the speed of the video can be changed considerably, so 24 fps can be sped up to 25 fps to play at PAL speed.
The disadvantage of resampling is that it doesn't work with passthrough, and there is a slight loss of audio quality.
Skipping/duplicating audiopackets has no loss of audio quality, but the speed of the video can only be changed a little to avoid doing a skip/duplication too often, most of the time it's inaudible, but it can produce a very audible click.
Adjusting the clock has the best audioquality, but some extra video jitter can occur, also the speed of the video can't change much, as the audio will sync the clock more often the more the speed of the video is changed.
How do I turn it on?
Under Settings->Videos->Player there are several new options:
What about the adjust refreshrate option?
That's something different, it will automatically set the refreshrate which is best matched with the video that is playing, but it is a good combination with the vblank clock.
How do I know it's working?
Turn on debug logging, turn on Sync playback to display and start a video, then search the debug log for CVideoReferenceClock.
Mine looks like this (on ubuntu with the binary nvidia driver):
Here I'm playing a 29.97 fps video on a monitor with a 60 hertz refreshrate, the speed of the clock is increased by 0.1% so the video wil play at exactly 30 fps.
The rounding of the refreshrate from 59.89 to 60 hertz does NOT matter. Why? because of the automatic change in clock speed.
Now press 'o' while playing to bring up the codec information, if the vblank clock is running it will show "VBlanks missed:" with a number next to it, that number shows how many updates the vblank clock has missed, this can either be because the update was too late or it missed a vblank completely and it's waiting for the next vblank.
This is not especially bad, because the render thread will update the clock instead. However if that number increases really fast it can mean the clock is not running at all or it's missing a lot of vblanks, in which case you might get some strange pitch effects when resampling and even jerky video.
If you get a like like this in the debug log:
It means it couldn't set up the clock and it uses the systemclock instead, the lines containing CVideoReferenceClock above it will usually explain what went wrong.
Known issues
Some videos don't provide correct fps information, so they'll play jerky anyway.
Crashes in linux with the binary ati driver.
On windows the detected refreshrate might be wrong, to fix this you can turn on measurerefreshrate in Advancedsettings.xml.
What is it for?
Lots of people experience jerkiness when playing video on a computer, this has to do with the way video frames are presented, smoothvideo tries to fix this by syncing the video to the refreshrate of the monitor.
It's like the reclock directshow filter, only much better.
How does it work?
Usually video is referenced to the system clock, but with a little magic a clock can be made with information from the videocard, this makes sure every frame is presented right after a vblank. Also because the clock can now be controlled, the speed can be changed a little so the fps of the video playing matches the refreshrate.
What about audio?
Audio has to stay in sync, this can either be done by resampling, skipping/duplicating packets, or adjusting the clock if it gets out of sync too far.
Resampling has the advantage that the speed of the video can be changed considerably, so 24 fps can be sped up to 25 fps to play at PAL speed.
The disadvantage of resampling is that it doesn't work with passthrough, and there is a slight loss of audio quality.
Skipping/duplicating audiopackets has no loss of audio quality, but the speed of the video can only be changed a little to avoid doing a skip/duplication too often, most of the time it's inaudible, but it can produce a very audible click.
Adjusting the clock has the best audioquality, but some extra video jitter can occur, also the speed of the video can't change much, as the audio will sync the clock more often the more the speed of the video is changed.
How do I turn it on?
Under Settings->Videos->Player there are several new options:
- Sync playback to display
Turn this on and the magic happens, a thread will start that makes a clock from the vertical blank.
- A/V Sync method
You can set this to Audio Clock, Video Clock(resample audio) or Video Clock(Drop/Dupe Audio)
Resample audio does not work when passthrough is selected.
- Resample quality
Quality of the resampler, goes from low to really high, the default is medium which should be fine for anyone. The higher the quality of the resampler, the more cpu it will use. You can look at the resampler types at libsamplerate
- Maximum Resample Amount (%)
The maximum percentage the speed of the video can be changed to fit the refreshrate, the default is 5% to allow cinema to PAL speedup (24 to 25 fps, 4%), this is only available when resampling (a small speed change will still happen without resampling).
What about the adjust refreshrate option?
That's something different, it will automatically set the refreshrate which is best matched with the video that is playing, but it is a good combination with the vblank clock.
How do I know it's working?
Turn on debug logging, turn on Sync playback to display and start a video, then search the debug log for CVideoReferenceClock.
Mine looks like this (on ubuntu with the binary nvidia driver):
Quote:21:09:39 T:2874137488 M:1382379520 DEBUG: CVideoReferenceClock: Setting up GLX
21:09:39 T:2874137488 M:1379201024 DEBUG: CVideoReferenceClock: output of nvidia-settings -nt -q RefreshRate 2>&1: 59.89 Hz
21:09:39 T:2874137488 M:1379201024 DEBUG: CVideoReferenceClock: Detected refreshrate by nvidia-settings: 59.890000 hertz, rounding to 60 hertz
21:09:39 T:2865744784 M:1379323904 DEBUG: CVideoReferenceClock: Clock speed 100.100000%
Here I'm playing a 29.97 fps video on a monitor with a 60 hertz refreshrate, the speed of the clock is increased by 0.1% so the video wil play at exactly 30 fps.
The rounding of the refreshrate from 59.89 to 60 hertz does NOT matter. Why? because of the automatic change in clock speed.
Now press 'o' while playing to bring up the codec information, if the vblank clock is running it will show "VBlanks missed:" with a number next to it, that number shows how many updates the vblank clock has missed, this can either be because the update was too late or it missed a vblank completely and it's waiting for the next vblank.
This is not especially bad, because the render thread will update the clock instead. However if that number increases really fast it can mean the clock is not running at all or it's missing a lot of vblanks, in which case you might get some strange pitch effects when resampling and even jerky video.
If you get a like like this in the debug log:
Quote:CVideoReferenceClock: Setup failed, falling back to QueryPerformanceCounter
It means it couldn't set up the clock and it uses the systemclock instead, the lines containing CVideoReferenceClock above it will usually explain what went wrong.
Known issues
Some videos don't provide correct fps information, so they'll play jerky anyway.
Crashes in linux with the binary ati driver.
On windows the detected refreshrate might be wrong, to fix this you can turn on measurerefreshrate in Advancedsettings.xml.