PSNR, SSIM, Rate Factor in x264 header [Archive]

turbojet

13th October 2009, 16:32

The ratefactor of the second pass will be different from the ratefactor of the first pass because different options are used, so the ratefactor in the encoded files header wouldn't be the ratefactor of the file itself.

The ratefactor of a second pass will be different from a first pass, no matter what settings were used, because they're different metrics.

Calculate it during the second pass?

Why would you want to put those numbers in the header anyway ? what's the use ?

So we can have a real quality factor from the result of a 2 pass encode. With xvid, divx you have tools that can measuer quantizers, you can with x264 as well but they aren't very accurate.

As for seeing a quality factor during an encode can help a user decide on what resolution, size, settings they use. It's also something that's been available in xvid, cce, hcenc for years and something I've gotten accustomed to and it's really helped. Currently with x264 multipass the quality can't be judged until the last pass is finished and you watch it.

LoRd_MuldeR

13th October 2009, 17:08

Calculate it during the second pass?

I think this leads to the same problem as before:

We would know the final rate factor at the end of the second pass. But we already wrote the user data at the very beginning of the second pass, when the final rate factor was still unknown...

turbojet

13th October 2009, 17:21

Changing the bits of the encoding settings in the header doesn't break the file. Why couldn't x264 add or change the header after the encode?

Dark Shikari

13th October 2009, 17:31

Changing the bits of the encoding settings in the header doesn't break the file. Why couldn't x264 add or change the header after the encode?Because libx264 doesn't know what "changing the header" means. It just returns bytes to the calling application.

We're not going to completely redesign the API and break piping just because someone wants useless crap in the header.

turbojet

13th October 2009, 17:34

OK then will keep judging quality by quant even though it's not very accurate but it's all that can be done for now.

How about calculating rate factor during pass 2/3 and displaying it while it encodes like many other encoders?

If you did that I can add my own header to the file to get what I've been able to get from MPEG4 ASP for years, an accurate quality measure hard coded in.

Dark Shikari

13th October 2009, 17:37

accurate quality measureYou keep using that word... (http://www.youtube.com/watch?v=G2y8Sx4B2Sk)

turbojet

13th October 2009, 17:42

Quantizers are the most accurate way of telling quality during and after the encode from MPEG ASP outside of your eyes, but quantizer can also tell things about the source. Such as a bad source with low quantizers would look bad to the eyes but the encode was done at good quality and the encoder can't be blamed for the quality.

If ratefactor isn't the most accurate measure in x264 then what is?

All I'm asking for is to be able to do what I've been doing for years and there's and considering there's tools out there to distinguish quantizers, knowing that info isn't 'useless crap' to everyone.

Reimar

13th October 2009, 17:50

Then what do you think is an accurate quality measure other than your eyes if you know the source and encoder settings?

Well, besides that there probably is no such thing, based on the fact that there is not even an accurate, unambiguous definition of quality -
Why not just run x264 with SSIM and PSNR calculation on and pipe the output into a .txt file? If necessary write a tool in addition that extracts the info from that and regenerates the H.264 header with that info added (or since you'll probably remux into some other format anyway, add it as metadata for that format).

LoRd_MuldeR

13th October 2009, 18:01

If the video is stored in a container like MKV, it should be no problem to add meta tags of any kind after the encode has finished.

So with a simple script you can parse the PSNR/SSIM value from x264's text output and call the required CLI tool to add that information to the file as meta data ;)

That should work with the "final ratefactor" the same way...

turbojet

13th October 2009, 18:01

I could do that but PSNR/SSIM isn't a very accurate of measure and honestly probably better off using quantizer.

I'm looking for something more accurate like ratefactor, too bad it's only displayed after the first pass, even so if it was displayed during first pass it would help determine the quality to expect.

13th October 2009, 18:06

I could do that but PSNR/SSIM isn't a very accurate of measure and honestly probably better off using quantizer.
SSIM is much better for your purpose than looking at a ratefactor or quantizers, regardless of the encoder or video format. I'd suggest the same as Reimar.

LoRd_MuldeR

13th October 2009, 18:13

I could do that but PSNR/SSIM isn't a very accurate of measure and honestly probably better off using quantizer.

There probably isn't a better "objective" quality metric than SSIM.

But if there is one, I'd be very interested too, because I need one for a project I'm working on now :devil:

Suggestions would be welcome :)

turbojet

13th October 2009, 19:14

Actually I mainly use m2ts container where metadata and ability to analyse quants is lost however mediainfo can still read x264 encoder settings. I really can't have any measure hardcoded, oh well, forget about writing things to the header.

In the tests I ran --keyint 240 is 0.0002-0.0005 lower SSIM then --keyint 24 at the same size. Average quantizers are 0.1-0.3 lower in the --keyint 240. At --crf 28 my eyes tell me --keyint 240 is a little higher quality. At --crf 24 my eyes can't tell a difference.

Quantizers aren't very good either, using x264 --crf 26 resulted in a 4 MB file that looked good, adding --tune ssim resulted in a 1 MB file that was barely watchable. Quantizers were identical, SSIM of the 4 MB was 0.00016 larger.

I haven't seen an x264 dev respond to this yet, but is there any chance of calculating rate factor during second pass and also display the rate factor in real time while encoding the first and second pass?

G_M_C

13th October 2009, 22:40

Another question: How does putting numbers into the header help measuring quality exactly ?

Currently with x264 multipass the quality can't be judged until the last pass is finished and you watch it.

If you want a target quality, and still want to use 2-pass VBV, i'd do it the other way around.

I'd make a test AVS with some minutes of the whole clip; Compile a sample with several different cuts of the whole video, so you end up with a representative short version of the whole video. Run that through x264 with different CRF's.

Then screen those samples, and look for the one that has the desired quality. Use the final bitrate of that as the value to use on the encoding of the whole video.

LoRd_MuldeR

13th October 2009, 22:45

Currently with x264 multipass the quality can't be judged until the last pass is finished and you watch it.

Well, if you do a 2-Pass encode, this usually means you need to hit a specific size or average bitrate.

So what you request and what you'll get is the best possible quality x264 can retain for that size (under your chosen settings).

If your target size/bandwidth really is restricted, you'll have to accept that quality. If it satisfies you or not ;)

And if your size is not restricted, you simply would use CRF mode and specify the CRF value which gives the desired quality...

If you want a target quality, and still want to use 2-pass VBV, i'd do it the other way around.

I'd make a test AVS with some minutes of the whole clip; Compile a sample with several different cuts of the whole video, so you end up with a representative short version of the whole video. Run that through x264 with different CRF's.

Then screen those samples, and look for the one that has the desired quality. Use the final bitrate of that as the value to use on the encoding of the whole video.

Why should we do that? You know that 1-Pass VBV now works at least as good as 2-Pass VBV? :confused:

For "target quality with VBV" you can use 1-Pass CRF + VBV and that's it...

PatlaborForce

13th October 2009, 22:51

Currently with x264 multipass the quality can't be judged until the last pass is finished and you watch it.

Which is no different than the case with DivX and XviD. DRF values of ASP encodes don't allow you to make any meaningful quality judgments.

G_M_C

13th October 2009, 22:56

[...]
Why should we do that? You know that 1-Pass VBV now works at least as good as 2-Pass VBV? :confused:

For "target quality with VBV" you can use 1-Pass CRF + VBV and that's it...

I had a case in mind where the size matters. You can use the sample to see if you can get the quality you want on the original resolution, or if you have to for instance resize to a smaller size to get good enough quality.

LoRd_MuldeR

13th October 2009, 23:04

I had a case in mind where the size matters. You can use the sample to see if you can get the quality you want on the original resolution, or if you have to for instance resize to a smaller size to get good enough quality.

How is that realted to 1-Pass vs. 2-Pass VBV ???

Anyway, downscaling is only another way of killing detail/quality. So it's the question how you define quality here.

Also often the target resolution is pre-defined by the playback device, which means downscaling isn't an available option.

And if we intend PC playback, there usually is no strict size limit, so we can use CRF mode again...

turbojet

14th October 2009, 00:27

Another question: How does putting numbers into the header help measuring quality exactly ? Same way putting --crf in the header does.

If you want a target quality, and still want to use 2-pass VBV, i'd do it the other way around.

I'd make a test AVS with some minutes of the whole clip; Compile a sample with several different cuts of the whole video, so you end up with a representative short version of the whole video. Run that through x264 with different CRF's.

Then screen those samples, and look for the one that has the desired quality. Use the final bitrate of that as the value to use on the encoding of the whole video.

That seems like a whole lot of work to achieve what I want which is basically something that tells me if x264 doesn't have enough or too much bitrate (~CRF 20 is indistinguishable from 12 for me) for the reolution/file size set. With a rate factor realtime display I should be able to tell that within 10 minutes of the first pass and make adjustments.

Well, if you do a 2-Pass encode, this usually means you need to hit a specific size or average bitrate.

So what you request and what you'll get is the best possible quality x264 can retain for that size (under your chosen settings).

If your target size/bandwidth really is restricted, you'll have to accept that quality. If it satisfies you or not ;)

This is what we have to live with now but it's what I'm seeking to avoid.

Which is no different than the case with DivX and XviD. DRF values of ASP encodes don't allow you to make any meaningful quality judgments.

With xvid I can usually tell within 10 minutes into the first pass based on estimated size which reflects quantizers in the second pass. Average quantizer of 3 at 640x352 will most often look better then quantizer 5 at 720x384.

14th October 2009, 00:35

This is what we have to live with now but it's what I'm seeking to avoid.
Why don't you use CRF with VBV then?

PatlaborForce

14th October 2009, 01:10

Same way putting --crf in the header does.

So basically not too much? What meaningful information about the quality of a file do you get from knowing that the CRF was at 18 instead of 19?

LoRd_MuldeR

14th October 2009, 01:14

Well, if you do a 2-Pass encode, this usually means you need to hit a specific size or average bitrate.

So what you request and what you'll get is the best possible quality x264 can retain for that size (under your chosen settings).

If your target size/bandwidth really is restricted, you'll have to accept that quality. If it satisfies you or not ;)

This is what we have to live with now but it's what I'm seeking to avoid.

It is impossible to avoid. If you are encoding for a fixed target size, the best quality you can squeeze out is 2-Pass with the bitrate accordingly.

And if you are not encoding for a fixed size, use CRF mode with a suitable CRF value for the desired quality.

Therefore I don't see the point why you want to "emulate" CRF mode with 2-Pass mode by successively adjustment the bitrate until the quality is as desired.

Why not use CRF right from the start? ^^

turbojet

14th October 2009, 01:58

So basically not too much? What meaningful information about the quality of a file do you get from knowing that the CRF was at 18 instead of 19?

Not between 18 and 19 but I can between CRF 18 and 26 for example.

It is impossible to avoid. If you are encoding for a fixed target size, the best quality you can squeeze out is 2-Pass with the bitrate accordingly.

And if you are not encoding for a fixed size, use CRF mode with a suitable CRF value for the desired quality.

Therefore I don't see the point why you want to "emulate" CRF mode with 2-Pass mode by successively adjustment the bitrate until the quality is as desired.

Why not use CRF right from the start? ^^

I aim for DVD5 or DVD9 with 720p, 1080p so there's 4 possible situations. CRF is way too hit and miss on file size. Wasting a lot of space aiming for DVD usually means degraded quality, going over is a waste of time.

Dark Shikari

14th October 2009, 02:05

RichardA

14th October 2009, 06:31

I aim for DVD5 or DVD9 with 720p, 1080p so there's 4 possible situations. CRF is way too hit and miss on file size. Wasting a lot of space aiming for DVD usually means degraded quality, going over is a waste of time.

You are therefore targeting a specific file size, so you should be using a 2-pass encode with a bitrate target, not a CRF encode.

Step 1: Decide whether to aim for DVD5 or DVD9.

Step 2: Calculate the bitrate required to fill the available space. Apply a ceiling to the bitrate to catch insane values for short clips.

Step 3: Run a 2-pass encode at that bitrate.

The only slightly tricky step is deciding whether to aim for DVD5 or DVD9. This should be obvious from the source, but if you wanted to script this and have it run automatically, you have to translate your "gut feeling" into an algorithm. You could perhaps base the decision on resolution_x * resolution_y * number_of_frames. This would give you a value for the uncompressed size of the clip. You can look at some of your past encodes to determine the maximum compression ratio you're happy with.

This doesn't consider how easily the source material can be compressed though. So you might want to run an ultra-fast CRF encode at a predetermined CRF value and see what the file size finishes up being. Perhaps if an ultra-fast encode at crf=20 fits on a DVD5 then run the 2-pass high-quality encode at the DVD5 bitrate. If encoding speed is more important than accuracy, you could perhaps run the CRF encode over 10% of the file and multiply the result by 10.

Richard.

turbojet

14th October 2009, 10:11

Use 2-pass CRF. Run the first pass as CRF, and then run the second pass as MIN( CRF bitrate, max bitrate ).

Spending twice the amount of time encoding is something I really want to avoid. It's also something I've never had to do with xvid/cce/hcenc while still getting a very good measure of quality based on the realtime quant/est file size display.

You are therefore targeting a specific file size, so you should be using a 2-pass encode with a bitrate target, not a CRF encode.

Step 1: Decide whether to aim for DVD5 or DVD9.

Step 2: Calculate the bitrate required to fill the available space. Apply a ceiling to the bitrate to catch insane values for short clips.

Step 3: Run a 2-pass encode at that bitrate.

The only slightly tricky step is deciding whether to aim for DVD5 or DVD9. This should be obvious from the source, but if you wanted to script this and have it run automatically, you have to translate your "gut feeling" into an algorithm. You could perhaps base the decision on resolution_x * resolution_y * number_of_frames. This would give you a value for the uncompressed size of the clip. You can look at some of your past encodes to determine the maximum compression ratio you're happy with.

This doesn't consider how easily the source material can be compressed though. So you might want to run an ultra-fast CRF encode at a predetermined CRF value and see what the file size finishes up being. Perhaps if an ultra-fast encode at crf=20 fits on a DVD5 then run the 2-pass high-quality encode at the DVD5 bitrate. If encoding speed is more important than accuracy, you could perhaps run the CRF encode over 10% of the file and multiply the result by 10.

Richard.

Time, bitrate, resolution are all factors but will never judge compressibility. I have 2 hour movies that fit DVD5 1080p with CRF < 22 (had to be tested using CRF). On the other hand I have seen CRF 22 of 90 minute 720p movies end up 7-8 GB. Looking at the 2 movies they are both fairly low action with a little grain and about average brightness. At first glance I'd say they both would encode about the same and aim for 1080p DVD9 or 720p DVD5 on the 2 hour movie and 1080p DVD5 on the 90 minute movie and I'd be completely wrong with nothing to tell me I was wrong except for a long CRF encode. Also ultrafast encodes I've seen up to 5x larger bitrate then what my normal setitngs are, while some are roughly the same size.

I could use selectevery() and do a CRF encode on that and see what the size is, which is a typical compression check. But there are flaws to this method especially if you have some scenes that will use extremely high or extremely low bitrate and only 5 out of 10000 frames represent this in selectevery(). Where as a quick first pass with rate factor display gives a much better representation but it's skewed due to different encoding settings. However second pass rate factor realtime display would be the most accurate way I know of that would tell me if the encoder had enough or too much bitrate.

Dark Shikari

14th October 2009, 10:20

Spending twice the amount of time encoding is something I really want to avoid. It's also something I've never had to do with xvid/cce/hcenc while still getting a very good measure of quality based on the realtime quant/est file size display.Twice the amount of time? The first pass is easily half a dozen times faster than the second pass for sane settings.

And if even that is too much, do a test encode using SelectEveryRange.

G_M_C

14th October 2009, 10:23

[...]
I aim for DVD5 or DVD9 with 720p, 1080p so there's 4 possible situations. CRF is way too hit and miss on file size. Wasting a lot of space aiming for DVD usually means degraded quality, going over is a waste of time.

Try what i suggested. That's what i do to find out what is the max quality i can reach given the space (and given the audio track i want to keep !).

You can also simply choose one or more point where you simply split the video in parts. Video's of like 2 hrs, i just split into 2.

turbojet

14th October 2009, 10:44

Twice the amount of time? The first pass is easily half a dozen times faster than the second pass for sane settings.

How I understand what you mean is use x264 --crf --pass 1 --slow first pass --stats <same settings as second pass>. Judge based on bitrate for the second pass then run the second pass. Is this what you mean?

This would do helpful at deciding but it needs about 175% more time then a normal 2 pass and at times could still be tough to make a decision. For instance if --crf 28 1080p (my target ceiling for viewing 1080p) is 5 GB and there's 450 MB audio/overhead should I go 1080p DVD5, 1080p DVD9 or 720p DVD5. I'd have to spend a few minutes thinking about it and I'd probably stay safe and choose 720p DVD5, however I may have been able to achieve a better picture with 1080p DVD5. With a real time rate factor within the first 5 minutes of the second pass I could make a decision I felt comfortable with.

And if even that is too much, do a test encode using SelectEveryRange. Often accurate enough but I have encountered some problems with it as I explained.

Try what i suggested. That's what i do to find out what is the max quality i can reach given the space (and given the audio track i want to keep !).

You can also simply choose one or more point where you simply split the video in parts. Video's of like 2 hrs, i just split into 2.

Seems like a lot of manual work and time to make my decision and with a fairly short attention span I'd be better off running a full --crf --slow first pass which requires coming back to the computer hours later, not very helpful when you often encode overnight.

Dark Shikari

14th October 2009, 10:47

How I understand what you mean is use x264 --crf --pass 1 --slow first pass --stats <same settings as second pass>. Judge based on bitrate for the second pass then run the second pass. Is this what you mean?Whoever said to use a slow firstpass?

turbojet

14th October 2009, 10:49

Whoever said to use a slow firstpass?

Fast first pass --crf may result in a file much larger (I've seen up to 5x larger) then the second pass and some times about the same size.

Anyhow is there any chance of calculating rate factor on --pass 2 and displaying it real time in both first and second pass?

RunningSkittle

14th October 2009, 12:44

Fast first pass --crf may result in a file much larger (I've seen up to 5x larger) then the second pass and some times about the same size...

Umm no... (you are on the verge of trolling)

LoRd_MuldeR

14th October 2009, 13:02

Fast first pass --crf may result in a file much larger (I've seen up to 5x larger) then the second pass and some times about the same size...Umm no... (you are on the verge of trolling)

I think he's right. The "fast firstpass" mode, as the name implies, uses much faster settings.

And for CRF mode using "faster" settings can have two effects: Bigger overall file size at same CRF -and- worse quality per size ;)

J_Darnley

14th October 2009, 13:17

Since the fast first pass settings use subme 2 the bitrate obtained is close to a slow encode, it may even be lower due to things like psy-rd being off.

LoRd_MuldeR

14th October 2009, 13:27

Since the fast first pass settings use subme 2 the bitrate obtained is close to a slow encode

You need to explain that statement :confused:

For a "slow" encode we certainly wouldn't use anything below SubME=7 (the default). So how is a fast setting, like SubME=2, anywhere close to a "slow" encode?

BTW: Did you ever test "--crf 18 --preset veryfast" against "--crf 18 --preset veryslow" for the same source and look at the resulting filesize ???

J_Darnley

14th October 2009, 13:42

Because it still uses SATD which has a very large effect in mode decision

As evidence, I present you with these results:

x264-r1292M-patched "C:\DVD\Projects\Kung Fu Hustle\Kung Fu Hustle.avs" -o NUL --preset slow --tune film --crf 21 --pass 1
encoded 5000 frames, 39.37 fps, 778.95 kb/s, in 0:02:07

x264-r1292M-patched "C:\DVD\Projects\Kung Fu Hustle\Kung Fu Hustle.avs" -o NUL --preset slow --tune film --crf 21
encoded 5000 frames, 11.02 fps, 892.21 kb/s, in 0:07:33

x264-r1292M-patched "C:\DVD\Projects\Kung Fu Hustle\Kung Fu Hustle.avs" -o NUL --preset slow --tune film --crf 21 --psy-rd 0:0
encoded 5000 frames, 12.60 fps, 723.39 kb/s, in 0:06:36

P.S. veryfast uses subme=1 but I will still test as you wish

[EDIT] veryslow will be later

C:\Program Files\gnuwin32>x264-r1292M-patched "C:\DVD\Projects\Kung Fu Hustle\Kung Fu Hustle.avs" -o NUL --preset veryfast --tune film --crf 18
encoded 5000 frames, 58.68 fps, 2943.29 kb/s, in 0:01:25

LoRd_MuldeR

14th October 2009, 13:48

Not necessary. With the same sample I get 20 MB -vs- 32 MB at the same CRF value with "--preset veryslow" -vs- "--preset verfast".

So it's obvious that "faster" settings compress less efficient and thus likely produce a bigger file at same CRF...

14.10.2009 13:31 31.593.967 samples_crf18_veryfast.mkv
14.10.2009 13:34 20.055.317 samples_crf18_veryslow.mkv

And that's just the most blatant problem with your comparison. Most of x264's speed-quality tradeoff options both improve quality and reduce bitrate at a given QP...

nurbs

14th October 2009, 13:50

And for CRF mode using "faster" settings can have two effects: Bigger overall file size at same CRF -and- worse quality per size ;)
I wouldn't say using faster settings necessarily result in bigger filesizes. After finding a CRF that suits me I played around with the settings a bit starting with the current defaults and then using slower settings. At first the filesize got smaller, but then they started to get bigger again and then for the slowest settings I tested it was bigger than the defaults. I guess the same could happen if you used faster settings.
I mean maybe there are settings that always have a certain influence on the filesize, but I wouldn't just make a blanket statement that faster options always produce bigger files.

PatlaborForce

14th October 2009, 21:01

Not between 18 and 19 but I can between CRF 18 and 26 for example.

But how does that really tell someone anything meaningful about what the end quality is like? Please explain to me what exact information about the quality of that file I can extrapolate from knowing that it's encoded at crf 26? A particularly blurry source code potentially be perfectly transparent at CRF 26 and the CRF 18 could just be pure overkill. There is just no consistent, meaningful information you can extrapolate for every case based on the CRF value.

turbojet

15th October 2009, 00:25

What you explain sounds a lot like bitrate instead of rate factor. bad blurry source (http://www.mediafire.com/download.php?wk20hyzyiez). In this case CRF 26 is not acceptable to me but normally 26 is borderline. CRF 18 is always overkill for my eyes and I'm guessing I've done a lot of saturated encodes. If you have a sample that can backup your claims of CRF 26 looking transparent please post a link.

IVTCing this source:
x264.exe --preset veryfast --keyint 24 --min-keyint 2 --vbv-bufsize 18000 --vbv-maxrate 18000 --subme 2 -- bframes 3 --partitions none --no-8x8dct --direct auto = 780 kbps

x264.exe --keyint 24 --min-keyint 2 --vbv-bufsize 18000 --vbv-maxrate 18000 --subme 7 --direct auto = 523 kbps

fast first pass crf is 33% larger then second pass in this situation. Too inaccurate for me, if it was always within 5% I'd consider making a judgment by comparing the first pass crf bitrate to the target bitrate.

LoRd_MuldeR

15th October 2009, 00:37

I wouldn't say using faster settings necessarily result in bigger filesizes. After finding a CRF that suits me I played around with the settings a bit starting with the current defaults and then using slower settings. At first the filesize got smaller, but then they started to get bigger again and then for the slowest settings I tested it was bigger than the defaults. I guess the same could happen if you used faster settings.
I mean maybe there are settings that always have a certain influence on the filesize, but I wouldn't just make a blanket statement that faster options always produce bigger files.

That's why I said it can happen - as a response to RunningSkittle who implied that it cannot.

PatlaborForce

15th October 2009, 06:34

What you explain sounds a lot like bitrate instead of rate factor. bad blurry source (http://www.mediafire.com/download.php?wk20hyzyiez). In this case CRF 26 is not acceptable to me but normally 26 is borderline. CRF 18 is always overkill for my eyes and I'm guessing I've done a lot of saturated encodes. If you have a sample that can backup your claims of CRF 26 looking transparent please post a link.

No, what I'm describing is not about bitrate. Secondly, I never claimed CRF 26 was going to create transparent encodes I said there could be hypothetical sources which it could. The fact still remains that there is no actual way you can extrapolate a CRF value to a quality though. On some sources CRF 22 might look fine, but on others it can look like crap. In some cases, CRF 18 is overkill while in other cases it might be the only minimum value to give sufficient quality.