Need some pointers understanding x264-codec.

[bananacreamandpeca]

Hi,


I re-encoded an xvid-video (700MB, mp3-vbr, 640x352) to x264/mp4 with Megui.
I did 2 versions (both with same postprocessing),
but 1 with resizing and the other without.

I resized 1 version with avisynth to 296x272
Yet the output size this morning for both encodes, were all 700MB!

I used Megui/default profile. I thought the resized one would be smaller in size???
What dont I understand?
I want to let x264 decide wich bitrate to use for the video.
Yet all are 700MB.

Help please.


Here's the log:

Log for job job1

avis [info]: 640x352 @ 23.98 fps (136562 frames)
x264 [warning]: VBV maxrate specified, but no bufsize.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 0 (scale 2997)
x264 [info]: slice I:561 Avg QP:11.47 size: 15031
x264 [info]: slice P:136001 Avg QP:14.41 size: 5175
x264 [info]: mb I I16..4: 69.3% 0.0% 30.7%
x264 [info]: mb P I16..4: 20.4% 0.0% 1.8% P16..4: 24.9% 18.0% 9.8% 0.0% 0.0% skip:25.2%
x264 [info]: final ratefactor: 16.69
x264 [info]: SSIM Mean Y:0.9975554
x264 [info]: kb/s:1000.4

encoded 136562 frames, 10.88 fps, 1000.40 kb/s

desired video bitrate of this job: 1000 kbit/s - obtained video bitrate (approximate): 1001 kbit/s
----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated
Starting job job2 at 5:50:39
encoder commandline:
--bitrate 1000 --analyse p8x8,b8x8,i4x4 --vbv-maxrate 25000 --thread-input --progress --no-psnr --output "C:\dda re-edits496x272bilin.mp4" "C:\dda re-edits496x272bilin.avs"
successfully started encoding
Processing ended at 8:10:09
----------------------------------------------------------------------------------------------------------

Log for job job2

avis [info]: 496x272 @ 23.98 fps (136562 frames)
x264 [warning]: VBV maxrate specified, but no bufsize.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 0 (scale 2997)
x264 [info]: slice I:570 Avg QP:10.00 size: 11567
x264 [info]: slice P:135992 Avg QP:10.93 size: 5187
x264 [info]: mb I I16..4: 71.1% 0.0% 28.9%
x264 [info]: mb P I16..4: 27.8% 0.0% 1.4% P16..4: 29.7% 17.6% 9.1% 0.0% 0.0% skip:14.4%
x264 [info]: final ratefactor: 12.81
x264 [info]: SSIM Mean Y:0.9980845
x264 [info]: kb/s:1000.0

encoded 136562 frames, 16.35 fps, 1000.01 kb/s

desired video bitrate of this job: 1000 kbit/s - obtained video bitrate (approximate): 1000 kbit/s
----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated

[GmorG McRoth]

If I understand what you ask properly:

Frame Size does not matter, only bitrate.
You resized frames but left bitrate of encode at same level. thats why final encode had same file size.

To make x.264 set bitrate you should set, instead of 2 pass mode, constant quality or constant quantizer mode.

[DarkZell666]

GmorG McRoth you understood perfectly :p

@bananacreamandpeca : x264 works just like any other codec. If you ask it to use 1000kbps, it will use 1000kbps. If you want it to give you a certain quality, ask it to use crf or cqp modes (each being constant "quality" and constant quantizer).

If you told it to use 1000kbps, it will use 1000kbps, no matter width/height of the frames.

Look at the final ratefactor value:16.69 in the first case, and 12.81 in the second case. Those values are very good (the lower, the better).

But I guess you don't understand correctly how MeGUI works (and I won't blame you for that, I also have trouble with it :p).

[bananacreamandpeca]

Sorry if my Question was a bit hard to understand.

I just used the default profile within Megui/x264
And didnt know the 1000kbps was standard, Ok. it makes sense now :p

How can I let x264 decide for itself what bitrate is needed
drung encoding? VBR?
I want to see how small I can let the output become,
without much quality loss. With such good ratefactor
values at 1000kbps, I can certainly downsize the bitrate a bit for this content am I right?

Also: Can I let Megui transfer and Mux the source audio with the new output-video without the need to re-encode it?

[DarkZell666]

Try using CRF18 or CRF20 and watch the bitrate come down :)

[bananacreamandpeca]

Thank you 'DarkZell666'
I do have a few questions yet.

If I understand correctly:

*This "CRF" Means Constant Rate Factor?
And is this CRF the same as the "Final rate factor"
I see in the x264 log?

ie: "x264 [info]: final ratefactor: 16.69"

* I let Megui encode 1 testvideo with "Constant Quantizer 18"
What I notice aferwards is that the video became real small in size.
But it takes like forever to start playing in VLC!
I can't fast forward either, that takes like forever to start playing again.
Why is that, Aren't there enough Key-frames used?

Heres the log:

Starting job job1 at 5:38:53
encoder commandline:
--qp 18 --analyse p8x8,b8x8,i4x4 --thread-input --progress --no-psnr --output "f:\dda re-edits496x272bilin.mkv" "C:\dda re-edits496x272bilin.avs"
successfully started encoding
Processing ended at 7:18:52
----------------------------------------------------------------------------------------------------------

Log for job job1

avis [info]: 496x272 @ 23.98 fps (136562 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:548 Avg QP:15.00 size: 6820
x264 [info]: slice P:136014 Avg QP:18.00 size: 1355
x264 [info]: mb I I16..4: 71.6% 0.0% 28.4%
x264 [info]: mb P I16..4: 8.1% 0.0% 0.4% P16..4: 15.7% 9.5% 3.3% 0.0% 0.0% skip:63.0%
x264 [info]: SSIM Mean Y:0.9942056
x264 [info]: kb/s:264.1

encoded 136562 frames, 22.77 fps, 264.13 kb/s
This is a CQ job so there's no desired bitrate. Obtained video bitrate: 266 kbit/s
----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated

*I still need help on howto transfer the source-audio to the new
encodes.

*What's the difference between "Constant Quantizer",
and "Constant Quality" in the x264 settings, Are they the same?

[foxyshadis]

*This "CRF" Means Constant Rate Factor?
And is this CRF the same as the "Final rate factor"
I see in the x264 log?

ie: "x264 [info]: final ratefactor: 16.69"
Basically. After the two-pass encoding, it'll give you the crf value that would give approximately the same size output, which will be approximately the same quality.

* I let Megui encode 1 testvideo with "Constant Quantizer 18"
What I notice aferwards is that the video became real small in size.
But it takes like forever to start playing in VLC!
Usually, if you remux with yamb (mp4) or mkvmerge, it'll play normally. Because the index in these formats is at the beginning of the file, not the end, x264 doesn't write a full index. You have a normal # of keyframes in there.

*I still need help on howto transfer the source-audio to the new encodes.
Just remux the old audio into the new, if it's mkv. If mp4, you'll have to convert into mp3 or aac first.

*What's the difference between "Constant Quantizer",
and "Constant Quality" in the x264 settings, Are they the same?

No, for the same size quality (crf) is almost always better perceptual quality. It's similar to ABR in that the quants fluctuate, so hard scenes don't look quite as good, but usually not nearly as bad or as fluctuating as ABR mode. If you're not targeting a specific bitrate it's the way to go.

[bananacreamandpeca]

Usually, if you remux with yamb (mp4) or mkvmerge, it'll play normally. Because the index in these formats is at the beginning of the file, not the end, x264 doesn't write a full index. You have a normal # of keyframes in there.

I just muxed the audio with the mkv-video.
But the muxed result still takes forever (10 sec.) before playing with VLC...
I tried this with both MKV-muxer in Megui and MKVMerge.

What could be wrong?
Could it be the conent has lots of still backdrop wich in turn means the encode will have lots of
intermediate frames and less key frames or whatever?
goddammnit, why is video coding so painstakingly hard?
Ir freaking took me 1.5 month read up on all this and I still dont understand it all.
Whats wrong?

No, for the same size quality (crf) is almost always better perceptual quality. It's similar to ABR in that the quants fluctuate, so hard scenes don't look quite as good, but usually not nearly as bad or as fluctuating as ABR mode. If you're not targeting a specific bitrate it's the way to go.

So wich one is the "CRF" in Megui/x264, The "Constant quality" or "Constant Quantizer"-option ?

[DarkZell666]

Just to save you an extra week reading :

Constant Quality = CRF (which literally means: Constant Rate Factor, but doesn't mean much else for the end user :p)
Constant Quantizer = CQP

I don't have a clue about long playback starting times though ... try with mpui just in case ? (http://mulder.brhack.net/public/downloads/MPUI.2006-12-03.Full-Package.exe)

Cheers ;)