Avisynth Help thread

[Dark Shikari]

Originally Posted by Nagato

with low bitrates the blocks will be revived like zombies anyway.

Not if you use psy-RD

[TheFluff]

Originally Posted by MoonLight-

MSmooth

don't do this

[edogawaconan]

Originally Posted by MoonLight-

<snip>

tell the watcher to use gradfun. and pray that their system is powerful enough

[max2k]

Originally Posted by edogawaconan

tell the watcher to use gradfun. and pray that their system is powerful enough

Yes tell the crowd who think avi is the same think like divx, to use a postprocesor filter... Yes gradefun() ist postprocesing Filter, but with enough bitrate some off the grain will be keept in a x264 encode, and its looks nicer then addgrain()....

[Dark Shikari]

Originally Posted by max2k

Yes tell the crowd who think avi is the same think like divx, to use a postprocesor filter... Yes gradefun() ist postprocesing Filter, but with enough bitrate some off the grain will be keept in a x264 encode, and its looks nicer then addgrain()....

Gradfun2db() compensates for a lack of precision in the YV12 colorspace... its not really related to any particular video format.

[max2k]

I tested gradefun2db() with some colorbanding heavy source, it was fine for the x264 encode, but xvid never keept enough of the grain, even with 150% of the average bitrate of the 1pass, to compensate the colorbanding.

[edogawaconan]

Originally Posted by max2k

Yes tell the crowd who think avi is the same think like divx, to use a postprocesor filter... Yes gradefun() ist postprocesing Filter, but with enough bitrate some off the grain will be keept in a x264 encode, and its looks nicer then addgrain()....

tell them to right-click that cute red FFv icon on systray and click on gradfun?

*and tell anyone else whom doesn't use windows/ffdshow that they are out of luck

[MoonLight-]

blocks get better atm ^^

I didn't know that 3600 is low bitrate, anyway I switched to 4200..
but.. blocks still existied in darky clips T_T

I think darky animes is the most annoying for encoders, especially when darky clip
and blur comes together imo

[max2k]

With a bitrate of 4200 in x264 ther should be some serious decoding issues and one episdoe with 24 minutes should have a size around 800mb...

[TheFluff]

Originally Posted by max2k

With a bitrate of 4200 in x264 ther should be some serious decoding issues

what kind of issues?

[max2k]

Originally Posted by TheFluff

what kind of issues?

I dont think i realy have to tell you.

Some thing on the line of heavy slow downs on playback on most systems because of to high cpu usage at the decoding time. You know x264 is not mpeg2 or a lossless codec, it has more complex compresion algorithm, thats why files can be mouch smaller with good quality, but need more cpu power to encode and to decode. And the bitrate is the next bigest factor how hard a file is to decode.

(I should really try a to high bitrate encode in x264 myself, i dont know if x264 realy stops if he dont can use the bitrate anymore, like xvid would do. And how hard the surplus informations are to decode. I did a automated 2pass at a bitrate of 1500 with a source that would reach quant16 at 600, and he used all the bitrate so i thought the x264 codec whould use all the bitrate u give him at any time. Is it wrong?)

[Dark Shikari]

Originally Posted by max2k

I tested gradefun2db() with some colorbanding heavy source, it was fine for the x264 encode, but xvid never keept enough of the grain, even with 150% of the average bitrate of the 1pass, to compensate the colorbanding.

Well of course, Xvid doesn't have the kind of AQ or psy RD that x264 has, which basically makes it impossible to retain the dithering from gradfun2db at any sane settings.

Originally Posted by max2k

I dont think i realy have to tell you.

Some thing on the line of heavy slow downs on playback on most systems because of to high cpu usage at the decoding time. You know x264 is not mpeg2 or a lossless codec, it has more complex compresion algorithm

Actually, most lossless formats are much slower to decode than H.264. Also, its called H.264, not x264; x264 is just the encoder, not the name of the format.

[max2k]

Originally Posted by Dark Shikari

Actually, most lossless formats are much slower to decode than H.264.

But thats more on the line of the bitrate they need to be lossless and not on the line of compresion algorithm, or?

[Dark Shikari]

Originally Posted by max2k

But thats more on the line of the bitrate they need to be lossless and not on the line of compresion algorithm, or?

Well yes, the main reason is because they have to compress (and decompress) a whole lot more information. Though, for example, FFV1 uses a very similar entropy coder to H.264.

[TheFluff]

Originally Posted by max2k

I dont think i realy have to tell you.

Some thing on the line of heavy slow downs on playback on most systems because of to high cpu usage at the decoding time. You know x264 is not mpeg2 or a lossless codec, it has more complex compresion algorithm, thats why files can be mouch smaller with good quality, but need more cpu power to encode and to decode. And the bitrate is the next bigest factor how hard a file is to decode

You make a logical argument but it's actually most likely wrong. You make the mistaken assumption that the bitrate is mostly evenly distributed and that 4mbps is a lot; this is wrong. Even with much lower bitrates (~1800kbps) x264's rate control can happily throw 10-15mbps or more at short (10-30 seconds) sequences (see f.ex. the kurenai op, which peaked at something dumb like 20mbps for a few seconds). It's true that doubling the average bitrate would give it more bits to allocate and in theory raise the bitrate peaks even more, but while this will happen to some extent, most of the extra bits will probably go to raising the average bitrate of the rest of the clip, at least with a sane minimum QP.

Originally Posted by max2k

(I should really try a to high bitrate encode in x264 myself, i dont know if x264 realy stops if he dont can use the bitrate anymore, like xvid would do. And how hard the surplus informations are to decode. I did a automated 2pass at a bitrate of 1500 with a source that would reach quant16 at 600, and he used all the bitrate so i thought the x264 codec whould use all the bitrate u give him at any time. Is it wrong?)

see --qpmin, set it to 1 to allow essentially infinite bitrates
(actually coding as lossy with qpmin 1 most likely allows a lot higher bitrates than coding as lossless (qp 0) in many cases. funny how that works.)

[max2k]

I not thought that that the "bitrate is mostly evenly distributed"(I did mouch xvid encopding in VfW, so i know how the bitrate distruption can look in a vbr encode). But i did make the failure to think : If i raise the average bitrate, that the "hard to compress scens" would get more bitrate near this factor.

Is ther a way to go sure that i dont get complains from leachers, that thought they can look the h264 720p Denou Coil encode, until the explosions scens start to kick in in episode 5, and bring the first real "bitrate peaks" of this series?

[TheFluff]

You can use the VBV buffer settings (intended to make sure the encoder doesn't encode streams with bitrate peaks that a DVD player or streaming device are too slow to read) to limit bitrate peaks of an encode.

[Dark Shikari]

Originally Posted by TheFluff

see --qpmin, set it to 1 to allow essentially infinite bitrates
(actually coding as lossy with qpmin 1 most likely allows a lot higher bitrates than coding as lossless (qp 0) in many cases. funny how that works.)

QP0 isn't lossless unless you explicitly set --qp 0 or --crf 0.

[TheFluff]

Originally Posted by Dark Shikari

QP0 isn't lossless unless you explicitly set --qp 0 or --crf 0.

Oh. I had no idea.

[OroSaiwa]

Originally Posted by TheFluff

You can use the VBV buffer settings (intended to make sure the encoder doesn't encode streams with bitrate peaks that a DVD player or streaming device are too slow to read) to limit bitrate peaks of an encode.

Talking about VBV and since Dark Shikari is an x264 developer, I keep having problems of VBV buffer underflow with my encodes, either I specify the VBV Buffer Size and Max Bitrate according to this http://rob.opendot.cl/index.php/usef...es-and-levels/ or leave it automatic.

I started to panic when I saw so many VBV underflows in avinaptic but then I checked another couple of encodes (CGR2 HD of Eclipse) and saw that avinaptic gave the same errors. It might be an avinaptic bug since it's not been updated since November?

Checked on Doom9 and saw this issue is frequent but I can't post there for another day.

Nicholi told me it's not sth to worry too much about if it's underflow. Overflow would be bad.

Anyway this is my line from my megui profile:

program --pass 2 --bitrate 3516 --stats ".stats" --level 5.1 --ref 8 --mixed-refs --no-fast-pskip --bframes 4 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --b-bias 4 --me umh --merange 24 --threads 2 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"

I'm ripping Code Geass Blu-rays at 1080p, mkv softsub so mostly for PCs.

I keep doing experiments and trying new things to introduce in the Italian fansub scene

Thnx to TheFluff and Mentar for their help and their patience.