Variable FrameRate

[-Habanero-]

Yes, CRF18 produced 4600 kb/s with no psychovisuals. You're saying at this bitrate is where psy-rd 1.00 is useful? What should I use for the lower bitrates? The reason I used them to test psy is to make the differences a lot more obvious. On high bitrates, everything looks good even with crappy settings.

Also I never heard of AV1. Is it DCT-based or what?

[poisondeathray]

Yes, CRF18 produced 4600 kb/s with no psychovisuals. You're saying at this bitrate is where psy-rd 1.00 is useful? What should I use for the lower bitrates? The reason I used them to test psy is to make the differences a lot more obvious. On high bitrates, everything looks good even with crappy settings.

Also I never heard of AV1. Is it DCT-based or what?

I'm saying most people would reduce psy when targetting low bitrate ranges. The simple fact is details require bitrate. The "cons" definitely outweigh the "pros" at that low bitrates. So 2Mb/s would probably be considered in the "low" bitrate range since it's about half

Yes, everything looks good at high bitrates, but that's sort of the point - using --no-psy will require more bitrate to achieve that point where most of the details are preserved instead of dropped. It's not some magical number or tipping point, and that "point" is going to be different for different people

So I'm guessing you'll see "pros" starting to outweigh the "cons" around 3-4Mb/s . Not necessarily --psy-rd 1:0 ; that' s just an arbitrary number. Just do some tests and look - you should already have a feeling of what is going on from the tests you've done so far. Important not to just look at still images, but in motion. Also do the interleave() tests; the latter will clearly show differences that are more difficult to see in motion

Just search for "AV1"articles, it's mostly VP10 code base plus other some additions from daala and others
http://www.streamingmedia.com/Articles/Editorial/What-Is-.../What-is-AV1-111497.aspx

[poisondeathray]

Whoops, I missed that you're using 10bit AVC .The quantizer scale is different than 8bit AVC. But the trend will still be the same

[-Habanero-]

I'll get back to the psy tests in a minute but I finally found that game footage test that had a huge benefit to deduplicating. It took a lot of digging but I found it, had to recreate the videos tho. The source had 33,565 frames and 70% of them are exact duplicates minus the 400 frames that were not removed as only up to 20 consecutive duplicates were killed.

The VFR video had 44% less bitrate for the same SSIM+ score. 1,670 KB vs. 930.

See, this is where I got the 50% efficiency number from. Here the efficiency is 60% while it was 25 for the South Park encode. I guess it's dependent on the footage. Ones with duplicates spread out all over the place is where it's beneficial while ones that are inherently non-VFR except select few scenes with prolonged stationary scenes and fadeouts don't benefit much.

For cartoons, VFR benefit is negligible but for classic game footage it's well worth it.

https://www.sendspace.com/file/w7mu0w

[poisondeathray]

For cartoons, it's also going to depend on the source frames. A "dirty" or "noisy" source will typically show more % benefit for the VFR version

The type of measurement is also going to give you different values. Can you run that gameplay through "classic" SSIM and PSNR ? I suspect the bitrate savings numbers will be lower if you go by those numbers

[sneaker]

It does sound suspicious. Perfect duplicates would compress extremely well anyways. The only difference should then be because of things like keyframe intervals.

[-Habanero-]

You don't understand, these are perfect duplicates so no noise is being removed. And clearly they DON'T compress that well. I don't buy your point about I-frame intervals because that wouldn't affect the bitrate by 44% but I can test it with an infinite I-interval too if you want.

PDR, I included all files including the source in the download. It's only 40MB and metric tests finish in seconds so you're welcome to look at 'em. PSNR and old SSIM should be abandoned since they're outdated anyway.

EDIT:

M:\pokeblueVFR.mkv M:\pokeblueCFRx264.avs
AVG: 0.99875 AVG: 0.99872

PSNR:
AVG: 33.20727 AVG: 33.20709

[poisondeathray]

Can you also upload the decimation / log file used ?

Yes PSNR and SSIM should be abandoned, but testers have a vast amount of experience and history with them, so people know how they perform under certain conditions and what to expect, where they fail, etc... They know that everything should be taken into context, not to rely on metric. Also, if 10/10 tests say the same thing about a trend that's more evidence in favor

SSIM+ is not free / closed source and not proven to be stable either. Jury is still out on that one

[-Habanero-]

True, but SSIM+ will be out there soon within a few years.
Here's the PSNRHVSM score as well. I have no idea why it thinks the CFR encode is so much crappier but it isn't, it's indistinguishable.
average 184.531921 143.288865

[poisondeathray]

and what settings did you use for the dedup script (threshold, etc..) ?

[-Habanero-]

I used the lowest possible, 0.00001. I actually used ExactDedup which technically doesn't let you input a threshold since it only removes identical frames but Dedup with 0.00001 threshold will achieve the same result, 9628 frames.

[poisondeathray]

I would also be cautious about how you intepret those results. Your bitrate range is tiny <50kb/s . A few +/- kb/s either way will make up a large % and skew the results becoming a large margin of error. Also your "VFR" file didn't have timecodes, so the filesize will increase with timecodes muxed into the container. Normally it's negligible and not significant, but at this bitrate range it becomes 6.4% larger with timecodes. At this bitrate range, you can even do "tricks" like strip SEI information which will reduce the filesize even more (a few kb becomes significant in this case)

You would expect that the lower the bitrate range, the larger the % impact of VFR, because the cost of duplicates (even pure duplicates) is normally tiny, but in the tiny bitrate range, it makes a proportionally larger amount.

[-Habanero-]

You're right, I forgot to include the times. Now it's a 40% reduction instead of 44.

I did a new test, this time aiming for almost flawless quality. This time it's a 36% reduction. 1489 vs 2317 KB. I included the times.txt. I had to use CRF6.5 for the VFR and CRF8 for the CFR. Sorry if the bitrates are so low but this is a 160x144 resolution with highly compressible content. Can you suggest a much more complex platformer game with lots of duplicates and higher resolution? I can't crank the bitrate any higher for this one or it will approach lossless.

M:\pokeblueVFR6.5.mkv M:\pokeblueCFRx264.avs
AVG: 0.99990 AVG: 0.99991

But I believe I've made my point. VFR is very useful for certain content. You might not think it's useful to halve a bitrate that's already ridiculously low but this is just a 9-minute video. Think of speedruns that take hours and hours. There is a 3 1/2 hour run of Pokemon Blue catching all 151 pokemon that is only 125 MB which would've been 200 MB otherwise. That's a big difference.

[poisondeathray]

But I believe I've made my point. VFR is very useful for certain content. You might not think it's useful to halve a bitrate that's already ridiculously low but this is just a 9-minute video. Think of speedruns that take hours and hours. There is a 3 1/2 hour run of Pokemon Blue catching all 151 pokemon that is only 125 MB which would've been 200 MB otherwise. That's a big difference.

I agree. That was exactly my point early on. The numbers you were giving were too high for typical cartoon content source like a dvd where you have runs of 6,12,24 fps. And the "savings" is never zero - you always have some savings, at least the way the tests are measured with the assumptions and testbed structured the method described earlier

Modern high res games don't really have duplicates, unless it's chess or some turn based strategy game.

The other example I mentioned earlier was a slideshow or presentation. There you can have even more duplicates than a game like pokemon. There are times when a speaker might be rambling on for minutes. But you might want to interrupt and introduce seekpoints depending on the audio content.

[-Habanero-]

Modern high res games don't really have duplicates, unless it's chess or some turn based strategy game.

I know, I was thinking of a platformer with more complex graphics that would yield a bitrate a little higher than frigging 14 kilobits.
There must be a SNES turn-based RPG. The few that I know I've never played yet.

The other example I mentioned earlier was a slideshow or presentation. There you can have even more duplicates than a game like pokemon. There are times when a speaker might be rambling on for minutes. But you might want to interrupt and introduce seekpoints depending on the audio content.

You won't save very much here, it's practically pointless. Before I remembered this Pokemon test I tried to do it with a different game with 6000 frames where 20% were duplicates and it reduced bitrate by only 2% (without times.txt). That's because the only parts it had duplicates were during level transitions or whenever the player brought the menu up briefly to pick a different weapon/spell.
The savings are huge only if the dups are spread all over the video, not concentrated in a few spots. Stationary scenes are pathetically easy to compress but to compress moving scenes with frequent duplicates needs to reference a greater number of frames which H264 limits to 16.

You implied that metadata was the only reason VFR saved so much bitrate on the pokemon blue footage.

[poisondeathray]

The other example I mentioned earlier was a slideshow or presentation. There you can have even more duplicates than a game like pokemon. There are times when a speaker might be rambling on for minutes. But you might want to interrupt and introduce seekpoints depending on the audio content.

You won't save very much here, it's practically pointless.

Not pointless, think about it - the % of duplicates can be astronmically higher on some types of presentations, slideshows. Runs of dead space a few thousand frames long. That's a lot of duplicates. You don't have to "limit" yourself to 20 by using an avisynth filter

You implied that metadata was the only reason VFR saved so much bitrate on the pokemon blue footage.

Not sure how you got that ? Which "metadata"? I said 6.4% for the timecodes.

I'm saying at low bitrates , small changes can result in large % differences. You could have used a smaller container and shaved of another 2-3%. Those types of things are negligible at "normal" bitrates. It's very "dicey" testing such low bitrates

[-Habanero-]

Not pointless, think about it - the % of duplicates can be astronmically higher on some types of presentations, slideshows. Runs of dead space a few thousand frames long. That's a lot of duplicates. You don't have to "limit" yourself to 20 by using an avisynth filter

I already addressed this. It's not important how many duplicates there are but WHERE they are. In my experience, slideshows don't benefit that much from VFR.

I'm saying at low bitrates , small changes can result in large % differences. You could have used a smaller container and shaved of another 2-3%. Those types of things are negligible at "normal" bitrates. It's very "dicey" testing such low bitrates

Ah, that clarifies it.


Anyway, since I've done so many friggin' tests on that Touhou cartoon sample in a short amount of time, I was curious how much it would benefit from VFR since exactly 2600 out of 5000 of its frames are duplicates. I was also curious how other codecs might benefit from VFR. Note that I didn't include the timecodes for Xvid and Mpeg-1 encodes.
The percentages are the bitrates saved for the same SSIM+ score to its CFR counterpart.

x265 @ 5,439 KB (209 kb/s) 15%
x264 @ 7,185 KB (301 kb/s) 10%
XVID @ 29,560 KB (1134 kb/s) 35%
MPG1 @ 28,734 KB (1102 kb/s) 18% [FFmpeg]
MPG1 @ 52,674 KB (2018 kb/s) 53% [TMPGenc]

Interesting that x265 benefits more than x264, not surprising that Xvid benefits greatly and I included TMPGenc's implementation of mpeg-1 because it incidentally saved the exact amount of bitrate as the frames, showing just how inefficient VCD-compliant MPEG-1 really is. It's probably the GOP.

[Selur]

exactly 2600 out of 5000 of its frames are duplicates.

duplicates = really identical, or just really similar (below a given threshold)?

[-Habanero-]

exactly 2600 out of 5000 of its frames are duplicates.

duplicates = really identical, or just really similar (below a given threshold)?

Sorry, not exact duplicates. But I've done a test on exact duplicates in this thread too.

[Selur]

Sorry, not exact duplicates. But I've done a test on exact duplicates in this thread too.

Okay, then I'm out. (not starting to read all 110 posts)

[-Habanero-]

Sorry, not exact duplicates. But I've done a test on exact duplicates in this thread too.

Okay, then I'm out. (not starting to read all 110 posts)

It's on this page... just scroll up.

[-Habanero-]

And getting back to my psychovisuals experiment. I used the same source (Resident evil trailer).

At 3 Mb/s the encode with --psy enabled did artificially make the statue of liberty look sharper. The contours were visibly more pronounced. However, the benefits were mitigated by areas that looked worse than the one without psychovisuals. For example, one prominent crack in the statue was completely smeared in the psy version while only slightly washed out in the --no-psy one.

At 4 Mb/s both encodes looked visually flawless. Upon close inspection, areas in the psy version were artificially distorted but on a much smaller level. Some very minute details that were smeared in --no-psy looked more pronounced in --psy. Edges and other areas had slightly more noise than the original.

Basically, all the expected behavior of psy happened in the high bitrate encode but on a much reduced level. Some areas looked better, some worse. I really can't tell which one is higher quality.

According to SSIM+ the psy is ~20% worse quality, the same difference as before. This bothers me, because they are indistinguishable.

My personal verdict is that --psy is either worse or useless. Not even gonna try it on a cartoon source, as I'm convinced it will perform even worse there.