Can't get above 181Mbps using Handbrake?

[Track]

I'm converting a Lagarith-encoded time-lapse video from 1.5Gbps to maybe half or a quarter of that bitrate but no matter what bitrate I choose, I always get 181Mbps.

It says that the "nominal" bitrate is 800Mbps, but the actual bitrate is 181Mbps (not sure what this means).

When I try CFR, even at 0 the maximum is 20.5Mbps, so that's obviously out of the question.

How do I render higher bitrate than 181Mbps?

Thanks.

[manono]

Geez, why would you want to try and force half or a quarter the bitrate? Lagarith is lossless. x264, even at it's highest settings, compresses the hell out of a video. If you got 181Mbps out of it then apparently that's the least it'll compress. Is there something wrong with it? You don't like the way it looks? Maybe if you gave us the settings you used someone will tell you how to squeeze the very last bit of quality out of it.

[Track]

Geez, why would you want to try and force half or a quarter the bitrate? Lagarith is lossless. x264, even at it's highest settings, compresses the hell out of a video. If you got 181Mbps out of it then apparently that's the least it'll compress. Is there something wrong with it? You don't like the way it looks? Maybe if you gave us the settings you used someone will tell you how to squeeze the very last bit of quality out of it.

As far as I understand it:

Lagarith - Lossless - 2.5Gbps (6K video).

H.264 - Lossy - 181Mbps (6K video).

The former is too large a file size and the latter too low a bit-rate.

So, in my mind, something in the middle would be good.. let's say 500Mbps-750Mbps?

Only question is, how do I do that when H.264 is capped at 181Mbps?

[racer-x]

I'm not sure using a high bitrate h.264 intermediate file is a good Idea. Have you tried working with that in your NLE? I would expect it to bog down your workflow because of the high CPU usage. Setting GOP to 1 should boost your bitrate if that's what you want.

Personally, I would rather go with I-frame Mpeg-2 in a "ts" container. Good quality and very easy to work with in NLE.

[Track]

I'm not sure using a high bitrate h.264 intermediate file is a good Idea. Have you tried working with that in your NLE? I would expect it to bog down your workflow because of the high CPU usage. Setting GOP to 1 should boost your bitrate if that's what you want.

Personally, I would rather go with I-frame Mpeg-2 in a "ts" container. Good quality and very easy to work with in NLE.

I have absolutely no idea what you just said

(Complete Novice)

I do experience very high CPU load when playing the 1Gbps+ file.

Are you saying I can get the same quality with a lower bit-rate?

[racer-x]

When I read your first post, I made an assumption that you shot a time-laps and wanted to save it as an intermediate codec to further work with it in your video editor. Maybe I made the wrong assumption?

I don't use Handbrake, but there should be a setting in there to make it I-fame only. Maybe enter a command like keyint=1

[Cauptain]

In advance tab use --force-cfr

General
Complete name : D:\amarec(20130829-2149).avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 66.7 MiB
Duration : 2s 33ms
Overall bit rate : 275 Mbps
Writing library : VirtualDub build 34802/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L5.2
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : H264
Duration : 1s 533ms
Bit rate : 363 Mbps
Nominal bit rate : 1 000 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 5.833
Stream size : 66.3 MiB (99%)
Writing library : x264 core 130 r2274bm c832fe9
Encoding settings : cabac=1 / ref=8 / deblock=0:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=4 / sliced_threads=1 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=10 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc=abr / mbtree=0 / bitrate=999999 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Matrix coefficients : RGB

Claudio

[Track]

But that shows the same problem.

Your chosen bit-rate is 1Gbps but the one you received was 363Mbps. I chose 800Mbps but received 181Mbps.

[manono]

He was just providing the evidence that 181Mbps isn't the max bitrate it'll produce. That's the question in your thread title. But his video is different from yours and more complex, thus allowing for a higher bitrate. There is no problem, except in your own mind.

[_Al_]

Are you saying I can get the same quality with a lower bit-rate?

Yes,
the smaller one is just compressed more, check cpu usage playing both files.

[Track]

He was just providing the evidence that 181Mbps isn't the max bitrate it'll produce.

Well, it is for me.

That's the question in your thread title. But his video is different from yours and more complex, thus allowing for a higher bitrate.

More complex? What does that mean?

There is no problem, except in your own mind.

Now you're calling me delusional?

[manono]

He was just providing the evidence that 181Mbps isn't the max bitrate it'll produce.

Well, it is for me.

No, it is for you with this video at those settings.

More complex? What does that mean?

Yours is of a slideshow, sort of - a bunch of static pictures. His may be of an action scene with fast cars and explosions and all that. His is more complex - there's more difference from frame-to-frame - than yours.

Now you're calling me delusional?

Nope. I'm calling you ignorant. Nothing wrong with being ignorant. We all were at one point. But when things are explained time and time again and you still insist on arguing about it and still don't get it, then you begin to cross the line from ignorant to stupid.

[Track]

But when things are explained time and time again and you still insist on arguing about it and still don't get it, then you begin to cross the line from ignorant to stupid.

*reads threads again*

Well then, I guess I am stupid because I certainly have not found a proper answer to any one of my question.

Either way, I consider this your fault. If you can't explain a simple matter to a simple person, you shouldn't be in a position to help anyone.

[smrpix]

I certainly have not found a proper answer to any one of my question.

That's a shame -- because the answers are right there.

[blud7]

I'm converting a Lagarith-encoded time-lapse video from 1.5Gbps to maybe half or a quarter of that bitrate but no matter what bitrate I choose, I always get 181Mbps.

It says that the "nominal" bitrate is 800Mbps, but the actual bitrate is 181Mbps (not sure what this means).

When I try CFR, even at 0 the maximum is 20.5Mbps, so that's obviously out of the question.

How do I render higher bitrate than 181Mbps?

Thanks.

CFR=Constant Frame Rate? Not bitrate...
Try setting Const Quality to 0...which is insane but try it.
Alternatively don't use Handbrake. It is pretty good but it's sometimes a bit wonky.

[jagabo]

In your other thread I mentioned that you should upload a small sample of your source. But here's something else for you to ponder:

Lagarith has a setting called "Enable Null Frames". With that enabled, whenever the codec encounters an exact duplicate frame it will insert a "just display the last frame again" flag (a "null" frame) instead of compressing the new frame. If you don't enable that setting every frame will be compressed as a separate image. Videos with lots of exact duplicate frames (like slideshows) get much more compression with null frames enabled.

Even at CRF=0 (or QP=0) x264 defaults to interframe compression. Only parts of the frame that don't change from frame to frame are not included. So if 90 percent of the frame is the same as the last frame only 10 percent of the frame is included in the new frame. In essence the encoder says "this 90 percent is the same as the last frame, just change this 10 percent." And of course, exact duplicate frames require hardly any bits, just like lagarith with null frames. You can change this by forcing the codec to use all i-frames (keyint=1). In which case each frame is compressed as a separate image.

So if your lagarith source has lots if duplicate frames (or large areas where there are no changes), lagarith isn't set to use null frames, and x264 isn't set to use all i-frames, the x264 video simply will not be able to reach the same bitrate (or size) as the lagarith source.

[jagabo]

Also, Lagarith can work in RGB, YUV 4;2:2, or YUV 4:2:0. x264 works in YUV 4:2:0 (for the most part). If your Lagarith source is RGB then converting to YUV 4:2:0 cuts the data in half even before x264 starts compressing.

[blud7]

Also, Lagarith can work in RGB, YUV 4;2:2, or YUV 4:2:0. x264 works in YUV 4:2:0 (for the most part). If your Lagarith source is RGB then converting to YUV 4:2:0 cuts the data in half even before x264 starts compressing.

10 bit 4:2:2?
Two-pass ABR probably?

[jagabo]

Also, Lagarith can work in RGB, YUV 4;2:2, or YUV 4:2:0. x264 works in YUV 4:2:0 (for the most part). If your Lagarith source is RGB then converting to YUV 4:2:0 cuts the data in half even before x264 starts compressing.

10 bit 4:2:2?
Two-pass ABR probably?

That's why I said "for the most part:. He's using Handbrake which doesn't have 10 bit or 4:2:2. I knew somebody would just have to bring this up.

[Track]

In your other thread I mentioned that you should upload a small sample of your source. But here's something else for you to ponder:

Lagarith has a setting called "Enable Null Frames". With that enabled, whenever the codec encounters an exact duplicate frame it will insert a "just display the last frame again" flag (a "null" frame) instead of compressing the new frame. If you don't enable that setting every frame will be compressed as a separate image. Videos with lots of exact duplicate frames (like slideshows) get much more compression with null frames enabled.

Even at CRF=0 (or QP=0) x264 defaults to interframe compression. Only parts of the frame that don't change from frame to frame are not included. So if 90 percent of the frame is the same as the last frame only 10 percent of the frame is included in the new frame. In essence the encoder says "this 90 percent is the same as the last frame, just change this 10 percent." And of course, exact duplicate frames require hardly any bits, just like lagarith with null frames. You can change this by forcing the codec to use all i-frames (keyint=1). In which case each frame is compressed as a separate image.

So if your lagarith source has lots if duplicate frames (or large areas where there are no changes), lagarith isn't set to use null frames, and x264 isn't set to use all i-frames, the x264 video simply will not be able to reach the same bitrate (or size) as the lagarith source.

Ahh! Finally someone comes in with some actual insight.

So, in fact, what H.264 is doing is interface compression and by that decreasing the requirement for bit-rate and file-size drastically, where as Lagarith cannot do interface compression which is why the file size is so much larger..

But then.. why is there still a difference in quality? Like I showed, there is a difference.

My logic was, if I increase the bit-rate on the H.264, that difference would go away entirely and I'd be left with a ~400MB file that has the exact same quality as the Lagarith 1.7GB (because the lossless is wasted on it).

[jagabo]

Since you aren't getting the expected results from your encodings nobody is going to be able to help you further until you upload some samples for analysis.

[Track]

Since you aren't getting the expected results from your encodings nobody is going to be able to help you further until you upload some samples for analysis.

Samples of what?

My question is:

How do I get a file that is in between the 1.7GB and 170MB in terms of quality?

[jagabo]

Since you aren't getting the expected results from your encodings nobody is going to be able to help you further until you upload some samples for analysis.

Samples of what?

Your ******* source video and your ******* x264 encoded video, you moron.

[Track]

Since you aren't getting the expected results from your encodings nobody is going to be able to help you further until you upload some samples for analysis.

Samples of what?

Your ******* source video and your ******* x264 encoded video, you moron.

How in the name of Jesus ************* Christ would that help you in telling how to encode a video with quality in between 1.7GB and 170MB?

[Baldrick]

Calm down now....:banghead:

[jagabo]

How in the name of Jesus ************* Christ would that help you in telling how to encode a video with quality in between 1.7GB and 170MB?

Everyone has already told you the things that should increase the bitrate and quality. You claim to have done those things and not seen any changes in bitrate or quality. It's been explained to you why, once 100 percent quality (ie, the x264 decoded image is pixel-for-pixel identical to the source) has been reached, you can't increase the bitrate further. You claim you are not at 100 percent quality so you should be able to get more quality. The only evidence you have supplied are two lossy JPEG images. One of those JPEG images is a different scale from the other (ie, one was zoomed in or out) indicating something other than just encoding was going on.

The only thing left to do is examine the real evidence.

[smrpix]

An observation. In the same way OP stubbornly refuses to believe he can make the file do something it won't or doesn't need to, I think the rest of us are stubbornly trying to teach OP something he won't or can't learn.

Ah symmetry.

Most of us who do video encoding are used to banging our heads against a problem until we siolve it. But this one may simply call for throwing in the towel.

Your best bet Track is to provide the sample requested -- otherwise you're not serious.

[Track]

If you guys thought that my samples do not reflect the actual video, why didn't you just say so in the beginning?

If you're right, then the 170MB would actually have the same quality.


But how do I check this?

[jagabo]

If you guys thought that my samples do not reflect the actual video, why didn't you just say so in the beginning?

I essentially told you that in my first reply of your other thread.

It's hard to say if it's from the encoding, the resizing, or both.

But how do I check this?

MSU VQMT or an AviSynth script:

v1=AviSource("source.avi")
v2=WhateverSource("compressed.ext")
Subtract(v1, v2)
Levels(112,1,144,0,255) # 8x amplify differences

Encoding/decoding sometimes causes a frame advance or delay so you might have to use Trim() to get the frame numbers to align.

[Track]

MSU VQMT or an AviSynth script:

v1=AviSource("source.avi")
v2=WhateverSource("compressed.ext")
Subtract(v1, v2)
Levels(112,1,144,0,255) # 8x amplify differences

Encoding/decoding sometimes causes a frame advance or delay so you might have to use Trim() to get the frame numbers to align.

I haven't the slightest idea what that means.