Optimal quality?

[Track]

So, I'm trying to figure out the optimal quality of a time-lapse I've created.

The original, using Lagarith was 1.7GB.

Then I encoded it with Handbrake and the output file was 170MB (1/10 the size).

Looking at a 100% crop, I can't notice the difference.

What do you think?

[manono]

Just do a CRF encode as suggested in by smrpix in one of your other threads. Then you won't have to wonder.

[jagabo]

There's a slight loss of detail in the image on the right. It's hard to say if it's from the encoding, the resizing, or both.

[budwzr]

Yes, you can see a slight loss in detail. Look at the window frames. The loss is due to interpolation. Anytime you enlarge something, new pixels have to be created, and they get fuzzy.

[Track]

Just do a CRF encode as suggested in by smrpix in one of your other threads. Then you won't have to wonder.

A CRF encode only goes up to 20.5Mbps, even at 0. The original file is 1.25Gbps, so using CRF the maximum file size is 19.5MB, which is far too low.

Yes, you can see a slight loss in detail. Look at the window frames. The loss is due to interpolation. Anytime you enlarge something, new pixels have to be created, and they get fuzzy.

Yeah, I noticed that too, but at 1/10 the file size.. isn't that impressive? I didn't know that was possible..

[manono]

A CRF encode only goes up to 20.5Mbps, even at 0. The original file is 1.25Gbps, so using CRF the maximum file size is 19.5MB, which is far too low.

Nonsense. You're comparing an x264 encoded and compressed file size with a lossless Lagarith AVI? And you're saying using CRF 1-pass encoding you can't achieve a size comparable to the 2-pass encode you did?

Then I encoded it with Handbrake and the output file was 170MB (1/10 the size).

So you set a bitrate or filesize? And you're saying a CRF encode can't achieve that same bitrate or greater? Then you're doing something very wrong, or it's not an apples-to-apples comparison.

[Track]

A CRF encode only goes up to 20.5Mbps, even at 0. The original file is 1.25Gbps, so using CRF the maximum file size is 19.5MB, which is far too low.

Nonsense. You're comparing an x264 encoded and compressed file size with a lossless Lagarith AVI? And you're saying using CRF 1-pass encoding you can't achieve a size comparable to the 2-pass encode you did?

Then I encoded it with Handbrake and the output file was 170MB (1/10 the size).

So you set a bitrate or filesize? And you're saying a CRF encode can't achieve that same bitrate or greater? Then you're doing something very wrong, or it's not an apples-to-apples comparison.

What could I be doing wrong..?

I used my photos and created a time-lapse using VirtualDub/VideoMach as an AVI file using the Lagarith codec.

This file was 1.25Gbps bit-rate and 1.7GB in size.

I inputted the file into Handbrake and chose CRF 20. The result was (if I recall) a 10Mbps bit-rate and a 19.5MB file size.

Then I chose CRF 10 - same result. Then CRF 0 - same result. I tried playing with all the settings besides CRF and I still got the same result - 19.5MB and (if I'm not wrong) 10Mbps bit-rate.

So, I decided to choose the bit-rate myself and chose 200Mbps, which came out as 170Mbps and a 170MB file-size, so I thought "finally, it works."

But then I tried 800Mbps and I only got 181Mbps and a 170MB file-size, so I figured that the cap for manually setting the bit-rate using H.264 in Handbrake is 181Mbps.

Why does this limit exist? I don't know.

Obviously, I can't limit myself to 181Mbps, so I'm desperately searching for a method to heighten the bit-rate.

[manono]

I inputted the file into Handbrake and chose CRF 20. The result was (if I recall) a 10Mbps bit-rate and a 19.5MB file size.

Then I chose CRF 10 - same result. Then CRF 0 - same result. I tried playing with all the settings besides CRF and I still got the same result - 19.5MB and (if I'm not wrong) 10Mbps bit-rate.

And doesn't that tell you that something's very wrong? Wrong with your settings, or with Handbrake, or your installation, or something somewhere?

Why does this limit exist?

You got the best possible result for your settings. You 'saturated' the codec, as it's sometimes said. Unless the two-pass bitrate encoding is also borked for you.

Obviously, I can't limit myself to 181Mbps...

Why not, if that's already the best possible quality, given your settings?

What could I be doing wrong..?

I haven't a clue as I don't (and won't) use that program.

[Track]

And doesn't that tell you that something's very wrong? Wrong with your settings, or with Handbrake, or your installation, or something somewhere?

That would imply that I trust myself more than the software. As I am a novice, I assumed it was my fault, not the program.

I've re-installed it, but nothing has changed..

You got the best possible result for your settings. You 'saturated' the codec, as it's sometimes said. Unless the two-pass bitrate encoding is also borked for you.

I get the same result under the two-pass encode - 181Mbps.

Are you suggesting that H.264 simply does not go higher than 181Mbps?

Why not, if that's already the best possible quality, given your settings?

Because I want something between Lossless and and 181Mbps.

Lossless looks good but I think 2.5Gbps is unnecessary.

181Mbps is not comparable to 2.5Gbps.

I want something in the middle, like I said.

I haven't a clue as I don't (and won't) use that program.

Well, it would be more helpful if you tell me what you do use, instead of what you don't..

[manono]

Are you suggesting that H.264 simply does not go higher than 181Mbps?

Not at all. I'm suggesting, unless your 2-pass encoding is screwed up for one reason or another, that for this particular video and the settings you used, this is the largest file size/bitrate possible.

Well, it would be more helpful if you tell me what you do use, instead of what you don't..

Why, since you're seeking help with Handbrake? Plenty of people swear by it and maybe can help you with it. For what it's worth, I use XviD4PSP for making MP4s with x264 video and AAC audio.

[Track]

Are you suggesting that H.264 simply does not go higher than 181Mbps?

Not at all. I'm suggesting, unless your 2-pass encoding is screwed up for one reason or another, that for this particular video and the settings you used, this is the largest file size/bitrate possible.

Well, it would be more helpful if you tell me what you do use, instead of what you don't..

Why, since you're seeking help with Handbrake? Plenty of people swear by it and maybe can help you with it. For what it's worth, I use XviD4PSP for making MP4s with x264 video and AAC audio.

Xvid4PSP does not accept the output file of neither VirtualDub nor VideoMach, so it is not an option I'm afraid.


What settings must I use in Handbrake to increase the bit-rate?

[manono]

Xvid4PSP does not accept the output file of neither VirtualDub ...

Wrong again. I've already told you I can easily open Lagarith AVIs from VDub.

[smrpix]

Track, across your various posts, it's still not clear WHY you think you need such a high bitrate h.264. What is your goal? Further editing? Viewing on your computer? Uploading to YouTube? Making a DCP package? Or is it simply to see if you can do it?

[Track]

Xvid4PSP does not accept the output file of neither VirtualDub ...

Wrong again. I've already told you I can easily open Lagarith AVIs from VDub.

No, you're right. I must be lying.

Track, across your various posts, it's still not clear WHY you think you need such a high bitrate h.264. What is your goal? Further editing? Viewing on your computer? Uploading to YouTube? Making a DCP package? Or is it simply to see if you can do it?

I just want something that is of quality that is directly in between the 1.7GB Lagarith and the 170MB H.264.

The former is too lossless and the latter is too lossy.

[smrpix]

Lagarith[/URL] and the 170MB H.264.

The former is too lossless and the latter is too lossy.

Because Lagarith and h.264 compress using very different schemes, simple filesize comparisons are nearly meaningless. As you noted in your first post (in this thread), you can't see the difference.

[manono]

Xvid4PSP does not accept the output file of neither VirtualDub ...

Wrong again. I've already told you I can easily open Lagarith AVIs from VDub.

No, you're right. I must be lying.

Look, I know you're frustrated and all that. But all I said was that XviD4PSP does accept Lagarith AVI input. I didn't say or even imply that you were lying. There's something very wrong with your setup that makes you the only one in the world that can't open an AVI in XviD4PSP or get Handbrake to run properly.. It's probably something very simple, but I have no idea what it might be.

I just want something that is of quality that is directly in between the 1.7GB Lagarith and the 170MB H.264.

I'll just chalk this one up to your newbieness, but you don't know what you're talking about.

[_Al_]

you can run JUST x264 and exclude any x264 front end software,
put your lagarith file in that folder, name it input.avi and run that BAT file, it is set to encode progressive video

[Track]

I'll just chalk this one up to your newbieness, but you don't know what you're talking about.

Well, of course I don't know what I'm talking about. That's why I'm here.

If you spent the time you take to makes remarks about me trying to actually tell me what I'm trying to know, my newbiness wouldn't be an issue.

This is why I'm frustrated.

Because Lagarith and h.264 compress using very different schemes, simple filesize comparisons are nearly meaningless. As you noted in your first post (in this thread), you can't see the difference.

I'm not comparing file-size, I'm comparing bit-rate.

I want something in between 2.5Gbps and 181Mbps.

[jagabo]

I'm not comparing file-size, I'm comparing bit-rate.

Since the running time is the same, file size and bitrate are directly proportional:

file size = bitrate * running time

So 10 times the bitrate means 10 times the file size (with some small variation due to container overhead).

I think you should provide a short representative sample of your source. Others can then tell you if what you are getting from x264 is normal or if something is going wrong. VirtualDub in Video -> Direct Stream Copy mode will let you trim out a section without reencoding.

[manono]

Well, of course I don't know what I'm talking about. That's why I'm here.

If you spent the time you take to makes remarks about me trying to actually tell me what I'm trying to know, my newbiness wouldn't be an issue.

And if you spent more time researching what you don't know rather than whining here, maybe you'd actually learn something. smrpix explained briefly in the post before mine why you can't compare a Lagarith encode with an x264 encode and then try and get a size half-way in between:

Because Lagarith and h.264 compress using very different schemes, simple filesize comparisons are nearly meaningless. As you noted in your first post (in this thread), you can't see the difference.

Lagarith doesn't compress nearly as much because it's lossless and it needs to be decompressed quickly, for further filtering and/or encoding. It's not a 'final-output' codec. Next, maybe you should research how modern compression codecs work.

[budwzr]

Yes, you can see a slight loss in detail. Look at the window frames. The loss is due to interpolation. Anytime you enlarge something, new pixels have to be created, and they get fuzzy.

The source is not worthy of lossless compression, that's why there's not much difference.

[Track]

Since the running time is the same, file size and bitrate are directly proportional:

file size = bitrate * running time

So 10 times the bitrate means 10 times the file size (with some small variation due to container overhead).

I think you should provide a short representative sample of your source. Others can then tell you if what you are getting from x264 is normal or if something is going wrong. VirtualDub in Video -> Direct Stream Copy mode will let you trim out a section without reencoding.

Dude, I just want an output file that is in between the 1.7GB and the 170MB in terms of QUALITY.

That is my question.

And if you spent more time researching what you don't know rather than whining here, maybe you'd actually learn something

Wow, are you serious?

This website is called "Video Help". It is a HELP forum.

I come and ask a question on a help forum and you consider that whining and tell me to do my own research?!

You're like a doctor who's so poor at his job he considers his patients' needs irritating and instead of treating them, tells them to go online and research their disease.

When someone asks a question on a forum I frequent, I give them an answer, I don't mock them or tell them to go do the hard work themselves.

If your ethics are so polarized from mine, I'd prefer it if you see yourself out of any future thread I "whine" in.

The source is not worthy of lossless compression, that's why there's not much difference.

Yes, that is true, but I think it could still use a little more bit-rate/whatever. Just a bit.

[jagabo]

Dude, I just want an output file that is in between the 1.7GB and the 170MB in terms of QUALITY.

Dude, I was explaining why "file size" and "bitrate" can be used interchangeably in this context. Because your reply to smrpix showed a lack of understanding.

Because Lagarith and h.264 compress using very different schemes, simple filesize comparisons are nearly meaningless.

I'm not comparing file-size, I'm comparing bit-rate.

You have yet to explain why the two shots in your original post indicate the video has been resized. And since they're JEPG images nobody can tell what problems were caused by JPEG compression.

[Track]

Dude, I was explaining why "file size" and "bitrate" can be used interchangeably in this context. Because your reply to smrpix showed a lack of understanding.

/facepalm

Why are you arguing with me instead of ANSWERING the question?

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

[_Al_]

Your question makes no sense, you'll realize that later. Both files have the same quality, providing you do things alright. I think you should start answering questions and cooperate.

You have two lossless files. Like two trailers full of bricks. Each trailer has 1000 bricks, one trailer has them neatly stored, second has them just thrown in so volume is bigger so at the end you need one larger trailer to carry those bricks that vere not stored that neatly. But there is same amount of bricks on each trailer. You'd refuse that first trailer thinking there is not enough bricks. That makes no sense. Analogy is no 100% accurate but you start there.

jagabo is trying to tell you that RGB video could be much bigger than YUV 4:2:0, . RGB Lagarith would not even work with that simple BAT encoder I posted here. x264 needs YUV video. But for example other encoder will accept that, but has to transfer RGB into YUV because H.264 IS YUV video. RGB to YUV transfer is not 100% clean. And for some reason you want pure cleanliness. Ask questions that clarify it for you. Post sample etc. You are not interacting much at all.

[smrpix]

This website is called "Video Help". It is a HELP forum.

Correct, it's called videohelp, not videohandhold, nor videowillfulignorance. Please listen to the good advice you are getting.

[jagabo]

Why this size discrepancy in your original post?



Scaling causes a reduction in quality. JPEG encoding causes a loss of quality. JPEG encoding with different cropping will give different drops in quality. This evidence is useless.

[smrpix]

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

What is the running time of your file?

filesize=bitrate*duration.

[jagabo]

I inputted the file into Handbrake and chose CRF 20. The result was (if I recall) a 10Mbps bit-rate and a 19.5MB file size.

Then I chose CRF 10 - same result. Then CRF 0 - same result. I tried playing with all the settings besides CRF and I still got the same result - 19.5MB and (if I'm not wrong) 10Mbps bit-rate.

This is not possible. Something is wrong.

[Track]

You have two lossless files. Like two trailers full of bricks. Each trailer has 1000 bricks, one trailer has them neatly stored, second has them just thrown in so volume is bigger so at the end you need one larger trailer to carry those bricks that vere not stored that neatly. But there is same amount of bricks on each trailer. You'd refuse that first trailer thinking there is not enough bricks. That makes no sense. Analogy is no 100% accurate but you start there.

Let me get this straight.

You're saying that the 1.7GB Lagarith encode does not have more quality (hold more bricks), rather it is just less organized. So, H.264 simply organizes it neatly and that reduces the file-size tenfold?

But what about the bit-rate? 2.5Gbps = unorganized and 181Mbps = organized? Is that it?

jagabo is trying to tell you that RGB video could be much bigger than YUV 4:2:0, . RGB Lagarith would not even work with that simple BAT encoder I posted here. x264 needs YUV video. But for example other encoder will accept that, but has to transfer RGB into YUV because H.264 IS YUV video. RGB to YUV transfer is not 100% clean. And for some reason you want pure cleanliness. Ask questions that clarify it for you. Post sample etc. You are not interacting much at all.

I chose the YUV option in Lagarith.

Why this size discrepancy in your original post?

Scaling causes a reduction in quality. JPEG encoding causes a loss of quality. JPEG encoding with different cropping will give different drops in quality. This evidence is useless.

I have no idea why there is a discrepancy. Both are 100% crops of a 3840x2560 file.

What software should I use to extract a useful piece of evidence?

What is the running time of your file?

filesize=bitrate*duration.

1.7GB - 2.5Gbps - 8 seconds
170MB - 181Mbps - 8 seconds

This is not possible. Something is wrong.

So, what do I do?