Do we have a non-VC1 file that has the same issue?
1 Like
You’ve lost me. You still haven’t explained why (you are expecting) it’s deinterlaced. VLC doesn’t deinterlace it. Just seems to play it at 29.97 frames per second. And it looks fine.
Here is what the log says when playing the 480 version:
2019-03-10 14:45:23.197 T:3544179440 INFO: ffmpeg[D33FE2F0]: Stream #0:0(eng): Video: mpeg2video (Main), yuv420p(tv, progressive), 720x480 [SAR 32:27 DAR 16:9], SAR 186:157 DAR 279:157, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc
Whereas for the 1080 version:
2019-03-10 14:43:39.911 T:3708809968 INFO: ffmpeg[DD0FF2F0]: Stream #0:0(eng): Video: vc1 (Advanced) (WVC1 / 0x31435657), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc
What are we supposed to make of metadata that says yuv420p(top first)? Is it progressive or interlaced??
Yes, the 480 version works fine. The 1080 one doesn’t. So, rather than launching into long explanations, shall we focus on the file that is problematic rather than the one that isn’t?
Indeed. The one that is problematic has confusing metadata. So why is it Vero’s problem?
Actually, I am going to have to explain that one again, aren’t I? The original source for the 1080 file is progressive: 24 progressive frames per second. This is repackaged as 60 interlaced fields per second (in the same way that a cinema film would be repackaged on an NTSC DVD).
A device that can handle the deinterlacing properly (for example, my Oppo 203) correctly identifies the file as originally-progressive frames split up into interlaced fields, and reconstructs the original frames, giving us an image with no moiré pattern. The Vero 4K+, however, fails to realise that it’s an originally-progressive source, and deinterlaces it as if it were 1080i/60 video rather than 1080i/60 film, and we get moiré.
No. Moire has nothing to do with the way it’s deinterlaced (although you can minimise it with yadif). You don’t get moire if it’s not deinterlaced.
It’s not confusing, it’s correct - the material is packaged as interlaced fields, but it’s from a progressive source.
And it’s the Vero’s problem because devices that don’t have broken deinterlacing handle it correctly. My Oppo 105D handles it correctly; my Oppo 203 handles it correctly; my LG G6 television handles it correctly (so long as I have “RealCinema” turned on); only the Vero gets it wrong.
Aren’t 1080i/60 titles sourced from 24p originals masters quite rare? The only such blu ray I have come across is Hoodwinked. I could not get satisfactory playback from the source rip so I Hanbrake’d it to 24p to get rid of the 3:2 pulldown and now it’s perfect. I have never found a version of Kodi on a Pi or Vero that can do 24p conversion on the fly as some DVD/blu ray players can, so when I have such a source I pre-convert it.
I feel like we’re talking at crossed purposes, here, @grahamh. Let’s go back to first principles.
Let’s take a DVD as an example; specifically, let’s imagine a British (”PAL") DVD. The video on a British DVD is always encoded as 576i/50. In other words, the way the video is always arranged on the disk as 50 interlaced fields per second.
But those fields could have been produced in two different ways.
First, it could be that the material was shot in a TV studio, using a TV camera which directly captures 50 interlaced fields per second - it captures one field, waits 1/50th of a second, then captures another field, waits another 1/50th of a second, and so on.
The other possibility is that material was originally captured on film. That was probably shot at 24 frames per second, and speeded up to 25; each frame was then split into two fields.
The important distinction is that in the first case, for a pair of fields, the two fields were captured at different moments in time; in the second case, the two fields were originally captured at the same moment in time as two parts of the same progressive frame.
So, when you come to play the DVD, you’ve always got video encoded on the disc as 576i/50 - it’s always 50 fields per second. To display it, that has to be deinterlaced into something progressive.
If the video was originally captured as 50 native fields per second, then the process of deinterlacing it involves various techniques that eventually generate 50 distinct frames per second.
But if it was originally captured as 25 progressive frames per second then the correct approach is to use the fields to reconstruct the original 25 progressive frames and display those.
So, the video as it is packaged on the disc is always interlaced; but in one instance the fields were captured as interlaced fields; in the other instance they were captured as part of a progressive frame. In the latter case, the video is packaged as interlaced, but tagged in the metadata as progressive - meaning, we have 50 fields, but the correct way to deinterlace them is to treat each pair as two parts of the same progressive frame. So, it’s not “confusing” to tag the video as progressive, despite it consisting of 50 fields per second; that description is entirely accurate, and helpful to the deinterlacer.
This is what we’re dealing with in the case of the 1080i/60 test clip: the video contained within the file consists of 60 interlaced fields per second; but the original source of those fields was 24 progressive frames per second. The video file is interlaced; the original source was progressive; and it helps the deinterlacer to choose the correct strategy if it knows that.
Does that now make sense?
The second problem is that (I think) you are using the word “deinterlacing” in too limited a sense. To go back to the British DVD example, you seem to think that, in the case where the original material was shot on film, the process of reconstructing the original progressive frames from the fields on the disc is not “deinterlacing”, and that it’s only “deinterlacing” in the case where you’re dealing with a natively interlaced video source. If you want to use a different word for the reconstruction of original progressive frames, I guess you can - but normally people use the word “deinterlacing” to refer to both of those processes. (And since many British TV shows are actually shot as a mixture of video and film, the deinterlacer has to switch strategies on the fly from to frame, so it doesn’t really make sense to treat the two processes as distinct).
They’re fairly rare; but 1080i/50 titles sourced from 25p masters are rather more common. A lot of BBC blu rays are in that format. This thread started because I was having problems with one of those.
I’ve offered a 1080i/60 test clip for initial testing because correctly recognising 1080i/60 that was taken from a 24p source is computationally very simple; if the Vero 4K can’t do that correctly, the chances of it handling 1080i/50 correctly are very small.
(Also because that clip is specifically designed as a test pattern to check if the correct deinterlacing approach is being used - it’s designed to be easy to spot if it isn’t).
I’m not necessarily expecting 24p output in this case; 60p is acceptable; but I am expecting the deinterlacer to weave rather than doing its motion-adaptive thing.
I haven’t used Handbrake in a couple of years, but the last time I did, it wasn’t possible to simply repackage video in that way, you had to transcode it at the same time. That’s not an acceptable solution for me, because decoding and re-encoding results in an inevitable loss of quality.
Has that changed in recent Handbrake releases?
I understand completely how telecine works, thank you. What I don’t know is what a telecine’d stream should look like ie the stream in detail). I only have this direct evidence: a stream which ffmpeg describes as (tv, progressive) which plays nicely on all devices and software I can muster here and a different stream which ffmpeg describes as (top first) and mediainfo, but not ffmpeg, describes as progressive which plays badly on every device I have here: vero, Pi, Kodi on Windows and Panasonic TV (from USB). The only way it plays nicely is with VLC on Windows and deinterlacing turned off. Hence my suspicion that it’s the deinterlacing process itself, not the manner in which it’s done, that’s the issue. VLC seems to be able to get acceptable results without what it calls deinterlacing.
So based on the 480 sample, I’m happy to take your word for it that the correct way to flag these telecine’d clips is ‘progressive’ but there’s clearly something different between the 480 and the 1080 clips about how they are conveying that ‘progressive’ message.
Are those two clips exact rips off your S&M test disk? Why is one MPEG and the other VC1?
Or coming back to the OP, can you cut out a clip from the stream which you had issues with which shows the problem?
Indeed, I have lots of these, VC-1 and h.264, have to say I’ve never noticed the Vero having a problem with 1080/50i, but if there is a specific title you are having issues with I’d be curious to know which one in case I have it.
Seems a bit harsh. Alll blu ray players I’ve seen that offer 24p conversion require the user to turn it on manually, have not found one that can do it completely automatically.
I agree that re-encoding is not desirable. However, given the choice between 3:2 pulldown judder and confused deinterlacing vs perfect 24p playback, I have re-encoded my R1 DVD films and also Hoodwinked on blu ray. Most of the DVDs have been replaced now anyway, and on Hoodwinked, there was no visual loss of quality at all, and for the rest of my 24p collection, it’s a non-issue.
The problem is that the H.264 spec is not clear about how to encode and signal non-progressive video. To make the compression better, the two fields from an interlaced video are stored and compressed as a single frame, just like every codec before. The problem is that a 30 frame per second interlaced video is 60 fields per second, and the spec is unclear as to whether this should be signaled as 30i or 60i.
The second problem is the signaling of field order and repeats, which is again not clearly specified. A really smart non-realtime de-interlacer (like many of the AviSynth filters) can look as enough frames/fields and figure out the cadence and do things perfectly with no signaling information (other than a top/bottom first hint). But, it’s hard to do this in realtime and maintain audio sync.
The end product is a video that contains 24 frames per second progressive content that has been telecined to 25 interlaced frames per second video, and marked as 24p, when it should be marked as either 25i or 50i, depending on how you read the spec.
The absolute best solution is to use AviSynth (or a wizard-like program such as Handbrake) to convert it back to 24p and re-enode. I have one region A BluRay that is a 24p film that had 2:3 pulldown added to make it 30 frames per second interlaced, then for some bizarre reason, they they doubled every frame to turn it into 60 frames per second.
It’s not necessarily that easy to spot. Loss of vertical resolution when the camera is moving is the give-away.
The original Planet Earth was what I was watching when I first posted this.
I think you may be missing the distinction between correct deinterlacing and frame-rate conversion. I don’t need it converted to 24p, I just need it correctly deinterlaced at 60p. Plenty of devices can do that fairly well (and automatically).
I don’t know, my television seems to handle it just fine in real time.
If it did, we wouldn’t have this thread, as it would de-interlace the output from the Vero automatically. The problem from your first post doesn’t exist using something like the SmartDecimate filter in AVISynth. It can even remove judder caused by naïve insertion of extra frames to convert 24p to 25p, even if the cadence varies. That’s because it can look forward in the stream at the next frame and compare it to the existing one, and drop the duplicate.
Curiously, my desktop PC running VLC plays it wrongly. Oppo 105D and Oppo 203 play it correctly. The television deinterlaces it correctly if it’s fed a native 1080i/60 signal. My phone plays it correctly using Kodi v18.1. My Nvidia Shield scrambles it horribly. The Vero gets it wrong, but not quite as badly as the Shield. Lumagen RadiancePro gets the deinterlacing right.
I think what we’re dealing with is an issue with the hardware-assisted deinterlacing.
To the best of my ability, yes. They were made straight from the disc using MakeMKV.
Presumably because one is SD and one is HD? I don’t know, you’d have to ask Mr Spears and Mr Munsil.
I can, but unless you happen to have something that plays it correctly and can compare the two side by side, you may have trouble spotting the problem. I have an annoyingly good eye for that kind of thing. 
I often wish I didn’t!
(It’s also in VC-1, if that matters).
But I could compare it in VLC with various different deinterlacing algos.
Here, it looks good with no deinterlace (fullscreen on a 1080 display). The ‘NTSC’ deinterlace is not much kop, the yadif x2 smudges everything enough to hide the moire.
No.
The Vero is not capable of outputting the video as 1080i only as 1080p.
Well, I say that; you can force 1080i output, but the way it produces that, according to Graham, is by deinterlacing internally and then reinterlacing before output, and in the general case I don’t trust it to do that correctly.
If the Vero 4K could directly output the native 1080i video then the problem would, indeed, disappear; but as far as I’m aware it can’t.