Need Suggestions on What to Do Next

[DeadSkullzJr]

If this is in the wrong location, I am sorry for posting in the wrong place.

I have been creating mkv video files of my DVD iso dumps recently for experimentation and viewing entertainment purposes. Upon doing extensive research, it seems to be concluded that film is supposed to be 23.976 frames per second, which so far seems fine, I have heard mentions of this for years, so it seemed that hasn't changed, however I am in a situation where I don't know if that's cleanly possible or accurate 100% of the time. I have a couple films that I decided to make an attempt to restore in their intended form, and so far I am running into issues doing this. I have utilized AviSynth+ and FFmpeg quite extensively individually and in combination, both seem to offer some decent results, but they both seem to have their own handling issues when dealing with film contents, which led me to try and use DGMPGDec, and by extension DGIndex to aid AviSynth+ and FFmpeg respectively. Unfortunately DGIndex kept getting stuck trying to process any of the MKV video files I threw at it to make d2v index documents, in which case I ended up stumbling on DGDecNV, which seems to work fine with generating dgi index documents, as such I rolled with that and worked up a script to use said documentation. The end result seems to lead to a standard video with typical 2:3 pulldown, however now comes the problems and the strange characteristics no matter what I do.

AviSynth+ Approach:
I tried to use AviSynth next and wrote up scripts for TIVTC related usage, TFM doesn't seem to do a very good job handling pulldown very well as some frames still have a very noticeable combing looking stair effect, and mind you that's with the settings set to the highest quality possible based on the capabilities of the TIVTC documentation provided. Proceeding further with TDecimate seems to yield cut frames that aren't supposed to be cut, which makes no sense considering when you look at the video as-is, it's clearly 2:3 pulldown, three progressive frames and two interlaced, shouldn't be handled in a way where this happens. I double checked my script settings and nothing seemed wrong, I had my cycle set correctly and all to handle the duplicate frames from 2:3 pulldown. Given the result from TFM and the crummy result from TDecimate, I decided to try FFmpeg next.

FFmpeg Approach:
This approach seems to have more interesting results. I removed the TFM and TDecimate entries from the AviSynth script I wrote and just left the DgiSource line in for FFmpeg to pick up, I then typed out a command involving FFmpeg's pullup option since that seems to do a better job than TFM (I plan to investigate this option further to ensure it isn't touching progressive frames), and attempted to source copy the audio and subtitles from the mkv and map them to the dgi index source I created. Up to this point things seem to be working fine, so I waited for the video to finish encoding. After the encode was finished, I checked the results out, and not only am I left with a strange frames per second result (that being 24.018 frames per second in this case), but the audio still desyncs. I checked for duplicate frames and going through quite a few of them I saw no duplicates, I even ensured that there were no strange frame jumps for the scenes with motion and saw nothing strange there either, as such I proceeded to try and recalculate the frame timings to work with 23.976 whilst preserving all of the frames. This didn't fix the desyncing either, but I did have a 23.976 fps video with all the frames intact.

The only approach that seems to work for either option, is to literally cut important frames out just to hit 23.976 frames per second to keep it synced with the audio. This to me makes no sense at all, so unless I am missing something entirely, or have a really bad understanding somewhere, I really don't know what else to do. My objective was to restore the films without dropping any important frames, only the duplicates, basically a lossless restore if possible.

I apologize if this seems all over the place, I've been at this for more than a couple weeks trying to sort this out and am running out of ideas.

I have provided a snip of one of the films I was working on.

[manono]

I have been creating mkv video files of my DVD iso dumps

Decrypt to VOB and use DGIndex on them. Then open them using MPEG2Source.
Trying to use MKVs as your source for an IVTC is just asking for trouble.

[Alwyn]

I'd suggest you attach an un-retouched 30 second sample of your MKV. I'm sure the experts will sort you out quickly. I create samples with AVIDemux as per my guide here.

[DeadSkullzJr]

I have been creating mkv video files of my DVD iso dumps

Decrypt to VOB and use DGIndex on them. Then open them using MPEG2Source.
Trying to use MKVs as your source for an IVTC is just asking for trouble.

You completely left out all the other details and told me to do stuff that basically was already done. I already decrypted the iso images, and made mkv video files using MakeMKV. I stated that I can't use DGIndex because it gets stuck processing the mkv videos to make a d2v source index to work with, I used DGDecNV instead (successor to DGMPGDec / DGIndex from what I understand) which worked. I listed the issues mentioned when either using the mkv video directly AND OR the dgi source index for TIVTC via AviSynth+ or the FFmpeg options. This response isn't helpful at all.

[DeadSkullzJr]

I'd suggest you attach an un-retouched 30 second sample of your MKV. I'm sure the experts will sort you out quickly. I create samples with AVIDemux as per my guide here.

Done. Though I don't know if the frame drop issue I mentioned will be prevalent with only 30 seconds to work with.

[Alwyn]

Sorry, you beat me to it. Max size for attachments here is 500mb so you could go up to probably 5 minutes worth of MPEG 2/VOB if needed.

[DeadSkullzJr]

Sorry, you beat me to it. Max size for attachments here is 500mb so you could go up to probably 5 minutes worth of MPEG 2/VOB if needed.

Fixed, the snip is sitting right on the border of the max size allowed lol.

[DeadSkullzJr]

Well this is unfortunate, I tested the clip I sent earlier and created a snip from the other movie I was working on, and both of the snipped portions seem to have processed more appropriately compared to processing the entirety of either film. The only thing you can probably reproduce with the snip I sent above is the issues with TFM doing a bad job fixing the pulldown. Other than that, I don't think there is a way to reproduce the issues I mentioned unless you guys have the whole video(s), which obviously isn't something that is going to happen since that isn't allowed and the obvious legal ramifications.

I at least went ahead and got images of a couple frames to show what TFM is doing and why I didn't like it. Left is the previous progressive frame, and the right image is the interlaced frame from the pulldown being treated by TFM. The actual video in question is from the dgi source index created from the original mkv video. TFM seems to also be trying to process multiple progressive frames later in the video too, leaving behind the same staircase combing mess seen in the right image, making it frustratingly inconsistent.

[Attachment 83895 - Click to enlarge]

[poisondeathray]

Horizontal lines such as in the body of the robot are going to resemble combing and be detected as such (false positive)

Adjust your TFM settings such as cthresh or disable post processing with TFM(pp=0) to see the effect of field matching only, then if you need to change the other settings like cthresh or use a more advanced PP like clip2 if you still need post processing. To help you debug with an overlay you can use display=true - it will say "combed - deinterlaced" when pp is applied if combing is detected according to the calculation in the documentation

You can probably get away with

DGSource()
TFM(pp=0).TDecimate()

Because it's a clean source, doesn't look like there's any bad edits or other problems but I didn't look too closely

[jagabo]

With a consistent pulldown pattern you can perform a manual IVTC:

LWLibavVideoSource("robots_snip.mkv") 
SeparateFields().SelectEvery(10, 0,1,3,4,6,7,8,9).Weave()

[DB83]

I have read this thread with 'interest'

Am I wrong that, unless there is good reason to 'convert' 29.97 fps back to 23.976 fps, then why bother since the pull-down takes care of of the different frame-rate ? Of course I am always open to opinion as to why such 'conversion' is appropiate.


On the other hand a 25 fps (PAL) video should be converted back to 23.976 fps simply to cancel the 'PAL Speed UP' whereas, unless I am mistaken, there is no 'speed up' between original film( 24 fps) and 29.97 fps video due to pull-down. And, of course, one regularily sees PAL releases these days with 'frame-blending' so there now is no speed-up and the dvd plays at the original run-time.

[jagabo]

Am I wrong that, unless there is good reason to 'convert' 29.97 fps back to 23.976 fps, then why bother since the pull-down takes care of of the different frame-rate ? Of course I am always open to opinion as to why such 'conversion' is appropiate.

My preference is to always have progressive video. Why be at the mercy of whatever device is deinterlacing during playback?

That said, the OP's video appears to be 100 percent soft pulldown. He can just ignore the pulldown flags.

[DeadSkullzJr]

With a consistent pulldown pattern you can perform a manual IVTC:

LWLibavVideoSource("robots_snip.mkv") 
SeparateFields().SelectEvery(10, 0,1,3,4,6,7,8,9).Weave()

This seems to cause destruction when comparing some of the frames, here is one for example.

Original:

[Attachment 83906 - Click to enlarge]

Your Script:

[Attachment 83907 - Click to enlarge]

Comparison: (Red means differences, gray means no differences)

[Attachment 83908 - Click to enlarge]

[jagabo]

I did a comparison of my earlier script with ffVideoSource (which ignores the pulldown flags) and the result was exactly the same (aside from a few extra frames at the start -- probably an open GOP issue).

manual = LWLibavVideoSource("robots_snip.mkv").SeparateFields().SelectEvery(10, 0,1,3,4,6,7,8,9).Weave()
nopulldown = ffVideoSource("robots_snip.mkv").Loop(3,0,0)

StackHorizontal(manual, nopulldown, Subtract(manual, nopulldown).Levels(127,1,129,0,255))

[DeadSkullzJr]

Went ahead and tried some of the suggestions on the other movie I was working on, and it doesn't seem to matter what I do for said movie, it apparently always goes from 29.970 to 24.000, and oddly enough the audio starts to lose sync over time when watching the movie, doesn't seem to matter if I use a clean copy from the source either, so it's definitely something with the video itself. I checked the frames and didn't notice any duplicates, though maybe I missed some frames somewhere that weren't obvious. Here is the MediaInfo data about the movie at least. Interestingly enough there is absolutely nothing mentioned about the movie being 29.970 in the metadata like it does for some other movies I have looked at, however when throwing the mkv into various different video editing software, it's detected as 29.970, so I guess nothing of a real problem? Either way, no idea how to fix this issue since all of my attempts so far other than literally cutting unique frames out, allows me to sync the video correctly with the audio. First time dealing with this as the other movies seem to be fine during testing with their respective audio streams. Any suggestions for this additional wrench being thrown in the mix, if possible, one that doesn't involve cutting corners by chopping unique frames out of the video (effectively destroying the video stream a bit) or destroying the audio in some way?

General
Format                                   : Matroska
Format version                           : Version 2
File size                                : 3.04 GiB
Duration                                 : 1 h 9 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 6 279 kb/s
Frame rate                               : 24.000 FPS
Encoded date                             : 2024-12-01 08:22:44 UTC
Writing application                      : MakeMKV v1.17.8 win(x64-release)
Writing library                          : libmakemkv v1.17.8 (1.3.10/1.5.2) win(x64-release)

Video
ID                                       : 1
ID in the original source medium         : 224 (0xE0)
Format                                   : MPEG Video
Format version                           : Version 2
Format profile                           : Main@Main
Format settings                          : CustomMatrix / BVOP
Format settings, BVOP                    : Yes
Format settings, Matrix                  : Custom
Format settings, GOP                     : Variable
Codec ID                                 : V_MPEG2
Codec ID/Info                            : MPEG 1 or 2 Video
Duration                                 : 1 h 9 min
Bit rate mode                            : Variable
Bit rate                                 : 5 812 kb/s
Maximum bit rate                         : 9 800 kb/s
Width                                    : 720 pixels
Height                                   : 480 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Frame rate                               : 24.000 FPS
Original frame rate                      : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Scan order                               : 2:3 Pulldown
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.701
Time code of first frame                 : 00:00:00:01
Time code source                         : Group of pictures header
Stream size                              : 2.81 GiB (93%)
Language                                 : English
Default                                  : No
Forced                                   : No
Original source medium                   : DVD-Video

Audio
ID                                       : 2
ID in the original source medium         : 189 (0xBD)128 (0x80)
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Commercial name                          : Dolby Digital
Codec ID                                 : A_AC3
Duration                                 : 1 h 9 min
Bit rate mode                            : Constant
Bit rate                                 : 448 kb/s
Channel(s)                               : 6 channels
Channel layout                           : L R C LFE Ls Rs
Sampling rate                            : 48.0 kHz
Frame rate                               : 31.250 FPS (1536 SPF)
Compression mode                         : Lossy
Stream size                              : 222 MiB (7%)
Title                                    : Surround 5.1
Language                                 : English
Service kind                             : Complete Main
Default                                  : Yes
Forced                                   : No
Original source medium                   : DVD-Video
Dialog Normalization                     : -24 dB
compr                                    : -0.28 dB
cmixlev                                  : -3.0 dB
surmixlev                                : -3 dB
dmixmod                                  : Lt/Rt
ltrtcmixlev                              : -3.0 dB
ltrtsurmixlev                            : -3.0 dB
lorocmixlev                              : -3.0 dB
lorosurmixlev                            : -3.0 dB
dialnorm_Average                         : -24 dB
dialnorm_Minimum                         : -24 dB
dialnorm_Maximum                         : -24 dB

Text #1
ID                                       : 3
ID in the original source medium         : 189 (0xBD)33 (0x21)
Format                                   : VobSub
Codec ID                                 : S_VOBSUB
Codec ID/Info                            : Picture based subtitle format used on DVDs
Duration                                 : 1 h 4 min
Bit rate                                 : 7 605 b/s
Frame rate                               : 0.287 FPS
Count of elements                        : 1112
Stream size                              : 3.51 MiB (0%)
Language                                 : English
Default                                  : Yes
Forced                                   : No
Original source medium                   : DVD-Video

Text #2
ID                                       : 4
ID in the original source medium         : 189 (0xBD)32 (0x20)
Format                                   : VobSub
Codec ID                                 : S_VOBSUB
Codec ID/Info                            : Picture based subtitle format used on DVDs
Duration                                 : 1 h 4 min
Bit rate                                 : 7 605 b/s
Frame rate                               : 0.287 FPS
Count of elements                        : 1112
Stream size                              : 3.51 MiB (0%)
Language                                 : English
Default                                  : No
Forced                                   : No
Original source medium                   : DVD-Video

Menu
00:00:00.000                             : en:Chapter 01
00:08:45.358                             : en:Chapter 02
00:18:02.214                             : en:Chapter 03
00:29:36.858                             : en:Chapter 04
00:40:16.881                             : en:Chapter 05
00:47:24.391                             : en:Chapter 06
00:53:44.104                             : en:Chapter 07
01:04:35.304                             : en:Chapter 08

[poisondeathray]

Timestamp errors from makemkv - because DVD-video does not support 24/1 fps .

It's common to have timestamp errors from MakeMKV , or from improper cutting eg. mediainfo says your first video is absurd 169 fps

Frame rate mode                          : Variable
Frame rate                               : 169.814 FPS
Original frame rate                      : 23.976 (24000/1001) FPS

Mediainfo doesn't scan the entire file thoroughly, so it's not a completely accurate picture

Use DGSource or demux the MKV and use DGIndex. They are the most reliable source filters.

Open the .dgi, or .d2v in a text editor. If the .dgi or .d2v says 100% film, it's 100% 2:3 soft pulldown - meaning it's 100% progressively encoded at 23.976, and repeat field flags tell the decoder to repeat fields to make 29.97 fps or 59.94 fields/s . You could use "force film" and that will give you 100% of the original film frames and that's the "best" option without any false positives, or any degradation due to PP

If it says anything other than 100%, it means there are other cadences (e.g. sometimes sections of the DVD have non 24000/1001 sections - e.g maybe titles, credits are common) , and you should honor pulldown flags and use field matching + decimation (IVTC). Some people don't mind if it's >99%, they just leave it

[Alwyn]

I'd be inclined to try ripping it with DVDDecrypter or DVDShrink.

[cholla]

I'd be inclined to try ripping it with DVDDecrypter or DVDShrink.

DVDShrink will usually error if it finds something wrong with a video.
I have found it to be a good tester even if you end up using a different software to do the rip.

[poisondeathray]

MakeMKV rip is probably ok in terms of frames, it just often produces buggy timestamps.

DGDecNV and/or DGMpgDec (on demuxed elementary video stream) don't care, because they index the actual video stream, looking at the byte offsets. They are basically not influenced by the bad timestamps because they pay more attention to the actual video data than timestamps

FFMS2, LSmash, BestSource are slightly influenced by timestamps. Easily correctable with AssumeFPS, assuming the decoded framecount is correct. Still these are slightly less reliable than DG tools

ffmpeg cares about buggy timestamps and is severely impacted by buggy timestamps. Everything in ffmpeg land runs off timestamps. You would need to fix the timestamps and/or use workarounds



DVD-Video as a standard does not support VFR. It's CFR encoded only. The content might be VFR (you can have functionally different fps sections, determined by repeated fields), but the presentation timestamps are always CFR as per the standard

Often what you get by using the MKV container is VFR "jitter" timestamps - because the MKV specs only allow 1/1000s timebase, the accuracy (only 1ms) and resolution is not high enough so you get rounded off timestamps. Frames display a bit longer or shorter than they should compared other containers with higher timebase resolution. Human eye cannot distinguish 1ms differences, so it's not a problem for a final format. Where it could become an issue is intermediate processing steps if you're not aware of the issue

[DeadSkullzJr]

I'd be inclined to try ripping it with DVDDecrypter or DVDShrink.

Are you implying that I create a new iso backup of the movie with either of these options or making an mkv video file from either of them? DVDShrink has consistency errors based on research, and DVDDecrypter while an option that I have used in the past, most of the research implies that I should stay away from it because it's outdated. MakeMKV was the recommended choice for stuff like ripping and making mkv video files from the iso images since the software is still being updated. Looking into other services out there, they all seem to charge a subscription or something of the sorts, I don't exactly have the flexible income to work under those conditions (let alone the fact that I do not like subscription services to begin with).

MakeMKV rip is probably ok in terms of frames, it just often produces buggy timestamps.

DGDecNV and/or DGMpgDec (on demuxed elementary video stream) don't care, because they index the actual video stream, looking at the byte offsets. They are basically not influenced by the bad timestamps because they pay more attention to the actual video data than timestamps

FFMS2, LSmash, BestSource are slightly influenced by timestamps. Easily correctable with AssumeFPS, assuming the decoded framecount is correct. Still these are slightly less reliable than DG tools

ffmpeg cares about buggy timestamps and is severely impacted by buggy timestamps. Everything in ffmpeg land runs off timestamps. You would need to fix the timestamps and/or use workarounds



DVD-Video as a standard does not support VFR. It's CFR encoded only. The content might be VFR (you can have functionally different fps sections, determined by repeated fields), but the presentation timestamps are always CFR as per the standard

Often what you get by using the MKV container is VFR "jitter" timestamps - because the MKV specs only allow 1/1000s timebase, the accuracy (only 1ms) and resolution is not high enough so you get rounded off timestamps. Frames display a bit longer or shorter than they should compared other containers with higher timebase resolution. Human eye cannot distinguish 1ms differences, so it's not a problem for a final format. Where it could become an issue is intermediate processing steps if you're not aware of the issue

So MakeMKV based video files are fine to use still? I wouldn't know a better alternative that can do any of the stream copying right from the iso images correctly, research kept pointing me to MakeMKV, so that is what I've been using. In the past I just ripped iso images and didn't do much else with them, that was back when DVDDecrypter was still the go-to, but I've been out of it for years and as such, a lot has changed, thus I kind of walked in with an empty slate with this stuff. Luckily I have studied up on videography already for some years now, thus I already acquired a lot of the knowledge necessary to perform most tasks. It's quite evident though that film is a rather different ballpark, and while I anticipated that I would learn much more from handling these things, let alone the potential difficulties, I definitely didn't anticipate the magnitude of processing film in these ways.

I do have a question though, FFmpeg seems to do a pretty decent job handling frames that have pulldown applied to them and such, I kind of want to replicate what FFmpeg does myself, but it never seems to spit out the commands it uses to make such results occur. Any idea on how I can sort out the exact commands it uses, I can maybe tie it in with the dgi index generated?

[_Al_]

Try to avoid using mkv - advice in first response in this thread, that you dismissed.
Back in days I used AnyDVD, just copied disks and then using DGIndex, like most, using it with Aisynth.

Googling AnyDVD equivalent today I got DVDFab as a response. Then wanting to buy it, DVD ripping (DVD copy) only, prices were not that high at all. You do not need al features it offers.
So go for something like that, getting a version of DVDFab that just creates a copy, while ripping DVD content.

Maybe there is something better than DVDFab, I do not know. But all you need is a ripper to get copy of your DVD, not necessarily ISO, just the whole structure, that is fine also, maybe even preferable.

Maybe this would be enough? https://www.dvdfab.cn/dvd-copy.htm it says, $42.50
others might say if it is enough.

[poisondeathray]

So MakeMKV based video files are fine to use still?

In my experience it's ok - in terms of the actual streams inside the MKV container. You can demux them and they will be bit identical as other methods. You just have to beware of the potential MKV container issues, and often buggy timestamps. You just have to know how to deal with it

It's quite evident though that film is a rather different ballpark, and while I anticipated that I would learn much more from handling these things, let alone the potential difficulties, I definitely didn't anticipate the magnitude of processing film in these ways.

Film is not a different ballbark. It's DVD NTSC telecine that might be confusing for some people - because of the various telecine methods used to make the film frames compatible with NTSC DVD-video standards

I do have a question though, FFmpeg seems to do a pretty decent job handling frames that have pulldown applied to them and such, I kind of want to replicate what FFmpeg does myself, but it never seems to spit out the commands it uses to make such results occur. Any idea on how I can sort out the exact commands it uses, I can maybe tie it in with the dgi index generated?

I don't understand what you're asking, because you have to enter the commands for FFmpeg - it's a command line application. Or is this some FFmpeg GUI that you're referring to ? If so , which one

If you're using dgi, then there is no reason to tie anything into ffmpeg except maybe to use it to encode

If your DVD is from a major Hollywood studio film release in the last 15-20 years, there is a 99.9% chance it's 100% soft pulldown.

From your sample - the dgi sasys 100% film, so jagabo was correct the sample is 100% soft pulldown

FPS 30000 / 1001
CODED 18231
PLAYBACK 22789
100.00% FILM

It's possible for other sections to be different. But if for the entire movie, it says 100% film, then it's 100% soft pulldown. End of story. You should disable PP if using IVTC (such as in TFM, or ffmpeg) , or use "force film" methods

[manono]

You completely left out all the other details and told me to do stuff that basically was already done. I already decrypted the iso images, and made mkv video files using MakeMKV. I stated that I can't use DGIndex because it gets stuck processing the mkv videos to make a d2v source index to work with

I left out nothing. For DGIndex it's always best to use VOBs as sources. Trying to use an MKV as a source is just inviting trouble.

There are workarounds that allow you to use MKVs as source files, as PDR pointed out. I for one much prefer to use the time-tested method of using DGIndex on VOB files. You have ISOs, so you mount them to expose the VOBs and then go to work. No need to ever create an MKV. It's just more work and often creates problems, as you discovered.

As pdr also mentioned, if the entire thing is 100% film you can use Forced Film and not have to IVTC at all.

[Alwyn]

Are you implying that I create a new iso backup of the movie with either of these options or making an mkv video file from either of them?

No, just rip the disk with them to VOBs, either into the VOB set or one single VOB.

I don't recall either having any trouble decrypting any-aged DVDs, latest releases or older. DVDs are old technology now.

DVDShrink has consistency errors based on research, and DVDDecrypter while an option that I have used in the past, most of the research implies that I should stay away from it because it's outdated.

They're both free. Given the problems you're having with the MKV, they are worth a try. Many of us use "outdated" software here.

You could also try converting your complete movie to MPG using AVIDemux as per my post #3 (Copy, Copy, MPEG-PS Muxer) to see if that cleared up any MKV issues.

[Alwyn]

if the entire thing is 100% film you can use Forced Film and not have to IVTC at all.

Could you explain "Forced Film"?

[DeadSkullzJr]

I don't understand what you're asking, because you have to enter the commands for FFmpeg - it's a command line application. Or is this some FFmpeg GUI that you're referring to ? If so , which one

If you're using dgi, then there is no reason to tie anything into ffmpeg except maybe to use it to encode

If your DVD is from a major Hollywood studio film release in the last 15-20 years, there is a 99.9% chance it's 100% soft pulldown.

From your sample - the dgi sasys 100% film, so jagabo was correct the sample is 100% soft pulldown

FPS 30000 / 1001
CODED 18231
PLAYBACK 22789
100.00% FILM

It's possible for other sections to be different. But if for the entire movie, it says 100% film, then it's 100% soft pulldown. End of story. You should disable PP if using IVTC (such as in TFM, or ffmpeg) , or use "force film" methods

I asked because when testing between Robots and the second film, FFmpeg seems to automatically run extra functions outside the intervention of my commands when encoding them. Example, if I encoded the entirety of the Robots movie using libx264 as the codec, it automatically does pulldown removal work on the frames and even decimates automatically to 23.976 (not that I'm implying the codec itself is doing that, just specifying what I was encoding into). Neither of which I specified to do in the command I typed out. Part of what confused me is when I tested with the second film, which had the same thing happen, except it was stuck at 24.000 FPS rather than 23.976 FPS, and still had a frame or so where there was apparent interlacing (likely mishandled due to the MKV video itself). I took the second film and generated an index using DGDecNV, even the demuxed result was 24.000 FPS, which confused me further because that didn't seem right. Proceeding further led me down to trying TFM and TDecimate from TIVTC for AviSynth, besides the PP being left on due to my misunderstanding, it looked like it worked, except there were noticeable skips during motion in some instances, which clearly meant something was wrong. I didn't think being in the MKV container was an issue, considering it's a container used for multiple codecs, between that and MP4, both are used pretty widely, so I didn't think much of it. I didn't think to use the VOB video files as manono and Alwyn suggested earlier. So I'm trying that out now as we speak. I just wanted to know if there was a way to see what FFmpeg was doing completely considering I found what it was doing interesting.

Might as well ask while I'm here, what would I have to do if by chance I run into a film that isn't considered 100% by DGDecNV? The second film was 99.68% or something along the lines when looking at the index. Could be an error due to me using the MKV video as the source rather than the VOB, but I'm sure there is a chance that even if I use the right source, it could still happen, so might as well ask.

[poisondeathray]

I asked because when testing between Robots and the second film, FFmpeg seems to automatically run extra functions outside the intervention of my commands when encoding them. Example, if I encoded the entirety of the Robots using libx264 as the codec, it automatically does pulldown removal work on the frames and even decimates automatically to 23.976 (not that I'm implying the codec itself is doing that, just specifying what I was encoding into). Neither of which I specified to do in the command I typed out.

FFmpeg can perform a lot of auto conversions. You can add -report to see more details

What was your command line ,and what was the direct input ? The 1st post implies it was DGSource only 1 line, as avs input into ffmpeg

Part of what confused me is when I tested with the second film, which had the same thing happen, except it was stuck at 24.000 FPS rather than 23.976 FPS, and still had a frame or so where there was apparent interlacing (likely mishandled due to the MKV video itself).

According to what procedure? Direct mkvinput into ffmpeg? What was the command line ?

I took the second film and generated an index using DGDecNV, even the demuxed result was 24.000 FPS, which confused me further because that didn't seem right.

According to what? Not DGSource. Not avisynth. I doubt your account of those events, or you've mixed something up, or you've missed conveying some other details. Look at the .dgi, there is no way it said 24.000 FPS. 0% chance. It's not supported by DVD-Video

Proceeding further led me down to trying TFM and TDecimate from TIVTC for AviSynth, besides the PP being left on due to my misunderstanding, it looked like it worked, except there were noticeable skips during motion in some instances, which clearly meant something was wrong. I didn't think being in the MKV container was an issue, considering it's a container used for multiple codecs, between that and MP4, both are used pretty widely, so I didn't think much of it.

Assuming it was ripped correctly, as mentioned above, MKV doesn't matter for DGSource . You're doing something wrong, or you've misconveyed some information if this was all film source

But skips might be "normal" if you had content other framerates and you used standard IVTC to a single constant frame rate e.g. you might have mostly film sections at 23.976p but there might be some CG or animation scenes at 29.97p. There might be truely interlaced content in some sections (should be double rate deinterlaced to 59.94). Those latter ones will jump or skip because 23.976 means dropped frames for those sections. You can make it VFR to express all types of content framerates - use search this is discussed on various forums with guides

Might as well ask while I'm here, what would I have to do if by chance I run into a film that isn't considered 100% by DGDecNV? The second film was 99.68% or something along the lines when looking at the index. Could be an error due to me using the MKV video as the source rather than the VOB, but I'm sure there is a chance that even if I use the right source, it could still happen, so might as well ask.

It means it's not 100% soft pulldown. There could be some hard telecine (still 3:2) , or some mixed content.

[DeadSkullzJr]

FFmpeg can perform a lot of auto conversions. You can add -report to see more details

What was your command line ,and what was the direct input ? The 1st post implies it was DGSource only 1 line, as avs input into ffmpeg

Performing this on the Robots movie yielded a 23.976 FPS video, and for the other movie it yielded 24.000 FPS.

ffmpeg.exe -i "...\video.mkv" -map_chapters -1 -c:v libx264 -c:a copy -c:s copy -preset placebo -crf 0 "...\video.mp4"

As for the AVS script version, specifying DGSource whilst having TFM and TDecimate enabled also yields 23.976 for the Robots movie, however when this was used on the second movie, there were noticeable frame cuts in some places that shouldn't have lost frames, most particular were scenes with motion, which clearly meant it wasn't right, implying that 24.000 FPS was still the target.

ffmpeg.exe -i "...\script.avs" -i "...\video.mkv" -map 0:v -map 1:a -map 1:s -c:v libx264 -c:a copy -c:s copy -preset placebo -crf 0 "...\video.mp4"

According to what procedure? Direct mkvinput into ffmpeg? What was the command line ?

Direct mkvinput into FFmpeg, first command listed above yielded the result explained.

According to what? Not DGSource. Not avisynth. I doubt your account of those events, or you've mixed something up, or you've missed conveying some other details. Look at the .dgi, there is no way it said 24.000 FPS. 0% chance. It's not supported by DVD-Video

When I encoded and combined the segmented demuxed m2v files produced by DGDecNV using FFmpeg, it still yielded 24.000 FPS (I didn't specify a specific frame rate at all). Guess I should have worded what I said better. Using any form of decimation during or after the process, regardless of FFmpeg or TDecimate via AviSynth, still yields the issue mentioned in the first comment about 23.976 showing noticeable cut frames where frames should exist, it's not supposed to have jumps. From what I understand, only the duplicate frames are supposed to be cut, not unique frames.

Assuming it was ripped correctly, as mentioned above, MKV doesn't matter for DGSource . You're doing something wrong, or you've misconveyed some information if this was all film source

I used MakeMKV to make the decrypted iso backups, I have these so I can burn discs for players that don't have access to USB ports and such for direct video streaming. I also utilized MakeMKV to make mkv video files using the decrypted iso images since it's much faster than making one while running a disc in the drive. It combines the respective segmented vob video files together and performs a stream copy straight into the mkv container, hence why it's kind of weird to me that the container is an issue apparently. Playing the movies as-is seems to work fine with no desyncs.

Side note, MakeMKV gives an interesting popup when I attempted to make an MKV from a backup that wasn't made by me in the past. Whether or not what the popup says is true, I have no clue since I haven't used anything outside of MakeMKV other than DVDDecrypter in the past for my DVDs. Forgot I had the snip still, figured I would post it here on the subject matter of mkv video backups.

[Attachment 83960 - Click to enlarge]

But skips might be "normal" if you had content other framerates and you used standard IVTC to a single constant frame rate e.g. you might have mostly film sections at 23.976p but there might be some CG or animation scenes at 29.97p. There might be truely interlaced content in some sections (should be double rate deinterlaced to 59.94). Those latter ones will jump or skip because 23.976 means dropped frames for those sections. You can make it VFR to express all types of content framerates - use search this is discussed on various forums with guides

It doesn't feel normal though considering one of the scenes in question where a frame cut happens involves a person turning their head to the left, in the 24.000 FPS encoded video it's fine, but in the forced 23.976 version, a frame is missing and it makes the person's head turning make a sudden jump, and it's noticeable at normal speed, it isn't the only scene where there are sudden frame jumps occurring, but it is one that sticks out, and that to me doesn't seem normal at all. Aren't these things supposed to be constant anyways and not variable?

It means it's not 100% soft pulldown. There could be some hard telecine (still 3:2) , or some mixed content.

Is this able to be fixed? Probably by hand I would assume, I have had to do frame repairs on normal videos in the past, so this wouldn't be out of the ordinary if true.

Also sorry if I am coming off annoying, it isn't the intentions.

[poisondeathray]

Performing this on the Robots movie yielded a 23.976 FPS video, and for the other movie it yielded 24.000 FPS.

ffmpeg.exe -i "...\video.mkv" -map_chapters -1 -c:v libx264 -c:a copy -c:s copy -preset placebo -crf 0 "...\video.mp4"

Recall that the 1st one is 100% soft telecine. If you ignore the repeat field flags - you get a perfect 23.976 . That might be what ffmpeg is doing. However, I would double check the output for buggy timestamps (maybe some of the timestamp errors were introduced from cutting the sample, not on the full movie) .

Beware that method has potential issues if you have a mixed content DVD, or broken cadences, or hard telecine

As for the AVS script version, specifying DGSource whilst having TFM and TDecimate enabled also yields 23.976 for the Robots movie, however when this was used on the second movie, there were noticeable frame cuts in some places that shouldn't have lost frames, most particular were scenes with motion, which clearly meant it wasn't right, implying that 24.000 FPS was still the target.

Post a sample of the 2nd source

When I encoded and combined the segmented demuxed m2v files produced by DGDecNV using FFmpeg, it still yielded 24.000 FPS (I didn't specify a specific frame rate at all).

Did you mean mean input m2v elementary stream directly into FFmpeg

Guess I should have worded what I said better. Using any form of decimation during or after the process, regardless of FFmpeg or TDecimate via AviSynth, still yields the issue mentioned in the first comment about 23.976 showing noticeable cut frames where frames should exist, it's not supposed to have jumps. From what I understand, only the duplicate frames are supposed to be cut, not unique frames.

But skips might be "normal" if you had content other framerates and you used standard IVTC to a single constant frame rate e.g. you might have mostly film sections at 23.976p but there might be some CG or animation scenes at 29.97p. There might be truely interlaced content in some sections (should be double rate deinterlaced to 59.94). Those latter ones will jump or skip because 23.976 means dropped frames for those sections. You can make it VFR to express all types of content framerates - use search this is discussed on various forums with guides

It doesn't feel normal though considering one of the scenes in question where a frame cut happens involves a person turning their head to the left, in the 24.000 FPS encoded video it's fine, but in the forced 23.976 version, a frame is missing and it makes the person's head turning make a sudden jump, and it's noticeable at normal speed, it isn't the only scene where there are sudden frame jumps occurring, but it is one that sticks out, and that to me doesn't seem normal at all.

Could be "normal" in the sense that content the frame rate for that section might be higher. If you "force" 23.976, you are dropping frames, so there are jumps and gaps in motion.

Examine that section either with separated fields, or a double rate deinterlacer applied and advance frame by frame. You can preview script in avspmod or vdub2. "normal" film content will look like 3 duplicates, 2 duplicates, 3:2:3:2 ..... A 29.97p section would look like duplicates. A 59.94 section would have motion every step

Side note, MakeMKV gives an interesting popup when I attempted to make an MKV from a backup that wasn't made by me in the past...

Not sure, but if that was for #2, that could explain the problems

It means it's not 100% soft pulldown. There could be some hard telecine (still 3:2) , or some mixed content.

Is this able to be fixed? Probably by hand I would assume, I have had to do frame repairs on normal videos in the past, so this wouldn't be out of the ordinary if true.

Depends what's causing it. For that small%, most people would ignore it or use adaptive IVTC (just the TFM/TDecimate route, +/- custom settings, possibly overrides)

[manono]

Could you explain "Forced Film"?

In DGIndex, Video->Field Operation->Forced Film.

The idea is if the DVD consists entirely of progressive 23.976fps content with soft pulldown, you can get back the progressive 23.976fps without performing an IVTC.

It's best to have 100% Film before doing that. Open the D2V in Notepad and look at the very bottom. It might still work anyway, without leaving behind any interlaced frames. But only if the film percentage is very high (99%+) and the video portions are in black frames, maybe at the very beginning.

There's a complete and very good guide to using DGIndex here:

https://www.afterdawn.com/guides/archive/using_dgindex.cfm