DGPulldown 1.0.9 Final supports in-place operation operation, creating, standard, instead, option

andy

This version adds an option for in-place operation, i.e., the input file is modified instead of creating an output file, thereby saving disk space. Thank you to timecop for coding and submitting this enhancement!

dgpulldown/dgpulldown109.zip

EDIT: Link updated to the latest beta version.

This is great news. Does the in-place result differ in any way to the standard result?


Originally Posted by ChainmaxDoes the in-place result differ in any way to the standard result?
My tests show complete binary identity.

sweet!  thanks DG and timecop

In this thread, I'm trying to make a DVD out of a 14.999fps source. The recommendation thus far seems to be to go PAL by speeding up to 16.667fps and then use DGPulldown to reach 25fps. Now, I seem to recall a post somewhere in here that said that any pulldown excepting the classic 23.976---gt;29.97 one would introduce some jittering (line moving artifacting, right?), is that true? If so, is there any way around it?

If you'd said quot;judderquot; I'd know what you are talking about. Even 23.976 -gt; 29.97 introduces judder.

But quot;line moving artifactquot;? You're baffling me.

It's probably judder then, sorry for my ignorance .

The judder is an unavoidable side effect of the field duplication. It is for you to judge whether it is tolerable for a given rate conversion.

I see, but would 16.667--gt;25 introduce more judder than 23.976--gt;29.97?

not really.  the judder is usually due to the frames being on the screen for different amounts of time (2 fields v 3 fields).  going from 16.67... to 25 will be an exact 3:3 pulldown, meaning every film frame is on screen for the same amount of time.

though it'll still appear slightly jerky seeing as the frame rate is lower after all, and when you track a moving object with your eye (on an interlaced screen), you'll see 3 ghost images as your eye moves (hope that makes sense.  the effect is quite distinct.  try track a medium-fast pan with your eye and see how things look).

would this method benifit low-bitrate anime encoding?

Only if mastering to DVD, but there you have lots of bitrate, usually. For pcs and handhelds, decimate the framerate to 8 or 12fps if you have to but never purposely introduce judder or interlacing. (Interlacing will look bad on them anyway, or take extra processing to remove messily.)

Was test this out today using the in place mode.  Seemed to run okay and said it completed, but can't use the resulting file in IFOedit or Scenarist.  IFOedit gave a message saying quot;Too many dropped framesquot; and stopped.  Scenarist stopped at roughly the same point with this in the log:
ErrorJ:\working\VTS02\Scenaid\NewD2V\VTS__02_P01.I-TFF.16~9_1.mpv
Error : Number of fields (48) in GOP(# 8531) or between sequence_header_code should be equal or smaller than 36.
Error : Frame rate (3 = reserved) is wrong.
Warning : Number of SequenceEndCode is 0.

Wondering if there's anything obvious I might have done wrong?  The video was flagged as interlaced on the original DVD but had no artifacts that I could find so I processed it as suggested in the third option in this guide mpg/big3-BatchCCEWS.htm + resized it to 720x480.  Then I ran dgpulldown on it and got the file I'm having problems with now.  I've got it running again processing it as if the source was interlaced to see if it makes a difference, but wondering if there are any suggestions people might have about what else could be wrong.


Originally Posted by DJKCWas test this out today using the in place mode.
What happens if you do everything the same but don't use in-place operation? Also, please tell me all the DGPulldown settings you used. How did you create the base M2V file? It sounds like you haven't encoded it for DVD compliance.

Unfortunately I didn't make a backup of the file before trying it, so I can't say.  I'm in the middle of encoding it again.

Rip+encode was done with DIF4U+scenaid+batchccews using CCE SP 2.70.  Options in batchccews were Progressive, TFF, and Close All GOPS.  DGpulldown options were 25-gt;29.97, Set Time Codes, and Modify file in place.  AVS script was:
import(quot;C:\Program Files\DoItFast4U\new.avs\addaudio.avsquot;)
LoadPlugin(quot;C:\Program Files\ScenAid\DGDecode.dllquot;)
Mpeg2Source(quot;J:\working\VTS02\Scenaid\NewD2V\VTS__02_P01.I-TFF.16~9_1.d2vquot;,idct=0)
AddAudio()
LanczosResize(720,480)
ConvertToYUY2()

Thanks for your response.

edit:
You were right, found a stupid error elsewhere in the encode process that was hosing things up an giving me a non-compliant final stream.  Sorry for posting here before I finished all my reencode tests.

I've recently had some problems with DGPulldown1.07 and the inplace option. I use QuEnc 0.70 and the encodes appear to be fine before the pulldown operation and creating a new file as part of the pulldown results in a good file too. However, when using the inplace option the resulting file plays okay for the majority of the time but then starts to stutter, plays too quickly and shows distorted flashes while the video plays.
I've been using 23.976-gt;25 and the original file has been about 3.5GB in size. I've not investigated it fully but when I reduced the resolution of the vid to 352x288 and lowered the bitrate to 600 so that the filesize was considerably smaller (0.5GB-ish) there was no problem. I am also using Avisynth 2.57 Alpha 3 if that matters.
I watched the gui for a while (sad I know) and the second number didn't seem to change as much towards the end of the file where the problem tends to arise.

Perform pulldown on your source M2V twice (keep a backup): do it once without in-place operation and once with in-place operation. Then perform a binary comparison of the two resulting files. Are they the same?

It's not clear whether you are reporting just an issue with in-place operation or a problem with the pulldown itself. This test will clarify that and then we can take it from there.

How do I perform a binary comparison?

Google quot;binary file comparequot;

Are you saying it only happens when you use in-place?

It only happens when I use in-place. I was mistaken above in that it actually occurs with a 23.976-gt;29.97 pulldown. (I've not checked the 23.976-gt;25)

My AVS file:

AVISource(quot;C:\Documents and Settings\JAMES PIKE\My Documents\My Applications\X3.aviquot;, false)
ChangeFPS(quot;ntsc_filmquot;)
LanczosResize(720,480)
ConvertToYV12()

My commandline to obtain an m2v:

quot;C:\Documents and Settings\JAMES PIKE\My Documents\My Applications\FAVC\QuEnc\Quenc.exequot; -i quot;C:\Documents and Settings\JAMES PIKE\My Documents\My Applications\FAVC\Working Folder 0\Title0.avsquot; -o quot;C:\Documents and Settings\JAMES PIKE\My Documents\My Applications\FAVC\Working Folder 0\Title0.m2vquot; -b 8000 -maxbitrate 8000 -dc 8 -1 -nohq -vbr -noscene  notrell -nocgop -nointerlaced -noextreme -gopsize 12 -maxbframes 2 -nocmatrix -aspectratio 16:9 -mpeg2mux noaudio -silent -auto -close

I then perform pulldown with the GUI, or command line. Using default options apart from choosing in-place or not. The results of the binary file comparison begin with:
C:\Documents and Settings\James\My Documents\FAVC\Working Folder 0gt;cmp title0.m2v title0.m2v.pulldown.m2v -L[0]
BinaryFileCompare-32bit  v2.30  Copyright (c) 1998-2000,2004 Vladimir Tarasov
WARNING! The files have different size (3676978814:3676978813)
Comparing  title0.m2v  and  title0.m2v.pulldown.m2v ... 164936 differences.
Working time: 748.33 seconds.

Here is the report file created:
~pike/report.cmp

It only seems to happen on large m2v files, with respect to filesize that is. Here's what it looks like: