Pseudo MIN bitrate with noise?
 

@vmesquita,

Just an idea.
Because setting the MIN bitrate in mencoder/ffmpeg just doesn't work correctly, and causes all kinds of side effects (quantization errors, etc.), I have a suggestion.
Could you encode a "black" source (no video) and add "noise" parameter with very low values, until you get an average bitrate of ~300Kbps :?:
This way, you have a fixed low bitrate noise stream, which guaranteed a minimum bitrate on black scenes.
I, and many others too, have problems with MIN bitrates. For example, on my JVS player, when a movie starts, right after the initial credits where it goes to total black before switching to the start of the movie, that single 1 second pause comes out to 7 or 8 seconds of "stutter", until the MIN bitrate passes a treshold, and from there on the rest of the movie is fine.
But on some rare scenes, and on some movies, where there is a total black scene, this effect could repeat.
I assume that a very low constant level of noise, will not be visible, but will maintain the video stream at a level that will help with the issue.
What do you think :?:

-kwag

@ Kwag: Better than this, there is a way to add a kind of "MA" noise?

Well, the idea is to maintain a very low noise static bitstream. When there's regular video, the "noise floor" will always be present, but won't affect the picture because the visibility of noise will be under the visible luma/chroma levels.
So this really doesn't apply to motion adaptiveness. It would really apply to "brightness" adaptiveness, and if this could be implemented, then that would be the way to go, because after the brightness drops below the treshold point (equivalent to 300Kbps), noise could be switched ON, and again turned OFF, once the brightness level trips above the treshold point.
Call it "Brightness Adaptive Linear Noise". That would be the correct term ;)

-kwag

Is for this that I put MA between quotation marks. I don't knew what expresion to use.
The idea is for to avoid adding noise (and more final size).

Yes, the idea is to only add noise *only* on very black scenes. Blockbuster does this already, so it can be used right now for this purpose.
But I'm almost sure that a constant noise floor of 300Kbps wont really add that much to the final file size, because the average of a movie is always way above that point.
As a matter of fact, if the noise floor is "weighted" to apply an average bitrate of ~300Kbps in a total black scene, this will be exactly the equivalent of having a fixed MIN bitrate of 300Kbps ;)
Anyway, it's better to use the internal noise filters in libavcodec, because that way it's platform independent, and we can use this technique in any OS supported by mencoder.
With AviSynth filters, we're sticked to Windows only.

-kwag

Can you say me how to do this whit blockbuster? I mean to obtain ever, a min bitrate of 300, even in a total black scene.

Ok, you're going to have to encode from a fake .avs script, generating black video.
Then, using *ONLY* BlockBuster in your script (after resolution and resize, of course), encode a small 1 minute or so, with very low values in BlockBuster.
Then drag your encoded .m2v into Vdub, and check the average bitrate.
Keep doing this until you get ~300Kbps average.
Remember this. The value you find above, will be the value to use :arrow: for the current resolution you used.
Other resolutions will have different values (parameters) for BlockBuster.
This is something that must be taken into consideration if implemented into MencoderME/mencoder.
Of course, if vmesquita does implement this in MencodeME, the noise floor will already be automatically set for the selected resolution (right vmesquita :?: :lol: )
But you can go ahead and do it right now with BlockBuster. Let me know :!:

Edit: read here to generate a black video: http://www.avisynth.org/index.php?page=BlankClip

-kwag

I also thought about that ;-)

ScriptClip(clip, "diff = averageLuma()"+chr(13)+"diff < X ? Blockbuster(xxxxx,diff/4,xxxx) :Nop()"
4 is here just an example for deviding the diff so a minimal blockbuster noise gain change will occur (like in tempsoften by deviding the nf)

Find out the right X as threshold and do apply an adaptive X/y within blockbuster noise gain so you can avoid nosie kick-ins.

Just adapt it to MA.

Its like an an MA but sees if a frame gets dark, so NO comaprison to the next frame BUT analyse the present frame. So a very low y would come out on very dark scenes.
THEN! We have to setup blockbuster right that a "all over" noise will be generated, because blockbuster can be set to do thresholded noise, ... not refered to present luma! but to plain surfaces and edges.

But Mencoder on dark scenes gots a very sensible quantizer threshold.
And on Credits ... it just "CUTS" high freq's, means fine noise.I tried that already by using a static plain noise when encoding a test (ANd I do mean "noise"! :lol: .

But when using an MA-Noise-on-black script, it can process a "kick in" of noise at dark parts where the quantizer engine of mencoder "could" think .... "Oh ... no black"

But maybe since then the engine changed a bit so another test would be very senseful!

:wink:

This is a very good idea. Mencoder offers basically two kinds of noise: temporal, spatial and averaged, which can by applied to luma and chroma is separated degrees.
My previous tests indicate that spatial only noise creates an effect of "the screen of the TV is dirty", while the temporal noise can create "dancing artifacts" if bitrate is too low. I used noise in MencodeME AVI filtering combo...
What kind of noise you think it would be better (temporal/spatial/averaged on luma/chroma/both)?

noise[=luma[u][t|a][h][p]:chroma[u][t|a][h][p]]
Adds noise.

<0-100> :arrow: luma noise
<0-100> :arrow: chroma noise
u :arrow: uniform noise (gaussian otherwise)
t :arrow: temporal noise (noise pattern changes be- tween frames)
a :arrow: averaged temporal noise (smoother, but a lot slower)
h :arrow: high quality (slightly better looking, slightly slower)
p :arrow: mix random noise with a (semi)regular pat- tern

The problem is ... I think theres no adaptive noise based on average luma input in mencoder like we can do in avisynth like explained above. :(

But maybe Im totally wrong :wink:

PS: Senseful would be to add a shock of chroma noise as you wont see it on already very low luma parts, but the encoder does interprete that as "dancing" details.

Here's your 350Kbps MIN bitrate ;)

BlockBuster(method="noise", detail_min=1, detail_max=1, variance=0.1, seed=5823 )

This was tested with TMPEG.
Enjoy,
-kwag

Yes, you can't vary the ammount of noise per frame. :(
Have you tested this? Because I saw the dancing details adding noise to luma only (I was trying to remove DCT blocks). Does chroma produces the same effect?

@kwag
Nice! :D 8)

Perfect Kwag!

Now try that on mencoder as it quantizes different on black frames as TmpgEnc.

So try....

ScriptClip(clip, "diff = averageLuma()"+chr(13)+"diff < X ? BlockBuster(method="noise", detail_min=1, detail_max=1, variance=0.1, seed=5823 ) :Nop()"

We have to find out the right X threshold for B.Buster kick in.
This would avoid usesless noising on average movie content as even there noise would mean less compression as seen as a whole ;-)

@ VMesquita

? Do you mean you recognised these "dancing blocks" when noising the luma only?? Maybe chroma noise is just the only we need?? We should test that :D
(or maybe that was it what you meant)

@Inc
I meant that I was noising the luma blocks (to remove DCTs) and saw the dancing blocks. But I didn't try to noise luma and chroma or chroma only to see what happens. More tests needed. :D

But looks like the avisynth idea is more suitable, specially you get the adaptative thing working, otherwise we would be wasting bits in places that doesn't need noise. Too bad it's not multiplataform. :(

Here's my final setting, to be tested with MencodeME/mencoder.

noise=3th

You can change it in MencodeME presets, for example: "DVD.fil", and it will look like this:
@vmesquita,

I changed the noise generation from "uniform" to "temporal", because uniform is a static noise, which is identical on every frame. With the temporal option, the noise is ranrom on every frame, and it's more natural.
Anyway, the value is so low, that it's barely visible, but it maintains a MIN bitrate around 290Kbps.
Give it a whirl ;)

Edit: This settings were tested on a 704x480 target, so if you use other resolutions, your MIN bitrate will be slightly different.

-kwag

And what about non black scenes, but very bright (amost white), or all of almost monochromatic scenes (full red, full, green, full other colour). IIRC the MPEG does not recognize colours, but grade of changes. This hapen very rarely but some movies are going "fade to white" not to black. Have you tested this type of scenes :?:

Very good observation Hydeus :D
In case of the mencoder noise generator, it's irrelevant, because the noise floor is statically being generated, no matter what brightness/activity there is. So the minimum bitrate will always be present, no matter what color is on the screen, even if it's a static white screen.
I thought that this would affect BlockBuster, but I just tested it with a white screen: BlankClip(length=3000, width=720, height=480, fps=23.976, color=$FFFFFF) and I got the same result. A steady MIN bitrate of around 300Kbps
I also tried a gray screen: BlankClip(length=3000, width=720, height=480, fps=23.976, color=$808080) with similar results :)

-kwag

Great 8)

This is great! In my tests I were using a higher threshold that's why I was getting dancing blocks. BTW did you try adding noise only on chroma or only on luma? The downside of temporal noise is that it's also less compressible across all frames but since you're using a small threshold this shouldn't be a problem. :D

Yes, I noticed that, and I was also seeing "smearing" on surfaces, so I suspected a too high temporal value. See the changes below. No I didn't. But the noise is so minimal, that it's barely noticeable But it does keep the minimum bitrate around the needed 300Kbps. :)These are the latest settings I'm using:

hqdn3d=3:6:2
noise=3th

I'm currently doing an encode with those parameters, and it looks pretty good :D

-kwag