encoding videos to .mp4 containers using h.264 codecs

[mgadallah]

Hello,
Please I'd like to know why encoding videos to .mp4 containers using h.264 codecs takes a lot of time to do the encoding!?
I've tried a lot of tools and found two types of encoders, 1st type is the encoders do converting to various containers like WinAVI, AnyVideoConverter, ...etc
2nd type is the dedicated encoder to only encode to .mp4 like VidCoder, Handbrake ...etc
I used to use WinAVI to do the encoding but the encoded file quality was not good as VidCoder and file size for WinAVI was big and not that small as VidCoder. This is the only reason for my questions, it is mandatory important to have a very fast time for encoding, but even using core i7 2600k with nvidia gtx geforce 550 ti 2 gb with 16 gb ram ddr3 can not make the encoding time fast.
Please advise and help :)

[LoRd_MuldeR]

It is not putting the H.264 stream into the MP4 container (or MKV container) what takes a lot of time, it's the actuall H.264 encoding!

H.264 encoders like x264, which is used in almost all free(ware) video encoding tools today, are already HIGHLY optimized for speed. Still video encoding is a complex task and needs CPU time!

x264 provides a very convinient Preset system that lets you tweak the encoder for "Speed" or for "Quality". Using a faster Presets trades quality for speed. As in real life, nothing comes for free ;)

To speed up things, getting the fastest CPU you can afford is the best you can do. The graphics card doesn't matter, because sofware encoders, such as x264, don't use it at all...

There is some hype around "GPU" video encoders, but up to now all available GPU encoders have been more than disappointing! If they beat software encoders speed-wise, they suck quality-wise.

(The only thing that the grpahics card is good for, at this time, is decoding your source video. But that doesn't need a high-end model. A cheap model will work just fine)

[mgadallah]

It is not putting the H.264 stream into the MP4 container (or MKV container) what takes a lot of time, it's the actuall H.264 encoding!)Please I do not follow this part, may you clear it a little bit more?

H.264 encoders like x264, which is used in almost all free(ware) video encoding tools today, are already HIGHLY optimized for speed. Still video encoding is a complex task and needs CPU time!)Yes it is a time consuming process.
I wish if there is a solution for this issue!

x264 provides a very convinient Preset system that lets you tweak the encoder for "Speed" or for "Quality". Using a faster Presets trades quality for speed. As in real life, nothing comes for free ;))Where can I find it?

To speed up things, getting the fastest CPU you can afford is the best you can do. The graphics card doesn't matter, because sofware encoders, such as x264, don't use it at all...)does my i7 2600k sandy bridge fits or not?

There is some hype around "GPU" video encoders, but up to now all available GPU encoders have been more than disappointing! If they beat software encoders speed-wise, they suck quality-wise.)if you can advise for some suggested encoders that would be awesome.

(The only thing that the grpahics card is good for, at this time, is decoding your source video. But that doesn't need a high-end model. A cheap model will work just fine)well,
please if you were in my place and this is required by my business due to contracts what would you do the achieve the fast encoding issue?
I've been advised that guys in this forum are the most talented around this subject.

THanks

[Atak_Snajpera]

regarding encoding speed. my advice is dump your crappy i7 2600 and buy eight pcs with 3960x on board and then use them in distributed encoding mode.

[mgadallah]

regarding encoding speed. my advice is dump your crappy i7 2600 and buy eight pcs with 3960x on board and then use them in distributed encoding mode.

please may you tell me more abou it?

[mgadallah]

you mean this one (https://www.google.com/url?q=http://ark.intel.com/products/63696/Intel-Core-i7-3960X-Processor-Extreme-Edition-(15M-Cache-3_30-GHz)&sa=U&ei=DbAzUKuKF4SKhQesuICIDQ&ved=0CAUQFjAA&client=internal-uds-cse&usg=AFQjCNHsZjXiCwEwqGOI1yyzibJSb7wOYA)

[mgadallah]

sorry for replying that fast but do you mean to use something like this:
RipBot264v1.17.3

[LoRd_MuldeR]

Please I do not follow this part, may you clear it a little bit more?

MP4 ist a container format. Just like MKV (Matroska) or AVI.

Wrapping a H.264 video stream into an MP4 (or MKV or AVI) container takes zero time. It's essential a byte-copy operation and only limited by the speed of your HDD.

The process that reall takes (CPU) time is re-encoding the source video into the H.264 format...

Yes it is a time consuming process.
I wish if there is a solution for this issue!

In reality, nothing comes for free ;)

x264 is the most optimized H.264 encoder that exists today. And you can get it for free. Actually that is a lot!

At this point you can only speed things up by either sacrificing Quality for Speed (e.g. by using faster Preset) or by buying a faster processor.

You could also downscale the video to a lower resolution, but that's also "sacrificing Quality for Speed", just in another way...

Where can I find it?

http://www.x264.nl/

As you probably which to use a GUI front-end instead of the plain command-line encoder, have a look here:
http://forum.doom9.org/forumdisplay.php?f=78

There are plenty of x264 GUI front-ends to choose from!

does my i7 2600k sandy bridge fits or not?

It's not too bad ;)

If you want to have something significant faster than that, you would probably have to go for a multi-socket server system with multiple Xeon's (preferribly from "sandy bridge" generation).

Either that, or, as Atak_Snajpera suggested, think about some "distributed" encoding solution...

if you can advise for some suggested encoders that would be awesome.

x264 probably is the most sophisticated and optimized H.264 encoder that exists today. And it is OpenSource. What more do you want ???

[mgadallah]

If you want to have something significant faster than that, you would probably have to go for a multi-socket server system with multiple Xeon's (preferribly from "sandy bridge" generation).



x264 probably is the most sophisticated and optimized H.264 encoder that exists today. And it is OpenSource. What more do you want ???

- How much $$ that would may cost?

- No, I do not want anthing else then and really .mp4 with h.264 is good enough for me

[LoRd_MuldeR]

- How much $$ that would may cost?

You mean for x264? x264 is OpenSource software, released under the GPL. Thus it doesn't cost you a single cent!

Of course, if you use H.264 in a commercial context (e.g. if you are running a business dealing with H.264 video), you have to pay patenting fees. But that is the case will all H.264 encoders.

If you are asking how much a multi-socket server system would cost you, that of course depends on a lot of factors! And you'd have to ask a hardware reseller for prices...

- No, I do not want anything else then and really .mp4 with h.264 is good enough for me

In never suggested anything else :confused:

All I wanted to make clear is that H.264 is a video format, while MP4 is one container (out of many!) in which H.264 streams can be stored.

Wrapping an existing H.264 stream into an MP4 container (or whatever container) is very fast, because it's not a CPU-bound task. It's just a copy operation.

Encoding the video into the H.264 format is the CPU-intensive task!

[mgadallah]

sorry if my English is not good.
it seems that I did not got what you said the right way.
I mean I will be more then happy to find a way to do the encoding to .mp4 using h.264 fast.
How much to pay and who to pay for regarding using h.264 as I never know ab out such a thing before?

[LoRd_MuldeR]

I mean I will be more then happy to find a way to do the encoding to .mp4 using h.264 fast.

Pretty much any H.264 encoder can output the H.264 stream in a MP4 container, because MP4 is the "standard" container for H.264 streams.

x264 is no exception here. As for speed and quality, it's the preferred choice anyway...

How much to pay and who to pay for regarding using h.264 as I never know ab out such a thing before?

If you use the H.264 video format in your business (i.e. you are not encoding for your private matters only), you probably have to pay patenting fees to the MPEG-LA (http://www.mpegla.com/main/default.aspx).

Contact them for details...

[mgadallah]

thanks a lot I will do so.
so it is a must to upgrade my hardware then.
hum ... but what should I start with 1st!?

[LoRd_MuldeR]

You hardware already is very good - for a single socket system.

I think before you consider an upgrade, you should try the latest x264 encoder. Either use the command-line encoder directly or use one of the various x264 GUI's (see link in my earlier post).

Also you should play around with the various x264 Presets. They can have a HUGE impact on speed. And you might be able to find a "quality -vs- speed" compromise that is acceptable for your needs.

Last but not least, you did not tell us what kind of source videos you are encoding and what pre-processing you need to apply (if any). What exactly is your processing chain ???

[mgadallah]

You hardware already is very good - for a single socket system.But what will be the result if I upgraded? and what kind of upgrading as I am really do not know.

I think before you consider an upgrade, you should try the latest x264 encoder. Either use the command-line encoder directly or use one of the various x264 GUI's (see link in my earlier post).Does the CLI allow me to do a crop and adjust screen resolution or frame size and adjust the audio and video bitrate and other various settings or not?
Also does the CLI achieve any progress regarding speed in cae settings are the same when using CLI or GUI?


Also you should play around with the various x264 Presets. They can have a HUGE impact on speed. And you might be able to find a "quality -vs- speed" compromise that is acceptable for your needs.
The only two good encoders I tried so far that allow me to do the crop and adjust frame resolution and video and audio bit rate were WinAVI and VidCoder but as I told you before, I did tried almost all presets and various profiles in VidCoder and really time is not good to encode.
Last but not least, you did not tell us what kind of source videos you are encoding and what pre-processing you need to apply (if any). What exactly is your processing chain ???If you are asking about my business ... well, in short to do not bothering you, we are a small media production company and we have just started few months ago, and we have short term contracts with local tv channels to do two things:
- record or capture the streaming of the channel
- edit and encode its tv shows and upload one copy to its associated youtube channel and another copy to its server website.
I am working with one person only and we have a small lab to do so.
- we have 20 computers dedicated for recording only and another set of 4 computers with i7 2600k to do the encoding.
- we are recording about 200 GB each new day and then transfer it to the i7 computers to do the edit.
- we are using mpg2cut to do the cut of tv show out of the big .ts / .mpeg-2 file.
- then we add all files to queue to be encoded.
- the reason I am asking for this is here localy it is costly that the tv channel to hire staff to do so but when they are hiring us and we are still new in the market they do not pay a lot of money (but it is a good money for us), so the fast encoding I can do the lot of videos I can produce and the more contracts we can get.
That is the full story.


But please let me ask if I buy a motherboard that support two processors may work more speed!?

[LoRd_MuldeR]

But what will be the result if I upgraded? and what kind of upgrading as I am really do not know.

As said before, all you can do is getting a faster CPU. But you already have a pretty "high end" Quadcore (single-socket) CPU.

Thus your only "upgrade" options here would be getting one of the Hexacore Core i7's (about 1.5x faster, compared to a Quadcore) or going for dual-socket Xeon server system (probably 2x faster, compared to an identical single-socket CPU).

Does the CLI allow me to do a crop and adjust screen resolution or frame size and adjust the audio and video bitrate and other various settings or not?

The x264 CLI encoder has some built-in filters including resize and crop. An of course you can always use Avisynth (http://avisynth.org/mediawiki/Main_Page) input, which gives you access to powerful filtering capabilities of Avisynth.

As x264 is a video encoder, x264 itself does not process audio at all. For audio encoding you need to use something like Nero AAC encoder...

Also does the CLI achieve any progress regarding speed in cae settings are the same when using CLI or GUI?

When using x264 through some GUI front-end, the CLI encoder will still be running in the background. The GUI is just a "nicer" interface. Speed-wise there should be no difference...

[mgadallah]

An of course you can always use Avisynth (http://avisynth.org/mediawiki/Main_Page) input, which gives you access to powerful filtering capabilities of Avisynth.

I've tried to use it before and found it really hard to be used to do the exact crop I want nd the exact frame or screen resolution I want.

I tried to read more info in the website but it is really hard for me.
Please if you know of any tutorials to simple it that would be awesome.

[mgadallah]

but which version I should use 32x or 64x?
I am on win7 ultimate 64x
2.5.8 or 2.6.0 ??

[mgadallah]

when I explored the Xeon cpu here:

http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&N=100006676&isNodeId=1&Description=xeon&x=0&y=0

There are a lot of them.

Which one you are suggesting or in other words what specifications I should look after?

[LoRd_MuldeR]

but which version I should use 32x or 64x?
I am on win7 ultimate 64x
2.5.8 or 2.6.0 ??

The 64-Bit (x64) variant of x264 should be quite a bit faster than the 32-Bit (x86) variant. So you probably want 64-Bit ;)

However be aware that 64-Bit x264 will also need the 64-Bit incarnation of Avisynth. 64-Bit x264 cannot work with 32-Bit Avisynth (or vice versa). At least not directly.

But 64-Bit Avisynth is still "experimental" and will also need 64-Bit Plug-ins. You can't use 32-Bit Plug-ins with 64-Bit Avisynth (or vice versa).

Finally, Avisynth 2.5.8 is the "stable" version, while Avisynth 2.6.x is the current "development" version. If you look for a 64-Bit build, it will probably be v2.6.x.

I've tried to use it before and found it really hard to be used to do the exact crop I want nd the exact frame or screen resolution I want.

I tried to read more info in the website but it is really hard for me.
Please if you know of any tutorials to simple it that would be awesome.

Of course Avisynth can do exact cropping and resizing! See Crop() (http://avisynth.org/mediawiki/Crop) and Resize() (http://avisynth.org/mediawiki/Resize).

Also there are plenty of Tutorials available form the Avisynth site:
* http://avisynth.org/mediawiki/First_script
* http://avisynth.org/mediawiki/Getting_started
* http://avisynth.org/mediawiki/Filter_introduction
* http://avisynth.org/mediawiki/Script_examples

when I explored the Xeon cpu here:

http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&N=100006676&isNodeId=1&Description=xeon&x=0&y=0

There are a lot of them.

Which one you are suggesting or in other words what specifications I should look after?

I'm not an expert on server hardware. Maybe Blue_MiSfit (http://forum.doom9.org/member.php?u=44477) can give a hint.

But I still believe you should follow my previous suggestion and try latest x264 with the different Presets on your current hardware, before you consider a hardware upgrade.

x264 can be extremely fast when using one of the faster Presets...

[mgadallah]

I've realized that during encoding using the vidcoder that the cpu is consuming about 65:72% and sometime jump to 80:81% ... this is according to the gadgets of the cpu in windows 7 and the task manager was reporting the same.
So does upgrading to a workstartion with dual xeon will make it any better?

[LoRd_MuldeR]

x264 scales to a very large number of threads, which means it can make use of a lot of CPU cores. Adding more CPU cores usually does speed things up.

But if you see the CPU usage drop significantly below 100%, it means you have a bottleneck somewhere. Though the bottleneck is not necessarily in x264 itself! It might very well be in the decoder that is used to decompress the source or in the pre-processing. I don't know what version of x264 that "Vidcoder" uses (AFAIK it is built on top of Handbrake), what decoder it uses to decompress the source, what pre-processing it applies or how much it screws up the x264 settings.

The more software you put in between, the more difficult it will be to draw any useful conclusions. To make things more clear, I would highly recommend to use the x264 CLI encoder and either feed it directly with your source file or with a simple Avisynth script. And make sure you download the latest x264 version! You can find it here (http://mirror01.x264.nl/x264/32bit/8bit_depth/revision2208/x264.exe). For usage help, see there (http://mewiki.project357.com/wiki/X264_Settings). Then you can check the encoding speed with different Presets and without any fancy pre-processing.

BTW: In case you use Avisynth input, you may want to have a look at AVSMeter (http://forum.doom9.org/showthread.php?t=165528). This tool will allow you to measure the "raw" speed of your input script. As x264 cannot encode faster than the input frames are delivered, the speed of your Avisynth script alone is the maximum encoding speed you will ever be able to reach. If your input is "slow" already, even the fastest encoder in the world with the fastest encoding settings won't help ;)

[mgadallah]

x264 scales to a very large number of threads, which means it can make use of a lot of CPU cores. Adding more CPU cores usually does speed things up.You mean it is not a must to do so and I may end up with nothing?

But if you see the CPU usage drop significantly below 100%, it means you have a bottleneck somewhere. Though the bottleneck is not necessarily in x264 itself! It might very well be in the decoder that is used to decompress the source or in the pre-processing. I don't know what version of x264 that "Vidcoder" uses (AFAIK it is built on top of Handbrake), what decoder it uses to decompress the source, what pre-processing it applies or how much it screws up the x264 settings.So you mean it maybe another thing like the HDD speed or that I may need to use SSD HDD?
I do not know about the version of the x264 that being used with VidCOder, but I will look into it and feed yuou back.

The more software you put in between, the more difficult it will be to draw any useful conclusions. To make things more clear, I would highly recommend to use the x264 CLI encoder and either feed it directly with your source file or with a simple Avisynth script. And make sure you download the latest x264 version! You can find it here (http://mirror01.x264.nl/x264/32bit/8bit_depth/revision2208/x264.exe). For usage help, see there (http://mewiki.project357.com/wiki/X264_Settings). Then you can check the encoding speed with different Presets and without any fancy pre-processing.I've downloaded it but really nothing happened when I double clicked it and nothing being installed.
I do not know how to add the source to this x264 software. :(

BTW: In case you use Avisynth input, you may want to have a look at AVSMeter (http://forum.doom9.org/showthread.php?t=165528). This tool will allow you to measure the "raw" speed of your input script. As x264 cannot encode faster than the input frames are delivered, the speed of your Avisynth script alone is the maximum encoding speed you will ever be able to reach. If your input is "slow" already, even the fastest encoder in the world with the fastest encoding settings won't help ;)
Regarding the version of avisynth, you mentioned that everything should be in 64x but the native 64x version is not stable yet, so please advise for this regard.

Thanks

[mgadallah]

-last post updated-

[LoRd_MuldeR]

You mean it is not a must to do so and I may end up with nothing?

No, what I said is the exact opposite. x264 scales to a large number of CPU cores, so adding more CPU's (CPU cores) does speed up things.

But: If you actually are bottlenecked by slow input, x264 won't be able to encode any faster for obvious reasons. In that case, adding more CPU cores might not help.

Also, as long as you haven't evaluated various "quality -vs- speed" trade-off's, by using different x264 Presets, it's to early to think about a h/w upgrades.

So you mean it maybe another thing like the HDD speed or that I may need to use SSD HDD?

It is highly unlikely that HDD throughput becomes a bottleneck with video encoding

It might be, if you are dealing with uncompressed video (like "raw" YUV data). In all other cases, something like a RAID-0 or SSD won't speed up video encoding.

From what you described so far, you are not dealing with uncompressed video, so HDD throughput shouldn't be a problem...

I've downloaded it but really nothing happened when I double clicked it and nothing being installed.

x264 is a command-line application. There is nothing to install. And, of course, just double-clicking on the executable won't do anything ;)

You need to run the x264 CLI encoder from the command prompt. And you need to pass the proper arguments, as describes in the link I provided in the previous post.

I urge you to read up the basics about command-line applications here:
http://en.wikipedia.org/wiki/Command-line_interface

A simple (but often sufficient) x264 command-line would look like this:
x264.exe --crf 22 --preset fast --tune film --output "c:\foobar\my_output.mp4" "c:\foobar\my_input.avs"

I do not know how to add the source to this x264 software. :(

If you are not a developer, just use the pre-compiled x264 binaries from the link I provided in the previous post. You don't need to deal with the source codes.

Regarding the version of avisynth, you mentioned that everything should be in 64x but the native 64x version is not stable yet, so please advise for this regard.

64-Bit x264 unavoidably requires 64-Bit Avisynth. And 64-Bit Avisynth unavoidably requires 64-Bit plug-ins. That's a matter of fact.

The same way, 32-Bit x264 requires 32-Bit Avisynth and 32-Bit Avisynth requires 32-Bit plug-ins.

As speed seems to be your primary concern, you probably want to go with 64-Bit x264 (and thus 64-Bit Avisynth), because 64-Bit x264 is a bit faster than 32-Bit x264.

Indeed the latest "stable" Avisynth is v2.5.8 and the "official" builds are 32-Bit only. You'll have to take the risk of going with "unofficial" builds, if you want 64-Bit.


BTW: Actually there is a way to use 64-Bit x264 with 32-Bit Avisynth. You can do this by running Avisynth and x264 in separate processes and pass the data via a pipe.

(For example, my Simple x264 Launcher (http://forum.doom9.org/showthread.php?t=144140) can use this technique)

[Atak_Snajpera]

only distributed encoding can significaly reduce encoding times. using your four i7 2600 you can expect almost 4x speed up!

[LoRd_MuldeR]

only distributed encoding can significaly reduce encoding times. using your four i7 2600 you can expect almost 4x speed up!

That would be true, if he already is getting the maximum out of his Core i7 2600 system - which is absolutely not clear at this point.

And even then, going for a dual-socket system might be an option to consider...

[Atak_Snajpera]

in de mode he can activate two servers in order to maximize cpu usage (two chunks will be encoded on single pc)

[smok3]

@mgadallah;

a. decide what encoding speed you need
b. test x264 (either from cli or from some gui) with different presets to see if it is feasible to get to speed defined in a.
c. if b=false thinker with new hardware.

So there is some reading to do, plenty in this forums. (Alternative to avisynth might be to use ffmpeg with integrated x264 lib and some integrated AAC encoder perhaps).

[mgadallah]

Thanks for your help.

Please it seems that I reported a wrong information regarding CPU usage.

Please I've recorded a video for the whole process and what system monitoring says as well in the attached video.

http://www.youtube.com/watch?v=dmXu06nC2Jw&hd=1

Choose HD quality.

I think that HDD maybe the reason for this slow performance if I am not mistaken.

So please tell me your opinion regarding this issue and shall I go for the SSD option 1st before go to xeon.

So what kind of a Motherboard I should stick to in case I will buy a SSD drive and does the brand vary or all are the same?

I will buy the biggest size of course which is 256 GB as far as I know.

Thanks a lot and too much appreciated

[smok3]

I think that HDD maybe the reason for this slow performance if I am not mistaken.
test and measure, guessing will only lead you to spending money on possibly unnecessary stuff.

[Atak_Snajpera]

I think that HDD maybe the reason for this slow performance if I am not mistaken.
yep . You are mistaken ... HDD IS NOT A BOTTLENECK IN YOU CASE!!! I would like to see your face after speending money for 256GB SSD for ZERO improvement in encoding speed :)

[mgadallah]

Please if any of you watched the youtube video I've posted!?
http://www.youtube.com/watch?v=dmXu06nC2Jw&hd=1

Choose HD quality.

[smok3]

Please if any of you watched the youtube video I've posted!?
http://www.youtube.com/watch?v=dmXu06nC2Jw&hd=1

Choose HD quality.

and? what is the input, where does it come from? networked drive, local drive? whats vidcoder (do you really want something that uses handbrake engine and why? what are the alternatives?), what else did you try? (was it faster/slower/better/worse quality) How much faster/slower do you need this to go? is quality ok or not? What x264 settings did you try for speed/quality/ect ...

So stop vampire-ing and do some real tests...

[mgadallah]

Thanks alot for reading and replying and too much appreciated for all these question wich will let me know more ofcourse.
and? what is the input, where does it come from? The input file is .MPEG-2 recorded from a satalitte using PCI card Tevii DVB-S2 420.

networked drive, local drive? No, it is local HDD not a network drive.

whats vidcoder (do you really want something that uses handbrake engine and why? Honestly I did goggled and found the native .mp4 with h.264 is HandBrake or VidCoder that is based on HandBrake engine, but I do not know if it is really good or not, but I goggled and asked in various forum and VidCoder was one of the suggested tools.

what are the alternatives?), I was using WinAVI before.

what else did you try? WinAVI.

(was it faster/slower/better/worse quality) It was faster then VidCoder.
How much faster/slower do you need this to go? is quality ok or not?I want to encode a file with 1 hour length in 3 minutes instead of current 7 minutes.

What x264 settings did you try for speed/quality/ect ...I choose the following:
http://i.imgur.com/5WoqP.png
http://i.imgur.com/vlSCr.png
http://i.imgur.com/goEgr.png
http://i.imgur.com/qygQ7.png
http://i.imgur.com/N67AG.png

So stop vampire-ing and do some real tests...Please suggest and addvise for what test I can do :)

Thanks a lot for your time reading my posts.

It may seems that I am lazy but I am not and I am really ant to know and learn but I do not know a lot.

:)

[LoRd_MuldeR]

Honestly I did goggled and found the native .mp4 with h.264 is HandBrake or VidCoder that is based on HandBrake engine, but I do not know if it is really good or not, but I goggled and asked in various forum and VidCoder was one of the suggested tools.

In order run encoding/performance tests, it is very important to kick out everything you don't absolutely need. Otherwise there are far too many factors that might be influencing your results and you won't learn anything from these results. Thus the natural way to do this kind of tests would be using the plain x264 CLI encoder, not some fancy/bloated "all in one" software suite. Consequently you have been asked to just use the x264 CLI encoder or, if you really can't manage to do that, use the x264 CLI encoder with some lightweight GUI front-end. Especially you have been asked to try the different x264 Presets and check the "quality -vs- speed" results. Still you didn't report your results of doing that...

[mgadallah]

In order run encoding/performance tests,...Yes, ok, please may you name some tests to do it. Please accept my truley apologize if my questios is wrong or stupid but I am really meaning my question and I want to know exactly what tests? :)

it is very important to kick out everything you don't absolutely need. ...These are really makes much sense and logical indeed.

Otherwise there are far too many factors that might be influencing your results and you won't learn anything from these results. ...This is exactly what I want to do, THANKS a lot for you :)

Thus the natural way to do this kind of tests would be using the plain x264 CLI encoder, not some fancy/bloated "all in one" software suite....OK.

Consequently you have been asked to just use the x264 CLI encoder or, if you really can't manage to do that, use the x264 CLI encoder with some lightweight GUI front-end. Especially you have been asked to try the different x264 Presets and check the "quality -vs- speed" results. Still you didn't report your results of doing that...Yes, honestly I found it a bit hard to use the cli for x264 with avisynth.
Please may you be more patient and tell me where to start?

[Atak_Snajpera]

go to mpeg 4 gui section and downlad gui which has over 3300000 views.

[mgadallah]

go to mpeg 4 gui section and downlad gui which has over 3300000 views.

You mean this thread here:
RipBot264 v1.17.3 (http://forum.doom9.org/showthread.php?t=127611)

But what I did read about this tool before that it is only useful if I am using more then one real machine and not only one machine.

Unless I am mistaken.

[LoRd_MuldeR]

Please may you be more patient and tell me where to start?

Open a command-prompt (cmd.exe), navigate to the directory where your x264.exe is located (by using "cd" command) and type:
x264.exe --crf 22 --output "out.mp4" "input.foo"

In this command, replace "input.foo" with your actual input file. Can be a media file in some format supported by x264's built-in FFMS2 or an Avisynth script (.avs).

[mgadallah]

Open a command-prompt (cmd.exe), navigate to the directory where your x264.exe is located (by using "cd" command) and type:
x264.exe --crf 22 --output "out.mp4" "input.foo"

In this command, replace "input.foo" with your actual input file. Can be a media file in some format supported by x264's built-in FFMS2 or an Avisynth script (.avs).

Can I do a queue files?
I mean can I do this with 10 files at once and make it runs one after another ? or I must do it by hand one by one?

[LoRd_MuldeR]

Can I do a queue files?

Sure. Commandline applications are predestinated for scripting (http://en.wikipedia.org/wiki/Batch_file). That's one of the reasons that makes them popular among "advanced" users.

You can try something like this:
@echo off

set "INPUT_PATH=c:\input"
set "OUTPUT_PATH=c:\output"
set "PRESET=fast"
set "CRF_VALUE=22"

for %%f in (%INPUT_PATH%\*.*) do (
x264.exe --crf %CRF_VALUE% --preset %PRESET% --output "%OUTPUT_PATH%\%%~nf" "%%f"
)


Furthermore, most GUI front-ends for the x264 CLI encoder will allow queuing easily...