Variable Framerate Ouput (Avisynth)

[Vaengence]

I have a small question, as I don't know if this is normal or I am doing something wrong.

I am trying to do some processing through Avisynth of VFR files that were NTSC to start with (old Star Trek DVD's as a reference), but I am getting discrepancies on the displayed VFR stats between the input and output files.

I am following the general guide for IVTC VFR using Two Step, (TFM/TDecimate), getting an output MKV timecodes file and muxing everything fine - the video seems to play fine but seems choppy at times.

I noticed on the last episode that DGIndex, which I run it through to generate the D2V file for inport, says the following in the stats:

D:\Video\NTSC Season 4\Disk 2\Episode 6\VTS_03_1.VOB

Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=4:3
Picture_Size=720x480
Field_Operation=0
Frame_Rate=29970 (30000/1001)
Location=0,0,0,e4404

FINISHED  87.22% FILM

Which indicates 87.22% Film. When I finish generating the Timescodes file for MKV, it says the following:

# timecode format v1
Assume 29.970030
# TDecimate v1.0.6 by tritical
# Mode 5 - Auto-generated mkv timecodes file
# vfr stats:  98.94% film  01.06% video
# vfr stats:  81769 - film  875 - video  82644 - total
# vfr stats:  longest vid section - 50 frames
# vfr stats:  # of detected vid sections - 72

Which is indicating a significantly higher 98.94% film.

I am wondering if this is also why I notice stuttering occasionally. My main question is whether this large discrepancy matters? Am I doing something wrong with the process or is this normal or a mistake of one of these files reporting wrong?

The actual two step code being used for reference is (without all the filters etc on the output cluttering it up as its the same output metrics):

First Pass:

D2VSource("D:\Video\Voyager\S04E06 Demuxed\VTS_03_1.d2v")

SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)


#Pass 01
    tfm(d2v = "D:\Video\Voyager\S04E06 Demuxed\VTS_03_1.d2v", mode = 1, output="D:\Video\Voyager\S04E06 Demuxed\tfm_out.txt")
    tdecimate(mode=4, output="D:\Video\Voyager\S04E06 Demuxed\tdecimate_metrics.txt")

Second Pass:

D2VSource("D:\Video\Voyager\S04E06 Demuxed\VTS_03_1.d2v")ConvertToYV12()
  Checkmate()
  Bifrost(interlaced = True)
  
  tfm(input="D:\Video\Voyager\S04E06 Demuxed\tfm_out.txt")
  tdecimate(mode=5, hybrid=2, cycleR=1, vfrDec=0, input="D:\Video\Voyager\S04E06 Demuxed\tdecimate_metrics.txt", tfmIn="D:\Video\Voyager\S04E06 Demuxed\tfm_out.txt", mkvOut="D:\Video\Voyager\S04E06 Demuxed\timestamps.txt")

       

   
Spline16Resize(720,540)

[LigH.de]

"Variable Frame Rate" is something completely different than a probability of Telecine detection. VOB as DVD Video compliant source has a constant frame rate (NTSC: 29.97 fps). I would not recommend VFR handling, only based on a more or less accurate detection of Telecine patterns.

[Vaengence]

I don't know if i entirely follow what that meant, but if I am understanding somewhat, hopefully this reply is coherent.

These DVD's, as with all from that period, are all VFR, with mixtures of 23.976 portions and 29.97 sections of CGI. Normal decimation for IVTC will leave the filmed portions fine, but the CGI ones will become choppy. I can blend decimate those to try to smooth them out, but its not perfect. I can also try the opposite and blend convert them up, but there are issues with that as well.

I have read pages and pages and pages of people trying to deal differently with these DVD's and what they prefer. There is a whole thread on Doom9 with people arguing over the best way to deal with the mixed footage, with no real apparent agreement.

What I was trying to do, and was my understanding was possible, was rather than blend sections and lose quality, or make the video choppy in sections, that I could do some processing on the footage and re-make the original VFR for the sections so that it would maintain the original temporal resolution without causing additional artifacts, or problems on playback.

I admit, the number of posts and directions on how to do that with VFR seem few and far between, and the guides I have found usually just end up being literally process using the scripts above and re-mux the MKV with the timecodes - I have not been able to find any other guides explaining or going into options on how to do it. Hence why I was wondering if I was doing something wrong, or why exactly the difference in the original and ouput.

I am also no expert on these scripts - what you said might make sense, but I am not entirely following what it was you were trying to say, sorry.

[LigH.de]

Oh, right, I forgot mixed "Film with computer animations". Well, that is indeed an issue. Most of all, safely detecting the animated scenes which don't need IVTC. I doubt you can fully automate it without worrying.

I'll leave better advises to more experienced members now...

[jagabo]

NTSC DVD is always constant field rate -- 60 fields per second (for brevity I'm going to round all the numbers here). That can be sourced from 0 to 30p with hard pulldown, 24p to 30p with soft pulldown, 30p or 30i (60 fields per second). If you index the MPEG2 video with "honor pulldown flags" then bob (QTGMC, interleaved TFMs, etc.) to 60p you will get as smooth playback as the original DVD. You'll still get pulldown judder, just like the DVD.

Otherwise you'll have to split the video into sections, 24p, 30p, 30i, treat them individually, and encode VFR.

[hello_hello]

I have a small question, as I don't know if this is normal or I am doing something wrong.

I am trying to do some processing through Avisynth of VFR files that were NTSC to start with (old Star Trek DVD's as a reference), but I am getting discrepancies on the displayed VFR stats between the input and output files.

DGIndex refers to any sections with repeat field flags (soft telecine) as film, and everything else as video, so film sections with encoded telecine fields aren't reported as film. TIVTC should inverse telecine any sections with encoded telecine fields though, restoring the original film frames, and eventually report therm as being film, so the discrepancy isn't necessarily a bad thing. If a source was 100% hard telecine, DGIndex would report it as 100% video, but TIVTC should still apply inverse telecine and output 100% film.

I am following the general guide for IVTC VFR using Two Step, (TFM/TDecimate), getting an output MKV timecodes file and muxing everything fine - the video seems to play fine but seems choppy at times.

While I'm thinking about it, if you're encoding with the x264 encoder, it can encode in variable frame rate mode. You just need to give it the timecodes file to play with. The command line option is --tcfile-in, so you'd add something like this to the command line.
--tcfile-in "D:\Video\Voyager\S04E06 Demuxed\timestamps.txt"
I don't know if the x265 encoder has a similar command line option for a timecodes file.

I think at some stage someone decided to change the timecodes name to timestamps, so if x264 rejects the timecodes, try changing the very fist line:
# timecode format v1
to this:
# timestamp format v1

When you encode as VFR, x264 will choose an appropriate timebase, which might help with playback. If x264 is writing directly to MKV, there's no need to add the timecodes file when muxing. For a raw AVC stream you might have to.... I can't remember.

The scripts you posted have Checkmate and Bifrost before TFM and TDecimate for the second pass, but not the first. You may have simply omitted them from the script you posted, but just in case.... any filtering you add before TFM should be there for both passes. Filtering following TIVTC can be left off for the first pass. The addition of Checkmate and Bifrost indicate a noisy source that might confuse TIVTC, even if you're not doing VFR encoding. Try chroma=false and denoise=true for TDecimate. If they don't make a difference, maybe upload a sample of the source. A small section that stutters after encoding will do.

Below is a small VFR sample. See if it plays okay, just to eliminate the problem being on the playback end.
QTGMC did the de-interlacing for TFM, because the source is somewhat hard to de-interlace in parts. I've also attached the function I used for automatically naming the metric and timecode files. As long as each episode you encode has a unique name, so will they. It takes a lot of the drudgery out of creating scripts.

Edit: One other thought.... and assuming you're using MKVToolNix for muxing.
If you don't give x264 the timecodes file for VFR encoding, the video is encoded at the average frame rate (as Avisynth has to output a constant frame rate) but later you're muxing with a timecodes file to make it VFR, so the video stream and MKV container would have different timing info. I doubt it's the problem, but if you don't show x264 the timecodes file, try checking the MKVToolnix "Fix bistream timing info" option when muxing, just to see if it makes a difference.

LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\drawn.d2v")

DeintClip=QTGMC(FPSDivisor=2)

# 1st pass
# TFM(Output=FTFM(), Clip2=DeintClip)
# TDecimate(Mode=4, Hybrid=2, Output=FTDec())

# 2nd pass
TFM(Input=FTFM(), Clip2=DeintClip)
TDecimate(Mode=5, Hybrid=2, Input=FTDec(), TFMIn=FTFM(), mkvOut=FTC())
CropResize(0,0, 4,2,-4,-2, InDAR=15.0/11.0, ResizeWO=true)

[Vaengence]

DGIndex refers to any sections with repeat field flags (soft telecine) as film, and everything else as video, so film sections with encoded telecine fields aren't reported as film. TIVTC should inverse telecine any sections with encoded telecine fields though, restoring the original film frames, and eventually report therm as being film, so the discrepancy isn't necessarily a bad thing. If a source was 100% hard telecine, DGIndex would report it as 100% video, but TIVTC should still apply inverse telecine and output 100% film.

This makes sense thanks. I think I also managed to visually verify this as well. After seeing the discrepancy and doing some more checking since the first post, I noticed that visually inspecting the frames showed the familiar 3:2 pattern just about all sections I looked at. I am guessing that, and now based on your explanation, that the CGI elements on this episode are hard telecined and the filmed sections are soft telecined which would explain the difference and why, in the end, it looks like most CG sections also had the 3:2 pattern visually.

I think the only section that (in this episode) were not telecined were the end credits in which I saw no indication of interlacing on any frames and suspect it was playing back at its native 29.97 and account for the final 1% or so of "video"

This segue's into an interesting theory or discussion on how these episodes were encoded. I know for a fact (at least many people have discussed it including people that said they were involved in the CG creation) that the CGI elements were originally produced in 29.97 which is where the VFR of many episodes comes from (the mix of the live and CG elements), but I have also noticed that not all CGI elements are visually showing that - it seems to change from episode to episode.

A good example is if I go to Episode 1, which has several types of mixed footage, I can clearly see progressive 29.97 frames in the opening CG section, going immediately into 3:2 frames when the filmed section starts - BUT - the opening titles sequence that plays in every episode, which is CG, is ALSO 3:2 telecined, not 29.97 progressive. This appears to be the same in the current episode.

This would suggest that the opening titles have always been 23.976 on the DVD's - and might explain why the titles are the biggest culprit of the "choppyness" I keep seeing. I suspect (as I can only guess) that if all CG was originally created in NTSC 29.97, then sometime before it was encoded to DVD, it was converted to 23.976 - maybe to make it easier to splice into the episodes easily (?). Ultimately I am just guessing.

The scripts you posted have Checkmate and Bifrost before TFM and TDecimate for the second pass, but not the first. You may have simply omitted them from the script you posted, but just in case.... any filtering you add before TFM should be there for both passes. Filtering following TIVTC can be left off for the first pass. The addition of Checkmate and Bifrost indicate a noisy source that might confuse TIVTC, even if you're not doing VFR encoding.

I always assumed that the first pass was just to generate guides for the decimation on the second pass and all filters go into the second pass. I shall have to remember that thanks.

The source in the early seasons has some significant artifacting that's very distracting. The episode I am doing at the moment doesn't have the best examples of it, but you can kind of see it in the screenshot here:

https://puu.sh/HLARK/965af55ecc.png

Specifically, the checkerboard pattern on the horizontal light areas. It is notoriously bad on these panels in Voyager and as it is Voyager, these panels appear a lot. My biggest issue with these, is I have tried every form and filter of dot crawl removal and none of it makes a dent.

I can turn up the settings on some of these filters to drastic levels and it never makes much difference. This suggested to me that maybe I was misreading what the artifacts were - I happened to use Santiag on one of these sections with custom adjustments (santiag(nns = 4, nsize = 6, strv = 4, strh = 5)) and about 80% of it disappeared. This is leading me to believe its more an aliasing issue than a dot crawl issue.

If your curious, I can upload a really good short clip of a section that has very obvious artifacts of these kinds which you can play with if you think you have a better option - only if you feel like it though, no stress.

[hello_hello]

I have encodes of the Voyager series, but I encoded them so long ago I can't remember if the DVDs were NTSC or PAL. Next time I see my sister I'll try to remember to check them out, as they're hers, but I live in PAL-land so unless there was a shortage of PAL DVDs when she bought them, I didn't have to worry about 3:2 pull-down problems for my encodes.

The problem with telecine and interlacing is...... DVDs were intended as an interlaced format to be viewed on an interlaced display (CRT TV) and early DVDs were often created under that assumption, as progressive-scan DVD players and progressive displays didn't exist.
It's not uncommon for a telecined DVD to have the occasional "orphaned" field, due to editing in the middle of a 3:2 cadence, and it's not uncommon for the 3:2 pattern to change due to editing. As far as 90's effects and CGI go, it's often not quite as simple as dividing the DVD into film and video sections because some sections can be both. If I remember correctly, the opening sequence for Deep Space 9 fades between shots in a few places (the last second or so of one shot is blended into the beginning of the next), but the 3:2 pattern for the blended frames doesn't "line up", so to speak. CGI can cause problems when it's overlaid on telecined film, and interlaced scrolling credits over a moving telecined picture is a fun one. I think AnimeIVTC has a special mode for dealing with that. What should happen for sections with interlaced content overlaid on telecined film, is TIVTC should treat it as interlaced and de-interlace for 29.97fps, but maybe it's getting it wrong now and then because the source is noisy. I'd need a sample to try to work out the cause of the stutter, but have you tried again using Checkmate and Bifrost for both passes?

I know nothing about how Voyager was made, but back in the 90's and early 2000's it was still common for special effects to be added after transferring the film to video tape, because it was cheaper, and it's no doubt why converting DVDs from that error to a progressive output can sometimes be challenging.

Do the end credits scroll? If they're static and there's nothing happening underneath, they'll probably be treated as"film" and decimated for 23.976fps progressive.

I'll have a play with a sample if you upload one, but jagabo is probably the artefact fixing expert, should he return.

[colonel0812]

I'm working with DS9 right now in Adobe, and I have a workflow to basically manually IVTC, and it is somewhat tedious. What it looks like to me is that when you play the DVD, it plays at a constant 29.97fps, but there are flags that switch the playback between 3:2 pulldown (29.97 interlaced footage) and 2:2 pulldown (23.976 progressive footage). I think this is is the case because when I do a straight conversion, interpreting the DVD as progressive, the 23.976 sections are faster than the 29.97 interlaced sections.

So basically to perform an IVTC, I convert the whole episode to 29.97p. Then I make 6 different interpretations: 1 that is simply slowed down to 23.976p, and 5 that are set to remove pulldown, one for each cadence. Then I manually scrub through the 23.976p footage, and replace any sections that show interlacing with the pulldown removed version with the correct cadence. It takes a long time, but as long as I find them all the result is perfect and lines up perfectly with the audio.

I would love to know if there is a better way. At the very least, something that could spit out timestamps or frame numbers of where the changes occur. Mostly it occurs during CG sequences, and whenever there are generated titles. Some episodes have stretches where the pulldown switches for 3-7 frames before and after every scene edit, and it's a massive pain to find and fix them all.

Another thing worth noting is that in the end credits, the frame rate is a true 29.97p, but the upper and lower fields are off a full frame from each other.

[manono]

I would love to know if there is a better way.

I doubt there's a worse way. If you've followed the thread so far, then you should know AviSynth is the way to go. IVTC the hard and soft telecined parts and then decide what to do with the true 29.97fps parts.

Another thing worth noting is that in the end credits, the frame rate is a true 29.97p, but the upper and lower fields are off a full frame from each other.

A simple TFM from the AviSynth IVTC called TIVTC will bring that back to progressive 29.97fps. Again, though, you'd have to decide what to do with it. As jagabo suggests earlier in the thread, using a good bobber on the entire thing is certainly the easiest - and perhaps the best - way to handle it. Personally, I have no use for VFR.

[jedard@hotmail.com]

Can anyone tell me if an in-car dashboard camera system that the fps is selected and set can actually record at a variable rate? Also, if a system has rates of 7.5/15/30 fps how could a one second clip have a fps of 115?

[Selur]

Probably just messed up time codes. Share a sample or remux the file without the time codes and check whether it's async or not.