how does Ripbot264 think ... ?

[zero7404]

is the b-frames setting similar to the example jagabo had given earlier ?

i need to revisit some of my encodes, i've been knocking out movies one after another and not watching them thru to make sure they are done correctly. some movies i've seen block pixelation where darks and black colors are predominant. but i just noticed in 2 recent encodes (Centurion and 2012) that there's pixelation in a few instances that are both light and dark scenes. very breif and only a few seconds max within the films, but i really don't want this present because the movies on the drive will represent my library basically. this pixelation sometimes is like an inversion of colors and sometimes is the entire frame/picture.

if you guys can tell me more about refining the video settings for the HD Progressive profile i would be happy to try the settings with my future encodes as well as go back and correct the erroneous movies i find.

i am using the HD Progressive profile with no resize, no crop, etc. i have not touched any advanced settings.

[jagabo]

this pixelation sometimes is like an inversion of colors and sometimes is the entire frame/picture.

That sounds more like a ripping error. Ie, the data given to the encoder was corrupt.

So, inspired by this thread and my eternal hatred of shadow blocking, I re-ripped Heat and tried a re-encode with Ripbot264. I set the CQ to 18 and changed the b-frames setting from 4 to 0. Final size was a little over 11GB. Guess what, no blocking.

4 b-frames is excessive in my opinion. B-frames are smaller mostly because they are encoded at a lower quality. 4 b-frames means 80 percent of your frames are encoded with that lower quality -- and with a 24 fps video that represents 1/6 of a second between cleanups. I usually use 2 b-frames in x264.

[smitbret]

Yeah. I looked at the thread that he linked and set the b-frames to "0". Check the thread I just started today. Some of the answers really made sense:

https://forum.videohelp.com/threads/339319-What-s-the-point-of-B-Frames

When I checked my 11GB (CQ 18 and no b-frames) encode of Heat, I lost the blocking but had "busy" backgrounds where the night sky would be just above the horizon. I assume that would be due to bit starvation. Using the same settings for Braveheart seemed to create the same busy background with what seemed to be a loss of contrast in certain night scenes, i.e. the honeymoon scene at 38 minutes. I set Heat for an 18GB 2-pass with the same settings and it really looks pretty good. I'm running Braveheart with a target of 23.5GB (from the 36GB rip) and it should be done running when I get home from work this evening.

[zero7404]

if the value of 4 for b-frames represents 80% of the frames encoded, what percent would a value of 2 be ?

i looked at your thread smitbret, looks like a discussion regarding the b-frames topic ....
there are other types of frames involved, i would like to learn more about them ...

in the meantime, while posting i put centurion in for another go at it, without changing any settings and the encode came out good ....
before encoding i usually check out the mkv file to ensure it's good, but impossible to spot an anomaly by just randomly scanning the video ...
i also do light duty things on the computer while it's encoding, like web surfing, email etc. some of these apps use the same drive that ripbot is using during encoding. i'll try to leave the computer to do it's thing during encodes.

[jagabo]

if the value of 4 for b-frames represents 80% of the frames encoded, what percent would a value of 2 be ?

2 b-frames is still about 66 percent of the frames. But the big difference is the amount of time the lower quality b frames are visible. With 4 b frames you have something like:

IBBBBPBBBBPBBBBPBBBBP...

That means for a 4 frames in a row, 1/6 of a second at 24 fps, you have lower quality frames, then they're cleaned up by a P frame. 1/6 of a second is long enough to notice. And you'll be able to see the beating of clean blocks blocks blocks blocks clean blocks blocks blocks blocks clean....

With 2 b-frames

IBBPBBPBBPBBP...

you will have a degraded picture for only 1/12 of a second at a time. That's fast enough that it's much less noticeable.

And with 1 b frame:

IBPBPBPBP...

the lower quality frames are only visible for 1/24 second at a time.

The difference in compression you get with 4 b frames vs 2 b frames is very little, on the order a a few percent. Whereas dropping to no b frames reduces compressibility by a lot more, maybe 20 percent. For example, if you compress a video at CRF 18 with 4 b frames you may get a 1 GB file. If you reduce that to 2 b frames you may get a 1.05 GB file. If you reduce it to no b frames you may get a 1.2 GB file.

[zero7404]

jagabo .... the errors i noticed with 2012 i spotted on my wife's laptop as she was playing the movie via an NAS (network drive connected to my router), i re-ran the same movie on my ps3 and my own laptop and did not see the glitches, so i suspect i need to update the codec packs on my wife's machine or check her wireless connection speed although i doubt it's the wireless because the connection is 802.11n, whereas the ps3 connects using 802.11g and has no problem playing the movie.

the inverted pixelation i spotted in centurion i suspect that was an error either with the encode or with the demux. however during cloud and dark scenes in general there is some blockiness associated with the movies i have. they are not excessive, but i wish to approach blu-ray picture quality with these compressed movies.

would you say that stepping b-frames down to 2 will help the picture at all ? i will give it a try with one of the movies i have done before and see ....

[jagabo]

during cloud and dark scenes in general there is some blockiness associated with the movies i have. they are not excessive, but i wish to approach blu-ray picture quality with these compressed movies.

Aren't these blu-ray rips? If they're already h.264 encoded reencoding them with another h.264 encoder at lower bitrates is expected to reduce the quality. The bitrate savings have to come from somewhere!

would you say that stepping b-frames down to 2 will help the picture at all ? i will give it a try with one of the movies i have done before and see ....

It should make the blocking less noticeable. Be aware there are a lot of other limitations with Blu-ray encoding. Ie, Blu-ray does not support all h.264 features. You can read about some of them at the x264 wiki site:

http://mewiki.project357.com/wiki/X264_Settings

Of course, individual players may be able to play video exceeding the spec.

[zero7404]

Aren't these blu-ray rips? If they're already h.264 encoded reencoding them with another h.264 encoder at lower bitrates is expected to reduce the quality. The bitrate savings have to come from somewhere!

i am using the starting base as the blu-ray itself, so what i meant was the source is the reference. of course the real reference is the actual film or whatever medium was used to store the master, and that's significantly higher resolution than blu-ray offers.

my quest is to find the 'sweet spot' of picture quality, audio quality and size (this third item to an extent). dropping b-frames down somewhat is the starting point for me to tweak the codec settings further until i attain what i am looking for ... the best possible rip with a reasonable file size. for my favorites, i have chosen to step up the bitrate to 6144 kbps on my 2-pass encodes, but once i tweak the other settings further, i will revisit those movies and redo them with the custom profile i end up with.

i noticed the b-frames setting in the HD Progressive profile is default set at 3. I will change it to 2 and see what improves. there are other settings as well, i have to read up on that wiki further to find out more ....

[zero7404]

i just tried updating ffdshow to the 64 bit version, but ripbot didn't recognize it ... i've been using the 32 bit version all this time, wouldn't the 64 bit version improve encoding and speed ?

[jagabo]

With 64 bit Windows 64 bit programs use 64 bit codecs, 32 bit programs use 32 bit codecs. 64 bit programs cannot access 32 bit codecs, and 32 bit programs cannot access 64 bit codecs. So if ripbot is a 32 bit program 64 bit ffdshow isn't available to it.

Using 64 bit software doesn't improve encoding speed by much -- typically only by a few percent. And sometimes 64 bit programs run slower than 32 bit programs. The only real advantage of 64 bits is the ability to address more memory. And few programs use more than is available under 32 bit Windows. So all that extra memory just gets used as a disk cache by Windows.

[zero7404]

With 64 bit Windows 64 bit programs use 64 bit codecs, 32 bit programs use 32 bit codecs. 64 bit programs cannot access 32 bit codecs, and 32 bit programs cannot access 64 bit codecs. So if ripbot is a 32 bit program 64 bit ffdshow isn't available to it.

Using 64 bit software doesn't improve encoding speed by much -- typically only by a few percent. And sometimes 64 bit programs run slower than 32 bit programs. The only real advantage of 64 bits is the ability to address more memory. And few programs use more than is available under 32 bit Windows. So all that extra memory just gets used as a disk cache by Windows.

i see ... perhaps some components of ripbot are available as 32-bit only, hence the reasoning. i am using a 64-bit OS and have 8GB of ram, but i set windows not to use virtual memory because i have so much ram. i also have an SSD as my primary drive for the OS. maybe i can cut down encoding time if i re-establish virtual memory use in windows ....

[jagabo]

perhaps some components of ripbot are available as 32-bit only

I suspect all of ripbot is 32 bit. I don't see a 64 bit version available for download.

maybe i can cut down encoding time if i re-establish virtual memory use in windows ....

No.

[zero7404]

jagabo, if you could tell me what settings you use to encode your videos ? aside from b-frames setting, what other advanced settings in the codec are critical to extract good picture quality without losing much to the trash ?

i am looking to tweak my 4k and 6k encodes further, to extract the best possible pq & audio without bloating file sizes too much ...