Tweet
Hello to you all who are interested in high quality video playback on Linux! There is one very interesting project in development that allows perfect redraw synchronization when using AMD and Intel graphics hardware. I'm postin here to draw more attention to the project _and_ to make sure AMD hardware is not left behind. Main developer seems to work on Intel at the moment. Technical details follow.
Many of you probably know what causes tearing and unsmooth video playback, but I'm going to explain a bit anyway. The very problem is different screen refresh and video frame/field frequency and the problem that frame rate resampling is anything but simple or perfect. Current solutions are just to ignore it (by dropping or doubling frames) or do the resampling (NVidia Purevideo). The resampling works well if the source is already motion compressed, so motion vectors can be used for constructing frames at arbitrary times. For really high fidelity stuff the workload is very high as motion serach has to be done, just like mpeg compression, but in realtime. Even still, the quality suffers. More processing -> more errors.
Almost all of the above is unnecessary if screen and frame rates are the same. Television does just that. On PC hardware things get a bit tricky as apparently, is wasn't designed with such usage in mind. The project FRC or Frame Rate Control does those tricks purely in software and that makes it qute special. I've been trying to get some attention to the problem before and it may be of value to read a bit there too:
FRC, the _important_ part:
For testing the concepts I suggest a clip of _interlaced_ DV-video with plenty of motion and camera stutter or dvb grab of animated news tickers. Before heading to the FRC it is good idea to play a bit with "cvt" and "xrandr" commands to get proper display modes. You'll need 50 Hz capable monitor for European dvb or digitized PAL. Also cvt rounds framerates somewhat weirdly, but specifying a bit more will get you closer. Like "cvt 1600 1200 50.05" will get 50.01 Hz out. The error would result field jitter every 50/(50.01-50)=5000 fields so once per 100 seconds. Normally that close tolerance is not achievable bacause of the cheap clock crystals and no adjustment. Kaffeine has good controls for deinterlacing, so make sure you are using _one_ frame deinterlacers like linear blend. Otherwise motion is blurred away.
Last but not least I hope to see some developer comments here as this is definitely something to include to VA-API or some other video processing api specification. I remember Brigdman saying something like "frame locking is difficult to get working reliably" somewhere on phronix forums.
Have fun!
Many of you probably know what causes tearing and unsmooth video playback, but I'm going to explain a bit anyway. The very problem is different screen refresh and video frame/field frequency and the problem that frame rate resampling is anything but simple or perfect. Current solutions are just to ignore it (by dropping or doubling frames) or do the resampling (NVidia Purevideo). The resampling works well if the source is already motion compressed, so motion vectors can be used for constructing frames at arbitrary times. For really high fidelity stuff the workload is very high as motion serach has to be done, just like mpeg compression, but in realtime. Even still, the quality suffers. More processing -> more errors.
Almost all of the above is unnecessary if screen and frame rates are the same. Television does just that. On PC hardware things get a bit tricky as apparently, is wasn't designed with such usage in mind. The project FRC or Frame Rate Control does those tricks purely in software and that makes it qute special. I've been trying to get some attention to the problem before and it may be of value to read a bit there too:
FRC, the _important_ part:
For testing the concepts I suggest a clip of _interlaced_ DV-video with plenty of motion and camera stutter or dvb grab of animated news tickers. Before heading to the FRC it is good idea to play a bit with "cvt" and "xrandr" commands to get proper display modes. You'll need 50 Hz capable monitor for European dvb or digitized PAL. Also cvt rounds framerates somewhat weirdly, but specifying a bit more will get you closer. Like "cvt 1600 1200 50.05" will get 50.01 Hz out. The error would result field jitter every 50/(50.01-50)=5000 fields so once per 100 seconds. Normally that close tolerance is not achievable bacause of the cheap clock crystals and no adjustment. Kaffeine has good controls for deinterlacing, so make sure you are using _one_ frame deinterlacers like linear blend. Otherwise motion is blurred away.
Last but not least I hope to see some developer comments here as this is definitely something to include to VA-API or some other video processing api specification. I remember Brigdman saying something like "frame locking is difficult to get working reliably" somewhere on phronix forums.
Have fun!
... Also FRC does the adjustment without full crtc reset (unlike real mode change), so there is no blank period to be seen.
Comment