View Full Version : sharktooth's profiles into core?
smok3
20th December 2006, 09:28
any chance to put the profiles into x264 source? (so they will become platform independant... and they could simplify the command line, any additional parameters would simply override the profile hardies)
example:
x264 --profile fancy --pass 1 --filter sharp --bitrate 500 myfile.avi --output myfile.mp4
akupenguin
20th December 2006, 09:55
http://forum.doom9.org/showthread.php?p=895296#post895296
I will not add code to x264 when there's already a solution that works for all commandline programs ever.
smok3
20th December 2006, 10:13
not shell related (you could do a batch file on win) but more 'i wanna be uptodate with presets as well' thingy.
So when a new x264 is available i would know that presets are uptodate as well....
akupenguin
20th December 2006, 10:31
If someone writes a script to convert Sharktooth's xml profiles to commandline args and vice versa, I'm willing to include it. Or you could distribute it with the profiles.
lazyn00b
20th December 2006, 12:44
I think including custom presets in the x264 exe is a bad idea. Look at the mess caused by the "--r3mix" preset which the poor LAME devs had to support for ages after the preset was declared obsolete. I'm not saying there's anything wrong with Sharktooth's presets - I use them myself frequently - but who knows what we will want for presets in the future? The current system of modular megui profiles seems just fine, IMHO, because it's so flexible.
smok3
21st December 2006, 09:09
akupenguin, hopefully we will get one hero for the job then.
lazyn00b, you are missing the point (s):
- lame has a good and simple to use profile system today (so we can all learn something from its history :))
check
http://www.hydrogenaudio.org/forums/index.php?showtopic=28124
- megui is win only (so users on macs are not welcome...)
lazyn00b
22nd December 2006, 05:07
No, I get your point, and I know all about hydrogenaudio. The problem with the LAME presets is not that they aren't any good, but rather that they are an attempt to answer the following question, "What settings are BEST?", and then impose the answer from above. There is a reason the mods don't like it when people ask that question around here. It's hard enough to prove what's best when you use rigorous testing regimes like they do at hydrogenaudio, but for video codecs I think the issues are even more complex. Before you know it, people would be arguing over metrics (of dubious merit) like PSNR and SSIM and so on... use your imagination, it could get nasty.
Furthermore, hard-coding presets into the executable may sound like a good idea, but think of the implications for the developers. A hard-coded preset is like a statement, "THIS is the best way to do it". So the x264 developers would have to ask themselves, do we really want to be responsible for this? If the answer is yes, well then they should it. I only point out LAME because, in that case, the encoder IS the preset for all intents and purposes. Mods over at hydrogenaudio won't even tolerate discussion anymore of user tweaked settings, they just say "Quit posting wacky command lines!" and point to the Official Recommended Settings page.
For me, tweaking the x264 settings and judging the results for myself is the most fun part of encoding videos - I would hate see that kind of fun killed at Doom9 by a "preset culture".
smok3
22nd December 2006, 09:05
lol, so get the written statement everytime the preset is used:
"this may not be the best way to do it, please waste countless hours to get the job done by writting at least 3 line commands..."
check
22nd December 2006, 09:11
you don't need preset integrated into x264 for the simple reason that those who would most need them (beginners, etc) I would mostly expect to be using frontends. If you really needed CLI presets, just write up a batch file which you pass in a string. Then the batch file will run a certain command(s) depending on the contents of the string.
smok3
22nd December 2006, 09:57
i wrote everything i have to, nothing to add :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.