Pal to NTSC conversion ;o)

[StrobeLightEpileptic]

Well, I'm back with the same problem. I went ahead and ran the entire video through the avisynth script. I then stuck it into Tmpgenc per the settings from the guide and let it encode. It took 30 hours to get the whole thing done.

Then I authored into dvd. The video is way ahead of the audio again.

I figure I have the video stored on disc as 24 fps. (approximate, I know. The actual being 23.976. I'm using for 24/30 figures for simplicity). But the player is playing it back at 30 fps.

If that were the case then the 90 minute film would finish in 72 minutes. So, I timed the video. Sure enough, it finished a few seconds over 72 minutes.

The same thing happens in dvd-rom player, so it's not my dvd-player that's at fault.

My suspicions are falling on the Tmpgenc settings. In advanced settings there are checkboxes for Inverse Telecine and 3:2 pulldown. I didn't have these selected, I only had Video:Framerate and the Video:Encode Mode set per instructions on the digitalfaq guide.

Should I have had settings in the Advanced Box set?

[jagabo]

I figure I have the video stored on disc as 24 fps. (approximate, I know. The actual being 23.976. I'm using for 24/30 figures for simplicity). But the player is playing it back at 30 fps.

NTSC DVD always play back at 59.94 fields per second (nominally 29.97 frames per second). You have to add 3:2 pulldown flags that instruct the DVD player how to create 59.94 fields per second from the 23.976 frame per second source. You set the Encode Mode to "3:2 Pulldown Whan Playback" and the Frame Rate to "23.976 fps (internally 29.97 fps)".

Here's a comparison of the sample from smurf's guide (left) compared to AviSynth's SRestore() method:



SRestore() isn't perfect but at least the heaviest ghosting is gone.

[lordsmurf]

SRestore actually seems to add some ghosting in 1-2 frames.
Fast pan shots will be problem using any method.

The best advice on PAL to NTSC is still "don't do it".

[StrobeLightEpileptic]

You set the Encode Mode to "3:2 Pulldown Whan Playback" and the Frame Rate to "23.976 fps (internally 29.97 fps)".

Yes, those settings were called for in the guide, so I've had them set in Tmpgenc all along. But the pulldown doesn't seem to be working.

[jagabo]

I suspect there's something wrong in your video. Check the frame rate of your MPG and VOB files with GSpot. It will show you the pics/s (should be 23.976), frames/s (should be 29.97), and fields/s (should be 59.94).

[manono]

Yes, those settings were called for in the guide, so I've had them set in Tmpgenc all along. But the pulldown doesn't seem to be working.

If you got a speeded up video, then you didn't do something right. Please post a GSpot screenshot of a resulting VOB or M2V. You probably won't have to do the encode all over again. If you're lucky and didn't mess up the encode too much, you might just have to demux and run the M2V through DGPulldown before remuxing.

[StrobeLightEpileptic]

Well, it hit me that I might have used avisynth incorrectly.

I loaded the script in VirtualDub and then had VD save as an AVI. I think the program was in full processing mode when I did that. I didn't realize at the time that I could just run the captured video through avisynth right into Tmpgenc.

Instead I took the output from VD and put that into Tmpgenc.

So right now I'm encoding again. This time I loaded the capture into avisynth and loaded the avisynth script into Tmpgenc.

So, once it's done I'll report back.

[jagabo]

Open your AviSynth script and VirtualDub and check the frame rate with File -> File Information. It should be 23.976.

[jagabo]

SRestore actually seems to add some ghosting in 1-2 frames. :?

Actuallly it didn't. If you look closely you'll see that the two videos start in sync but your video falls a frame behind by the end (watch the siren). In all cases that I saw where it looked like the SRestore() video had more ghosting than yours it was because SRestore() was showing an earlier frame.

This happened because SRestore() restored the original 24 fps film frames (the PAL version was not sped up, it had duplicate blended fields added and retained the original running time of the 24 fps source). Your technique first created 25 fps and then slowed it down to 24 fps, increasing the running time.

[StrobeLightEpileptic]

Open your AviSynth script and VirtualDub and check the frame rate with File -> File Information. It should be 23.976.

Here that is:

[jagabo]

Ok, so the output of AviSynth was correct. It shows the right frame rate and the right running time. Now how about the intermediate AVI file you made (if you still have it). Then a GSpot report on the MPG/VOB file from TMPGEnc.

[StrobeLightEpileptic]

Ok, so the output of AviSynth was correct. It shows the right frame rate and the right running time. Now how about the intermediate AVI file you made (if you still have it). Then a GSpot report on the MPG/VOB file from TMPGEnc.

Well, I'm going to have to start over. Last night's effort was ended by an error that occurred in TMPGEnc. The error read:

"Read error occurred at address 0049FC55 of module 'TMPGEnc.exe' with 00000010."

The brief bit of video I got out of it had a message imprinted on it. But, I've since discarded that.

I also discarded the VOB files from the attempt you're looking for.

But the intermediate file I used previously, I still have. Here is the g-spot info on the file I fed into tmpgenc last night through the avisynth script that I gave info on above.

[StrobeLightEpileptic]

Now, the above report from VirtualDub and G-spot were for the most recent attempt, That went like this:

Avisynth loads "capture" and filters it.
Avisynth script loaded into TMPGEnc.

The previous attempt I made was where I loaded the same avisynth script into Vdub and saved as AVI with full processing. I then put the results of that into TMPGEnc. Here is the G-Spot for that intermediary file:

[StrobeLightEpileptic]

I've decided to work with a smaller video segment to shorten the time it takes to do multiple encodes while trying to resolve this problem. I'm trying to be as thorough as I can in documenting each step. So, I loaded a smaller clip into avisynth and then loaded that into TMPGEnc. (hopefully this is still large enough to make a dvd that will play on my player.)

Anyway, I am now getting the same imprinted message on the video. It reads:

"I dont' know what "d32" means
([ScriptClip], line19)"


By the way, if someone could clue me in on how to upload multiple pics for one post that would be convenient.

[manono]

I guess we won't see the VOB to help discover where you went wrong, as you say you discarded it. We do have the evidence in those pics, in case anyone doubts it, that the video's length remains the same after being unblended to 23.976fps from the source 25fps.

As you learned, you open the AviSynth script directly in TMPGEnc (with a 'ConvertToRGB()' line at the bottom). It's always a good idea to test the script first in VDub to make sure it's a good script. I suspect the writing you got on the failed encode was an error message of some sort. Also, one of the reasons to use AviSynth is so that you can use Fast Recompress in VDub, when using VDub to encode. You won't need to use the slower and inferior Full Processing any more.

Also, you shouldn't ever need to make that absolutely enormous uncompresssed AVI, even if making a lossless intermediate AVI (which I often do because of the slow filters I might use). Much better would be to make a lossless intermediate Lagarith or HuffYUV AVI.

[StrobeLightEpileptic]

The error it mentions I've traced to Srestore.avsi.

On the clip it says line 19. In the Srestore script you get a ScriptClip function and on line 19 of that function you get the following:

17: ## diff value shifting ##
18: d_v = yplanemax (dclp)+.015625
19: d43 = jmp ? d32 : d_v
20: d32 = jmp ? d21 : d_v


So the first instance of d32 is at line 19. Now, I'm wondering if the program could'nt read this it simply exited out of the function altogether? After all, if it couldn't understand d32 at line 19, it wouldn't understand d32 at line 20 either.

So, the srestore script was never fully executed to begin with?

Could this also have been my problem with the read error?

[StrobeLightEpileptic]

Well, again, the segment I tried to encode ended with a read error.

I've been looking at the code in the Srestore script as it begins in the ScriptClip function. I'm not the greatest at making sense of code. That takes a lot of work. But, I do notice that the value of d_v is assigned early in the function. But the value of d32 is not assigned until after it is first referenced. So the function seems to be trying to assign the value of d32 to d43 depending on whether jmp is true or not. But d32 itself has no value assigned to it until the next line.

In the next line you have the same problem with d21. Likewise with the next line and the next line. Until finally you have a line assigning the value of d_v to d34, which value could be used in assigning all the preceeding values.

But like I say, I'm not the greatest at interpreting code. And it seems to me that this error would have been caught by someone much earlier than now.

[manono]

There's nothing wrong with the function. You shouldn't be using SRestore as an autoloading .avsi, but should be loading the .avs into the script. As it clearly says in the included SRestore readme:

Use import("srestore.avs") in your script...

Import("C:\Path\To\SRestore.avs")

In case that's not it (although I suspect it is), the readme also gives you the names and versions of the other needed .dlls. Perhaps you have the wrong version of a needed plugin:

needed plugins: - mt_masktools v2.0     (allways)
                - TIVTC v1.04 or higher     (only for cache>0, not default)
                - RemoveGrain   (only for double-blend-removal, not default)
                - Average       (only for double-blend-removal, not default)

[StrobeLightEpileptic]

Okay. That worked. Thanks. I am now encoding a smaller file that I hope is big enough to play in the dvd-player. I'll report back

[manono]

Oh, I forgot to mention that SRestore has a big memory leak. For your 90 minute video you should be OK, unless you don't have much RAM. For me with 2 GB of RAM it usually craps out after a little over 2 hours of a movie. The answer is to divide the movie into 2 parts encoded separately to a lossless AVI (I use Lagarith), then to be rejoined using a couple of AVISource lines in an AviSynth script before sending to the MPEG-2 encoder.

[jagabo]

Oh, I forgot to mention that SRestore has a big memory leak.

Thanks, I never noticed that.

[StrobeLightEpileptic]

I got that read error again in TMPGEnc. It happens just as it crosses over from analysis to encoding. This has happened with different video files. But it didn't happen when I mistakenly encoded only 15 minutes instead of the half hour.

So, I read somewhere to increase the DirectShow plugin's priority so that it was the highest in the VFAPI environment settings. But, I also had a setting in TMPGEnc's environment settings that I just recently started using: the Cache setting which saves the analyzing result into a cache file. I had this set to 7500MB. This along with what you said about SRestore having a memory leak problem made me decide that maybe this was part of my problem with this read error.

Next, I rebooted the machine because that is supposed to clear out virtual memory. And now I am defragmenting my drives, which haven't been defragmented in three weeks even though I've been creating and deleting hellacious files.

So, once the drives are all defragmented I'll set up the encode again and let it run through the night.

[StrobeLightEpileptic]

Well, I gave that priority to Direct Show, stopped the tmpgenc analysis cache, and defragmented my drives. Some of them multiple times.

I then went with an encode and authored a dvd that wouldn't play. The video would play, (in the computer), but the sound would went awry like someone just touching the surface of a record with the needle and then lifting it. Then touching it again and then lifting it. I deleted some of my files with an eye to another encode, when I saw that the vob file was encoded at a rate of over 10000kbps. So, I figured that was why it had such a hard time playing even on my computer. But there was no message imprinted on my screen and the video did a complete encode -- no read error.

I began another re-encode and this time I got the message imprinted and I also got a read error at 99% of the encode. The read error might be a memory problem, I don't know. But that message imprint I don't understand. Here's the script I used:

loadcplugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
avis_clip = AVISource("E:\swt\swt-vid.avi", false)
yadif(avis_clip,1,0)
import("C:\Program Files\Avisynth 2.5\plugins\SRestore.avsi")
SRestore()
Crop(12,4,-12,-4)
Lanczosresize(704, 480)
# Lanczosresize(512, 384)
AddBorders(8,0,8,0)
ConvertToRGB24()

And below is a pic of the message on the screen. I looked in ScriptClip again and this time the code it had a problem with was a bit further down than before. The first time it was dv32. This time it was bp something. So, again, I can't say that the SRestore had even been used, because I'm not sure what happens when tmpgenc can't read the code. Anyway, I made a disc out of what I had and again, it wouldn't play on my settop, but in the computer the video was way ahead of the audio again.

I did keep track of every step, so I'm going to go ahead and post everything to see if anyone has any idea. This will take multiple posts because I don't know how to upload multiple pics with one post.

Here is that message that appears on the screen:





vlcsnap-00001.png

[StrobeLightEpileptic]

I meant to say, that I am importing SRestore in the script and have always had all the dependencies installed.

The following pic had the gspot info on my source file -- the capture stitched together in vdub(that's why it says vdub junk), and to the right of that is the file info from my script in Vdub.

[StrobeLightEpileptic]

On the left is a gspont of my m2v file, and on the right is a gspot of the vob.

[StrobeLightEpileptic]

The folowing captures are all of the tsunami settings:

[StrobeLightEpileptic]

The second and third pages of the settings:

[StrobeLightEpileptic]

fourth and fifth settings:

[StrobeLightEpileptic]

The environment settings that deviate from the defaults:

[StrobeLightEpileptic]

Finally the VFAPI settings and the VBR setting: