Is it possible to force fps around 1 with x264 ?

[sirt]

Hi,

I have another question that might be silly but well...consider I try to encode some video with x264 using a basic commandline (--sar 10:11 --preset veryslow --crf 18 for example). Then the encode will be done, that is not the problem. But it seems I can't control fps to vary around 1. It will fluctuate without me interfering, sometimes around 2, sometimes around 6. Then is there a possibility to force fps to remain around 1 ? If I use some enchancement filters trough an avisynth script, the encode may be slow down (fps below one sometimes) but it still can't be controlled either.

[Atak_Snajpera]

what are going to achieve with constant encoding speed???

[Nevilne]

try something like
assumefps(1)
in avisynth script
then pipe it with ffmpeg
ffmpeg -re -i input.avs -f yuv4mpegpipe - | x264 -o output.264 --demuxer y4m --fps 30 -

[sirt]

Thanks for your answer Nevilne I will try soon and let you know . Anyway do you think it is a good idea to force that fps while using crf (or 2 pass) ? Will it improve something or not or change something ?


Atak_Snajpera, well I would like to control it. In fact, do you think that encoding with fps around 10 on the one hand and with fps around 1 on the other - but using the same x264 settings - will have an impact on the output (quality, frame prediction ect) ?

[CruNcher]

there was a patch by Avail media for this but it most probably is totally outdated by now,atak normaly you use this for Live Broadcast Scenarios keeping the output FPS fixed think about it like a Vsync though it's more complex it all the time adapts the settings so you get always the best output @ the given FPS ;) . So instead of you putting in bitrate or crf you chose your desired Encoding Speed and it will try to keep it, it's a different type of RC of course you still can manipulate the VBV :)

[J_Darnley]

What is this whole thread about? The speed at which your computer can run x264 has no effect on the quality, output or anything other than the encoding speed printed during and at the end which is just: frames / (current time - start time).

x264 does change the quality of a frame based on how long it will be shown for but if you think there is some problem here you really need to describe it better.

[sirt]

Here is a picture to show you what fps I'm talking about : http://i39.tinypic.com/zvbkia.jpg

I'm referring to the 1.80 fps line. Adding the assumefps(1) line in the AVS script seems to work : the encoding is now done with fps around 1. But my question is what will happen if I use assumefps(10) for example but the same x264 settings ? Does that have an influence on the quality ? I'm still confused about that, sorry.

J_Darnley, is there a way to modify "the encoding speed printed during and at the end which is just: frames / (current time - start time)" you refer to ?

[sirt]

CruNcher I'm not sure to have totally understood what you said ; could you please develop more what you mean by "Vsync though it's more complex it all the time adapts the settings so you get always the best output @ the given FPS" and how to use use that if it is possible.

[J_Darnley]

Here is a picture to show you what fps I'm talking about : http://i39.tinypic.com/zvbkia.jpg
Yes, that is the encoding speed.

I'm referring to the 1.80 fps line. Adding the assumefps(1) line in the AVS script seems to work : the encoding is now done with fps around 1. But my question is what will happen if I use assumefps(10) for example but the same x264 settings ? Does that have an influence on the quality ? I'm still confused about that, sorry.
x264 will still only encode at 1.8 fps because that is as fast as it can go on your computer with the settings you used.

J_Darnley, is there a way to modify "the encoding speed printed during and at the end which is just: frames / (current time - start time)" you refer to ?
Yes, edit x264.c and recompile. Just what changes do you want to make?

[Audionut]

Here is a picture to show you what fps I'm talking about : http://i39.tinypic.com/zvbkia.jpg

That is the speed the x264 is encoding at, not the framerate of the video.

[sirt]

Ok thanks for those precisions. So I think I don't have to worry about that encoding speed nor the framerate of the video, have I ? ; Indeed, that assumeffs(1) line is forcing my video framerate (which is natively at 24 img/s) to 1 img/s which I don't want, so I guess I don't have to include it on the AVS script.

J_Darnley : "Yes, edit x264.c and recompile" ; are you serious ? Do you want me to reedit myself the x264 program made by experts ? In fact I aimed at encoding with the slowest encoding speed possible but it seems it has no sence in so far as it will give me the same result, am I wrong ?

[CruNcher]

CruNcher I'm not sure to have totally understood what you said ; could you please develop more what you mean by "Vsync though it's more complex it all the time adapts the settings so you get always the best output @ the given FPS" and how to use use that if it is possible.

You cant use it until you get it patched in and as i said avails patch for it is very old and it makes only sense if you want to restrict the Encoding Speed (Frame Limiting) and for example keep latency and power consumption as low as possible for transcoding it's not really relevant, and it wont make sense also if your system isn't able to reach the desired FPS @ all. When you Broadcast a Program Live you don't want above Realtime Speed results and lowest latency possible and thus need to limit x264s Framerate ;)

[Audionut]

Indeed, that assumeffs(1) line is forcing my video framerate (which is natively at 24 img/s) to 1 img/s which I don't want, so I guess I don't have to include it on the AVS script.

That's correct. Remove the assumefps.

In fact I aimed at encoding with the slowest encoding speed possible

x264.exe --preset placebo --tune grain --crf 10 --merange 64 -o "output.xxx" "input.xxx"

but it seems it has no sence in so far as it will give me the same result, am I wrong ?

Generally, slower encoding speed on the same computer will result in higher quality. But the difference in quality between encoding at 5fps and .5fps is probably not going to be much.

The best way to adjust this is with the "--preset" parameter.

Encoding speed will always fluctuate due to differences in your video. Some parts of the video are easier to encode then others. So these easier parts are faster to encode.

You've got the wrong ideas about what's going on and what you want. Just because the encoding speed fluctuates during an encode, doesn't mean anything as far as quality is concerned.

[LoRd_MuldeR]

The encoder spends most of the time in searching the best decision within the "space" of possible decisions. This could be done with a simple "brute force" approach: Try out everything and pick the one that gave the best result. But of course that would be much too slow! Instead a decent encoder will use "smarter" search strategies. Put simply, the encoder will concentrate its search one the most promising regions of the search space. At the same time it will try to discard "bad" regions as soon as possible. The search is usually stopped, as soon as the result doesn't improve any further between two consecutive search iterations. Consequently the best (or at least a very good) decision may be found very quickly. However sometimes it can take much longer until the search terminates. That's why the encoding speed may vary, depending on the content. But this does not mean that the final decision of a "longer" search is necessarily better than that of a "shorter" search.

And there is another reasons that comes to my mind: The CABAC coder takes a lot of CPU cycles. But the CPU time spent for CABAC encoding/decoding highly depends on the bitrate. Of course the bitrate will fluctuate throughout the movie, because more "complex" scenes need more bits than less "complex" scenes for the same level of quality - and thus the rate-control algorithm will adjust the bitrate accordingly. As a result, "high bitrate" scenes take more encoding time than "low bitrate" scenes. And therefore it is expected that the encoding speed will fluctuate along with the bitrate.

All this doesn't mean that fluctuations in the encoding speed are a bad thing. The encoder will simply encode "as fast as possible" with the given encoding settings and the given input video. If, with the given encoding settings, one part of the input video can be encoded faster than another part, then it doesn't make any sense to slow-down the encoding speed "artificially" in the part that could be encoded faster. You can think of it like this: Each "scene" in the video needs a certain number of CPU cycles to be encoded. If one scene happens to need less CPU cycles (for the reasons explained above), why should the encoder waste additional CPU cycles being idle? Instead it will move on to the next "scene" as soon as possible...

[sirt]

Thanks guys for the explanations.

LoRd_MuldeR, the question is why would the encoder encode "as fast as possible" as you explain and not as "slow as possible" then ? I guess you would reply me back : in order not to waste additional CPU cycles. But, I don't get why the encoder is supposed to go trough the scenes asap instead of taking "his time".

"the final decision of a "longer" search is necessarily better than that of a "shorter" search." For example, let's say I use first --preset placebo --merange 16 --crf 18, then --preset placebo --merange 64 --crf 18. As expected, the second configuration is slower (fps around and below 1). Do you think there will be a significant difference between the too final encodes ? To some extend, could shorter search be more effective than a slower search in some cases ?

[Atak_Snajpera]

check in dictonary what OPTIMALIZATION means. Most people don't even see difference between medium preset and placebo. i would rather use 10 bit medium preset than 8 bit placebo. Also check what placebo means:)

[sirt]

check in dictonary what OPTIMALIZATION means. Most people don't even see difference between medium preset and placebo. i would rather use 10 bit medium preset than 8 bit placebo. Also check what placebo means:)

Please explain me because it is not totally clear. I know the preset just gathers a collection of settings setted differently, but I think you will see a difference between some presets. Of course I haven't detected myself something significant between placebo and veryslow but look there http://dev.gentoo.org/~beandog/x264_preset_reference.html . Medium uses treillis 1 whereas placebo used treillis 2, also subme is lower and direct is spatial so I think there will be a difference. But it is not an easy issue to discuss.

[Atak_Snajpera]

anything above medium preset is a waste of time and energy for me. period.

[LoRd_MuldeR]

Thanks guys for the explanations.

LoRd_MuldeR, the question is why would the encoder encode "as fast as possible" as you explain and not as "slow as possible" then ? I guess you would reply me back : in order not to waste additional CPU cycles. But, I don't get why the encoder is supposed to go trough the scenes asap instead of taking "his time".

Why doesn't the encoder work as "slow as possible"? Strange question. Why should the encoder force itself to work "slower" when it can finish the same job faster?

And what should the encoder do when it finished processing the current frame faster than the previous frame? Should it wait idle until more time has passed? Makes no sense!

The encoder "goes through a scene" the way the current encoder settings tell it to do. This may take more or less CPU cycles, depending on the individual input frames.


It indeed would make sense, for certain highly-specific scenarios (such as real-time streaming), to enforce a certain minimum encoder FPS.

This means, if the FPS drops below a certain threshold, the encoder would automatically switch to "faster" encoder settings, which will trade some quality for performance.

Doing so will obviously cause quality fluctuations, because some parts of the video will be encoded with "faster" (lower quality) settings! :eek:

But this may be an acceptable price, if your application eagerly needs to ensure a certain minimum throughput (FPS), as is the case with real-time streaming, for example.

However, the other way around this hardly makes any sense! Finishing earlier/faster (with the very same settings/quality!) never is a bad thing. Right? ;)

"the final decision of a "longer" search is necessarily better than that of a "shorter" search."

No, that's certainly NOT the case. It is NOT necessarily better. It depends! I might be better, but quite often it won't.

A "slower" (more intensive) search strategy might find a better solution, but a "faster" (smarter) search strategy might find the exactly same result (or one that is very close).

The real question is: What is the probability that the "slower" search really finds a better solution than the "fast" one? And does that probability legitimate the additional speed cost?

Quite often, the "slower" (more dumb) search strategy is significant slower than the "faster" (smarter) strategy, but the probability to actually find a better solution is pretty low.

For example, using the "hex" motion estimation gives a significant improvement over "dia". And "umh" gives yet another improvement, that (usually) legitimates the speed cost.

But the "esa" or even "tesa" methods, while being a lot slower than "umh", will usually not give any improvement over "umh". Or the improvement is so small, that it's not distinguishable.

That's why these kind of settings will only be used in the "placebo" preset, i.e. these are settings that are "slower" (a whole lot slower!) but usually not any better. Bummer!

Another fact to keep in mind is that even the very same search method may terminate "faster" (earlier) or "slower" (later), depending on the input data.


And to make this clear again:

x264 does not change the "search strategy" during the encode. It sticks to the selected settings (strategy), which simply may happen to terminate "faster" once in a while.

So if you see the encoder FPS go up, this does NOT mean x264 just switched to "faster" (lower quality) settings. It only means the last few frames were "more easy" to process :)

[sirt]

Thanks a lot for those informations Lord_Mulder, it is really clear in the way you explain that to me ! Now, it appears slower settings are not necessarly implying a huge improvement.

Anyway, I'm personnaly using tesa and umh but honestly I haven't seen anything special on the different encodes. It seems umh is enough. What's problematic to me is the aq-mode parameter ; I have seen a few differences while using mode 2 sometimes and - from what I've tested - mode 1 seems to work well and to be enough. I'm sorry for going out of subject, but well I would like to speak about another parameters : aq-stenght ; do you think there is a sence raising it to something like 1.6 while using crf and preset placebo for example ? What about qcomp ? I have setted it to something like a range between 0.70 - 0.75 and I've seen some differences, but that's maybe juste me. What do you generally think about those last parameters ? What do they really change ? I have read many things about right there or on the dedicated x264 settings page but it is still not totally clear to me.

[Atak_Snajpera]

do not touch anything. Stick to presets.

[CruNcher]

sirt would you see if this used placebo or not http://a4.video4.blip.tv/0530001566211/Cr4bl3r-intelhdrecordingtestx264tuned349.mp4 ?

[sirt]

sirt would you see if this used placebo or not http://a4.video4.blip.tv/0530001566211/Cr4bl3r-intelhdrecordingtestx264tuned349.mp4 ?

I can't tell you if preset placebo was used or not given that the settings are hidden (I have asked about how to do that in another thread, I guess I would have to modify the C file and recompil it, wouldn't I ?) and because I'm not an encoding expert to detect what strategies of encoding were used. I could only recognize placebo parameters if the settings would be avaible.

[LoRd_MuldeR]

I can't tell you if preset placebo was used or not [...] I could only recognize placebo parameters if the settings would be avaible.

If that is the case, then it's the prefect prove that "placebo" (and all the extra CPU time it takes) is useless ;)

That's because if the "placebo" settings actually gave a non-negligible improvement over "veryslow", then you would be able to tell the difference with your own eyes by looking at the video.

(And I guess that is what CruNcher wanted to demonstrate ^^)

[Didée]

Without even looking at the video. From only one file available, it is close to nonsense to ask "can you see if it used placebo or not". Shall I upload some random sample and ask "can you see if it used subme 8 or subme 9?" ? Imagine ... at otherwise fixed settings, it's quite possible that --preset placebo looks worse than --preset slow --aq-strength 1.3. Par examplé. All things depend on many other things.

Silly.

[CruNcher]

@Didée
;)

[sirt]

Could you explain what is the impact of that aq-strength parameter ? In particular, is setting it to a certan value synonym of using VAQ (Variable AQ) ? I'm still confused with VAQ, what is it exactly ? It seems aq-strenght can interfer significantly : what shall happen if it's setted below it's default value 1 or above 1 ? I have done some encode with --aq-strengh 1.5 and another one with default, both with --preset placebo but I haven't seen anything special excepted a small difference of size although I have checked some frames.

[LoRd_MuldeR]

VAQ means "Variance Adaptive Quantization" and it's the AQ (Adaptive Quantization) algorithm used by x264. AQ means that each block in a frame can have its own quantizer value (instead of settings them all to the same value).

There are two parameters to control AQ: --aq-mode and --aq-strength. The former can be used to selected the AQ mode (0: Disabled, 1: VAQ, 2: Auto-VAQ). The latter, as the name implies, controls the "strength" of AQ.

Usually you will be best off with keeping the default AQ mode (mode 1). Disabling AQ is not a good idea, because AQ greatly improves the visual quality. AQ mode 2 is still considered "experimental", but you can feel free to give it a try.

AQ strength is all about finding the "sweet spot". Setting AQ strength too low will hurt the quality. But setting AQ strength too high will hurt the quality as well. Unless you want to experiments a lot, simply trust on the defaults!

Note that one of the options that is controlled by x264's "--tune" parameter is the AQ strength! Consequently you should set "--tune" according to your type of source and not overwrite "--aq-strength" manually...

See also:
http://forum.doom9.org/showpost.php?p=1567194&postcount=9

[sirt]

Ok I see, it is very clear to lurn from you ! I guess I should mostly use --aq-mode 1 then (which is default ). It's not the first time I've heard it's not a good idea to adjust that aq-strength parameter and from what I know there is a correlation between it and the psy-rd parameter. Many guys recomand not to modify that parameter as well. Is there a good idea to adjust it and if yes, how ? I've tried --psy-rd 1.0,1.0 and --psy-rd 1.0,0.15 for example with and without --aq-strenght 0.92 and --preset placebo --crf 16 but I was unable to see something really different from an encode to another. It's possible I don't know where to look.

EDIT : it seems --tune film + --psy-rd 1.0,1.0 makes the output a little more detailed than the one with --tune film + --psy-rd 1.0,0.15 (both with --preset placebo --crf 16) and it sharpens, am I wrong ?

[LoRd_MuldeR]

it seems --tune film + --psy-rd 1.0,1.0 makes the output a little more detailed than the one with --tune film + --psy-rd 1.0,0.15 (both with --preset placebo --crf 16) and it sharpens, am I wrong ?

First of all "--tune film --psy-rd 1.0:0.15" is redundant, because Psy-RDO defaults to 1.0 and "--tune film" already sets Psy-Trellis to 0.15. So you can remove the "--psy-rd <psy-rdo>:<psy-trellis>" completely in that case ;)

Furthermore with Psy-RDO and Psy-Trellis it is like with AQ strength: It's all about finding the sweet spot. Some Psy-RDO and/or Psy-Trellis nicely improves the sharpness/detail, which most people seem to like (and quality metrics don't ^^).

But too much of Psy-RDO or Psy-Trellis will start to create nasty artifacts. Especially with Psy-Trellis you have to take care (1.0 is pretty heavy!). That's why "--tune film" only uses 0.15. But you can feel free to experiment yourself...

[Didée]

It was just an example, meaning that it's possible that a lesser preset (like "slow") with source- and bitrate-specific tweaking ~can~ turn out better than a higher preset (like "placebo") with everything-at-default.

Specifically in regard to "here-is-one-video--now-tell-if-it-used-placebo-or-not." :rolleyes:

[sirt]

Ok thanks a lot for those precisions guys. In so far as I've started to do some tests, let's ask you a few more things : I don't understand what will happen if I use --tune psnr" or "--tune ssim" or even both at the same time ? What are they intended for and what can happen if I set this ?

[sneaker_ger]

Don't use them! They are only useful for comparisons to other encoders made using PSNR or SSIM metrics.

[LoRd_MuldeR]

Ok thanks a lot for those precisions guys. In so far as I've started to do some tests, let's ask you a few more things : I don't understand what will happen if I use --tune psnr" or "--tune ssim" or even both at the same time ? What are they intended for and what can happen if I set this ?

The "--tune" option tunes/tweaks x264 for a specific type of source. Or for a specific kind of task.

For most content your best choice will be "--tune film". It works good for "real life" footage as well as CGI. For anime/cartoon with a lot of flat areas, the right choice would be "--tune animation".

Finally, "--tune grain" is for grainy sources and when your goal is to retain all that grain. Thus this is only a useful option for very high bitrate encodes, otherwise retaining the grain is a lost case anyway.

The options "--tune psnr" and "--tune ssim" configure x264 to get a maximum PSNR or SSIM score. Essentially they disable all the nice Psy-optimizations, so you do NOT want that for regular encodes! :eek:

(It's because the Psy-optimizations were created to get better subjective quality, as perceived by the human eye. They tend to hurt objective quality metrics, like PSNR or SSIM)

See also:
http://pastie.org/private/cq7stkxkfalbtijod1rdq

[sirt]

I understand, it's not the first time I've been told those tune pssn and ssim are not suitable but I was not totally aware of their impact. Unfortunately this page http://mewiki.project357.com/wiki/X264_Settings is not really discussing those points. Then let's finish with my last questions (I guess I should have opened another thread to discuss any points but well...)

1) I don't understand what is --open-gop made for ; same for --slices, in particular what would happen if I set it for a non HD source ? I read somewhere it may be possible to set it to 1 for such source and to 4 for HD source.

2) Is there a sence to set b-bias (with --bframes 3 for example) ? I heard it is a bad idea to use that because x264 makes itself his rate control.

3) Is there a point to touch qmin and qmax (respectively default 0 and 51) ? For example if I set qmin 10 and qmax 40, what could basically change ?

4) What will happen if I raise qpstep (to 8 for example) or if I reduce it (to 2 for example) ?

5) I use --ip ratio 1.60 and (when encoding via a 2pass mode) --pb-ratio 1.10 with --bframes 3 --preset placebo --crf 16 again (or respectively 2pass) ? Is it raisonable ? How should I adjust such parameters ?

[LoRd_MuldeR]

I understand, it's not the first time I've been told those tune pssn and ssim are not suitable but I was not totally aware of their impact. Unfortunately this page http://mewiki.project357.com/wiki/X264_Settings is not really discussing those points. Then let's finish with my last questions (I guess I should have opened another thread to discuss any points but well...)

PSNR or SSIM don't have any "impact" at all. They are just methods to (objectively) measure quality, i.e. you can make the computer "measure" quality and express the quality as a number.

It shouldn't be too hard to imagine that an objective quality which "perfectly" predicts the subjective/perceived quality does NOT exist. You are still best off trusting your own eyes ;)

1) I don't understand what is --open-gop made for

OpenGOP is only useful for very short GOP's, as required by the BluRay standard. Normally (i.e. when larger GOP's are allowed) the benefit of OpenGOP is small or negligible.

The idea behind OpenGOP is explained here:
http://forum.doom9.org/showpost.php?p=1300124&postcount=32

same for --slices, in particular what would happen if I set it for a non HD source ? I read somewhere it may be possible to set it to 1 for such source and to 4 for HD source.

Slices divide each frame into several segments, so that each segment can be processed independently.

The purpose of slices is to allow multi-threading within on frame (by processing multiple slices in parallel), rather than doing multi-threading by processing multiple frames in parallel.

But slices hurt the compression efficiency! Therefore x264 has switched to multi-threading without slices long ago. So if you encode with x264, you do NOT need slices to enable multi-threading.

On the other hand, the BluRay specifications define that you have to use 4 slices. So if your final goal is to author a BluRay disc, then you won't get around using slices ;)

(Long ago, there were some H.264 decoders which couldn't enable multi-threading, if the stream doesn't use slices. Up-to-date H.264 decoders do NOT rely on slices to use multi-threading)

2) Is there a sence to set b-bias (with --bframes 3 for example) ? I heard it is a bad idea to use that because x264 makes itself his rate control.

The "bias" controls the encoder's tendency to "prefer" B-Frames over P-Frames (or the other way around). Don't change the default, unless you have a very good reason to believe that the default is wrong.

3) Is there a point to touch qmin and qmax (respectively default 0 and 51) ? For example if I set qmin 10 and qmax 40, what could basically change ?

If you change the minimum and/or maximum quantizer, then this restricts the encoder's freedom to pick the "optimal" quantizer. By default, the encoder can use the full scale (0 to 51).

Unless you believe that x264's rate-control is doing something wrong with picking the quantizers, don't change the defaults!

4) What will happen if I raise qpstep (to 8 for example) or if I reduce it (to 2 for example) ?

The "qpstep" controls the maximum change of quantizer between two consecutive frames. The default limits this to 4 in order to avoid heavy quality fluctuations between consecutive frames.

Therefore setting "qpstep" much higher than 4 probably is not a very good idea. Setting it even lower may be a bad idea as well, because rate-control would not be able to "react" as fast as it used to...

[sirt]

Many thanks Lord_Mulder...you should just go on the wikipedia settings page and explain me ALL the parameters one by one ;) No, it's a joke !

Honestly, I will have to reflect a lot on what you told me and to do tests to see what happens on some specifical frames. Do you have any suggestions for the question 5) ?

Dealing with "bias" parameter, what could be such a reason to believe that the default is wrong ? I usually use 3 or 4 B-Frames but somebody told me that I could decide to set it to 16 and it won't be bad due to the fact the encoder would choose itself what to do. Anyway, would it be possible that increasing the number of B-Frames urges me to decide to modify that "bias" setting ?

While I'm using placebo preset qpmax is setted to 69 value, is there a reason for that ? What if I set it to 100, qpmin remaining untouched ? Well I know I will have to experiment myself of course, but I guess you can evaluate the tendency of the work done by the encoder in such conditions.

I changed scenecut 45 because I read somewhere such value would help the encoder react to movement complexity (I give a try to a nervous video with a lot of scene changes, fades in and fades out), is that true ?

Finally, I usually use rc-lookahead 60 but I gave a try to 250 but I was unable to see anything special, does that really change something ?

[LoRd_MuldeR]

you should just go on the wikipedia settings page and explain me ALL the parameters one by one No, it's a joke !

Like this?
http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264

Dealing with "bias" parameter, what could be such a reason to believe that the default is wrong ? I usually use 3 or 4 B-Frames but somebody told me that I could decide to set it to 16 and it won't be bad due to the fact the encoder would choose itself what to do. Anyway, would it be possible that increasing the number of B-Frames urges me to decide to modify that "bias" setting ?

You are mixing things up!

The "--bframes" options sets the maximum number of consecutive b-frames. It's only an upper limit, the encoder will still select the "optimal" number of frames!

So setting this to 16 is always "safe". Though in reality the encoder will very rarely actually go that high. Also setting it to a higher value slows down the encoding process noticeably!

Consequently it can be set to a lower value in order to safe some encoding time. By limiting this option to ~8 you don't loose much and you get quite some speed-up :)

The "bias" option, however, is something different! It influences the way how the encoder will decide what the "optimal" number of b-frames is! And you really shouldn't mess with that, unless you have a good reason.

While I'm using placebo preset qpmax is setted to 69 value, is there a reason for that ? What if I set it to 100, qpmin remaining untouched ? Well I know I will have to experiment myself of course, but I guess you can evaluate the tendency of the work done by the encoder in such conditions.

The maximum possible quantizer, for an 8-Bit build is 51. For an 10-Bit build it is higher (probably 69), because the quantizer scale is different then. That's why the default for "qpmax" is 69.

And that is not only for "placebo". It's always like that, unless you lower it explicitly. Again, you usually shouldn't do that for reasons explained earlier...

I changed scenecut 45 because I read somewhere such value would help the encoder react to movement complexity (I give a try to a nervous video with a lot of scene changes, fades in and fades out), is that true ?

The "--scenecut" option controls the threshold for I-Frames. If you increase that value, the encoder will detect a scene-change (and therefore place an I-Frame) less often.

Or in other words: The encoder will be less sensitive to scene-changes. If you lower the value, the opposite will happen, i.e. the encoder will be more sensitive to scene-changes and detect a scene-change more often.

As with all the other options that normally don't have to be touched by the users, you shouldn't change the default, unless you have a very good reason...

(Also be aware that the "--keyint" and "--min-keyint" limits still apply, regardless of "--scenecut". Thus by setting "--scenecute" to extreme values, you will only run into the "--keyint" or "--min-keyint" limits more often!)

Finally, I usually use rc-lookahead 60 but I gave a try to 250 but I was unable to see anything special, does that really change something ?

Higher "rc-lookahead" is better, but also needs more memory! It's mainly a memory problem. Also the more you increase "rc-lookahead", the less benefit you will get by increasing it even further...

[sirt]

Fantastic, thanks a lor for your time spent there. I can't believe I didn't know that tutorial page ; is that you who wrote that ? If you know another detailed pages like that, please post the links there.

[LoRd_MuldeR]

Fantastic, thanks a lor for your time spent there. I can't believe I didn't know that tutorial page ; is that you who wrote that ?

Partly.

[sirt]

I will have to read that carefully anyway and test some options. The fact is I'm working on a grainy source (especially in dark areas) and as I asked at the beginning, I wanted to slow down the encode but I understand it is not necessarly usefull to do this. I'm trying to adjust the parameter in order not to blurry it and to preserve the grains (I can't stand using filters to remove grains or noises), I want my video to be as natural and not blurry as possible. The parameter psy-rd seems to help a lot (especially when the psy-trellis option is setted to 0.15. It looked more detailed and sharpened. I don't want to oversharpen of course, just to have a lot of details, no blur and what I absolutely want to avoid is some kinds of artefacts near edges like in this example : http://i43.tinypic.com/ax1kdi.png I indicate what I refer to with the arrow ; you can see some kind of distorded pixels around the shoulder, what I apparently could call a form of ringing. I don't really know what to do for that but in order to avoid blurs it came up to my mind the idea to set --qblur 0.3 and --cplxblur 10 but I ignore if that's a good idea or not in so far I didn't find anything really noticable on the output. I also use --deblock -1,-1 but - in spite of the fact I read all the more I could on the forum about delbock - I still don't understand how to set this to achieve what I want : minimum blur but no macro block distorsions (especially in fade out and dark areas).

[LoRd_MuldeR]

You know that "--qblur" and "--cplxblur" has nothing to do with visual "blurring" you may see in the video, right?

It's all about applying a "gaussian" filter on the quantizer curve, i.e. the curve that you would get if you create a plot with the frame number on the x-axis and the frame quantizer on the y-axis.

This is done in order to limit the "fluctuation" of the quantizers between neighboring frames. If this wouldn't be done, the fluctuation could be visible in the output...

[sirt]

Okay and how would you set deblock then regarding what I want to achieve (minimum blur, no macro blocks, avoid ringing around edges) ? Or am I wrong to think deblocking might have an influence on this ?

[LoRd_MuldeR]

"Minimum blur" and "no macro blocks" (no "blocking" artifacts) obviously are contradictory or at least conflicting goals!

With the H.264 "In-loop deblocking" filter you can reduce the visible blocking artifacts - at the cost of increased blurring (reduced sharpness). As always in life, nothing is for free ;)

So as with most encoder settings: It's all about finding the compromise that gives the best result for your personal preferences. Extreme values (high or low) are no good...

(Note: The "film" tune uses "--filer -1:-1", so it slightly lowers the deblocking filter strength compared to the defaults. Personally, I usually stick with that)

[sirt]

Thanks Lord, I usally use -1,-1 too.

1) Now, I wonder how to set keyin and keyint-min : consider I have a source at 24 img/s. I chose to use --place placebo --crf 16 and --keyint 240 --min-keyint 24 ; for a PAL source at 25img/s, I would use --keyint 250 --min-keyint 25 . I'm approximately sure the min(keyint parameter is almost correct (I read it has to be the same as the framerate of the video). But am I right if I setted keyint like as said ? What would happen if I set it to 120 in the first case and 125 in the second, or even higher or lower ?

2) I've read in many places I shall use at least 3 ref frames (--ref 3) and not go under 5 or 6. Is there a bad idea to set that parameter 16 for example ? What does that imply on the quality and B-frames ?

3) I asked before something about qcomp parameter : what does imply setting it to somehting like 0.75 (instead of 0.60) or even 1 ? It's still not clear how it will modify the encoding.

4) Well as you have noticed (I think...) I am curious so a dum idea came to me : set --crf 16 and --bitrate XXXX ; is that a good idea to do that ? What would happen ? It seesm it results in some kind of ABR encoding but I don't know it it's great to do that. I wanted to to add that bitrate line in order to control the final size (CRF doesn't let me know what it will be). In particular, what's the difference between doing something like that and a 2 pass encoding with the bitrate line only ?

[Groucho2004]

Thanks Lord, I usally use -1,-1 too.

1) Now, I wonder how to set keyin and keyint-min : consider I have a source at 24 img/s. I chose to use --place placebo --crf 16 and --keyint 240 --min-keyint 24 ; for a PAL source at 25img/s, I would use --keyint 250 --min-keyint 25 . I'm approximately sure the min(keyint parameter is almost correct (I read it has to be the same as the framerate of the video). But am I right if I setted keyint like as said ? What would happen if I set it to 120 in the first case and 125 in the second, or even higher or lower ?

2) I've read in many places I shall use at least 3 ref frames (--ref 3) and not go under 5 or 6. Is there a bad idea to set that parameter 16 for example ? What does that imply on the quality and B-frames ?

3) I asked before something about qcomp parameter : what does imply setting it to somehting like 0.75 (instead of 0.60) or even 1 ? It's still not clear how it will modify the encoding.

4) Well as you have noticed (I think...) I am curious so a dum idea came to me : set --crf 16 and --bitrate XXXX ; is that a good idea to do that ? What would happen ? It seesm it results in some kind of ABR encoding but I don't know it it's great to do that. I wanted to to add that bitrate line in order to control the final size (CRF doesn't let me know what it will be). In particular, what's the difference between doing something like that and a 2 pass encoding with the bitrate line only ?


All this is explained at length in the links provided in this thread. Had you read the content you would not have to ask these questions, particularly the last one.
A simple search here on this forum would also give you more info on these options than anyone could wish for.

But I understand that reading and searching is really inconvenient, right?

[sirt]

Don't worry about that, I read the whole day about that and it's not something easy to understand.

[Groucho2004]

Don't worry about that
I'm not worried.

I read the whole day about that and it's not something easy to understand.
It's unlikely that you understand everything about the encoding options by just reading for one day.

My point is that I keep seeing questions like "what happens if I change this parameter from 0.6 to 0.7" or "should I use 4Mbps or 6 Mbps for this source" but nobody seems to simply go ahead and try that for themselves and look at the results. Very odd.

[sirt]

Who says I'm not trying to do tests ? It's exactly what I do. If I ask it's because it is not enough clear from what I read. And for your information, I'm not reading "for one day" ; the reason for which I keep on asking on this thread, is because Lord_Mulder explains the things very clearly to me. So, if you don't plan answer my questions and come to advise me to read by myself and experiment - whereas it is why I do right now - I would rather you not to interfer.

[john_z]

To say the truth, I was reading carefully of LoRd_MuldeR's explanation a lot, I thank him and also learnt a lot.

All these settings are fundamental but very useful to beginners , I was wondering if LoRd_MuldeR has a full tutorial and I 'm willing to translate to our language as what I learnt before is totally wrong.