Need help with VFR encoding

[cloaknsmoke]

I have a video (anime) that has a 30fps opening, but the rest of the show is 24fps. I'm using TFM to field match, and I am trying to follow the guide on the avisynth wiki for vfr using TDecimate. I output the stats files and am encoding using mode 5 and outputting timecodes. My issue is that I played a little bit of the video and the timecodes that were output seem to want to play the opening at 24fps. I didn't play through the whole video, so maybe that was just incomplete output or something, but can someone tell me if I'm doing something wrong?

My other idea was to encode the opening and other parts of the video separately. I would do both as cfr and then use mkvtools to append the video part to the opening which would automatically create a vfr video (I think).

Any thoughts on the matter would be helpful.

[Motenai Yoda]

play with vidDetect in tdecimate

also you can trim op/ed and use tdecimate only on the main video
then op+video+ed and manually* create timecodec file

*or using avisynth's WriteFileStart

[cloaknsmoke]

Alright, let's say I go with the timecodes method. I can't seem to find an adequate specification for the construction of a timecodes file anywhere on the internet. I can extract timecode_v2 from an existing mkv just fine, but if I'm going to programatically generate timecodes, I need to know what I'm dealing with before hand. The mkv specifications don't talk about a timecodes text file. It talks about the concept of timecodes relative to blocks and such as xml which the timecodes file is not.

[sneaker_ger]

https://mkvtoolnix.download/doc/mkvm...timecode_files

timecode_v1 is more helpful when writing one by hand.

[AzraelNewtype]

If you're positive about the 30fps being all of the OP and nothing else, do not try tweaking the automatic vfr settings in tdecimate. Just write an override file that sets the frames that comprise the OP to video (the syntax is "firstframe,lastframe v", inclusive, see the tdecimate docs for further details) and use its mkvOut parameter to generate the timecodes. I believe that gives v2, which is ugly but you didn't have to write it yourself so whatever.

Allowing the plugin to determine what is truly video and what isn't can only lead to false positives/negatives, or a lot of trial/error to make sure you got the search thresholds right, and if you already know which frames need to be kept that's just a waste of your time. This is only ever a good idea if the content is very mixed, such that it's a huge problem to manually override. A single line (which may be identical for every episode if the show doesn't have cold opens) is not particularly onerous.

[cloaknsmoke]

I thought this was going to be a huge problem, so automating the process would have been useful. It turns out that I will only have to use manual timecodes on 3 episodes. The show was transitioning from 30fps to 24fps it seems. They rendered the meat of those 3 episodes at 24fps and the openings which were already established by that point retained the 30fps rate. After that, there's a new OP so everything is simple. Thanks for your help everyone.

[hello_hello]

I'm glad this thread popped up as recently I was experimenting with encoding some NTSC DVDs as variable frame rate (I live in PAL-Land so I don't play with a lot of NTSC) and I was quite happy with the result, but I still have a few questions to make sure I was doing it right.

I used the timecodes file to encode in variable frame rate mode rather than encode at a constant frame rate and mux the output with a timecodes file to make it variable again. I suspect encoding as variable frame rate might technically be better as the encoder knows how long each frame will be displaying.
The method I used was as follows (without the blue text originally... see below).

Analysis pass:
tfm(output="D:\TFMepisode 1.txt").tdecimate(hybrid=2, mode=4, output="D:\Episode 1.txt")

Encoding pass:
tfm(batch=true).tdecimate(hybrid=2, mode=5, input="D:\Episode 1.txt", mkvOut="D:\Episode 1 timecodes.txt", tfmIn="D:\TFMepisode 1.txt", batch=true)

For the encoding pass, I added the following to the x264 command line:
--tcfile-in "D:\Episode 1 timecodes.txt"
The timecodes file doesn't need to exist prior to starting the encoding pass. It's created as soon as the script is opened.

The TIVTC help file says TDecimate's mode=5 requires a tfmIn file from TFM. Then is says it doesn't, but.....
"If a tfmIn file is not specified then all matches are assigned as 'c', not combed, and not a d2v duplicate"
What I wasn't totally clear on, is whether TDecimate can use the hints from TFM for mode=5. The info explaining how the hints work doesn't specify.
Before I discovered TDecimate's Batch option, I ran the encodes as above minus the blue text, which means without the tfmIn file and therefore no need for batch mode, but while the result seemed fine for my recent encodes would it be safe to assume using a tfmIn file is a better idea?

The other thing I've not got my head around yet is how the timebase works. I can't remember exactly what I tried, but while it doesn't normally seem to effect the playback of the encoded video, the timebase used can effect what ReClock does. From what I've seen so far, when playing a variable frame rate NTSC encode, ReClock switches between reporting two constant frame rates for the source... ideally 23.976 and 29.970, and when that's viewed on a 60Hz display all is good. Any adjustment to playback speed remains constant.

Should I be specifying a particular timebase all the time? Here's an example of why I ask. I encoded a small section of a DVD as variable frame rate which happened to be 100% "film". It plays back perfectly but ReClock can no longer do it's thing as it sees the frame rate as 119.881fps. The x264 encoder chose the timebase.

[Information] [19/10/16 12:58:00 AM] timecode [info]: automatic timebase generation 1001/120000

Mostly for variable frame rate NTSC encodes, x264 chooses a 1/1000 timebase and the frame rates reported by ReClock make sense, so I thought I'd go with that, but the result for this test encode isn't what I expected. Is there a magic, one size fits all timebase?
I haven't tried testing it yet, but how does the timebase work if you encode a variable frame rate source at a constant frame rate and use a timecodes file when muxing to make the output variable again?

Thanks.

Timebase 1001/120000:



Timebase 1/1000:

[hello_hello]

I still haven't quite got my head around what the x264 help file says in relation to setting a timebase Vs the timebase it sets or the timebase required.

http://www.chaneru.com/Roku/HLS/X264...s.htm#timebase
The numerator is 'seconds', and the denominator is 'ticks'. Means how many seconds one tick takes.
If passed a rational, it will set the numerator and denominator accordingly.
If passed an integer, and an input timecodes file is set via tcfile-in, it will use the value passed as the numerator, and generate the denominator accordingly.
If passed an integer, and no input timecodes file is set, it will use the value passed as the denominator and generate the 'ticks per frame' from the input video.

I think I was wrong with my initial assessment of what ReClock was doing. Unless the timebase used is incorrect for the video in question, ReClock does seem to settle down eventually and display the correct frame rate, even if initially it displays the wrong frame rate or shows it's trying to estimate it.

The frame rate of the script seems to effect the timebase chosen by the x264 encoder (and the script frame rate appears to be the average frame rate) but the only time ReClock didn't settle down to displaying the correct frame rate or playback wasn't smooth was when I specified a timebase for the encoder myself that probably didn't make sense, so the moral of the story seems to be, give x264 the timecodes file and let it choose the timebase.