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]

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/x264-Snapshot.7z.html
i can upload the full x264 encoded if someone really need to watch it :rolleyes:
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 :p

[nm]

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

[Yong]

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. :eek:
But the flashy and blockiness reduced alot @ 600kbps :rolleyes:

[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]

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]

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]

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 :p

[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]

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 :p )

[bond]

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]

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]

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?

[LigH]

I have a little annoyance with Sharktooth's download link - not x264 related, more MIME/client behaviour:

When I click on the link for a download (e.g. http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r395.exe at the moment), Opera detects the file type "application/force-download" and wants to save the file as "x264-Std_r395.force-download".

Any ideas how I could convince Opera to use the submitted filename, not a constructed one? In previous versions, there was an option to toggle between "trust MIME type" and "guess by extension", but this does not exist anymore in the options dialog - and I'm not even sure if it would help here. I probably have to edit some config file instead, I'm afraid...

[bob0r]

Change http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r395.exe to

http://files.x264.nl/Sharktooth/x264-Std_r395.exe and it should work.

[virus]

@LigH:
I don't have such a problem when clicking the force.php link in your post. Opera (version 8.5-Win32) shows me type "application/force-download" as you, but when I choose "Save" the filename is simply "x264-Std_r395.exe".

Don't ask me why this happens for you, though. Maybe you can search/ask at the forums over at opera.com - maybe some mess in the config files (did you upgraded from, say, version 7 or older or is it a clean 8.x install?) or perhaps you unintentionally changed something in Tools->Preferences->Advanced tab->Downloads?

[LigH]

It was an update.

And I wonder what I could "mess up"... I just changed the settings from "Show download dialog" to "Save to disk" (or similar, I'm using the german language file).

But meanwhile, x264-Std_r395.exe does not exist anymore - boy, Sharktooth is fast!

http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r396A.exe

[Dayvon]

Just a quick note to you x264 developers and supporters.

You guys have done awesome work bringing the most cutting edge technology to the public. Keep up the great work. Loving your creations.

Dave

[CEC]

Is there any updated guide with all the new x264 features? The one i found in doom9 is old!

[LigH]

If you can read german - Selur's x264 documentations are usually quite up to date.

x264 VfW (http://www.flaskmpeg.info/board/thread.php?postid=54931) / x264 CLI (http://www.flaskmpeg.info/board/thread.php?threadid=5571)

[CEC]

If you can read german - Selur's x264 documentations are usually quite up to date.

x264 VfW (http://www.flaskmpeg.info/board/thread.php?postid=54931) / x264 CLI (http://www.flaskmpeg.info/board/thread.php?threadid=5571)

I can't understand anything!:eek:
But thanks anyway!:)

[LigH]

So what is your preferred language?

And what is the CEC, a software for creating computer aided art?

[DeathTheSheep]

<> Bi-directional ME
<> DCT-domain NR

2 new badboys that haven't been touched upon yet ;)

and....
http://www.myfilehut.com/userfiles/5120/untitled.PNG

[Piper]

I just want to echo other comments of praise for those developing x264. I've been playing with x264 ever since seeing the recent Codec shoot-out 2005 - final (http://www.doom9.org/codecs-final-105-1.htm#intro) and I'm astonished with what this codec is capable of. Thanks for all your continued hard work on this project!!

[Marsu42]

I've been playing with x264 ever since seeing the recent Codec shoot-out 2005 - final and I'm astonished with what this codec is capable of.

While being an absolutely convinced x264 user, I have to admit I don't quite understand how the ateme codec could have lost the competition because x264 shows some annoying washed blocks I have been experiencing in my own encodes, too: Take e.g. the "Scene 7: Neo faces Agent Smith" and look at the rain in middle and right of the picture. Is it just me or does the encode really look blurred? I am wondering if this is a bug or just unlucky rate control during exactly this scene?

[foxyshadis]

Do you mean the capture, or did you get ahold of (or replicate) the encode of the full scene? Doom9 specifically says do not study captures too closely, because they don't accurately reflect how the encode fared while being watched closely. It might be a B-frame in one encode and an I in another.

It's somewhere in his faq.

[Marsu42]

Do you mean the capture, or did you get ahold of (or replicate) the encode of the full scene?
I just looked at the capture, but it strikingly reminded my of the phenomenon I exprerienced w/ my own encodes - sometimes, the background tends to be very blurred. Of course, It were lower bitrate encodes (~900-1000) and I might have chosen bad filter settings, but in comparison to XviD, I was still surprised. On the other hand, maybe it's due to XviD's tendency to "restore" detail as described in Doom9's test and perfectly normal behavior for any other codec.

[max-holz]

I just looked at the capture, but it strikingly reminded my of the phenomenon I exprerienced w/ my own encodes - sometimes, the background tends to be very blurred. Of course, It were lower bitrate encodes (~900-1000) and I might have chosen bad filter settings, but in comparison to XviD, I was still surprised. On the other hand, maybe it's due to XviD's tendency to "restore" detail as described in Doom9's test and perfectly normal behavior for any other codec.

Simply use --no-fast-pskip for me the best solution.

[DarkFoon]

I've experienced a wierd X264 "bug" you might say.
In animated encodes, when something moves very fast (and this is the only thing I could notice that might have an effect) a white block appears in its former place for a moment. It doesn't even do this for all fast motion parts.
I'd love to post some screen shots, but I don't know of a convenient image hosting service. (any reccomendations?)
A picture is worth a thousand words, and I have a few thousand to show, but no way to do it.

[bob0r]

@DarkFoon
You may send files to files@x264.nl and ill host them for you.
(Please be sure to give a link to the right forum thread also, so i know where to add a reply with the file(s), this is more a general message for others)

Edit:
BTW, paste your command line used (or screenshot of settings used in gui, if not megui (show commandline)
Also what x264 version did you use? sharktooth's? x264.nl's other?... info info info)!

[DarkFoon]

Well, I'm going to take those screne shots now and email them.

unfortunately, I did the projects over a month ago, and I have since forgotten the commandline. I used one of sharktooth's builds, probably around 375.
I should try to re-encode the source (I may have lost it ) with a more recent build to see if the problem is still there.

and lastly, (but not the least) Thanks bob0r for hosting these files!

[omion]

In animated encodes, when something moves very fast (and this is the only thing I could notice that might have an effect) a white block appears in its former place for a moment. It doesn't even do this for all fast motion parts.
I'd love to post some screen shots, but I don't know of a convenient image hosting service. (any reccomendations?)
Does it look anything like the first picture on this thread (http://forum.doom9.org/showthread.php?p=766051)? It came out right after somebody walked past the frame, and I think it may be related. For me, all of Sharktooth's builds from 379 do it, but I'm still not sure what it is.

[edit: I guess I'll find out when the screenshots are posted. I really need to read posts when I quote them...:rolleyes:]

[DarkFoon]

@ Omion,
yeah sorta like that, but a little different.
Here are my screenshots:
Example 1 - Frame 1 (http://files.x264.nl/DarkFoon/example1-1.png)
Example 1 - Frame 2 (http://files.x264.nl/DarkFoon/example1-2.png)
Example 1 - Frame 3 (http://files.x264.nl/DarkFoon/example1-3.png)

Example 2 - Frame 1 (http://files.x264.nl/DarkFoon/example2-1.png)
Example 2 - Frame 2 (http://files.x264.nl/DarkFoon/example2-2.png)
Example 2 - Frame 3 (http://files.x264.nl/DarkFoon/example2-3.png)

In example 2, that half of the frame is supposed to be white (its a camera 'flash') the bad part is the little black block in the top left of that white area.

Example 1, his hand was next to his head, and then he moved it quickly away, and well, you can see the picture.

These screenshots aren't superb, and I apologize for that. Directshowsource() doesn't really allow frame-accurate seeking. and VLC player doesn't pause when I tell it to.

@Omion (again)
The only time I saw that effect as bad as those images you showed me was when I used FFDshow's X264 almost a year ago to encode a test clip, and all motion in that clip had that effect.

[lspbeyond]

hi, everybody, I have a question about x264 decoder.
I know ffmpeg-libavcodec is the first choice in decoding x264 streams currently and it works well. However, how about your opinions in developing own decoder in x264 project?

[CREXbzh]

However, how about your opinions in developing own decoder in x264 project?

I think patches to improve/fix the decoder will certainly be considered for inclusion; however, don't expect too much enthousiasm to help you as the code team of x264 already maintains part of ffmpeg h264 decoder, and probably doesn't feel like duplicating efforts (to work on x264 own decoder).

[bond]

hi, everybody, I have a question about x264 decoder.
I know ffmpeg-libavcodec is the first choice in decoding x264 streams currently and it works well. However, how about your opinions in developing own decoder in x264 project?man, its time for you to :search:

1) the question about the x264 decoder is as old as x264 itself. basically one point of an open standard, like avc, is that you can use any avc decoder you want for decoding an avc stream. this means there is absolutely no need for a x264 decoder
2) the fastest decoder supporting as good as all available avc features and still being freely available is coreavc (http://forum.doom9.org/showthread.php?t=104277)

[lspbeyond]

Thanks CREXbzh and bond, I have learned very more.
But I also have three different opinions?
1. we know encoder include the reconstruction loop, it has already implemented mostly part of decoder, expect stream parsing and entropy decoding . So I think develop decoder in x264 project is not a hard work.
2. The decoder can share the improvement of x264 encoder directly, e.g. the mc function, dct, deblock ... are all common.
3. If somebody have been familar with x264 encoder, they can learn the decoder part quickly. IMO, if x264 has more things be needed to do, then there will be more people join in developing it.

[akupenguin]

1. Reconstruction != construction. While it would be mostly cut-and-paste, it's not as simple as calling the existing code.
2. The optimal way of coding mc and deblock are not the same between encoder and decoder.
3. Do I hear you volunteering?

[lspbeyond]

to akupenguin, thank u
1. I don't think so. I think the mc, deblock and etc functions can called without any modification.
2. I am interesting in this point very much. If you can tell me in detail, I will appreciate of you. Thank u very much.
3. Though I'm a fresh man in video coding area, if I can do my little contribution to x264 project, I will.

[akupenguin]

I'll describe mc, because it's the most different:

x264 has one function that performs all 3 halfpel interpolations on the whole frame (note that the computation of the center halfpel includes one of the other positions, so we get one for free). Thus we have 4 versions of the luma plane. We also mc enough pixels past the edge of the frame to deal with unlimited mvs, and a bit more to simplify motion estimation.
Thereafter, any fullpel or halfpel-aligned mv can be retrieved with only pointer math, no pixel operations. And the remaining qpel mvs require just a PAVGB operation. Since the encoder tests many mvs, this is a big win.

But when decoding, that would be slow. Each pixel only involves 1 mv (or up to 2 in B-frames), and it's quite often the 0,0 mv that doesn't need any interpolation, and then there's intra... So we don't want to compute all 3 halfpels everywhere. Furthermore, we'd need to not only break even in terms of pixel operations, but get over the fact that the extra planes increase cache pressure.
So the optimal mc method for decoding is to have functions which do halfpel and qpel mc just on one block, for each of the 7 block sizes.
And (I haven't benchmarked this, but michaelni says so) instead of padding the edges of the frames enough to account for all concievable mvs, it's better to pad only a little bit, and then copy the rest of the pixels on demand.

--
If you are interested in writing the decoder, I would be happy to answer any technical questions you have. (well, I answer stuff anyway, but potential contributors get first pick.)

[lspbeyond]

very good.
I have thought of this problem of mc.
And I have bethought of the method that interpolating the pixels when used. But I am uncertain if the overlap case (i mean the repeated interpolation of a pixel) is frequent or not.

ps: I used intel vtune analysing the t264 decoder, and I found the memset function cost a big proportion. I know mostly video encoder or decoder program have used this function frequently, is there any faster fuction can instead of it?

[Manao]

But I am uncertain if the overlap case (i mean the repeated interpolation of a pixel) is frequent or not.On the encoder side - definitely. A rough guesstimate of the number of subpel positions analysed would be around 20 per macroblock. On these interpolated positions, qpel are computed using 2 hpels, and represents ~12 ( second guesstimate ). So in the end, for each macroblocks, you end up doing 8 + 12 + 12 hpel interpolations. So it's definitely worth it to do it once and for all, especially if you think that a reference frame may serve more than once ( bframes, multiref ).

On the decoder side - definitely not, since 1 macroblock = 1 or 2 hpel interpolations at most, so doing the 3 hpels for the whole picture make you lose time ( not speaking of the cache miss increase ).

[Selur]

dump,.. asked this before but nobody answered:
What are the min/max values for aq-sensitivity and aq-strength ?

Cu Selur