I tried that, but it’s brutal on your CPU.
If you thought encoding your DVD remuxes into x264 wasn’t at acceptable speeds with your current hardware, don’t even think of upscaling it as well during the encoding process.
I have pretty competent hardware (Gen12 i7-12700) and it still takes a good chunk of time per each episode.
I don’t even want to think about doing multiple seasons!
In case this is of interest to @sam_nazarko or @grahamh or any of you other guys, I made a little progress on the issue of a 480i video being distorted when decoded in software. (I had some assistance from someone over at the Kodi forums).
Just to recap: playing a 16:9 NTSC DVD remux produces a vertical band of distortion within the image. To see it clearly you need to use software decoding, set deinterlacing to Off, set scaling to Nearest Neighbour, and make sure the output mode is 480p.
(N.B. Using other settings with software decoding doesn’t fix the issue, it only makes it harder to see; but as far as I can tell, decoding in hardware actually fixes it, albeit at the cost of introducing unrelated deinterlacing errors).
Now, obviously, if the video is 480i and the output mode is 480p, there shouldn’t be any scaling happening; so the fact that switching between nearest neighbour and bilinear scaling makes any visible difference at all means that Kodi must be miscalculating the size of the video somehow.
Some recent logs: https://paste.osmc.tv/hufemoxuru
Scanning through this we find:
2023-02-22 15:01:07.021 T:3095 DEBUG <general>: CRenderManager::Configure - change configuration. 720x480. display: 719x405. framerate: 29.97.
719x405, not 720x405. So it looks like Kodi is indeed getting the horizontal dimensions of the video wrong by 1 pixel - scaling from 720 pixels to 719 is what’s causing the distortion.
So, we took a closer look at my test clip, and specifically at the aspect ratio metadata. Using MediaInfo there’s nothing remotely controversial, but if we take a look with ffprobe, then this pops up:
Stream #0:0(eng): Video: mpeg2video (Main), yuv420p(tv, progressive), 720x480 [SAR 32:27 DAR 16:9], SAR 853:720 DAR 853:480, 29.97 fps, 29.97 tbr, 1k tbn
As an experiment, we tried massaging the metadata of the test clip, using ffmpeg:
ffmpeg -i 480i_60_deinterlace_test.mkv -aspect 16:9 -c copy 480i_60_deinterlace_test_fixed.mkv
Run ffprobe on the result and this time we get:
Stream #0:0(eng): Video: mpeg2video (Main), yuv420p(tv, progressive), 720x480 [SAR 32:27 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn
Playing this new file, I don’t see the obvious distortion any more; and the corresponding line in the log file this time shows 720x405 instead of 719x405. (Logs for the altered version: https://paste.osmc.tv/butalokeqi ).
All this might suggest an issue with the test clip, except that I knew perfectly well I’d seen the exact same distortion on other DVD remuxes! So I grabbed a season of Angel off the shelf, remuxed an episode, played it, and, sure enough - there was the exact same distortion again, and the same SAR and DAR values in the remuxed file.
Given that the same issue is happening on a number of unrelated titles, one of which is a Spears and Munsil calibration disc, I doubt it’s a consistent disc-authoring error across multiple publishers. So that leaves two possibilities:
-
The original remux metadata is, in fact, perfectly valid according to the MKV spec, and Kodi simply isn’t handling it correctly.
-
The original remux metadata is not valid, which means there must be a long-standing bug in MakeMKV which causes it to consistently mess up the metadata of 16:9 NTSC DVD remuxes. (And given how many people use MakeMKV, there are going to be a lot of files like that in the world!)
So, does anyone know enough about the MKV container spec to say which of these it is?
Links to test clips…
Original: Dropbox - 480i_60_deinterlace_test.mkv - Simplify your life
Massaged version: Dropbox - 480i_60_deinterlace_test_fixed.mkv - Simplify your life
Intriguing. I don’t have a lot of 16:9 NTSC rips these days but I pulled an episode of The West Wing ripped with an old version of makemkv and was able to create the vertical distortion you describe, and it was eliminated by “massaging” the metadata. I happened to re-rip an NTSC movie the other day and it too has the same metadata oddity. I’m seeing supplemental DAR values of 279:157 in the two files I checked.
I also checked a PAL 16:9 mkv and a 4:3 NTSC mkv and they were both fine, corroborating the theory that something is specific here with 16:9 NTSC.
@angry.sardine This might have improved with ffmpeg5, which Kodi v21 will use.
As it’s a big change, once we have moved to v20, we will start preparing ffmpeg5 test builds to make sure things like 3D don’t break.
@sam_nazarko I’m hoping you or someone else around here might know enough about the MKV container specs to be able to say if a remux file (as produced by MakeMKV) is in a valid state or not.
If it’s not valid then the root problem is that MakeMKV is screwing up the metadata during remuxing and Kodi is blameless; but if the file is valid, then that means Kodi (or ffmpeg) isn’t handling valid metadata in the way it should. At the moment I’m not sure which of those two things is happening.
Which are the main differences between FFMPEG 5 and 4?
This sheds some light:
https://ffmpeg-user.ffmpeg.narkive.com/rvor2AeW/two-sar-dar-pairs-codec-and-stream-sar-dar
I’ve no idea where the value 853 comes from and haven’t investigated what Kodi does with it. I suspect we do want to take notice of metadata in the stream for streams where the a/r changes (eg for ads in a TV rip).
FWIW, ffprobe built from source outputs the same SAR/DAR values so ffmpeg 5 is no different from 4.
853:480 is obviously approximately 16:9. (Actually 853.33333…). But whether that number should actually be there or not is a whole other question. “What Kodi does with it” is clearly the core issue. 
As far as I can tell, with hardware decoding enabled, there is no extraneous scaling going on - certainly all references in the log to CRenderManager::Configure are followed by 720x405, not 719x405. If it’s the case that Kodi with hardware decoding handles this file correctly while Kodi with software decoding doesn’t, that might suggest that there is an issue with Kodi software decoding rather than an issue with the file… but 
OK so 720 x 853 / 853.333 is 719.7 which is being rounded down to 719. For 4:3 and 576 lines at 16:9 or 4:3 that problem doesn’t exist. We just need to find out where that rounding down is happening.
1 Like