Star Trek TNG DVDs - Scan Type is missing from certain episodes

[bobrosswins]

I am ripping an old collection of Star Trek The Next Generation DVDs. I noticed that certain episodes were displaying combing artifacts and so I checked Mediainfo.

On most episodes the scan type is as follows:

Scan type : Interlaced
Scan type, store method : Separated fields (2 fields per block)
Scan order : Top Field First

However on certain episodes these flags are missing altogether. This causes mpv (and other players) to assume progressive. Is this an error in the DVD authoring process or something that I can fix in MakeMKV? Does MakeMKV add these flags after scanning the video or are they present in the source?

[dcoke22]

I'm speculating, but I assume MakeMKV is just copying whatever is authored on the disc.

You could try using mkvpropedit (part of the MKVToolNix tools) to add the flags to the .mkv file.

[dcoke22]

The mkvpropedit command line is probably something like:

Code: Select all

mkvpropedit /path/to/mkv/file --edit track:v1 --set FlagInterlaced=1 --set FieldOrder=1

Matroska Element Specification.

[bobrosswins]

Thanks! For my own edification how can I locate the header field names that mkvpropedit will take? Man page doesn't list.

[dcoke22]

Thanks! For my own edification how can I locate the header field names that mkvpropedit will take? Man page doesn't list.

I'm pretty sure it'll take the names listed in the Element Specification, the link in my last post.

[bobrosswins]

I really went down the rabbit hole on this one. Learned about detelecining vs deinterlacing. The core issue for me is Plex/mpv isn't deinterlacing/detelecining content that should be because the MKV headers are either missing a Scan Type or it's set to Progressive with 2:3 pulldown.

If I change the headers is it doing anything to the underlying streams? I don't want to have to rerip all these discs again if I make the wrong choice...

[bobrosswins]

In order to satisfy my own curiosity, I used ffmpeg to extract the mpeg2 video stream to a ts container for both the original MKV and a copy where I changed the header to "interlaced."

I then compared SHA-256 hashes of the two ts files and they were identical. So it appears that changing header data on an MKV does nothing to the underlying stream (which is good).