From what I’ve read, that’s exactly what hasn’t been done there properly… David Attenborough’s voice is deeper on UHD HD 
I just thought if you were pressing one disc for the whole world you might go for the source framerate rather than convert from 50 to 60Hz.
Yep - that would fine if North American TVs could handle 50Hz or 25Hz sources. Many of the mainstream manufacturers (Sony, Panasonic etc.) don’t… It’s 59.94Hz or 23.976/24Hz only…
If you release a 1080i25, 720p50 (or 2160p25/50 UHD) disc - as a global release you’ll be deluged with returns from North America accompanied by ‘It won’t play’ complaints. (And 1080p25 isn’t an option for Blu-ray - it’s not part of the standard)
(Or a 576i25 DVD for that matter)
Meanwhile a 1080p23.976, 1080i29.97, 720p59.94 (or 2160p23.976/59.94) release will play globally… (or a 480i29.97 DVD)
1 Like
Yep - that’s the downside - people have to know what they are doing…
1 Like
It’s been four or five months since we last talked about any of the issues in this thread. Some of them are much more involved than others, of course; but I’d like to know if there has been any progress towards getting deinterlacing back to working as well as it used to under the 3.14 kernel. Fixing the regressions we got in 4.9 would be a significant step forward.
The two most important problems introduced in 4.9 are the reduced ability to distinguish between interlaced-at-source and progressive-at-source SD material (e.g. live TV and DVD remuxes), and particularly the deactivation of diagonal filtering when decoding in hardware.
You could say there’s been progress in that we’re working on a new kernel which may turn out to be better at deinterlacing. This is essential so we can support newer technologies. However with each new kernel the video stack is substantially different so it’s not feasible to just pick out the bits from previous code that worked better before.
We’ve not forgotten you. 
4 Likes
Are you sure that’s an issue with the kernel and not Kodi?
I guess I’m not certain, no. I have the impression these issues have been outstanding for quite a while; and I was on a 4.9 kernel test build for considerably longer than I was on a v19 test build; but no, I’m not certain. If there’s 4.9 kernel / Kodi v18 test build somewhere (or alternatively a 3.14 kernel / Kodi v19 build) I’m happy to install it to verify.
May also be worth mentioning, there is quite a lot of code in the kernel that deals with deinterlacing; and would Kodi even know about what’s going on with hardware acceleration active?
Since you bring it up, there is one issue mentioned earlier in this thread that quite possibly is either a Kodi or ffmpeg problem, because it only affects software playback, and that’s this one:
That one has been a problem for longer than the deinterlacing issues - you can see it in 3.14/v18 releases too. If someone could definitely verify that it is a Kodi problem I would be happy to raise it as an issue against Kodi rather than on here.
It is and it isn’t. The rule for me is if I can reproduce the problem on PC then it’s a Kodi problem (meaning it’s a problem Team Kodi might take an interest in). You might still have to convince them it’s an issue that a lot of users are bothered with.
I don’t think I have a PC that’s capable of 720x480 output… I’ve tried reproducing the issue on my Amazon Fire TV devices, but the deinterlacing is so messed up I can’t really tell what’s going on (and I’m not 100% sure it’s really setting scaling to Nearest Neighbour correctly). Much the same applies to my Pi 3 running OSMC 19. I guess I could try reinstalling OSMC 18 on the Pi, see if it shows up there…
Would you care to elaborate? 
If you guys are willing to go on record as saying that it’s a Kodi issue, I can raise it as such, with a note to the effect that “the OSMC guys have assured me this is a Kodi-level problem and not an OSMC one”. Might not get anywhere, but if it isn’t an OSMC problem, there’s clearly not much point in me bugging you guys about it either(!).
It might not be all that complicated to fix - if I had to guess, I’d say it’s miscalculating the horizontal dimensions of the display window by one pixel, so that parts of the image are offset horizontally by that amount.
I’d like to bump this thread, as several of the issues raised back in post #1 are still outstanding and it’s been a while since they were last discussed.
In the time since this thread was originally created there has been significant progress on VC-1 playback - so we can ignore any of the VC-1-related issues originally raised here. Of the others, one (occasional cadence-detection errors on 1080i/50 h.264 stuff) has been looked at and judged to be unsolvable for the foreseeable future, so we’ll ignore that one too.
That leaves us with three issues that are still ongoing:
-
When decoding in hardware, my 480i wedge pattern (see post #1 for a link) is identified as field-interlaced when it is in fact frame-interlaced. (There is no reason to assume that this issue is limited to that one file; it just happens that it’s especially easy to see there, as the file is designed to be a deinterlacing test pattern). This file used to play correctly in the November 2020 release; it now doesn’t.
-
When decoding in hardware, if the file is field-interlaced, there is no diagonal filtering; this leads to jagged edges on diagonal lines, and sometimes flickering. This used to work correctly in the November 2020 release. (See the Time Flight clip for an example. The issue is easier to spot on SD material, but it actually does affect 1080i h.264 stuff as well.)
-
When playing a 480i/60 DVD remux with the output mode set to 480p, and decoding in software, there is some scaling going on when there shouldn’t be. The effect is somewhat masked (but not eliminated!) With
with scaling set to bilinear; but with scaling set to nearest neighbour, it’s very clear - a vertical band of distortion across the picture. At a guess, I’d say the horizontal dimensions of the video are being miscalculated (maybe by one pixel?), which causes pixels in the image to be displaced horizontally. This is a long-standing problem - it certainly dates back to before November 2020. The effect is particularly easy to see using my 480i wedge pattern, but it is also quite visible on other 480i/60 DVD remuxes.
This combination of issues is annoying, as it means that neither hardware- nor software-decoding of DVD remuxes is entirely reliable: in software you get the 480i scaling problem, in hardware you get the lack of diagonal filtering and possible cadence-detection problems.
Issue (3) could conceivably be a Kodi problem rather than an OSMC one, but I have no way to test that at the moment.
If it’s a software decode, we are relying on Kodi’s implementation of ffmpeg.
I’m sorry those other issues never seem to reach the top of the pile. I’m sure you’ll understand reports of ‘no video’, ‘no audio’ or ‘won’t boot’ tend to get priority in the queue for volunteer devs’ time.
Does that mean it should be raised as a Kodi issue?
(I’ve tried to reproduce it on other devices, and have so far failed, but that’s not really an indication that it only affects the Vero 4K; it’s just that I don’t have any other Kodi device that can produce good quality 480p output; or at least, not combined with software decoding and nearest-neighbour scaling, anyway).
I do understand that. I guess I want to make sure they’re still in the pile, at least. 
I guess it’s also tantalising, because if something used to work better than it does now, that at least shows that a fix is theoretically possible - we’re not dealing with (say) a fundamental limitation of the hardware.
By the time video gets to your screen through Windows and a typical PC GPU it’s been thoroughly messed about. I don’t know about other platforms.
Tantalising indeed, but AML don’t have much time for supporting 905X on the newer kernels. And we couldn’t keep linux 3.14 for ever.
I’ve never been satisified with DVD remux playback on the Vero.
It’s really a niche thing these days so I don’t expect it to get much attention from the developers.
My work around has been to re-encode the files into x264.
If you have your settings correct, the encoder should handle the telecine and interlacing properly but the issue I could never get around was fps, since the Vero does not like variable fps and some source DVDs have variable frames.
Using RF 16 makes the video encoding transparent, and the ac3 and vob can be muxed untouched.
It’s not ideal, but better than playing the actual discs as that forces me to watch FBI warnings and a bunch of other annoying things like trailers and menus unnecessarily.
Can 720x480 even be output in interlace with HDMI?
If so then, maybe the Vero could just output it untouched and leave your TV to do all the scaling and deinterlacing etc… but I don’t think it can.
I think it only does 480p60, which means the player would have to do the pull down for 24 fps and doubling for 30 fps.
Anyway, hopefully they can do something, because then you and I could enjoy it but we’re probably the only two people looking to do this stuff.
Doing that at acceptable speeds would require some significant hardware investment for me. 
It certainly can, although this is not a panacea. The original recording should contain metadata which actually tells the player when the material is field-interlaced and when it’s frame-interlaced. That information isn’t preserved in the HDMI signal, so an external deinterlacer has to analyse each frame and make an educated guess as to which strategy to use - which will sometimes be wrong. In theory it should be possible to handle most 480i/60 stuff correctly because you look for a repeating sequence of fields with a 3:2 pattern; but in practice external deinterlacers often aren’t that clever - they tend to work by trying the effect of doing a frame-deinterlace and then looking for evidence of combing. And that’s the only possible strategy for 576i/50 stuff.
On the subject of new output modes, 480p/24Hz would also be extremely useful, but I’m not sure if HDMI supports that one!
There’s an awful lot of classic TV that is only available in SD (and where the quality of a DVD is much better than anything streamed). I’ve recently been watching a lot of 90’s Star Trek - Voyager and Deep Space Nine - and it’s unlikely there’ll ever be a hi-def version of those. Ditto Babylon 5. There is a hi-def version of Buffy the Vampire Slayer but it’s atrocious - they decided to reframe it from 4:3 to 16:9 in a way that sometimes results in members of the camera crew becoming visible in the frame, and they also didn’t correctly reproduce digital colour grading, so you have vampires walking around in full daylight without any explanation. There’s all sorts of classic BBC stuff too - I, Claudius, The Singing Detective, Blake’s Seven, stuff like that. Classic Doctor Who they are beginning to re-release on blu ray now, but even that has to be in 1080i/50 format rather than 1080p, so it still needs deinterlacing.
Yes it can and we used to do it but there’s no point as we weren’t passing through interlaced frames untouched. Plus AML aren’t interested in outputting interlaced modes in their newer kernels.
HDMI doesn’t support frame/field interlaced signalling or 720x480p24.
These DVDs are all over the place when it comes to frame rates.
Do you have a standalone DVD player?
It might be your best option for DVDs with variable refresh rates.
I did an x264 encode at 120fps so the 24 frame sections and the 30 frames sections don’t studded but Vero still needs to upscale it to 1080p in order to output it at 1080p120.
It really is a pick your poison situation the way I see it.
It’s a necessarily subjective thing - everyone will have their own priorities. Personally I’m much more bothered by loss of detail or within-the-frame video artefacts (of the kind that are caused by incorrect deinterlacing or poor-quality upscaling) than I am by occasional judder; I’ll even take something captured at 24fps and watch the whole thing at 60Hz rather than put up with the Vero’s dubious upscaling. But many people would decide differently. (And my options are somewhat more limited than yours, as my TV doesn’t support 1080p/120).
This isn’t something I’ve ever looked into, but is there some way you could pre-upscale the video as part of the transcoding process, in a way that would improve on the Vero’s real-time upscaling?