x264 development

[Manao]

Actually, Ateme codec has an option to encode at x.xx times the realtime speed. It works roughly as akupenguin described, and that does the job very well.

[Marsu42]

Originally Posted by akupenguin

My intended method of realtime streaming (if I ever implement it) is: Have some list of presets at different speeds, and select between them based on how full the encoding buffer is. That would be "constant fps"; I don't plan to implement "average fps", but it wouldn't be any harder.

Constant fps should do ok for my purpose, too, but I guess when encoding a dvd through an avs script x264 is the bottleneck, so the encoding buffer would be alway full and the lowest quality options would be locked in? Therefore, it would be nice - if possible - to have this --fps switch which tells x264 when to reduce quality and gain speed as an alternative to measurement of the buffer.

[akupenguin]

The speed option would control how fast input frames are copied into the buffer.

[mgh]

The latest profiles do not have adaptive quantization?

[unmei]

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all"

[Yong]

Ive noticed this problem sometime already(XviD have the same problem too)...
the video look flashy with some blockiness when it fade-out(white to black).

Here is the link for the part of x264(rev389 with AQ, subme7.. patch applied) encoded video snapshot(png):
http://rapidshare.de/files/9978648/x...apshot.7z.html
i can upload the full x264 encoded if someone really need to watch it
Here is the link to original source:
http://www.sp-janis.com/download/heaven_anime.mpg

Please correct me if im wrong, here is the x264 options i used:

start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 3 -r 1 -f -6:-6 -A none -w -m 1 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress --b-pyramid
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 3 -r 5 -f -6:-6 -A all -m 7 -w --chroma-qp-offset 2 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress --b-pyramid --me umh -8 --mixed-refs -t 2 --aq-strength 1.1 --aq-sensitivity 15 --b-rdo

Now im tring to encode with higher bitrate see the problem solved or not

[nm]

The answer is right above your post: try --no-fast-pskip instead of AQ.

[Yong]

Originally Posted by nm

The answer is right above your post: try --no-fast-pskip instead of AQ.

Nope, the problem still persist after i removed aq options and add --no-fast-pskip.
But the flashy and blockiness reduced alot @ 600kbps

[nm]

You have set the deblocking parameters to very low values. That probably causes blocking at low bitrates, so it's better to try the default values (0) first.

By the way, there are also thin black borders left in your sample images. It is better to crop the borders entirely if you aim for maximal quality.

[Yong]

Originally Posted by nm

You have set the deblocking parameters to very low values. That probably causes blocking at low bitrates, so it's better to try the default values (0) first.

By the way, there are also thin black borders left in your sample images. It is better to crop the borders entirely if you aim for maximal quality.

The blockiness and flashy problem still there even set loop filter alpha:beta to 6:6...

and the source is 640x480 and the x264 encoded was cropped with .Crop(0,56,-0,-56), =640x368, no more black borders already

[nm]

Originally Posted by Yong

and the source is 640x480 and the x264 encoded was cropped with .Crop(0,56,-0,-56), =640x368, no more black borders already

There is a 1-pixel dark line on top even if you crop with (0,64,-0,-64) so for "best" results you'll need to crop 15 lines of actual image with (0,72,-0,72).

[Yong]

Originally Posted by nm

There is a 1-pixel dark line on top even if you crop with (0,64,-0,-64) so for "best" results you'll need to crop 15 lines of actual image with (0,72,-0,72).

The problems still there even i cropped the video clips with (0,72,0,-72)....
May be im not suppose to encode video clips at such low bitrate

[foxyshadis]

Have you tried removing b-frames? For extremely low bitrates they're not really a good idea, and in fact, deaththesheep had a few other suggestions in his quality guide.

[Yong]

Originally Posted by foxyshadis

Have you tried removing b-frames? For extremely low bitrates they're not really a good idea, and in fact, deaththesheep had a few other suggestions in his quality guide.

Just now i finished the encoding with this options:

start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 0 -r 1 -A none -w -m 1 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress --no-fast-pskip 
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 0 -r 5 -f -w -m 7 --me umh -t 2 --chroma-qp-offset 2 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress --no-fast-pskip --mixed-refs

I still couldnt get rid those flashy and blocky problem...

forgot to mention, the video snapshot i uploaded all are p-frames.

Here is the link to download the splitted mkv:
http://www.geocities.com/y0ngc/heaven_anime-002.zip
(thnks for someone reminds me that MKVtoolnix have splitting function )

[bond]

Originally Posted by unmei

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all"

fastpskip has been changed too, so it doesnt show the blue blocks problem anymore

[redfordxx]

Originally Posted by unmei

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all"

Does it mean, that once using --no-fast-pskip option, some AQ settings couldn't add any quality at all?

[bond]

Originally Posted by redfordxx

Does it mean, that once using --no-fast-pskip option, some AQ settings couldn't add any quality at all?

no, "some" AQ can still add quality, but not the AQ that has been tested till now

so to say there were two fixes for the blue blocks problem:
1) the AQ patch from haali
2) a tuned fastpskip

as solution 2) was chosen, so there is no need for 1) anymore

[nm]

I tried Yong's source with the default (tuned) fastpskip, and there is annoying flicker and blocking in the end. 256 kbps is a low bitrate, so edges are not so sharp anymore, but the blocking is generally stationary and not so annoying elsewhere in the clip. The slow fade seems to trigger it.

[squid_80]

Does anyone have any idea how to extend x264.c to print the avisynth error when it fails to open a script? I got it to work but unfortunately it only works by compiling as c++ rather than c and I'd prefer not to do that.

[redfordxx]

I've been doing 1sp pass now and the power supply failed. Some precious encoding time already behind, so I continue with --seek option (with 1000 frames overlap). Then will I join the stat files. I will have to renumber the second stats file because x264 starts numbering the frames from zero again.

Wouldn't it be useful to keep original frame numbers?


BTW: Capital 'I' is the IDR frame in stats file - that's where I can join it, correct?
When on the topic already: is somewhere the stats file syntax description to find?