720x480 NTSC ---to---> 720x576 PAL

[provato]

Sorry for double post. I have one more question regarding the sound:

When I speed up the video with "AssumeFPS(25)", I noticed that the duration of course gets shorter (21:33 from 22:28)
The DTVRip of the PAL-Land channel that I have captured also has a duration of 22:28!!! And I respect the pitch/tempo of this video's audio - I don't want to change either!

Is it possible that the TV channel showed the episode with the 24 (Film) fps sound??? Because the 21:33 video (with "AssumeFPS(25)") cannot be synchronized to this sound's duration!!

And if so, which is the correct solution???

-To mux the PAL DTVRip's audio onto the 24fps video (without assume/change/convertFPS)

-To mux the PAL DTVRip's audio onto the 25fps video, that has been encoded with some duplicate frames ("ChangeFPS(25)") <--- correct me if I'm wrong with this "duplicate frames" phrase

-To mux the PAL DTVRip's audio onto the 25fps video, that has been encoded with blending/ghosting ("ConvertFPS(25)" - I really really hate ghost effect though...)

[jagabo]

Are you saying that in the script I have posted above, I don't have "TFM() and TDecimate() together"?

You posted your script while I was writing my response to your earlier posts. So I didn't see your script until now. Your script does include TFM() followed by TDecimate(). TFM() does occasionally leave some small residual comb artifacts.

[jagabo]

When I speed up the video with "AssumeFPS(25)", I noticed that the duration of course gets shorter (21:33 from 22:28)
The DTVRip of the PAL-Land channel that I have captured also has a duration of 22:28!!! And I respect the pitch/tempo of this video's audio - I don't want to change either!

The other way I mentioned of converting film to interlaced PAL (via pulldown) will keep the original film running time. Or maybe they just duplicated one frame every second to convert 24 fps to 25 fps, also retaining the original running time.

[manono]

Are you saying that in the script I have posted above, I don't have "TFM() and TDecimate() together"?

I'll say that either you didn't use that script or there's no interlacing if you did use it. And I was wrong about not needing Mode=1. You do need it.

TFM().TDecimate(Mode=1)

There's no interlacing left if using that on your sample.

TFM() does occasionally leave some small residual comb artifacts.

Sure, but he said " I get 1 interlaced frame every 3 frames!"

[provato]

Dgpulldown sounds good, but I seem to not understand something here...

In order to use dgpulldown, I must have an interlaced 23,976 source. Since the vob files I have are 29,97, how can I make them 23,976 to use them with the program?

Please excuse my ignorance, I haven't used dgpulldown before

[provato]

I'll say that either you didn't use that script or there's no interlacing if you did use it. And I was wrong about not needing Mode=1. You do need it.

TFM().TDecimate(Mode=1)

There's no interlacing left if using that on your sample.

TFM() does occasionally leave some small residual comb artifacts.

Sure, but he said " I get 1 interlaced frame every 3 frames!"

Yes sorry Manono, The "source is anime" option in MeGUI, must have screwed something up.
If I manually type "mode=1" the video frames are perfectly progressive

[hello_hello]

"source is anime" shouldn't do anything but add mode=1 to the script where appropriate. When you change something in the script creator (including checking/unchecking "source is anime") the preview automatically switches back to displaying the original, unfiltered source video.

Normally when the preview switches between the unfiltered and filtered versions and IVTC is being used, it's very obvious because the preview stays on the same frame number, but because the IVTC process reduces the number of frames, the previewed image jumps from one place in the video to another. If you're previewing the video close to the beginning (and especially in the case of your sample where there's lots of repeated frames) the picture may not appear to "jump" from one position to another, so it may be that you're checking the "anime" box without using the "preview script" button again, and it appears to be having an adverse effect because you're no longer previewing the IVTC'd version. Hopefully that makes sense.

You can preview changes without needing to click on the preview button each time, by checking the "Auto Apply Preview" box under the script creator's I/O tab. I tend to do the standard things (cropping and resizing etc) while previewing the original video as I find it easier that way, but sometimes the auto preview function is handy.

[manono]

Dgpulldown sounds good, but I seem to not understand something here...

In order to use dgpulldown, I must have an interlaced 23,976 source.

In order to use it you must have a progressive source. You'll have one after doing the IVTC and encoding for progressive 23.976 (or also speeding it up to 25fps with AssumeFPS and encoding for 25fps).

[hello_hello]

Hahaha... Thank you jagabo, it wasn't that I didn't set the sar in the x264 encoder...
I just had set it to force 4:3 because I didn't know the correct aspect ratio of 720x576 video
Lol

I'd recommend not using the x264 encoder to set the SAR. Let MeGUI do it because if you crop, the DAR will change, and if you resize the SAR will change. Letting MeGUI calculate it all is easier than having to do it yourself. Leave the "Force SAR" option in the encoder configuration set to default.

To get MeGUI to calculate the SAR, all you need to do is enable anamorphic encoding in the script creator. If you open a 4:3 NTSC DVD, enable anamorphic encoding and switch to the script tab without applying any cropping you'll see this at the beginning of the script.... if the Input DAR is "ITU 4:3 NTSC".

# Set DAR in encoder to 6480 : 4739. The following line is for automatic signalling
global MeGUI_darx = 6480
global MeGUI_dary = 4739

If the Input DAR is just 4:3 (although I think ITU resizing is correct for this DVD.... and pretty much all 4:3 DVDs) then you'll see this:

# Set DAR in encoder to 4 : 3. The following line is for automatic signalling
global MeGUI_darx = 4
global MeGUI_dary = 3

Now apply some cropping and switch back to the script tab. You'll notice the DAR (display aspect ratio) in the script has changed. That's logical, because if you remove some of the picture then the display aspect ratio must change. Next try adjusting the resizing (select the anamorphic encoding method which allows resizing if need be) and check the script again. Notice how resizing has no effect on the DAR displayed in the script? That's because when using anamorphic encoding you don't want changing the resolution to change the DAR (the shape of the picture). The pixel aspect ratio (SAR) should change instead so the display aspect ratio won't. MeGUI will calculate the new SAR for you, although you don't see it in the script.

When the script is loaded for encoding, MeGUI uses the DAR in the script along with the resolution after resizing to calculate the correct SAR. When you load the script into the video encoding section and use the preview it'll open and display as though it uses square pixels, but the preview window will show the correct DAR down the bottom. It also has a checkbox to adjust the preview to display with the correct aspect ratio.

MeGUI does limit the resizing it'll automatically add to the script when using anamorphic encoding, so resizing from 720x480 to 720x576 needs be done manually, but that's easy to do. Here's an example (no cropping included, but it'll work the same way if you crop).
Open the 4:3 NTSC DVD. Enable anamorphic encoding and select "resize to selected mod". Change the resizing to something... anything.... it doesn't matter because resizing has no effect on the DAR in the script. The only reason for changing it is to get MeGUI to add some resizing to the script. Now switch to the script tab. If the Input DAR was "ITU 4:3 NTSC" the DAR in the script will be 6480 : 4739 (no cropping). Change the resizing to 720x576. Save the script. When it's loaded for encoding the preview window will display "ITU 4:3 NTSC (1.367377)" as the display aspect ratio. The output resolution will be 720x576.

For the record, the preview window which opens after loading a script for encoding has a drop down box next to where the DAR is displayed. You can use it to change the DAR to something else, and MeGUI will use the selected DAR when encoding (it'll ignore any DAR in the script). For example if you change the DAR to 16:9, the output will be 720x576 with a 16:9 display aspect ratio. That'd be another way to do it. You could resize your video to 720x576 (no anamorphic encoding) then set the display aspect ratio to NTSC 4:3 in the preview window, but if you're cropping, anamorphic encoding lets MeGUI automatically adjust the DAR/SAR in order not to distort the picture, so there's no need to work it out yourself.

[provato]

I tried it again hello_hello, and no matter what I do (either in the script or in the preview window) I can't get Megui to encode a 720x576 4:3 video after cropping the black bars. It always encodes in 5:4 DAR, and the video becomes stretched. (Even if I put global MeGUI_darx = 4 AND global MeGUI_dary = 3)

The only way I found to solve this, was to force sar inside x264 to 12:11

Maybe if I tried something else in the script for darx and dary???

@Manono:

Could you explain in a little more detail how to use DGpulldown? I need it to produce a 25fps progressive video
Also, since it duplicates 1frame/second, what is dgpulldown's difference from "changeFPS(25)" in the end of the avs script?

[manono]

Also, since it duplicates 1frame/second...

It doesn't do that at all. If you encode for progressive 23.976fps and then run it through DGPulldown with the 'Custom' box ticked and it set for 23.976->25fps, the player will output 2 duplicate fields per second, making 25fps. But since it's outputting 2 additional fields at different places during that second rather than a single frame (as in ChangeFPS(25)), the playback is much smoother. In addition, those duplicate fields aren't encoded into the video where the duplicate frames are.

Have you compared the length of the PAL audio you're adding with the length of your video, at both 23.976fps and at 25fps? If the PAL audio was created by speedup, then you'll probably want to speed up your video with an AssumeFPS(25) (which won't need any DGPulldown). If it's the length of the 23.976fps video, then you'll want to run the 23.976fps video result through DGPulldown.

[provato]

Also, since it duplicates 1frame/second...

It doesn't do that at all. If you encode for progressive 23.976fps and then run it through DGPulldown with the 'Custom' box ticked and it set for 23.976->25fps, the player will output 2 duplicate fields per second, making 25fps. But since it's outputting 2 additional fields at different places during that second rather than a single frame (as in ChangeFPS(25)), the playback is much smoother. In addition, those duplicate fields aren't encoded into the video where the duplicate frames are.

Have you compared the length of the PAL audio you're adding with the length of your video, at both 23.976fps and at 25fps? If the PAL audio was created by speedup, then you'll probably want to speed up your video with an AssumeFPS(25) (which won't need any DGPulldown). If it's the length of the 23.976fps video, then you'll want to run the 23.976fps video result through DGPulldown.

Yes, that is what I said earlier. Even though the DTVRip (from dvb-t TV) is 25 fps, the audio has the exact same length with the 23,976 video!!! (Maybe the TV channel used an NTSC to PAL converter in order to broadcast the video)
So DGpulldown is the solution I want for smooth video (minimize jerks).

I just can't understand, how is it possible to add fields (duplicate fields) in a progressive video that has only frames, not fields. (Again, correct me if I'm wrong)

[manono]

I just can't understand, how is it possible to add fields (duplicate fields) in a progressive video that has only frames, not fields. (Again, correct me if I'm wrong)

It's not reencoding. It's not adding those fields to the video. The pulldown (think of it as a form of software) consists of flags that tell the DVD player how the fields are to be output. On the DVD disc are stored only the progressive 23.976fps frames. But the output is interlaced 25fps.

It's the same, in principle as the 3:2 pulldown most NTSC DVDs have for getting the progressive 23.976fps frames to output interlaced 29.97fps for NTSC televisions. This form might be called 2:2:2:2:2:2:2:2:2:2:2:3 (I think) pulldown.

[provato]

Ok, new program = new nightmare with DGPulldown...

when I browse for the mp4 file in "input" and select "23,976 --> 25" and then hit "convert", DGPulldown tells me it only accepts "elementary streams"...
I read that DGPulldown only accepts m2v files (MPEG2) but my file's elementary stream is mp4/264!

Any way I can make this "pulldown flags" thing work with my mpeg-4 file?

[jagabo]

DgPulldown only works with MPEG 2 elementary streams. It's meant for DVD material. Mpeg 4 doesn't support pulldown flags, you have to perform hard pulldown and encode interlaced. You'll see a pattern of 12 progressive frames, 13 interlaced frames, repeating.

Regarding how pulldown works: the video is stored as progressive frames. The pulldown flags tell the player how to produce 50 fields per second from those progressive frames (or 59.94 fields per second in the case of NTSC).

When NTSC video is broadcast as PAL they usually use hardware NTSC to PAL converters that blend fields. If you step through your DTV video field by field you'll probably see many that look like double exposures -- blended fields.

[provato]

So, please tell me if get this straight:
If I want an mp4 final file....
I would have to encode in progressive mpeg2 (m2v file), then dgpulldown 23,976 to 25 and finally re-encode in mpeg4 file.

[jagabo]

So, please tell me if get this straight:
If I want an mp4 final file....
I would have to encode in progressive mpeg2 (m2v file), then dgpulldown 23,976 to 25 and finally re-encode in mpeg4 file.

No, you can perform the pulldown in software.

#23.976 fps source, any fps source really
ChangeFPS(50) # duplicate frames to make 50 fps
SeparateFields() # 100 fields per second
SelectEvery(4,0,3) # 50 fields per second
Weave() # 25 frames per second

The disadvantage of this is that you are encoding interlaced which requires more bitrate and delivers lower quality. Personally, I would never do this for mp4 or mkv. I'd speed up the video to 25 fps and adjust the audio.

If you want blended fields, like most NTSC to PAL broadcast, use ConvertFPS() instead of ChangeFPS().

[provato]

Yes you are right once again jagabo lots of blending (ghost effect) in both live watching DTV and watching the captured dtvrip...

So, TV channels use "convertfps(25)" in a sense... Right?

That also (probably) means that the "professional" PAL-foreign-language dub was made using the NTSC film 23,976 video...
If that is true, then I don't see why I should change 23,976 fps to 25 fps. (Since every screen/TV/VCR I have doesn't have problems playing 23,976 fps videos)

[jagabo]

So, TV channels use "convertfps(25)" in a sense... Right?

Yes, the hardware does something similar.

That also (probably) means that the "professional" PAL-foreign-language dub was made using the NTSC film 23,976 video...

The material was shot on film at 24 fps. It was then slowed to 23.976 fps and hard telecined to 59.94 fields per second for recording onto NTSC analog tape. The tape was then converted to 50 fields per second with field blending, then packaged as 25 fps interlaced frames per second for digital broadcast.

If that is true, then I don't see why I should change 23,976 fps to 25 fps. (Since every screen/TV/VCR I have doesn't have problems playing 23,976 fps videos)

Which is what DB83 suggested in post #2. But, depending on how your equipment handles the NTSC video, you may get smoother playback by converting to PAL in software.

[provato]

Really nice explanations, I'm starting to understand the cartoon-tape industry regarding NTSC countries cartoons

Why they chose field blending 59,94 to 50, instead of speeding 24fps to 25 fps, in order to make a pal tape, is beyond my knowledge and comprehension...

I know that dd83 had suggested that I leave the NTSC video, but in most cases I had DTVRip sound that could not be synchronized with the 23,976fps video. I had to speed up the video to 25 fps or change the audio's tempo.
In this case, it seems that "field blending" to achieve 25 fps, maintained the video/audio's duration exactly like the ntsc's video/audio's duration.

[jagabo]

Why they chose field blending 59,94 to 50, instead of speeding 24fps to 25 fps, in order to make a pal tape, is beyond my knowledge and comprehension...

It's simple: they get interlaced NTSC video tape (always 59.94 fields per second) as the source. Then run it through a studio NTSC to PAL converter which outputs 50 blended fields per second. They don't spend time figuring out how best to convert the material.

[hello_hello]

I tried it again hello_hello, and no matter what I do (either in the script or in the preview window) I can't get Megui to encode a 720x576 4:3 video after cropping the black bars. It always encodes in 5:4 DAR, and the video becomes stretched. (Even if I put global MeGUI_darx = 4 AND global MeGUI_dary = 3)

The only way I found to solve this, was to force sar inside x264 to 12:11

Maybe if I tried something else in the script for darx and dary???

I can't imagine what you're doing wrong. If anamorphic encoding is enabled it works for me every single time.
Are you certain the SAR in the x264 encoder configuration is set to "Default"? If you are.....

Run a short encode and switch to the Log tab. Right click on the log file to save it and then copy and paste the contents here. The log file includes the script used, the command line, and the aspect ratio etc. Hopefully it'll indicate what's going wrong.

Or take a look at this one and compare it to yours. It's an encode of the sample you uploaded. I used anamorphic encoding and cropped to remove the crud and to keep the display aspect ratio the same. The Input DAR in the script creator was set to "ITU 4:3 NTSC". There's no need to crop extra if you don't want to, it's just the way I'd do it, but if you apply the same cropping as I did, the end result should be the same. If not, the DAR/SAR will be a little different depending on how you crop. I manually changed the resizing in the script to 720x576. Before encoding I opened the x264 encoder configuration and loaded the defaults. I've highlighted the important bits. The script is in blue, the resolution, DAR and SAR bits are in red. The only time the resolution and aspect ratio should be the same is if the log file shows "using SAR=1/1".

--[Information] Log for job1 (video, 720x576.avs -> 720x576.mkv)
--[Information] [05/01/14 4:52:41 AM] Started handling job
--[Information] [05/01/14 4:52:41 AM] Preprocessing
--[Information] [05/01/14 4:52:41 AM] Avisynth input script
---[NoImage] # Set DAR in encoder to 6480 : 4739. The following line is for automatic signalling
---[NoImage] global MeGUI_darx = 6480
---[NoImage] global MeGUI_dary = 4739
---[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
---[NoImage] DGDecode_mpeg2source("D:\VTS_01_1.VOB.12.d2v")
---[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
---[NoImage] tfm(order=-1).tdecimate(mode=1)
---[NoImage] crop(16, 4, -8, -12)
---[NoImage] Spline36Resize(720,576) # Spline36 (Neutral)
--[Information] [05/01/14 4:52:41 AM] resolution: 720x576
--[Information] [05/01/14 4:52:41 AM] frame rate: 24000/1001
--[Information] [05/01/14 4:52:41 AM] aspect ratio: 6480:4739 (1.367)
--[Information] [05/01/14 4:52:41 AM] Job commandline: "C:\Program Files\MeGUI\tools\x264\x264.exe" --keyint 240 --sar 5184:4739 --output "D:\720x576.mkv" "D:\720x576.avs"
--[Information] [05/01/14 4:52:42 AM] Process started
--[Information] [05/01/14 4:52:42 AM] Standard output stream
--[Information] [05/01/14 4:52:42 AM] Standard error stream
---[Information] [05/01/14 4:52:43 AM] avs [info]: 720x576p 5184:4739 @ 24000/1001 fps (cfr)
---[Information] [05/01/14 4:52:43 AM] x264 [info]: using SAR=5184/4739
---[Information] [05/01/14 4:52:43 AM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
---[Information] [05/01/14 4:52:43 AM] x264 [info]: profile High, level 3.0
---[Information] [05/01/14 4:53:45 AM] x264 [info]: frame I:16 Avg QP:23.36 size: 33770
---[Information] [05/01/14 4:53:45 AM] x264 [info]: frame P:818 Avg QP:25.54 size: 9436
---[Information] [05/01/14 4:53:45 AM] x264 [info]: frame B:680 Avg QP:26.74 size: 2667
---[Information] [05/01/14 4:53:45 AM] x264 [info]: consecutive B-frames: 15.0% 70.5% 14.5% 0.0%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: mb I I16..4: 3.6% 82.4% 14.0%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: mb P I16..4: 0.2% 4.1% 0.7% P16..4: 52.4% 18.0% 10.0% 0.0% 0.0% skip:14.6%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 46.0% 2.2% 0.3% direct: 2.0% skip:49.3% L0:42.6% L1:56.3% BI: 1.1%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: 8x8 transform intra:82.4% inter:76.2%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: coded y,uvDC,uvAC intra: 88.5% 81.3% 40.8% inter: 30.3% 31.3% 0.3%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: i16 v,h,dc,p: 66% 9% 4% 20%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 15% 21% 6% 7% 7% 9% 8% 9%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 17% 14% 6% 9% 9% 10% 6% 6%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: i8c dc,h,v,p: 44% 18% 28% 10%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: Weighted P-Frames: Y:16.1% UV:3.1%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: ref P L0: 53.8% 18.9% 16.6% 9.3% 1.4%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: ref B L0: 80.6% 18.0% 1.3%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: ref B L1: 96.8% 3.2%
---[Information] [05/01/14 4:53:45 AM] x264 [info]: kb/s:1276.07
---[Information] [05/01/14 4:53:45 AM] encoded 1514 frames, 24.05 fps, 1276.16 kb/s

[provato]

@ hello_hello:

I don't get this at all if I follow your instructions:

global MeGUI_darx = 6480
global MeGUI_dary = 4739

Instead, I get this in the "avs script creator" after I enable "anamorphic" - "resize to selected mod" AND change the "resize" field to anything, as you suggested (no cropping):

# Set DAR in encoder to 67 : 49. The following line is for automatic signalling
global MeGUI_darx = 67
global MeGUI_dary = 49

Note: Megui finds the "input DAR" to be "ITU 4:3 NTSC"


Megui Log:

(I just added TIVTC, crop, resize to 720x576 manually, undot, and set the x264's "force SAR" option to "default")

[Warning] Log for job4 (video, VTS_01_1.avs -> )
-[Information] [4/1/2014 9:07:12 μμ] Started handling job
-[Information] [4/1/2014 9:07:12 μμ] Preprocessing
-[Information] [4/1/2014 9:07:12 μμ] Avisynth input script
--[NoImage] # Set DAR in encoder to 4 : 3. The following line is for automatic signalling
--[NoImage] global MeGUI_darx = 4
--[NoImage] global MeGUI_dary = 3
--[NoImage] LoadPlugin("N:\Προγράμματα\--==VIDEO TOOLS==--\MeGUI\tools\dgindex\DGDecode.dll")
--[NoImage] DGDecode_mpeg2source("C:\Users\Provato\Desktop\VTS _01_1.d2v", info=3)
--[NoImage] LoadPlugin("N:\Προγράμματα\--==VIDEO TOOLS==--\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
--[NoImage] ColorMatrix(hints=true, interlaced=true, threads=0)
--[NoImage] LoadPlugin("N:\Προγράμματα\--==VIDEO TOOLS==--\MeGUI\tools\avisynth_plugin\TIVTC.dll")
--[NoImage] tfm(order=-1).tdecimate()
--[NoImage] crop(8, 0, -10, 0)
--[NoImage] Spline64Resize(720,576) # Spline64 (Sharp)
--[NoImage] LoadPlugin("N:\Προγράμματα\--==VIDEO TOOLS==--\MeGUI\tools\avisynth_plugin\UnDot.dll")
--[NoImage] Undot() # Minimal Noise
-[Information] [4/1/2014 9:07:12 μμ] resolution: 720x576
-[Information] [4/1/2014 9:07:12 μμ] frame rate: 24000/1001
-[Information] [4/1/2014 9:07:12 μμ] aspect ratio: 4:3 (1.333)
-[Information] [4/1/2014 9:07:12 μμ] Job commandline: "N:\Προγράμματα\--==VIDEO TOOLS==--\MeGUI\tools\x264\avs4x264mod.exe" --level 4.1 --preset slow --tune animation --pass 1 --bitrate 1200 --stats "C:\Users\Provato\Desktop\VTS_01_1.stats" --deblock -1:-2 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --sar 16:15 --output NUL "C:\Users\Provato\Desktop\VTS_01_1.avs"
-[Information] [4/1/2014 9:07:12 μμ] Process started
-[Information] [4/1/2014 9:07:12 μμ] Standard output stream
-[Warning] [4/1/2014 9:07:12 μμ] Standard error stream
--[Information] [4/1/2014 9:07:14 μμ] raw [info]: 720x576p 16:15 @ 24000/1001 fps (cfr)
--[Information] [4/1/2014 9:07:14 μμ] x264 [info]: using SAR=16/15
--[Warning] [4/1/2014 9:07:14 μμ] x264 [warning]: VBV bitrate (62500) > level limit (50000)
--[Warning] [4/1/2014 9:07:14 μμ] x264 [warning]: VBV buffer (78125) > level limit (62500)
--[Information] [4/1/2014 9:07:14 μμ] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
--[Information] [4/1/2014 9:07:14 μμ] x264 [info]: profile Main, level 4.1


OOOOPS!!! The final video (according to mediainfo) is 720x576 4:3!!! I just noticed that
But is everything ok with my log? Because it's very different from yours hello_hello.... Mine says that SAR=16:15, and aspect ratio=1.3333

[manono]

why? ---> For educational purposes. I want to compare two anamorphic encodings of the same video: Both will be 720x576 PAL 4:3. But one will be "born" from a PAL DVD, and the other from the NTSC DVD.

Compare? You can compare PAL and NTSC DVDs just as easily as 23.976fps and 25fps MP4s. And, as mentioned, since everything that plays MP4s will play both framerates just as easily, better would be to use the original framerate. That would be 23.976fps, as it has to have another audio of the same length muxed with it.

I'm partly to blame here because after the first mention of DGPulldown I forgot you clearly stated you were making MP4s. As for making a 25fps MP4 from a 23.976fps source, the only decent way is with an AssumeFPS(25) line in the script which means also reencoding the audio to match. I don't consider purposely making it play jerky (ChangeFPS) or blending it (ConvertFPS) as acceptable. However, with anime which plays jerky anyway, ChangeFPS might work since it's for 'educational purposes'.

[hello_hello]

OOOOPS!!! The final video (according to mediainfo) is 720x576 4:3!!! I just noticed that
But is everything ok with my log? Because it's very different from yours hello_hello.... Mine says that SAR=16:15, and aspect ratio=1.3333

The difference is due to a setting which effects the way MeGUI calculates the DAR/SAR. I've not changed it for so long I'd almost forgotten about it until now. It's kind of hidden away...... but don't forget you also applied different cropping which effects the final SAR too.

Open the Script Creator. Under the I/O tab you'll see the drop down box next to "Avisynth Profile". That's where Avisynth templates are created/selected. It's similar to the way encoder presets are edited/saved. Click on the Config button next to the drop down box. When the window opens, switch to the Extra Setup tab. The setting in question is the one labelled "acceptable aspect error". It's set to 1% by default. If you change it to 0% MeGUI should give you the same DAR/SAR as it did for me.

The acceptable aspect error setting only effects the DAR/SAR calculations for anamorphic encoding. The idea, I assume, is to make it easier to crop and still achieve an exact 4:3 or 16:9 display aspect ratio by allowing MeGUI to "round" the DAR/SAR calculations. The higher the acceptable aspect error, the more MeGUI can "round", or the more it can "fudge" the aspect ratio.
If "acceptable aspect error" is higher than 0%, when anamorphic encoding is enabled and you crop or resize, you'll probably see the reported "aspect ratio error" change accordingly because MeGUI is "rounding". It should never go higher than the specified percentage. When the "acceptable aspect error" is set to 0%, the reported "aspect ratio error" should always be 0% too.
Sorry.... I've had it set to 0% for so long it didn't occur to me it's not the default setting and therefore maybe I should mention it.

The options under the Extra Setup tab can be configured independently for any template/preset you create. While you're there.....
Uncheck "Colour Correction". It adds the colormatrix stuff to a script for mpeg video. It's a relic from a bygone era which won't do anything when converting DVDs but it can potentially convert the colours incorrectly if you're converting HD mpeg2 video. It should at least be disabled by default.
Check "Upsizing allowed". Why it's disabled by default I'm not sure. I generally resize 16:9 DVDs "up" to square pixels so I don't need to worry about players displaying anamorphic video correctly. That'd mean something like 854x480 for NTSC and 1024x576 for PAL (before cropping). It increases the file size compared to resizing "down" (ie 720x400) but it tends to retain more fine detail (often I use 960x540 for 16:9 PAL to reduce the file size a little, as I can't see any loss of detail compared to 1024x576). Plus if you use a sharpish resizer (I tend to use Spline36) resizing "up" can result in the encode looking a little sharper than an anamorphic encode would (at least for 16:9 PAL).

Under the Template tab you can add whatever you'd like to use in a script. You can also prevent MeGUI from adding things itself. As an example, if you delete <resize> from the template, the Script Creator's resizing will still function as it normally would, but it won't be added to the script. If you add things, just be careful of the order..... mainly when it comes to de-interlacing. As a rule you'd want that to come before any other filtering.

PS. Don't rely on MediaInfo to give you exact aspect ratios. It does lots of rounding. You can get a more exact aspect ratio by opening a video with MPC-HC and using the File/Properties menu. If the aspect ratio and the resolution is the same (ie square pixels) it'll only display the resolution. If they're different, it'll display both. This is what MPC-HC shows for the encode of your sample I did yesterday (MediaInfo says it's 4:3).



Or you could even open the encoded video with MeGUI as though you were going to re-encode it. The script creator should display the correct Input DAR.

For the record..... no software players I know of use ITU resizing for DVDs. They all resize to exactly 16:9 or 4:3, so if you compare an "ITU encode" with the original DVD video and the aspect ratio looks a little different, that'd probably be why.

Also for the record..... MeGUI seems to calculate the DAR/SAR when a script is loaded for encoding, so don't change the resizing in a script after it's been loaded. If you do, MeGUI will effectively try to correct the aspect ratio when you're not using anamorphic encoding. I haven't tested it to find out if changing the resizing/DAR in the script when using anamorphic encoding would have adverse effects, but it's probably best to play it safe.
If you change them, re-load the script or use the "re-open video preview" button before adding the encoding job to the queue.

[provato]

Ok, hello_hello, I think you had mentioned this 0% acceptable aspect ratio a few posts back. I'll change it to 0% and let you know if it's ok later today.

Thank you for the great MPC-HC "properties" way of seeing the DAR & SAR of a video!!!! This will help me a lot
I'll change the "colour correction" and "upsizing allowed" settings too. I was searching for these settings too (but couldn't find any) to change them anyway!
I don't really get though, what the difference between ITU 4:3 and 4:3 is....
Also, exactly when do you propose I should change the "resize" manually in the script, to make it 720x576? After I enable anamorphic encoding? Or maybe you say that I should always hit "re-open video preview" and then add the job to the queue, right after I change to 720x576 manually?


EDIT:

I checked the "file properties" of MPC-HC, in the file that was encoded with the megui log I pasted here yesterday:

-Video Size: 720 x 576 (AR 4:3)

-Video: MPEG4 Video (H264) 720x576 (4:3) 23.98fps 1199kbps [Video]
Audio: AAC 48000Hz stereo 126kbps [Audio]

So, MPC-HC also says (like mediainfo) that this video is 4:3 and not something else like in your mkv example!!! Isn't that what I want? So, why should I change the "aspect ratio error" setting?


EDIT #2:

If I open the same file for reencoding in MeGUI (your second method to see the correct AR), the "avs script creator" shows:

Input DAR: ITU 4:3 PAL (1.367521)

[hello_hello]

I don't really get though, what the difference between ITU 4:3 and 4:3 is....

"ITU" is the "official" DVD resizing method but not all DVDs seem to use it. There's no way to tell for sure which method was used, although sometimes you can find a spot in the video where there's a direct-on shot of something which must be round and then compare resizing methods to see which way it looks round. Aside from that.....
The ITU resizing method isn't exactly 4:3 or 16:9. I think it's always a little wider. The difference isn't huge.... something like 2.5%. As a "rule of thumb" (mine at least, don't hold me to anything) if a DVD has more than around 8 pixels of black bars down each side of the picture (or more than a total of 16 if they're uneven) it most likely uses ITU resizing. If the picture extends to the end of the frame (very small black bars at the sides or none at all) it probably requires exact 4:3 or 16:9 resizing. Pretty much all 4:3 DVDs are ITU. Old 16:9 DVDs are more likely to be ITU. Most newer 16:9 DVDs tend to be non-ITU.

If memory serves me correctly I think ITU resizing assumes only 704 pixels of the width is actual picture, but it's resized to 4:3 or 16:9 (so 704x480 or 704x576 becomes 4:3 or 16:9). Therefore when resizing the entire 720 width the same way, the DAR ends up being a little wider than 4:3 or 16:9.

You can over-ride the Input DAR MeGUI uses by changing it manually (ie change "ITU 16:9" to "16:9" etc). There's a setting in MeGUI's options to tell it whether or not to default to ITU resizing. Most programs let you choose one resize method or the other. Handbrake tries to be clever. I'm pretty sure it uses non-ITU resizing until the cropping exceeds a total of 14 pixels from the sides, then it switches to ITU resizing, but I don't think you can over-ride the Input DAR manually.

Also, exactly when do you propose I should change the "resize" manually in the script, to make it 720x576? After I enable anamorphic encoding? Or maybe you say that I should always hit "re-open video preview" and then add the job to the queue, right after I change to 720x576 manually?

You can change it in the script creator just before you save the script, but if you forget and need to change it after the script has been saved, open it with notepad and change it, but if the script is already loaded into the video section for encoding, re-load it or use the "re-open video preview" button before adding it to the job queue for encoding.

I checked the "file properties" of MPC-HC, in the file that was encoded with the megui log I pasted here yesterday:

-Video Size: 720 x 576 (AR 4:3)

-Video: MPEG4 Video (H264) 720x576 (4:3) 23.98fps 1199kbps [Video]
Audio: AAC 48000Hz stereo 126kbps [Audio]

So, MPC-HC also says (like mediainfo) that this video is 4:3 and not something else like in your mkv example!!! Isn't that what I want? So, why should I change the "aspect ratio error" setting?

You mean why change the "acceptable aspect error" setting?
You don't have to, but in your case, because the "acceptable aspect error" was set to 1%, it allowed MEGUI to round the DAR enough to give you exactly 4:3..... but it may have distorted the picture a tiny little bit to do it (the maximum would be 1%). Had the "acceptable aspect error" been 0%, the DAR would have been 6318:4739 which is 1.33319.
Hopefully I'm explaining it well, but for your example the difference between setting the "acceptable aspect error" to 1% or 0% is the difference between distorting the picture a tiny, tiny bit to allow the aspect ratio to be exactly 4:3, or not distorting it and the DAR being a tiny, tiny bit wider than 4:3 instead.
Chances are though, by the time a player opens each video and resizes it to full-screen, which means they've got to be rounded to the nearest pixel when resizing... they'd both end up being resized to the same DAR..... maybe give or take a pixel.

If I open the same file for reencoding in MeGUI (your second method to see the correct AR), the "avs script creator" shows:Input DAR: ITU 4:3 PAL (1.367521)

I'm fairly sure this is the exception to the rule..... MeGUI is getting it wrong. Why.......
MeGUI uses MediaInfo to determine the aspect ratio (far more accurately than MediaInfo displays it when your viewing a file with it), but something like this is happening......
MediaInfo says "this is a video with a 720x576 resolution and a 4:3 aspect ratio" and MeGUI decides "that's PAL" (ie DVD video etc). It's not PAL as such, although it could be, but MeGUI treats it as though it is and opens it using the DAR specified in settings. ie "ITU" in this case.
If you go into MeGUI's settings and uncheck "Use ITU Aspect ratio" MeGUI will default to opening PAL/NTSC video using straight 4:3 or 16:9 resizing. I'd be willing to bet if you uncheck it and open the encode with MeGUI again, this time MeGUI will display "4:3 (1.333333)" as the aspect ratio.
It's just one of those things..... if the resolution was anything other than 720x480 or 720x576, and probably if the aspect ratio was anything other than 4:3 or 16:9....... there wouldn't be any guessing as to the resizing.

MPC-HC always uses 4:3 or 16:9 for PAL and NTSC. No ITU resizing in sight. In this case that just happened to be correct......

[provato]

Well in my case (what I'm trying to achieve with this NTSC to pal conversion) I don't mind a tiny distortion of the video shape.
And since you say that my mp4 player/ TV screen would perform this distortion to achieve 4:3, I'd rather do it myself in megui!
(Because it's important to see the exact same video shape in my pc windowed mode, and in my TV)

Thanks hello_hello, great explaining of Megui behavior!

[hello_hello]

Well in my case (what I'm trying to achieve with this NTSC to pal conversion) I don't mind a tiny distortion of the video shape.
And since you say that my mp4 player/ TV screen would perform this distortion to achieve 4:3, I'd rather do it myself in megui!
(Because it's important to see the exact same video shape in my pc windowed mode, and in my TV)

I'm not sure we're on exactly the same page.
Whether the picture is distorted a little or not during resizing and whether a DVD uses an ITU or non-ITU DAR are two separate things. Sure you can crop an ITU DVD and re-size it to have an exact 4:3 aspect ratio, but you can do that while distorting the picture a little, or while not distorting it (depending how you crop).

I just edited my previous post a bit and added something you may not have read, so I highlighted it in brown. Hopefully that'll help explain why ITU resizing isn't exactly the same as 4:3 or 16:9 a little more clearly.

DVD players/TVs don't distort the picture as such... ITU resizing takes overscanning into account. When standard definition video is displayed by a TV, the TV overscans.... the edges of the picture are off the sides of the screen (when a 16:9 TV is running in 4:3 mode it still does the same thing). That's why you see the black bars down the sides when displaying DVD video on a PC monitor (which doesn't overscan) or when re-encoding it, but not when using a TV.

[jagabo]

I don't really get though, what the difference between ITU 4:3 and 4:3 is....

"ITU" is the "official" DVD resizing method

If you look at the DVD spec it refers to the MPEG 2 spec for aspect ratios. The MPEG 2 spec is very clear -- the full frame comprises the display aspect ratio unless a sequence display extension indicates otherwise.

Provato, the problem is as follows:

The ITU spec for digitizing standard definition analog video specifies particular sampling rates -- ie, it specifies the pixel aspect ratio (aka sample aspect ratio). The result is that the 4:3 picture was contained in a ~704 pixel wide frame*. But it was common practice to capture and save a slightly wider image, 720 pixels, to include part of the horizontal blanking period, so you wouldn't lose part of the picture if the image was slightly off center. So the full 720 pixel wide frame represents something a little wider than 4:3, about 1.36:1.

The MPEG 2 spec only allows a handful of display aspect ratios: 4:3, 16:9, and 2.21:1. The only pixel aspect ratio you can specify is 1:1 (where the display aspect ratio is the same as the frame size aspect ratio). And it specifies that the entire encoded frame comprises the aspect ratio. It provides a mechanism by which other display aspect ratios can be defined (sequence display extension) but I've never seen this used to compensate for the difference between ITU and MPEG2 aspect ratios.

So both DVD and ITU use a 720 pixel wide frame but they differ on what the display aspect ratio of that full frame is. DVD = 1.33:1, ITU = 1.36:1. Ie, the differ on the pixel aspect ratio.

When MPEG 2 encoding an ITU captured 720 pixel wide frame for DVD the difference between the ITU spec and the MPEG 2 spec is usually ignored. The 720 pixel wide image is simply flagged as 4:3 DAR. This could be avoided by using a 704 pixel wide frame but nobody in the industry seems to care. I've never seen a commercial DVD with 704x480 or 704x576 frame size.

In my experience, most DVDs made from analog tape follow the ITU spec; many (most?) non-video sources follow the DVD spec. If you look at what DVD players do, they tend to be schizophrenic. The players I've personally tested use ITU at the composite and s-video outputs, MPEG 2 at the upscaled HDMI outputs.

If you're a real stickler for exact aspect ratios you'll determine whether the correct DAR for your DVD is 1.33:1 or 1.36:1 and handle it accordingly. If there are obvious 8 pixel black borders at the left and right edges I'll trim them away if convenient. But you won't really notice the ~2 percent difference on casual viewing.

The equation that relates aspect ratios:

DAR = FAR * PAR

DAR = display aspect ratio, the shape of the final displayed image
FAR = frame aspect ratio, the frame dimensions
PAR = pixel aspect ratio, the shape of individual pixels

For example, with an ITU 704x480 capture:

DAR = FAR * PAR
4:3 = 704:480 * PAR
4/3 = 704/480 * PAR
(4 * 480) / (3 * 704) = PAR
1920 / 2112 = PAR
(divide both by 192)
10 / 11 = PAR
10:11 = PAR

For an MPEG 2 720x480 frame:

DAR = FAR * PAR
4:3 = 720:480 * PAR
4/3 = 720/480 * PAR
(4 * 480) / (3 * 720) = PAR
1920 / 2160 = PAR
(divide both by 240)
8 / 9 = PAR
8:9 = PAR

* with PAL video the 4:3 image is in a ~702 pixel wide portion of the frame. That's usually just rounded to 704 for convenience.