x264 - new pass with different dimensions, is it OK?

[kurbads]

Is it OK to change source dimensons via framserving and to run another pass.
Will x264 be able to use stats form previous runs correctly, or not?

I ran 5 passes of 3 hour FHD movie to fit on DVD9. It took me 28 hours. Now I see the results are not satisfying and want to downsample it to 720p and encode with same bitrate. May I run the new pass with same stats file or I have to create new one?

What essentialy is written in the stats file. If they are motion vectors, will x264 codec "resize" the information according to new data? Because other information like frame weight and key frame location should be the same, or not.

Will I loose more if I keep 28h encoding imformation?

[poisondeathray]

Nope, won't work properly

[creamyhorror]

I ran 5 passes of 3 hour FHD movie to fit on DVD9. It took me 28 hours.

What the...how are you even doing 5 passes, and why would you even want to...

[kurbads]

What the...how are you even doing 5 passes, and why would you even want to...

You do not sound like you want an explanation, do you?

But I cann't still miss a chance!

It takes me 28h because it is only C2D. Now I start to understand why there exist 8 core CPUs.
I ran first quick 4h pass in the evening, and left PC during the night to run 2 8h passes.
Wasn't satisfied fith results - left another night two more passes.
Still not satisfied - start over. I wish to see if it is possible to fit 3h FHD movie on the single double layer DVD thats all.
I see it is not. Even the 32Gb original in MPEG2 BR original has visible 8x8 pixel blocks.
Now I wish to see if at least 720p can be fit.
By the way SD Mpeg2 encodings with CCE my PC handls at 7x. I run 2 passes of 3h movie in less than an hour.
Mpeg4 part 10 is a new thing for me. But I already hate to see some 15Mbit encodings with less than inferior quality. Other H.264 codecs realy do encode faster but they are far from exelence of x264.

[poisondeathray]

You're wasting your time...

x264 quality gains for 3pass vs. 2pass are negligible (<0.1-0.5%) , let alone 5pass...

If the original source already has macroblocking, consider preprocessing it (ie. filters)

Unlikely to look good @ 1080p24, because 3hours, assume 192kbps AC3, is ~6.1Mbps average bitrate, assuming .mp4 or .mkv container (5-7% overhead if using transport stream for BD9 use). So unless it's a very still, low complexity movie... it's not going to happen. 720p24 much better choice for this case

[creamyhorror]

Using Avisynth to do light deblocking may help with the visible macroblocks. (You can do it with the MPEG2Source filter's 'CPU' parameter.)

Remember to use one of the recent x264 releases (r1200 and over), which have significant new capabilities that can improve quality dramatically.

720p24 is the best choice.

[kurbads]

Thanks!

[kurbads]

I encoded with 5664 kbits/sec to fit 640Kbit audio. With resolution 1328x720. The results are much better but still far from original. I didn't use the deblocking feature, because I thought it is irrelevant when downsample. Now I will try it and also the latest version of x264. The version I used is from February 26, 2009. It is VFW for use in VirtualDub. Even the latest version is bundeled with 1195 version of x264. So I will have to study the syntax, write a batch file and use x264 CLI.
Here is a script I used to compare result with original:

v1 = AVCSource("Kagemusha.dga")
v1 = Crop(v1,0,20,960,1040)
v1 = Lanczos4Resize(v1,664,720)
v2 = AviSource("Kagemusha.avi")
v2 = Crop(v2,0,0,664,0)
StackHorizontal(v1,v2)

Also should I try BicubicResize instead of Lanczos? The blurier result probably will be easyer to encode.
The blocks are complately gone when the video is downsampled.
Probably only poor results can be obtained from any encoder because the movie is very grainy.

I will use this code for script:

AVCSource("Kagemusha.dga")
Crop(0,20,0,1040)
BicubicResize(1328,720)

And this code for batch:

x264 --bitrate 5664 --pass 1 --stats "G:\Kagemusha.stats" -o "G:\Kagemusha.mkv" "G:\Kagemusha.avs" --threads 2
x264 --bitrate 5664 --pass 2 --stats "G:\Kagemusha.stats" -o "G:\Kagemusha.mkv" "G:\Kagemusha.avs" --threads 2
Pause

By the way it works twice as fast as VFW!
While I wrote this post it is already 4% of 1st pass and PC feels like idle in contrast with VFW.
Most probably it is because of Bicubic instead of Lanczos4!

No pros without cons.
Developers of advanced CL tools often forget about simple details like to include sample syntax into their help.
One can find out if there have to be commas present or not in command line only by try and guess!
Or what those capital letters are -B for example - complately useless. Are they for reviewing purposes?

[ronnylov]

If you want it strictly 720P then the resolution should be 1280x720, otherwise it will not fulfil things like Blu-ray compability. But if you only intend it for computer playback then you can use whatever resolution you like. I don't think you loose much picture if you just crop the sides a bit so it will be 1280x720. Regarding resising I always use spline36resize in avisynth. Use some degraining filter if you want better compressibility.

Personally I like MeGUI and the x264 presets which seems reasonable tuned. MeGUI does use the CLI x264 version. However I am not sure if the latest x264 buids will be updated automatically in MeGUI yet. I have installed one manually, just replacing the original x264.exe with the new one.

[jagabo]

PC feels like idle in contrast with VFW

You can set VirtualDub to idle priority when encoding to get the same thing.

[creamyhorror]

Here is a script I used to compare result with original:

v1 = AVCSource("Kagemusha.dga")
v1 = Crop(v1,0,20,960,1040)
v1 = Lanczos4Resize(v1,664,720)
v2 = AviSource("Kagemusha.avi")
v2 = Crop(v2,0,0,664,0)
StackHorizontal(v1,v2)

You should download AvsP and use it to switch between the same frame from both sources. That's an easier way to see the differences.

Also should I try BicubicResize instead of Lanczos? The blurier result probably will be easyer to encode.

If you want less sharpness, use Spline36Resize like ronnylov suggested.

Probably only poor results can be obtained from any encoder because the movie is very grainy.

x264 --bitrate 5664 --pass 1 --stats "G:\Kagemusha.stats" -o "G:\Kagemusha.mkv" "G:\Kagemusha.avs" --threads 2
x264 --bitrate 5664 --pass 2 --stats "G:\Kagemusha.stats" -o "G:\Kagemusha.mkv" "G:\Kagemusha.avs" --threads 2
Pause

You should be using the --tune film or --tune grain switches. Also, what preset are you using? x264 now emphasizes the use of presets to improve results. Try --preset slower for high quality. You probably want to use --threads 0 to let x264 choose the number of threads.

No pros without cons.
Developers of advanced CL tools often forget about simple details like to include sample syntax into their help.
One can find out if there have to be commas present or not in command line only by try and guess!
Or what those capital letters are -B for example - complately useless. Are they for reviewing purposes?

You should be consulting a guide for sample commandlines, rather than trying to figure one out yourself. Doom9's MPEG-4/AVC forum is the place to see what other people are doing. There should also be guides here on Videohelp.

[kurbads]

Thank you for the great input. You opened new horizons for me.

[jagabo]

I like to use Interleave() to compare two videos.

[poisondeathray]

I didn't use the deblocking feature

Generally a bad idea, unless you use very high bitrates for the material. If it's too blurry you can adjust the strengths for alpha and beta (more negative), if it's too sharp and you are getting blocks, adjust it higher (more positive). The usual range is -3 to +3

You can use --longhelp to list switches and options

http://mewiki.project357.com/wiki/X264_Settings
for quick description of settings

[creamyhorror]

Thank you for the great input. You opened new horizons for me.

No problem. Hope you have a good time learning about x264 CLI. Make sure you take a look at the page that poisondeathray linked - it contains all the basics about x264's options.

[kurbads]

preset slower[/b] for high quality

I put did not read carefully your post and set veryslow instead of slower.
I went home yesterday, and today logged into office computer where the encoding goes on and look what I saw

G:\>x264 --preset veryslow --tune grain  --bitrate 5664 --pass 2 --stats "G:\Kag
emusha.stats" -o "G:\Kagemusha.mkv" "G:\Kagemusha.avs" --threads 0
avis [info]: 1280x720 @ 23.98 fps (259825 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 5.0
[21.7%] 56420/259825 frames, 1.91 fps, 5016.58 kb/s, eta 29:36:50

The first, quick pass went at least at 11fps.

Generally a bad idea, unless you use very high bitrates for the material.

It is not I do not use it. I just left it at default setting.

[creamyhorror]

Heh, that's pretty slow for 720p. 'slower' and 'slow' would probably be more to your liking. I do recommend increasing max b-frames to 4 or 5 for your future encodes, because on quite a few movies, x264 seems to use that number of b-frames. It improves quality/bitrate-efficiency although encoding is slowed down slightly. (Just add --bframes 5 to the commandline. Don't use more than 6 for non-animation sources!)

You can see the percentage of b-frames used in the stats output:

x264 [info]: consecutive B-frames: 3.5% 10.8% 20.6% 28.2% 16.8% 4.5% 15.6%

Percentage of frames within a sequence of this many B-frames. P = 1, PB = 2, PBB = 3, etc.