The fundamental problem here isn’t actually to do with interlaced playback, it’s to do with progressive playback. The problem is that if your video is 1080p/25fps progressive, and you play it with the output video mode set to 1080p/25Hz, it plays correctly; but play the same video with the output video mode set to 1080p/50Hz and you get jerky playback. The same thing happens if you have a video that is 1080p/29.97fps and you output it at 1080p/59.94Hz. (And in fact the same issue happens with 2160p material too - 2160p/25fps is jerky with 2160p/50Hz output).
There has some discussion about whitelist logic, but ultimately that would be a workaround to this problem: if we could output 1080p/25fps at 25Hz and 1080i/50 at 50Hz, that would circumvent the issue. But apparently that’s very difficult, for the reasons Graham explained; so that gets us back to the original problem. If we could output 1080p/25fps video smoothly at 1080p/50Hz, then the current whitelist behaviour would be fine.
On the face of it there’s no good reason why the box shouldn’t simply show each frame twice to convert smoothly from 25fps to 50Hz, but it clearly isn’t doing that.
I’ve a couple of clips here that say they’re 1080p25 but the hw decoder tells me that they’re interlaced, so 50 fps would be the way to go. In Kodi there’s code that assumes that 25 and 29.9 fps are interlaced modes. That’s why the fps value is doubled. The question now is: if we can’t rely what ffmpeg tells us, then what should we do?
I’ll have a look at that clip here. Maybe I find some way to differ between “real” 25p and interlaced clips.
If a video is genuinely interlaced - field-interlaced, anyway - then it won’t play smoothly at 1080p/25Hz. The case we’re most interested in is the progressive video that plays correctly at 1080p/25Hz but is jerky at 1080p/50Hz. If you can make those play smoothly at 50Hz, the problem goes away.
But to be able to do that, you first have to be able to determine what a video really is, p/i, otherwise you cannot program anything to correctly do something. I think that is the real issue at hand here.
It isn’t subtle to me, but not everyone is susceptible to it as others are. Did it play as 1080p50 or 1080p25 on your TV?
At first I thought it was part of the way it was recorded, but couldn’t let it go and checked it out on my LG TV with the Plex app and the difference to me, was night and day.
I played it at both 25 and 50Hz direct from USB disc. 25Hz was maybe smoother but only in the first few seconds where there’s more movement. This on a Philips OLED.
Yeah, I purposefully used a scene where there was horizontal movement. When there is no horizontal movement, you do not see it that much.
Also, if you use smoothing techniques like motion smoothing or whatever it is called on your TV, you will not notice it that much. I dislike motion smoothing, as it introduces artifacts, even on the better engines, but that is a different discussion
Though, it is an assumption that you do use some kind of motion smoothing so I could be wrong , if you do not use any of those functions, in horizontal movement shots, the experience in this case is pretty bad for me.
I do turn all that crap off, but who knows what goes on in a TV? I just ran your clip on a Panasonic and the jerks are more obvious. Also the header metadata seems intact so it’s a useful clip, thanks.
@angry.sardine, @grahamh I had a look at the logs today. That clip is a “real” progressive one playing at 25 fps. So everything’s fine with the clip. The problem is introduced by the whitelist logic that prefers double refresh rates if there’s no whitelist set.
If there’s no whitelist configured, then Kodi first filters out refresh rates between 24 and 30 fps. So e.g. 29.97 and 25 are discarded. From the remaining modes Kodi now searches for a mode that matches the double refresh rate. In that case here it finds 50 fps and is happy.
To be exact: that search for double refresh rate happens either if there’s no whitelist defined OR if that “allow double refresh rate” flag is set.
I wonder if we should change that logic a bit? Would it make sense to allow the double refresh rate check only if there is a whitelist set AND that “allow double refresh rate” flag is set? And of course, the refresh rates between 24 and 30 fps should not be filtered out at the first place.
Btw, that filtering was introduced about 6 years ago, and the comment in the code tells us the reason:
// do not add half refreshrates (25, 29.97 by default) as kodi cannot cope with
// them on playback start. Especially interlaced content is not properly detected
// and this causes ugly double switching.
// This won't allow 25p / 30p playback on native refreshrate by default
I wonder if that’s still a valid reason, and if it ever was one for Kodi running on the Veros?
There’s a lot of 25fps progressive stuff on Netflix.
To my mind the fundamental problem is, why can’t a 25fps video be played at 50Hz by simply showing each frame twice? If the box could do that, the current refresh-rate logic would generally be correct.
If you want to tackle this by means of using 1080p/25Hz output mode then you will have to find some way of distinguishing reliably between 1080p/25fps and 1080i/50 - if you start playing 1080i/50 at 25Hz it goes crazy (and never properly recovers, even after the output mode switches a second time to 1080p/50Hz).
To take this approach I think the logic should be:
Interlaced material must always be played at the higher frame rate, irrespective of checkbox settings.
For progressive material, the “double rates” checkbox should do what it says, namely it should allow double refresh rates but not prefer them. (So 1080p/25fps should default to 1080p/25Hz, if that mode is available, regardless of checkbox status. If that mode isn’t available then it will fall back to 1080p/50Hz with the box checked, or 2160p/25Hz with it unchecked.)
Behaviour with no whitelist should mimic whitelist behaviour with double rates checkbox checked.
But honestly, getting a 25fps video to play smoothly at 50Hz is still going to be the best option, if it’s possible.
Because, well, reasons . It’s not a kernel problem, it’s a Kodi one. The algorithm that determines what it should do with the next frame (keep it, skip it or show it) is (let’s say) a bit complicated. I’ve already tried to touch it but I’ve made it worse. And that algorithm is also responsible to keep audio/video in sync. So it’s not easy to get it right there.
Right. I would suggest to remove that filtering of refresh rates as I’ve mentioned it in my last post. If a user uses a whitelist or not, the algorithm just gets a different set of available modes as input. If there’s no whitelist, then every available mode should be fed into that whitelisting algorithm.
Users will expect only modes > GUI will be used. Otherwise, the whitelist really becomes a blacklist which was discussed at length in the Kodi forum and rejected back in the day. People will get confused if the whitelist works differently in that respect on different platforms.
I am assuming with that 99% you are referring to 1080 25 material? If so, I do not think that is true at all, I have a lot of 1080 25 material and they all are progressive. I do not have a single 1080 25 file that is interlaced here.
Just an observation
Possibly Graham means that, in the absence of a whitelist, only resolutions from GUI res and up should be used (e.g. it won’t switch down to 720p, 576p or 480p)?
I said IF you assume 99% is interlaced. ie it made sense with that assumption.
Nothing at all. I think the logic at Team Kodi went like this: make the default (ie with no whitelist) prefer 50/60Hz because most video plays better with that. That may come about because many TK members live in countries where interlaced TV is the norm. Then I’m with @angry.sardine - permitting double refreshrates should not mean preferring them when the user has set up a whitelist.
Ok, yesterday I did some tests and found a way to get 25p at 50 fps going. It was easier as I’ve initially thought, because I just had to adjust the frame duration in a different way. I’m not sure if my “fix” is a real fix though. I will address that issue again when we start working on Omega.
Regarding the whitelisting: so if there’s no whitelist configured, then we put all available/supported modes in a pot. In case there is a whitelist, then only the whitelisted modes are put in that pot.
Then we’re looking for a matching mode out of that pot. If we find an exact match then we’re done.
If not then we check for a double refresh rate mode only
if no whitelist is configured, or
if there’s a whitelist then that “allow double refresh rate” option must be checked
And as @angry.sardine mentioned, for interlaced material we always need the double refresh rate.
The change in the whitelist algorithm would be minimal in that case. We would just have to stop looking for alternative modes if we found an exact match in the beginning.
, if you do not use any of those functions, in horizontal movement shots, the experience in this case is pretty bad for me.
. It’s not a kernel problem, it’s a Kodi one. The algorithm that determines what it should do with the next frame (keep it, skip it or show it) is (let’s say) a bit complicated. I’ve already tried to touch it but I’ve made it worse. And that algorithm is also responsible to keep audio/video in sync. So it’s not easy to get it right there.