Log in

View Full Version : Strange x264 undersizing


dimzon
7th April 2008, 15:41
Hi!
I decide to encode complete LOTR trilogy (3xDVD9 PAL) to fit it onto one DVD5. To obtain best bitrate distribution I decide to join them all together into one AviSynth script and encode as one long movie. My script is here:
function src(d2v,ac3)
{
v = mpeg2source(d2v)
#a = nicac3source(ac3,drc=1)
return v #audiodub(v,a)
}

s1= src("C:\LOTR_THE_FELLOWSHIP_OF_THE_RING\VIDEO_TS\aaa.d2v", "C:\LOTR_THE_FELLOWSHIP_OF_THE_RING\VIDEO_TS\aaa t01 3_2ch 448kbps delay 0ms.ac3")
s2= src("C:\LOTR_TWO_TOWERS\aaa.d2v", "C:\LOTR_TWO_TOWERS\aaa t01 3_2ch 448kbps delay 0ms.ac3")
s3= src("C:\LOTR_RETURN_OF_THE_KING\aaa.d2v", "C:\LOTR_RETURN_OF_THE_KING\aaa t01 3_2ch 448kbps delay 0ms.ac3")

s1 ++ s2 ++ s3
crop(0,80,0,-80)


fft3dfilter(sigma=2, plane=4, sharpen=0.5)


To save some bits i decide to use zone feature for credits for each part.

I'm using such x264 build (containing AQ path)
C:\Program Files (x86)\megui>x264.exe --version
x264 0.58.798M 17e5dac

1st pass:
"C:\Program Files (x86)\megui\x264.exe" --pass 1 --bitrate 907 --stats "C:\LOTR\lotr_video.stats" --ref 10 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --me umh --merange 24 --threads auto --thread-input --zones 245542,256599,q=45/503502,514698,q=45/790988,803862,q=45 --sar 1697:1250 --progress --no-dct-decimate --output NUL "C:\LOTR\lotr_video.avs"

2nd pass:
"C:\Program Files (x86)\megui\x264.exe" --pass 2 --bitrate 907 --stats "C:\LOTR\lotr_video.stats" --ref 10 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --me umh --merange 24 --threads auto --thread-input --zones 245542,256599,q=45/503502,514698,q=45/790988,803862,q=45 --sar 1697:1250 --progress --no-dct-decimate --output "C:\LOTR\lotr_video.mp4" "C:\LOTR\lotr_video.avs"

problem: x264 reports:
encoded 803862 frames, 6.40 fps, 907.12 kb/s
but actual bitrate is 681kbps
another problem - there are "frozen" zone - from 5:11 to 7:40 - decoder doesn't decode it (even ffdshow osd current frame is frozen)

bob0r
7th April 2008, 16:20
Your second pass does not exist?
2x --pass 1.

buzzqw
7th April 2008, 16:21
doubt: is zones working with AQ ?

BHH

EDIT: 2093 minutes of encoding, 34hours :eek:

dimzon
7th April 2008, 17:07
Your second pass does not exist?
2x --pass 1.
Ups. First post edited.


BHH
EDIT: 2093 minutes of encoding, 34hours :eek:

34hours per ONE pass :)

bob0r
7th April 2008, 18:03
Try to make a 1 minute reproducable sample, using x264.nl build or a similar GIT code x264 build.

Also pass1 doesn't have to be that slow at all, but whatever makes you feel better :p

lexor
7th April 2008, 18:22
Also pass1 doesn't have to be that slow at all, but whatever makes you feel better :p

Why not? For a combination of all 3 LOTR, that's like 10hours if he didn't use the extended versions, so that's ~3.4x real length to encode. A 2 hour encode (with HQ settings) would take me 18 hours (for both passes) that's ~4.5x real length to encode. Depending on the CPU, he's actually doing pretty good.

dimzon
7th April 2008, 18:50
Seems like it's some unhandled x264 I/O error.
After remuxing mp4 to mkv I got increased filesize (3.5Gb) comparing to mp4 (2.5Gb) and "frozen" zone still exists.
Seem's like this mp4 is damaged...

lexor
7th April 2008, 19:17
btw, did you try opening the avs and jumping to the frozen part, does that play?

Ranguvar
7th April 2008, 19:57
Sometimes I notice different apps give different numbers for the bitrate. Try MediaInfo, GSpot, and maybe a few others, one might give exactly what x264 said.

talen9
7th April 2008, 20:20
Sometimes I notice different apps give different numbers for the bitrate. Try MediaInfo, GSpot, and maybe a few others, one might give exactly what x264 said.

AVInaptic could be a feasible option too :)

dimzon
8th April 2008, 12:24
btw, did you try opening the avs and jumping to the frozen part, does that play?
yes, it plays fine
As i said before seems like this mp4 file is damaged. I doesn't know why - hardware falture or some bug in x264 or some bug in GPAC...