Hybrid PAL Source (prog. and int.) to VFR Matroska-File

[ToS_Maverick]

hello!

i'm currently searching for good avs-settings, to backup my Babylon 5 episodes from dvd to matroska-files.

the source is PAL-DVD. the animations are interlaced while the rest of the material is film. i'd like to deinterlace the animations with TDeint to 50 fps, to keep the smooth motion, but i want the film-material to stay at 25 fps.

the way i wanted to achieve this, is to deinterlace the animations and double the film-parts:
TDeint(mode=1,full=false)

and then drop the doubled film-frames with tdecimate:
tdecimate(mode=3,hybrid=2,vfrDec=0,mkvOut="mkv-timecodesfile.txt")

but this won't work. i couldn't find another thread which covers this topic :(

another problem i have is, that TDeint doesn't recognise progressive frames very well. it very often interpolates the duplicate, which is then hard to decimate. i tried to fiddle with the thresholds, but that didn't work.

i'd very much appreciate any help, as VFR currently is a book with seven seals for me ;)

[berrinam]

Why don't you try following TDeint by DeDup (it's on warpenterprises's filter list at avisynth.org)? That finds duplicates and removes them, outputting a matroska timecode file.

[tritical]

Yeah, you don't need tdecimate here... its hybrid modes are for mixes of 24/30 where you need to either remove 1 frame in 5 and adjust the framerate of the remaining four frames or leave all 5 frames as they are. Dedup will do what you want (take 2 frames at 50fps where the 2nd is a duplicate and output 1 frame at 25fps).

another problem i have is, that TDeint doesn't recognise progressive frames very well. it very often interpolates the duplicate, which is then hard to decimate. i tried to fiddle with the thresholds, but that didn't work.

TDeint's combed frame detection is tuned to be pretty sensitive so that it errors on the side of caution when tryweave=true or full=false is used. For comparision here are the defaults for all settings that effect combed frame detection in TIVTC/TDeint (they use the same detection routine).

parameter: TDeint_default, TIVTC_current_default, TIVTC_old_default
cthresh: 6, 9, 10
MI: 64, 80, 100
chroma: false, false, false
blocky: 16, 16, 16
blockx: 16, 16, 16

TIVTC's defaults are less sensitive and more geared towards making the not combed decision (though they are more sensitive now then originally). Maybe you could try adjusting the values for cthresh and MI inside the range above. The IsCombed() function in the decomb package, which uses the same detection routine as fielddeinterlace(), uses a different combing metric than TDeint/TIVTC so it doesn't have an exact equivalent to cthresh. However, it does have equivalent parameters to MI/blocky/blockx/chroma (its values for MI/blocky/blockx are just hard coded). IsCombed's defaults are equal to:

MI: 15
chroma: false
blocky: 8
blockx: 4

If you want an easy way to see exactly how changing the parameters effects which pixels are detected as combed check out the ShowCombedTIVTC() function of TIVTC. The cthresh/chroma parameters effect which individual pixels are detected as combed and the blocky/blockx/MI parameters effect whether the frame is considered combed based on how many and which individual pixels are detected as combed.

[ToS_Maverick]

wohooo, thank you guys!

you saved my day :D

[ToS_Maverick]

after playing around with DeDup i'm getting pretty good results.

the only problem that's left is, how can i automate the extra-pass that's needed for DeDup?

for encoding, i use x264-MeGUI. it would be great if i could just add an extra-pass before the real encoding....

[berrinam]

That's a MeGUI feature request, so you should post it on the feature request thread: http://forum.doom9.org/showthread.php?t=105162

[ToS_Maverick]

this post is about
- a solution for the DeDup 1st pass in MeGUI and
- a problem with the x264-bitrate for the VFR-encode

for the 1st pass problem of DeDup i already got a solution, more or less:

i just add an 2pass 1st pass job with maxspeed settings to x264-MeGUI, which "plays" my 1st pass file for DeDup. to speed up this process, i resize the video to 16x16 AFTER the DeDup analysis.

here's the script for DeDup 1st pass:
LoadPlugin("C:\Programme\GordianKnot\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\UnDot.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\ColorMatrix.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TDeint.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\DeDup.dll")

mpeg2source("D:\Video\Babylon 5\S1E01\S1E01.d2v")
ColorMatrix(d2v="D:\Video\Babylon 5\S1E01\S1E01.d2v")
TDeint(mode=1,full=false,tryWeave=true)

DupMC(log="VFR.dup.txt")

LanczosResize(16,16)

and DeDup 2nd pass, to feed the encoder:
LoadPlugin("C:\Programme\GordianKnot\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\UnDot.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\ColorMatrix.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\TDeint.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\DeDup.dll")

mpeg2source("D:\Video\Babylon 5\S1E01\S1E01.d2v")
ColorMatrix(d2v="D:\Video\Babylon 5\S1E01\S1E01.d2v")
TDeint(mode=1,full=false,tryWeave=true)

DeDup(threshold=0.3, maxcopies=2, maxdrops=2, log="VFR.dup.txt", times="VFR.times.txt")

crop(10,0,702,576)
LanczosResize(1024,576)
Undot()


the problem with the x264-bitrate:

this night, i encoded this episode. in the morning i noticed that the encoded file was a way too small! what happened?

to calculate the needed bitrate, i opened the 1st pass avs-file with MeGUI and used the bitrate calculator to get a final size of 400 mb (video + ac3). the 1st pass avs has a framerate of 50 fps, which is constant.

the problem here is, that x264 gets the 2nd pass avs as input, which has much less frames. x264 gets the information that the video has an framerate of 50 fps. i think it determines the lenght of the video with: number of frames / framerate = length. so x264 thinks the video is shorter and therefore calculates the wrong filesize.

the solution for this, i think, is that there should be a possibility, to pass the final videosize to x264 in the same way, as we could in XviD.

please correct me if my assumption is wrong.

is there a way to get this working? i'd appreciate any help ;)

[foxyshadis]

The problem was that you used the second pass without remaking a first pass with the second script in between. ^.~ I'm surprised that it worked at all, but I guess x264 is more lenient with too many frames in stats file than too few.

And don't lanczosresize the first, just crop and it'll go even faster yet. Probably don't need colormatrix either.

The workflow should be:
Add first script, queue first pass, fastest settings.
Add second script, queue 'real' two passes (or auto 2pass), muxing, etc.

I've never seen Babylon 5 dvds, let alone PAL ones, so I wouldn't know if this was a candidate for TIVTC hybrid mode.

[ToS_Maverick]

The problem was that you used the second pass without remaking a first pass with the second script in between. ^.~ I'm surprised that it worked at all, but I guess x264 is more lenient with too many frames in stats file than too few.

And don't lanczosresize the first, just crop and it'll go even faster yet. Probably don't need colormatrix either.

The workflow should be:
Add first script, queue first pass, fastest settings.
Add second script, queue 'real' two passes (or auto 2pass), muxing, etc.

I've never seen Babylon 5 dvds, let alone PAL ones, so I wouldn't know if this was a candidate for TIVTC hybrid mode.

i'm sorry for the misunderstanding, maybe i explained it to badly (english is not my native language ;)). it's also not so easy to get along with the pass confusion (dedup 1st and 2nd pass, x264 1st and 2nd)

my workflow was the same that you described. i did a lot of encodes over the year, so i watched out very closely to avoid confusing the scripts ;)

And don't lanczosresize the first, just crop and it'll go even faster yet. Probably don't need colormatrix either.

i only resize, to speed up the pseudo analysis of x264, as i don't need the analyse data of the 1st script.

the thing with the colormatrix is a good idea ;)

[foxyshadis]

Oh, I think I understand what you're asking now, sorry about that, and it's because the framerate is now incorrect. The video itself is shorter, so that any bitrate calculations will give a smaller encode. In this case you need something like this to the end:

oldcount=framecount # this line must be before dedup
oldfps=framerate
averagefps=(framecount/oldcount)*oldfps
assumefps(averagefps).Nicefps()

Hope that helps!

(Crop(0,0,16,16) is still much faster than any resize. :p)

[ToS_Maverick]

thank you, that worked fine!

i don't know why, but ".Nicefps()" didn't work. but the file was ok without it.

now i got another problem... on my pc the file plays fine, but on a 2nd and on my notebook, the file plays to slow/fast and gets out of sync with the audio.

i tried to install exactly the same playback utilitys (i use the Combined Community Codec Pack, newest version most of the time), but it won't work :(