x264 development

[Kostarum Rex Persia]

You are not right, foxyshadis. If x264 user want to use that setting, let use it. Many people want slowest settings, and I aren't thinking on me.

[Manao]

I wonder, if there was an option --format-harddrive, would you use it ? Well, it's the same for --me esa. However, I would not disable it, but add a big fat warning telling how lame it would be to use esa in an everyday encode.

[Kostarum Rex Persia]

Yes, of course. Big fat warning telling how lame it would be to use esa in an everyday encode sounds OK.

[Sirber]

I blocked ESA in RealAnime since it's just useless.

[Ferux]

I always used ESA, but it's on video's which are important to me (home video's) and the colors are quiet blurry.

So you say it doesn't improve things? (That would be good news for me since my encodes take 7 days..)

[foxyshadis]

No, it is only infintesimally better than umh (multi-hex) on most sources, if at all, and many, many times slower.

[Sirber]

No, it is only infintesimally better than umh (multi-hex) on most sources, if at all, and many, many times slower.If it's 1% even better, it's 300% slower. Does not worth it.

[foxyshadis]

http://img301.imageshack.us/img301/8227/ssimtable6fx.jpg
&
http://img67.imageshack.us/img67/850/x264table7jz.png

It definitely isn't even 1% better, at least in the tests in the settings (http://forum.doom9.org/showthread.php?t=107699) thread, but I guess "many many times" is a bit of an exaggeration, 200-300% more usual. Subme7 is a much better use of the time and even that isn't amazingly useful, but at least it could give a small visual difference.

[Ferux]

Subme7 is a much better use of the time and even that isn't amazingly useful, but at least it could give a small visual difference.


Thanks for the explanation.

btw, i used both (esa and RDO level 2) :)

[shon3i]

Why bob0r builds don't have AQ Patch like ChronoCross. I downloaded lastest ChronoCross build and test this patch and there is big impact in quality especialy at dark scenes

[foxyshadis]

Because bob0r's builds are automated and intentionally direct from svn? Not everyone fully trusts the patches, or they'd be in svn.

[Caroliano]

I'm also in favour of eliminate --esa in normal builds, or at least make dificult and discourage it's use, like changing the name to --Insenely-Slow-And-Useles-Exaustive-ME, and keep it in "secret". Like FLAC's --super-secret-totally-impractical-compression-level (I'm not kiding! (http://people.ucsc.edu/~rswilson/flactest/)).

but I guess "many many times" is a bit of an exaggeration, 200-300% more usual.--esa was even slower some time ago, but pengvado made it 2~3 times faster in revision 388: https://trac.videolan.org/x264/changeset/388

[GodofaGap]

I wonder, if there was an option --format-harddrive, would you use it ? Well, it's the same for --me esa.
Well, it's not *really* the same. :rolleyes:

But if we go that way I can think of some more options that could be removed (merange and no-asm to name some), but what I don't understand is how anyone would benefit from doing this... IMO such things are better to be handled by GUIs.

[Isochroma]

Of course, I use ESA and RDO L2 too, so I hope it stays in there, at least for the CLI. Encoding time for me is no object, and any improvement in quality is desired!

[akupenguin]

Encoding time for me is no object, and any improvement in quality is desired!
Before you say that, make sure it actually does improve quality. On some videos, UMH is better by a similarly small amount...
oh no, have I just incited him to encode every movie twice, with esa and umh?

I should just skip to the point and add --placebo. The end user wouldn't be able to tell the difference, and it'd give me tons of spare CPU-time to further my own nefarious plots!

[Caroliano]

But if we go that way I can think of some more options that could be removed (merange and no-asm to name some), but what I don't understand is how anyone would benefit from doing this...
MErange is already a bit restrict (it is capped in 16 for dia and hex, etc) and higher values can be beneficial with low frame rate material (someone said that, but don't gave results to check IIRC), although it do more harm than help normaly... No-asm is an no-one-know option, that is fine where it is.

The harm of public know esa is that some people put everything in the max and then complain about the inefficience of x264 and even H.264. Or simply take toooo many time to get an infimous gain in quality, or none at all.

[foxyshadis]

Iso: Have you ever done an abx of uhm and esa? Before committing to an option that could double or triple your encoding time, I would make sure you can even spot any difference, let alone one that could be definitively called "better". It could mean the difference between a 18-hour dvd backup and a 48-hour one, on your 2500+.

I did it with subme 7 and could only spot very marginal differences when I tried, at the same filesize, so I stick to subme 6. But I wouldn't call it useless for real encoding, like esa, just slower than I prefer. (no-asm at least looks like the debugging option it is, since in theory it gives exactly the same results. perhaps rename esa to debug?)

[rushin_911]

I suggest keeping it. I think I've read somewhere on the board some people use it for stuff such as music videos (which are usually short), not to mention simply allowing the freedom of choice. I would think that any blocking or whatever option be from the gui of the encoder, since probably anyone using the commandline is knowledgable enough to know the effects of the available options (or at least the main ones).

[Isochroma]

Agreed.

[gumimaci]

Hi,
Where can i get ChronoCross build source code. I need the patched source code or the paches which are working with the latest svn.
Thanks.

[foxyshadis]

http://files.x264.nl/Sharktooth/?dir=./x264_patches

x264_p8rd.9_update2-391.diff (aka subme 7) does not merge into the current codebase, but the others should present few problems. x264.nl contains the main source.

[gumimaci]

I know where can i get Sharktooth old patches and the latest svn, but i have trouble to merge it. I want to know that someone update these patches or is there any merged source.

[ChronoCross]

All the patches present a shitload of problems at this current time. none of them except AQ merge out of the box. you literally have to merge them manually the first time around and then recreate the .diffs. right now I see no reason to use them until the developers pick them up again as the current features seem to provide the same quality. I will continue to add the AQ patch to all builds I make in the meantime due to popular demand.

[Kostarum Rex Persia]

Thanks for that effort, ChronoCross.

[shon3i]

@ChronoCross your build with AQ patch is cool. AQ is very powerfull tool for dark scenes. Is there some option to force bob0r to add patch in "official" build and MeGUI

[Sirber]

can AQ help at 318kbps, anime content, 640x480@24FPS in dark scenes?

[ChronoCross]

@ChronoCross your build with AQ patch is cool. AQ is very powerfull tool for dark scenes. Is there some option to force bob0r to add patch in "official" build and MeGUI

I wouldn't recommend having him include it in the official builds. Or using the word force for that matter. the official builds should be svn only.

Like I said on IRC AQ is not the most effective command and it is not done in the best way possible. which is one of the reason it hasn't been committed.

[shon3i]

can AQ help at 318kbps, anime content, 640x480@24FPS in dark scenes? Probably yes, You should be try.

[Todesengel]

Sharktooth, can you make build with current (or average) bitrate indication, like MENCODER's?

[Romario]

@ Todesengel

I really doubt it, because Sharktooth is still in hospital.

[Sharktooth]

i got home but i still have to recover the data from a broken raid 0 array...

[skyjaker]

i got home but i still have to recover the data from a broken raid 0 array...


Luckily you got backups...

[dimzon]

Hey!
Seems like MSU perform some tweaks around x264 ABR for low bitrates
http://www.compression.ru/video/x264/x264_improvement_en.html

http://www.compression.ru/video/x264/images/image002_en.png

http://www.compression.ru/video/x264/images/image004_en.png

[shon3i]

@dimzon did you see this topic http://forum.doom9.org/showthread.php?t=108438

[Kyle_Katarn]

x264 still crashes when used with PhotoToFilm (VfW) : http://www.kcsoftwares.com/?p2m

What's wrong with x264 ??

[SeeMoreDigital]

x264 still crashes when used with PhotoToFilm (VfW) : http://www.kcsoftwares.com/?p2m

What's wrong with x264 ??Every now and again I suffer crashes with JPGAvi...

I've tracked it down to some source image types having a bit depth less than 24 and/or some source images having resolutions below "mod4".


Cheers

[CREXbzh]

Every now and again I suffer crashes with JPGAvi...

I've tracked it down to some source image types having a bit depth less than 24 and/or some source images having resolutions below "mod4".

then you don't encode videos below mod4. It's sub-optimal anyhow!

[Kyle_Katarn]

Every now and again I suffer crashes with JPGAvi...

I've tracked it down to some source image types having a bit depth less than 24 and/or some source images having resolutions below "mod4".


Cheers

I'm using x264 default settings and 24bit JPEG images.
PhotoToFilm is available here : http://kcsoftwares.com

Can't understand what's wrong... Does someone knowns how to debug x264 or track down this crash on codec's side ?

[SeeMoreDigital]

Can't understand what's wrong... Does someone knowns how to debug x264 or track down this crash on codec's side ?Hi Kyle,

Indeed.... I've just tried it with some JPG source images that work perfectly with JPGAvi but crash in your application :(


Bummer!

[ChronoCross]

x264 still crashes when used with PhotoToFilm (VfW) : http://www.kcsoftwares.com/?p2m

What's wrong with x264 ??

There is nothing wrong with x264. There is something wrong with VFW in general however. do not use it. if you want to use x264, export your files losslessly and then encode it with x264 cli.

[SeeMoreDigital]

There is nothing wrong with x264. There is something wrong with VFW in general however. do not use it. if you want to use x264, export your files losslessly and then encode it with x264 cli.I wonder how the x264 VfW codec is able to work with JPGAvi then?

Cheers

[Kyle_Katarn]

Is it possible to trace x264 processing in order to see what makes it crash ?
PhotoToFilm crashes because of an exception raised inside of x264 codec.

[akupenguin]

Just like tracing any other program. build x264 with --enable-debug, and run it under gdb or your debugger of choice. (In the case of vfw, run your whole app under gdb, and it should catch x264 too)

[Kyle_Katarn]

the problem is that i my application is multithreaded .. and written in Delphi ;-(

[akupenguin]

gdb can handle mulithread, and delphi should be ok as long as the crash happens in C code.

[DarkFoon]

There is something wrong with VFW in general however. do not use it.
Not this again!! :rolleyes:

[Sharktooth]

Not this again!! :rolleyes:
why not? chronocross is right.

[DarkFoon]

Ugh...

Everybody, since we all know where we stand on the subject, let's just respect the other party's opinion, and let things be. Nobody is going to convince anybody else on this topic, that is clear. Therefore, it is a waste of time discussing (read: arguing) it at all.
Especially here.
If you want a VFW flame war, start a new thread titled "VFW sucks!" and enjoy. Or better yet, start your own forum website titled "DeathToVFW.net" and battle there.

And to you noobs out there about to post some problem you're having with x264 in Virtualdub: use your head a little bit before posting! Don't make a general acusation ("x264 is borken!") until you have pinpointed the problem. That is called making a good bug report. If the problem lies with VFW, you're S.O.L here. Use the CLI or a different codec. Or, fix the problem yourself.

[Sirber]

Use the CLI or a different codec. Or, fix the problem yourself.Or use RealAnime ;)

[Kyle_Katarn]

The problem is that i'm unable to fix the problem myself because on the lack of knowledge on codec developement and what's under x264 hood.

That's why i'm looking for the kind assistance on some developpers from this excellent forum :-)