x264 development

[Doom9]

I remember that this has come up before. But your scenario is so special that I wouldn't count on anything happening.

[Isochroma]

I just finished editing Noir ep. 1 (35089 frames processed by hand in 14 days of work). I am now encoding the final output using the newest x264 (v. 280). The file is ridiculously small (at q=20); I'm using ESA motion estimation and all the highest quality settings possible. Here is the commandline:

x264.exe --progress --qp 20 --subme 6 --ref 1 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me esa --merange 16 --bframes 15 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --analyse all --8x8dct --progress --fps 23.97600000 --sar 32:27 -o "F:\Video Files\Noir\Encoded\Noir.01.mp4" "F:\AVISynth Scripts\Noir\MP4 Output\Noir.01.avs"

I am very impressed with the quality this codec is achieving; it could only be excelled by Ateme among all other codecs in the world right now. My AthlonXP 2500+ running single-channel DDR400 gets about 3.2-3.5 fps (no filters in the avs):

avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi")
killaudio()
converttoyv12()

The avisource() line should explain why I used killaudio()! This unusual setup is due to the fact that Vegas 6.0 starts sending corrupt frames to saved AVI files after about f4000.

So many thanks to the developers; in combination with my intensively laborious hand-editing (or rather, choosing for replacement) of video frames, the codec is a perfect match for my insistence on perfect output, in archival grade.

Tomorrow or Thursday I will be posting the link to my new site, which will explain the techniques used in this process. Particularly, delta codecs such as x264 can benefit enormously from having source frames that differ only in quantization and film-grain noise replaced by the best among a group. This zeroes whole groups of frames - sometimes quite substantial in size.

Due to the high quality of x264, it tends to preserve noise much better than MPEG-4 ASP codecs, due to more efficient bit allocation at equivalent bitrates. Thus at equivalent bitrates, the value of source noise reduction is increased by a substantial amount. Beyond the saving of bits, choosing superior frames for replicative replacement of inferior ones increases the psychovisual quality of a video stream and is a powerful tool to provide a 'free' quality boost. It is time-intensive, though; The curent project is estimated to take one year and one month to complete.

Since encoding time is less than 5% of the time to produce a finished release, I'm not concerned about slow encoding speeds. Since I've invested so much time in the other 95%+, I use the most perfect encoding settings I know of.

If anyone knows of any way to make x264 run slower but achieve higher quality, please do point out the parameters that should be changed in the commandline above. Acceptable framerate for encoding is 0.1 FPS. Thanks!

[nm]

If anyone knows of any way to make x264 run slower but achieve higher quality, please do point out the parameters that should be changed in the commandline above. Acceptable framerate for encoding is 0.1 FPS. Thanks!
How about 2- or 3-pass encoding, --ref 15, --b-pyramid and --keyint 500 (this should be tested; probably no gain and may lose seeking precision).

[LigH]

Instead of
avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi")
killaudio()
converttoyv12()
simply try
avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi", false, "YV12")
This shall speed up a little, because it does not "request and delete" unnecessary data, but instead requests only desired.

[akupenguin]

--keyint 500 (this should be tested; probably no gain and may lose seeking precision)

--keyint is just a maximum. If increasing it removes some I-frames, then you both lose seeking precision and gain compression. If not, nothing changes.

[posix]

right,
sorry to be the pestering noob but...

"x264 options explained, step by step guide"

where?

[bond]

right,
sorry to be the pestering noob but...

"x264 options explained, step by step guide"

where?
:readrule: :search: :readguid:

also what does this have to do with x264 development?

striked

[LigH]

@ posix:

Because you seem to be a German, you may want to look in the german doom9/Gleitz board for Selur's "Wissenswertes rund um x264".

http://forum.gleitz.info

[Egh]

Where to actually report possible bugs in x264?

This one is assertion exception, raised apparently in x264 whilst encoding with VirtualDub.

http://forums.virtualdub.org/index.php?act=ST&f=15&t=10297&

[LigH]

x264.exe does not yet have a special "encode interlaced" option, as far as I can see in the help output of rev. 284 - or did I miss an option?

[bond]

x264.exe does not yet have a special "encode interlaced" option, as far as I can see in the help output of rev. 284 - or did I miss an option?nope, x264 doesnt support interlaced encoding till now

[TheBashar]

I have a problem, and I think it's in the bowels of the code. I don't think there is any way to tackle this from x264 option tweaking. I have a couple clips where x264 seems to lose low contrast detail. And there's now way I can stop it.

I have a clip with snow falling and a camera rotation. It's a pretty busy clip. The problem is the snow gets softened into a smeared falling macroblock look. Really not nice. I've tried everything (qcomp=0.7, qcomp=0, no deblocking, lots of deblocking) and nothing works except throwing massive amounts of bitrate at it.

Now, I understand you might take a look at the clip and say, well this is really busy, 10,000 kbps might be warranted. How do I get the bitrate to it without inflating the entire movie? The majority of the movie looks great at 1400 kbps. There are some other low contrast background smears/blockyness similar to the snow, but the (high-contrast) foreground details look great.

So, without some dev help, I think I'm stuck in the water. I think my clip needs something like a negative qcomp to take bitrate from the easily compressed scenes and throw it at the problem scenes. My guess is this is a much more intrinsic problem in that the basic encoding method naturally loses low-contrast details, so x264 wouldn't even have any way of knowing there was detail there that needed more bitrate.

Here is a 14MB huffyuv avi source clip. (http://www.savefile.com/files3.php?fid=9435255)

Here is a 0.8MB 5000kbps ABR x264 MP4. (http://www.savefile.com/files3.php?fid=8421389)
Here is a 0.8MB 5000kbps no-CQM ABR x264 MP4. (http://www.savefile.com/files3.php?fid=9665839)

Here is a 0.5MB 3000kbps ABR x264 MP4. (http://www.savefile.com/files3.php?fid=8480839)
Here is a 0.5MB 3000kbps no-CQM ABR x264 MP4. (http://www.savefile.com/files3.php?fid=3282791)

The first x264 clip was made with the following command-line:
x264.exe --bitrate 5000 --keyint 300 --ref 5 --bframes 3 --b-pyramid --subme 6 --weightb --analyse all --8x8dct --qpstep 50 --qcomp 1.0 --me esa --merange 32 --cqmfile eqm_avc_hr.cfg --progress --no-psnr --output ep-2.mp4 ep-2.avs --ratetol inf

Please be sure to examine the snow falling in front of the dark parts of the volcano on the left. Hey ya know, maybe that's not snow, maybe it's ash! Damn, I'm slow!

[omion]

How do I get the bitrate to it without inflating the entire movie? The majority of the movie looks great at 1400 kbps. There are some other low contrast background smears/blockyness similar to the snow, but the (high-contrast) foreground details look great.
I'd think this would be a perfect candidate for using the --zones command. Add --zones start,end,b=5.0 to your command line and x264 will make the range of frames from start to end use 5 times the bitrate as the rest of the movie. It's sort of like curing the symptom instead of the disease, but it should work.

[SeeMoreDigital]

Where was the source from originally.... Was it a TV capture or from a DVD.... I'm wondering why your 14MB huffyuv sample is 880x480 pixels... not 720x480 pixels?


Cheers

[Pookie]

omion-Thanks for the info on the zones command. Gonna try it out on some footage with ocean scenes.

[TheBashar]

Where was the source from originally.... Was it a TV capture or from a DVD.... I'm wondering why your 14MB huffyuv sample is 880x480 pixels... not 720x480 pixels?

It's off my SG-1 (tv series) DVD collection. The size reflects the fact that I captured the "source" at the end of my postprocessing setup. I guess I should have been more clear that it was the source for the encode, not the ultimate source.

@omion:
Thanks for reminding me about the zones. It's not a good solution since in addition to easily identifiable scenes like the one I posted, there are small stretches with low contrast backgrounds that get smeared or blocky and they are scattered throughout. Not meaning to diminish your suggestion however, I will point out that while it's not a good solution, it is the best one that I have. :)

[LigH]

On the occasion of several remarkable speedups between r28x and r293, x264 now has a lightning fast new logo. Well done, bob0r - beautiful!

http://x264.nl/x264_fire.gif

[hpn]

Yes, a very nice logo. It's also a very complex one with lots of collors and shadows, so gif is not the best format (55k). It could be easily transformed losslessly to 48k PNG, so bob0r could make his site half a second faster :)

[SeeMoreDigital]

... It could be easily transformed losslessly to 48k PNG, so bob0r could make his site half a second faster :)Oh yeh....

http://img300.imageshack.us/img300/8559/x264fire95am.png

at 41.5KB PNG

[gaekwad2]

38.4KB

http://img76.imageshack.us/img76/4430/x264fire1sg.png (http://imageshack.us)

[Chaos Creator]

What Sarktooth wants to say exactly with this:

x264 win32: rev.292 - Last build until sanity comes back into ppl's mind. ???
:confused: :confused: :confused:

[LigH]

@ SMD, gaekwad2:

Which tools did you use? SMD - probably IrfanView's PNGOUT?

[Chaos Creator]

http://forum.doom9.org/showthread.php?p=711871#post711871

Ok, thanks for answering my question!! Some people really can't understand the open source philosophy!!!! :( You can't request anything!!!!

[gaekwad2]

@ SMD, gaekwad2:

Which tools did you use? SMD - probably IrfanView's PNGOUT?
I used a batch script that was posted at Hydrogenaudio a while ago, it runs advpng, pngcrush, optipng, pngrewrite and pngout (plus pngout /f0 which shaved off another 4 bytes :)).

[Audionut]

http://img355.imageshack.us/img355/5179/x264fire5fn.png

28.5kb png


http://img380.imageshack.us/img380/8624/x264fire19nl.jpg


18.1kb jpg

[hpn]

Ok, because I started this oftopic talk, lets finish it by pointing out that one can go as low as 5k with jpg or lossy PNG, but the whole idea was to make a lossless transformation and preserve the good looks of the original logo, not to make it as small as possible, so the 38.4KB version of gaekwad2 seems the smallest possible lossless GIF to PNG transformation (lossless = fully preserves the rendered RGB triples)

the facts:
http://www.cs.toronto.edu/~cosmin/pngtech/optipng.html
and the batch scripts:
http://www.hydrogenaudio.org/forums/index.php?showtopic=22036&hl=

edit: even lower than gaekwad2 losslessly to 39108 bytes:
http://img167.imageshack.us/img167/8427/x264fire9ry.png

[Antony]

Hi all,
I have revamped the VFW settings window into a smaller tabbed window. Screenshot and source code here: http://members.shaw.ca/antony.boucher/download/x264rev293_gui_patch.zip
Cheers

[sr78]

Hi All.
I am just now starting development on the x264.
I woundered if there is any good documentation I can get
in order to understand the source code better?

thanks.

[Kopernikus]

@Antony: Please send the Patch to the x264-devel mailinglist (see here http://developers.videolan.org/lists.html)

@sr78: Unfortunately there is almost no documentation for the sources. But reading the standard and the sourcecode parallel can help much. Also there is a document describing the reference encoder http://ftp3.itu.ch/av-arch/jvt-site/2005_01_HongKong/JVT-N046r1.doc, which may help in understanding.

[bob0r]

Hi all,
I have revamped the VFW settings window into a smaller tabbed window. Screenshot and source code here: http://members.shaw.ca/antony.boucher/download/x264rev293_gui_patch.zip
Cheers

Hi Antony, welcome, finally :D

Please remove my AWESOME Logo from your VFW patch, it is highly patented by me and i require a lot of money to use it.... or as most please say.... its horrible ;) ( No seriously, just add no logo, i just keep playing around with it on x264.nl )


Also, please disguss with VFW Patch with Sharktooth, he can also test them, and he makes custom builds so others can play with stuff before it gets commited to svn (or not)

His builds: http://forum.doom9.org/showthread.php?t=89979

[celtic_druid]

If anyone wants to test it:
http://mirror05.x264.nl/celtic_druid/force.php?file=./x264vfw.exe

[Sharktooth]

New 293B builds up with the antony's vfw patch released.

[dimzon]

how about target filesize instead of target bitrate option?

[bob0r]

New 293B builds up with the antony's vfw patch released.

Arg, please remove the logo, when people use Themes (antony uses Silver theme), like me, it's ugly.
Maybe if it was transparent it could be fun, but the logo is only wasting space; download and vfw window wise...

http://mirror05.x264.nl/public/antony_vfw.gif

as for the VFW file itself... testing ;)

[Sirber]

logo's pretty cool :devil:

[hpn]

Hi All.
I am just now starting development on the x264. I woundered if there is any good documentation I can get in order to understand the source code better?

thanks.
All you can do is read the comments in the source (if any). Besides the H.264 official specs (search "h264.pdf" in google), you can also buy and read the Iain Richardson book
http://www.vcodex.com/h264mpeg4/index.html

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/x264vfw.png
Looks ok to me.

[leowai]

http://mirror05.x264.nl/celtic_druid/x264vfw.png
Looks ok to me.
very nice! Good job, celtic_druid.
Will it be good to change the *.ico (icon) as well?

Still, we need to get permission from bob0r. :P

[Sharktooth]

new builds up (with updated logo)

[SeeMoreDigital]

new builds up (with updated logo)Thanks Sharktooth,

Great work guys... the new GUI makes things much clearer and simpler to understand ;)


Cheers

[Koti]

very nice :)

[hpn]

The tabs look nice. One wish: Now I have to click 8 times before starting each encode to check all my settings, just to make sure I haven't changed some of the options by mistake previously. I hope it's possible to add a small "No tabs" "Tabs" botton, changing label depending on what is currently active (next to "Load Defaults" button for example), to switch between all settings on one big screen (as it was before) and the new tabbed version. Once set, people just keep using the way that suits them best.

[foxyshadis]

The tabs look nice. One wish: Now I have to click 8 times before starting each encode to check all my settings, just to make sure I haven't changed some of the options by mistake previously. I hope it's possible to add a small "No tabs" "Tabs" botton, changing label depending on what is currently active (next to "Load Defaults" button for example), to switch between all settings on one big screen (as it was before) and the new tabbed version. Once set, people just keep using the way that suits them best.
This sounds like something better solved through profiles. (Not the mutating ones in megui, just normal ones.) You reset to a saved profile, and make any tweaks from that known config.

Very nice, overall. I think more of the advanced features could be pushed into one or two tabs rather than a half-dozen, but overall it looks cleaner and slicker.

[hpn]

Ok, suppose today I create 3-4 profiles for common encoding tasks ("Save Processing Settings" in VirtualDub in my case). I don't think when in a few days before starting a 20 hours encode, I'll simply load some of these profiles, without rechecking again all options. So with or without profiles I'll always end up clicking all tabs, unless I don't mind running the 20 hours encode again if something turns out to be wrong, like loading a wrong profile name, potential bugs in VirtualDub, etc, etc. Exactly the same holds true if I encode with MeGUI. IMHO profiles are overrated. I don't say that the tabs are bad, just let people choose what suits them best :)

[foxyshadis]

Ok, suppose today I create 3-4 profiles for common encoding tasks ("Save Processing Settings" in VirtualDub in my case). I don't think when in a few days before starting a 20 hours encode, I'll simply load some of these profiles, without rechecking again all options. So with or without profiles I'll always end up clicking all tabs, unless I don't mind running the 20 hours encode again if something turns out to be wrong, like loading a wrong profile name, potential bugs in VirtualDub, etc, etc. Exactly the same holds true if I encode with MeGUI. IMHO profiles are overrated. I don't say that the tabs are bad, just let people choose what suits them best :)
They're only overrated if you actually do check/change options all the time. All I ever change is bitrate; everything else never changes depending on if I'm encoding animation/real/streaming footage because I know they're already on the best settings I've found for that type. I can understand where you're coming from though.

[stephanV]

The old GUI is still in SVN, so download that and compile it yourself. Making two GUIs in one is a bit bloated IMO. Although I do agree that the new one has a few tabs too many perhaps.

[Sirber]

is it me or rev 295 is kinda lots faster than previous builds?

encoded frames: 3529/41516 (8.5%), 29.12 fps

I was around 21 before :D

[celtic_druid]

I don't see anything that would make it quicker. Did you compiled with the mmx/mmxext patches that were posted on the mailing list?

[Sirber]

I'm on Sharktooth build. I read on the changelog some functions were optimized MMX.

MMX quantization functions, and optimization of the C versions. ...
SSE2 pixel comparison functions ...

Could be that :)

[edit]

Seems to be in "fast first pass" only. Normal encoding is ~8 FPS as usual.

[celtic_druid]

That was for r293 though.
Revision 295:
fps patch by Haali

Revision 294:
* configure: added support for ia64, mips/mipsel, m68k, arm, s390 and hppa
platforms, as well as linux sparc.

Nothing there to increase speed.