Is this reproducible? I’m just recording BBC News on both SD and HD channels and I can typically watch either. But one time I got video but no sound. Stop and re-start fixed it.
I wanted to say that I’m really happy with the image-quality improvements to VC-1 playback that I’m seeing in this test build. It has definitely got us back to where we were in the kodi-18.9/kernel-3.14 release, and I think may even be a slight improvement on that. (I can’t be bothered to reinstall an old image to check, but if memory serves there was always a slight loss of clarity on VC-1 back in v18 days, as if it was doing some subtle DNR in post-processing. But even that seems to have gone now!)
Is there a chance someone could take a look at the other picture-quality issues that were introduced with the 4.9 kernel - perhaps most importantly the lack of diagonal filtering when deinterlacing in hardware (which used to work beautifully in 3.14)?
You seem to be the only one commenting re. VC-1 picture quality. As such, we need to prioritise accordingly.
I know @ac16161 is also a frequent tester of VC-1 material, so I’ll be interested in his thoughts as well.
Some photos of current kernel vs the 3.14 stack you were happy with would be good.
Cheers,
Sam
The problem with live view of in-progress recordings is pretty persistent. Mostly I get audio with no picture, sometimes the reverse. I enabled logging and it happened to work on the first attempt but then failed on the subsequent two cycles.
Deinterlacing errors are tricky to capture in a still screenshot.
I have discussed these issues before, in this thread: Deinterlacing / extraneous scaling issues . There are some attempts at screenshots in there (first post in that thread) but as far as diagonal filtering is concerned, it’s easier to compare by eye the difference between decoding in hardware (no diagonal filtering) and decoding in software (correctly filtered).
Go here: Dropbox - Deinterlacing test patterns - Simplify your life and download the Time Flight clip. Decoding in hardware, you’ll notice there’s a constant flicker at the top left of the screen; also, watch the control console between 00:10 and 00:15, and between 00:34 and 00:39 - note the jagged edges and “crawling” effect along the edges of the metallic strips. Software decoding mostly fixes both issues.
(“Then why not just use software decoding?” you may well ask: that does indeed work okay for 576i stuff, but there’s a separate, much longer-standing problem that messes up 480i playback with software decoding - also described in the thread I linked to above, if you’re curious; but as that wasn’t a regression in the 4.9 kernel, I’m less hopeful of a fix.)
I confess I was watching on a different device to the tvh server. I’ll do some more testing using just one device. It may need @tanio99’s skills but he won’t have access to the BBC.
Later: I can repro on HDTV - I get audio or video but not both. SDTV seems OK except takes a couple of seconds to find its feet.
Later still: the codec is just not being recognised. This is normal playback (ITV-HD while recording BBC1-HD on the same mux):
2022-08-23 15:18:50.608 T:8212 DEBUG <general>: AddOnLog: pvr.hts: id: 1001, type H264, codec: 27
2022-08-23 15:18:50.608 T:8212 DEBUG <general>: AddOnLog: pvr.hts: id: 1002, type AAC, codec: 86018
2022-08-23 15:18:50.608 T:8212 DEBUG <general>: AddOnLog: pvr.hts: id: 1004, type DVBSUB, codec: 94209
while this was sound only (BBC1-HD while recording)
2022-08-23 15:15:52.025 T:8212 DEBUG <general>: AddOnLog: pvr.hts: id: 1002, type AAC, codec: 86018
2022-08-23 15:15:52.025 T:8212 DEBUG <general>: AddOnLog: pvr.hts: id: 1003, type AAC, codec: 86018
2022-08-23 15:15:52.026 T:8212 DEBUG <general>: AddOnLog: pvr.hts: id: 1004, type DVBSUB, codec: 94209
then we get
2022-08-23 15:15:52.044 T:8212 DEBUG <general>: AddOnLog: pvr.hts: Dropped packet with unknown stream index 1001
Normal playing of BBC1-HD
2022-08-23 15:39:21.348 T:13715 DEBUG <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1001 with codec_id 27
2022-08-23 15:39:21.348 T:13715 DEBUG <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1002 with codec_id 86018
2022-08-23 15:39:21.348 T:13715 DEBUG <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1003 with codec_id 86018
2022-08-23 15:39:21.348 T:13715 DEBUG <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1004 with codec_id 94209
No idea how to fix this though 
1 Like
with 1080/24p content I can’t see any inferiority from the Vero vs a Kodi 18 Pi 3B with a VC-1 hardware key installed. I would give them both an edge over Infuse Pro on a first-gen Apple TV 4K.
with 1080/50i it’s more complicated. My go-to source content here is new Dr Who series 5 UK release. The content is actually 25p but encoded to 50i. With deinterlacing set to auto on the Vero motion is good but there is some moire once you spot where to look for it. Disabling deinterlacing provides PQ on the Time of Angels episode that I can only describe as outstanding with the latest build, but there are some occasional minor stutter issues. On the Pi I can disable deinterlacing and still get perfect motion every time, and PQ to my eyes is fantastic but I don’t think I could pick it out vs the Vero if the stutter could be fixed.
I’d go farther than that, actually - it’s directly comparable to my Oppo 105D blu ray player, which was generally regarded as being best-in-class for 1080p blu ray playback when it came out. Certainly a major improvement over the last non-test release!
Again, agreed - the stutter that you get playing 1080i/50 VC-1 when deinterlacing is set to Off is the only significant issue remaining for VC-1; if that could be fixed, VC-1 playback would be pretty much perfect. To my eyes, outputting 1080p/25Hz rather than 1080p/50Hz makes it significantly smoother, but this is annoyingly fiddly o do at the moment, since all 1080i/50 material now defaults to 50Hz output by default.
Beside the issue of minor stutter, would you say setting deinterlacing to ‘Off’ in the video OSD settings improves things for all videos or just in some scenarios?
Well, obviously, it’s designed to help with videos that were captured as progressive and then stored as interlaced. So, for example, if the video was originally captured by the camera as 25 progressive frames per second - 1080p/25 - and then stored on the blu ray disk as 1080i/50; or if it was captured as 1080p/24 and stored as 1080i/60; or captured as 1080p/30 and stored as 1080i/60. Material that was originally captured on film, for example, is inherently progressive.
If the video was originally captured as native interlaced fields (e.g. a HD news broadcast from the studio recorded as 1080i/50) then setting deinterlacing to Off will look horrible - you’ll get both stutter and combing.
Sometimes you encounter material which is a mixture of both - for example, the video was originally captured as progressive, but the closing credits were generated electronically as interlaced. (In the SD case, this mixture is much more common - classic BBC shows were often filmed as a mixture of interlaced video shot in the studio and progressive stuff shot on location on 16mm film; but this is very unusual in HD).
It would be nice if the video file header could be relied on to tell you when the file is natively progressive, but I imagine it’s not always reliable: so forcing the video to be interpreted as progressive is something that needs to be a manual option.
That said, most HD stuff that did not originate as a live broadcast is natively progressive. Of course none of this analysis applies to material that is actually stored on the disc as progressive (e.g. 1080p/24); but for stuff that is stored on the disc as interlaced, I think it’s safe to say that the majority of HD material looks better with deinterlacing set to Off, but not all of it. (A really cool new feature would be to be able to do this on h.264 material as well as VC-1 - at the moment that’s not an option).
I was not referring to what scenarios should benefit from the ‘Off’ setting technically, but whether it benefits all interlaced video playback visually? Have you tested this?
The impact is significant enough that I’ve given up watching 1080i/50 h.264 material on my Vero 4K+ entirely - it just annoys me too much. (I press my old blu ray player into service instead). I’m not suggesting every single frame is torture, but on the Vero it would be unusual for a 50-minute episode to go by without at least one visible deinterlacing error somewhere.
It depends a bit on the kind of thing being pictured. What particularly tends to trip up the automatic deinterlacer is when you have a lot of rapid variation in brightness or colour from top to bottom - for example, a brick wall in the distance, or fine horizontal stripes on fabric.
If you want to see an example of the deinterlacer getting it wrong, I uploaded one a while back: go to Dropbox - Deinterlacing test patterns - Simplify your life and download the “Sherlock” clip; watch the pattern on Mycroft’s grey suit between 00:30 and 00:47. The effect isn’t subtle.
As well as this kind of moiré-like pattern, you also sometimes get jagged edges on diagonal lines, or an overall softening with loss of vertical resolution (especially when the camera is panning).
You say these issues occur with the automatic deinterlacer. Does this mean these issues are gone with the setting set to ‘Off’ with any interlaced content?
What we’re trying to establish is: can we just fix the deinterlace setting to Off for VC-1 and have done with it? And we know you’re concerned about h264 as well but that’s handled very differently so for another day.
for my main system I’ll always watch HD progressive 50i content using a device with a disable deinterlace option, as for me the increase in all-round resolution is generally noticeable. But I appreciate this may not be high on everyone’s list of user requirements. I’m not sure which Kodi 19 platforms actually support this (my nVidia Shield does not as far as I can tell) so I tend to use a K18 Pi (as it can disable deinterlacing on h264 as well) or I sometimes check out Infuse on the Apple TV (which isn’t a contender for general use in my view as it’s hopeless with natively interlaced content, simply unwatchable). For more general-purpose displays around the house I find the Vero to be fantastic, especially since the HDR-to-SDR conversion got nailed, but I quite understand if development resource has to be focused elsewhere than fine-tuning deinterlace options.
Thanks, but, er, can you answer the question 
? Is there any 50i content that plays better on Vero with ‘deinterlacing on’ than with ‘deinterlacing off’?
Meanwhile, we have some ideas about the stutters …
sorry, I thought I had answered the question. Most of my HD 50i sourced from bluray is obviously progressive so I would just seek to disable deinterlacing on principle, for the bump up in resolution. Some mixed content HD 50i material is around (e.g. the classic Dr Who blu rays), so an auto method is required due to the constant switching between filmed exteriors and studio interiors captured on interlaced video.
OK, thx. So the Auto setting does give you a nicer picture for that mixed content? By classic Dr Who I assume you mean 20th Century. I’ll have a closer look at those clips, but I don’t think we’ve got any long enough to have both ‘interlaced’ and ‘progressive’ scenes in them. It would be really good to put a magnifying glass on their frame headers.
Ah. Maybe the ‘Spearhead from Space’ clip will do the trick. Nope. Not VC-1.
If you’re looking for mixed content VC-1 the only thing I have would be something like a season 5 episode of Dr Who where the main episode footage transitions to the end credits. To my eyes the credits must be natively interlaced as they have a fast vertical scroll, and while disabling deinterlacing benefits PQ for the main footage, the end credits become a messy scrawl., On auto the credits scroll perfectly.
If you could clip out a bit that goes through that transition for us, it would be great.