Doom9's Forum - View Single Post

hello_hello · 18th October 2016, 16:51

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:

18th October 2016, 16:51	#7 \| Link
hello_hello Registered User Join Date: Mar 2011 Posts: 4,829	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: Last edited by hello_hello; 19th October 2016 at 01:17.