help quality vs speed

[montreal.simo]

Hello Sirs,
I work on a research topic - QoS in multimedia transmission system-, I have to do some tests on h264 parameters ( compromise quality-speed).
My job is to establish four profiles, each profile has a given quality and consumes a measured CPU percentage .
the profile with a good quality well consomme more CPU than the others average,bad and very bad quality.
I tried the preset, subme, but without results. not really clear in PSNR terms (all presets have the same quality).
Gentlemen, if you can help me to find a good options that affect the quality and speed in the same time.

[LoRd_MuldeR]

x264 already has a sophisticated "Preset" system built-in to control the "quality -vs- speed" trade-off. Seems like your job is already done :)
http://mewiki.project357.com/wiki/X264_Settings#Presets

BTW: Of course using a "faster" Preset will not reduce the CPU usage (in terms of percent), but reduce the overall CPU cycles that will be required to complete the job.
This means that you will most likely see "100% CPU usage" with all Presets, but the time to complete the job may differ greatly, depending on the selected Preset.

[sneaker_ger]

Use 2pass with a constant bitrate, --tune ssim and measure with --ssim. Use the presets for different speeds.
(or psnr instead of ssim)

[montreal.simo]

I tested all the preset, I still have the same quality. I use the preset with the tune ZeroLatency.
I have the same quality, the PSNR still 42, I do not think that the presets are enough, same for preset = ultrafast the PSNR gives 40.

[LoRd_MuldeR]

Well, as we all know, objective quality metrics, such as PSNR or SSIM, can only give a very rough approximation of "perceived quality" ;)

If you look at the output with your own eyes, then the difference in quality between something like "veryfast" and "veryslow" Presets should be striking.

Otherwise, you are probably using a bitrate that is too high to see the differences. If "veryfast" already looks transparent at the chosen bitrate, then "veryslow" can't look any better, obviously.

And of course only files with an identical file size (identical average bitrate) can be compared by quality! Also note that "--tune psnr" is required, if you want to compare PSNR values.

Last but not least: With "--tune zerolatency" you enforce some rather "extreme" tweaks for minimum possible latency. This may "smudge" the difference between the Presets you are testing.

[montreal.simo]

Yes, I completely agree with you, but, you know, I can not make a subjective study now. It is true that the objectives methods that has yet (PSNR ...) are not the best, but we can transform the PSNR in MOS as normes to get an idea about quality.this is not the best way to evaluate quality but at least we must go through.
Maybe you're right about bitrate, I use a large bitrate, I will test with lower valuesr. by the way, what is the bitrate that you find reasonable for broadcast on the network ?

[LoRd_MuldeR]

Maybe you're right about bitrate, I use a large bitrate, I will test with lower valuesr. by the way, what is the bitrate that you find reasonable for broadcast on the network ?

This of course totally depends on what resolution you are dealing with as well as on the type of footage.

[montreal.simo]

I use the resolution 720x480, 25 fps for videoconferencing system but also it should work for dynamic movies

[LoRd_MuldeR]

"videoconferencing" and "dynamic movies" are quite different requirements, I think.

I would recommend you first find out which is the slowest possible Preset that meets your speed requirements. Then with that Preset and CRF mode find the highest possible CRF value that still gives satisfactory quality.

With those settings you can finally determine which average bitrate you get for each type of source. This should give you a good idea of what bitrate you'll need...

[spawnbsd]

Maybe you're right about bitrate, I use a large bitrate, I will test with lower valuesr. by the way, what is the bitrate that you find reasonable for broadcast on the network ?
Depends on the resolution, but most telco's use around 5mbit/s for 1080i/p, and 2-3mbit/s for 480i/p content. At those bitrates the differences between the presets will quickly become apparent.

[montreal.simo]

@LoRd_MuldeR : ya, you are right, its very different but I need to validate the work.
Unfortunately, I work on the Gstreamer platform , the implimentation of x264 does not contain the option CRF :(
@spawnbsd: with 2Mb, the quality still the same for all presets

[JEEB]

@LoRd_MuldeR : ya, you are right, its very different but I need to validate the work.
Unfortunately, I work on the Gstreamer platform , the implimentation of x264 does not contain the option CRF :(Oh really now? (http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/tree/ext/x264/gstx264enc.c#n1083)

Heck, I think they added support for even runtime settings changing in 2010 looking at a bugzilla entry (https://bugzilla.gnome.org/show_bug.cgi?id=621663) where Dark_Shikari (Jason) took part as well.

[nm]

Unfortunately, I work on the Gstreamer platform , the implimentation of x264 does not contain the option CRF :(
Sure it does.

$ gst-inspect x264enc
<snip>
pass : Encoding pass/type
flags: readable, writable
Enum "GstX264EncPass" Default: 0, "cbr"
(0): cbr - Constant Bitrate Encoding
(4): quant - Constant Quantizer (debugging only)
(5): qual - Constant Quality
(17): pass1 - VBR Encoding - Pass 1
(18): pass2 - VBR Encoding - Pass 2
(19): pass3 - VBR Encoding - Pass 3
quantizer : Constant quantizer or quality to apply
flags: readable, writable
Unsigned Integer. Range: 1 - 50 Default: 21


with 2Mb, the quality still the same for all presets

Check that the files were actually encoded with different settings: strings -100 video.264
If you don't have strings, use MediaInfo.

[Sagittaire]

Yes, I completely agree with you, but, you know, I can not make a subjective study now. It is true that the objectives methods that has yet (PSNR ...) are not the best, but we can transform the PSNR in MOS as normes to get an idea about quality.this is not the best way to evaluate quality but at least we must go through.
Maybe you're right about bitrate, I use a large bitrate, I will test with lower valuesr. by the way, what is the bitrate that you find reasonable for broadcast on the network ?

Be carefull, PSNR have decibel unit (log of sum of difference between input and output for make simple). 2 dB can be enormous quality difference between different encoding.

Anyway you must understand that for codec: the fonction quality gain = f (time) is something like A(1-e^(-bt)). It's more and more difficult to have quality gain and you must spend more and more time to have more quality.