Variable FrameRate

[Lazare Londaridze]

Hello, can anyone please explain what Variable framerate means? I'm working with an animation and should I set VFR to something specific when exporting ?
Also does the MkvToMp4 converter loss less converting ? I don't want to loose any video quality ( I don't care about the adudio ) .
Please help ..

[jagabo]

It means the frame rate of the video varies. Different frames are displayed for different amounts of time. This can be useful with animations because some shots may have motion at 24 fps, while others only have motion at 12 fps (or some other rate). In a constant frame rate encoding you have to encode both types of shots at 24 fps. In a VFR encoding you can switch between 24 fps and 12 fps (or other frame rate). That can give you slightly better compression.

MkvToMp4 has no ability to reencode the video, all it can do is remux the existing compressed video stream into the new container. It can optionally reencode the audio though.

[Lazare Londaridze]

In Premiere pro when exporting under " basic video settings" there is something called level, is that where you change VFR ? If not what it is then. And thanks you for your reply

[jagabo]

I don't use Premiere Pro but that setting doesn't sound like it has to do with frame rates.

[Cornucopia]

"Friends don't let friends use VFR".

There are no bitrate saving benefits to using vfr that cannot just as easily be gotten by well-tuned vbr (probably more). As I have said before, the only justified use for vfr is in low light camera capture (as exposure is influenced by shutter speed, which is related to framerate).

I'm guessing the levels adjustment you see in Premiere is referring to mpeg's avc profiles/levels options, which relates to complexity of encoding & decoder compatibility.

Scott

[johnmeyer]

Actually, the main use of variable frame rate is for streaming. You see it all the time. Available bandwidth in a streaming connection changes from second to second. In order to maintain an image that matches the audio, frames are dropped. A dropped frame is, basically, variable frame rate.

[El Heggunte]

Actually, the main use of variable frame rate is for streaming. You see it all the time. Available bandwidth in a streaming connection changes from second to second. In order to maintain an image that matches the audio, frames are dropped. A dropped frame is, basically, variable frame rate.

Very true. Both RealVideo and µ$oft's "Active" Streaming Format chose dropped frames as a form of bitrate control...

[flashandpan007]

"Friends don't let friends use VFR".

Couldn't have said it better. Keep away from VFR.

[Cornucopia]

Actually, the main use of variable frame rate is for streaming. You see it all the time. Available bandwidth in a streaming connection changes from second to second. In order to maintain an image that matches the audio, frames are dropped. A dropped frame is, basically, variable frame rate.

That is the symptom of bad buffering/low bandwidth and the need to maintain a/v sync, not the cause/intention. And again, smart vbr would do a better job.

Scott

[-Habanero-]

"Friends don't let friends use VFR".

There are no bitrate saving benefits to using vfr that cannot just as easily be gotten by well-tuned vbr (probably more). As I have said before, the only justified use for vfr is in low light camera capture (as exposure is influenced by shutter speed, which is related to framerate).

Don't spread bullshit, removing duplicate frames has huge bitrate saving benefits.

[Cornucopia]

You clearly don't understand the idea behind interframe compression!

Scott

[-Habanero-]

You clearly don't understand the idea behind interframe compression!

Scott

You clearly have never done a serious test to establish this. I have, and I got 50% more compression for half the frames removed, all which were duplicates.

I used maximum settings in x264 too in case you're gonna retort with predictable accusations.

[hello_hello]

I can see a justification for VFR when re-encoding video where the "underlying" frame rate changes. By "underlying" I'm referring to the original frame rate of the source. NTSC that's a mixture of progressive 23.976fps or progressive/interlaced 29.970fps, for example. VFR would have to be better than converting to a common frame rate, at least some of the time.

I'd tend to agree with Cornucopia in respect to the removal of duplicate frames not causing a huge bitrate reduction, but it might depend on the encoding method used and if removing the duplicate frames changes the frame rate or the duration.
I've got some small sample encodes here from the same source but de-interlaced differently. 25fps and 50fps. The resulting bitrates using the same encoder settings (CRF18) were 1677kbps and 1912kbps, but even though the 50fps version has double the number of frames, each one is generally not an exact duplicate of the proceeding frame. Constant quantizer rather than CRF mode would probably be a different story.

Part of it might be due to the x264 encoder being frame rate aware. I don't know how it works exactly, but if you encode a 24fps video at 24fps, then again after speeding it up to 25fps, the 25fps encode will have a slightly lower bitrate at the same CRF value. (Edit: The difference would be file size, not necessarily bitrate. See my next post).

Anyway, I'm curious now, so I'll run some test encodes later and report back.

[pandy]

There is second story behind VFR - jitter due poor acquisition (crappy software, slow HW etc) - such video have no benefits at all, this is most common video nowadays, produced by various mobile devices... There is huge difference between decimating (discarding) frames from video where there is no delta between frames (video is captured as CFR then later frames are discarded trough analysis) vs video where every frame code difference but they are captured in random time intervals... Side to this except variable sync displays (G Sync etc) rest of signal path is quite strictly CFR.

[hello_hello]

Anyway, I'm curious now, so I'll run some test encodes later and report back.

A random 15 minutes of video from a TV drama at 720p (resized from 1080p). For the first encode it's at the original frame rate of 25fps, while for the second I told ffms2 to output 50fps, which means it'll duplicate every frame. Twice the number of frames. Same duration.
Third encode.... as MeGUI normally sets -keyint to 10x the frame rate, it means the maximum gop size changes. ie -keyint 250 for 25fps and -keyint 500 for 50fps... and as the gop size can effect compressibility the I ran a third encode while keeping -keyint at 250.
Aside from the -keyint change, the x264 settings used each time were Preset Slow, Tune Film, CRF 18. The frame numbers used for Trim() are different at 50fps as there's twice the number of frames, but exactly the same section of video was encoded each time.

Encode 1 (25fps, -keyint 250), bitrate 3178kbps
FFVideoSource("E:\video.mkv", threads=1)
Spline36Resize(1280,720)
Trim(36000,58500)

Encode 2 (duplicated frames for 50fps - keyint 500), bitrate 3141kbps
FFVideoSource("E:\video.mkv", fpsnum=50, fpsden=1, threads=1)
Spline36Resize(1280,720)
Trim(72000,117000)

Encode 3 (duplicated frames for 50fps - keyint 250), bitrate 3180kbps
FFVideoSource("E:\video.mkv", fpsnum=50, fpsden=1, threads=1)
Spline36Resize(1280,720)
Trim(72000,117000)

I expected duplicating every frame would increase the bitrate at least a little bit, but apparently not. I'll confess though, if the bitrate remains the same, and assuming the duplicate frames take "some" bitrate to encode, even if very little, I'm having a hard time understanding why the quality of the 50fps encode wouldn't be lower. Maybe I'm not looking at it the right way.

While I was at it, one more test at 50fps, but this time by speeding up the video rather than duplicating frames (so the duration halved). I was curious to see what effect speeding it up would have on bitrate. Not that it's the sort of thing you'd generally do in practice, but just to see....

Encode 4 (sped up to 50fps - keyint 250), bitrate 4033kbps
FFVideoSource("E:\video.mkv", threads=1)
AssumeFPS(50,1)
Spline36Resize(1280,720)
Trim(36000,58500)

I scratched by head over the last encode, thinking encoding the same number of frames at a higher frame rate should reduce the bitrate. I checked encoder settings with MediaInfo and I checked log files, trying to explain why the bitrate increased, until the penny finally dropped.

Encode 1, 25fps, 22501 frames, bitrate 3178kbps, duration 15 minutes, file size 341MB
Encode 4, 50fps, 22501 frames, bitrate 4013kbps, duration 7.5 minutes, file size 216MB

So in my previous post when I said speeding up a 24fps video to 25fps would reduce the bitrate, that was probably wrong. The bitrate could remain the same, or possibly even increase a little, but because the frame rate increases it means the duration decreases and if the bitrate remains the same, the file size would therefore decrease. I guess when I originally compared encoding a video at 24fps and 25fps, I looked at the resulting file sizes and when I saw the file size for the 25fps encode was slightly smaller I assumed the bitrate was lower because I'm an idiot.

[jagabo]

I ran tests with x264 (using 16 reference frames and 16 bframes, where VFR should matter most) and high quality animated material where I made sure duplicate frames were exact duplicates using Dup() in AviSynth. Indeed, x264 produced much smaller files when encoding with VFR. But when I looked more closely, the VFR video was encoded with higher average quantizers, ie, lower quality per frame. When I reencoded the CFR version to match the higher average quantizers there was a much smaller difference in size. As I'm not really interested in VFR encoding I didn't pursue it further.

Note that x264 is indeed frame rate aware and uses lower average quantizers with higher frame rate material. I guess the assumption is you will not notice a little more quality loss when frames are displayed for shorter periods of time. But the above result with VFR, higher quantizers with lower frame rates of VFR, seems counter intuitive.

[El Heggunte]

Just my humble opinion:

as long as there are no Variable-Refresh-Rate monitors and TVs,
VFR video remains essentially pointless.

[poisondeathray]

Part of it might be due to the x264 encoder being frame rate aware. I don't know how it works exactly, but if you encode a 24fps video at 24fps, then again after speeding it up to 25fps, the 25fps encode will have a slightly lower bitrate at the same CRF value.

It is frame rate aware - the avg quantizer increases the higher the framerate

(Edit: The difference would be file size, not necessarily bitrate. See my next post).

But filesize is directly proportional to bitrate . So it has to be necessarily bitrate. Filesize = bitrate * running time



If there are claims of "bitrate savings", you need to include a control measurement for an endpoint "quality" . Typically SSIM or PSNR because they are objective and easily repeatable . ie. At a given SSIM or PSNR, what is the filesize. You can have a shitty encode using a shitty encoder and reduce the filesize (by reducing the bitrate) - is that a bitrate savings ? Technically Yes. But that's typically not what we really are really wanting to know about. The real question people are interested in is at roughly the same "quality" (however you want to define that) , what are the bitrate savings? And that would be for any type of compression test, whether it be VFR vs. CFR, HEVC vs. AVC etc...

So runs of CFR encodes and VFR encodes would be done, compared at the same SSIM or PSNR . Per frame curves have to be plotted compared because you have to ensure no large deviations occur (If you just have 1 average number, there might be large deviations, such as very poor quality in some scenes)

And it is problematic, because objective tests like SSIM, PSNR don't necessarily correlate perfectly with human visual perception. Also, they don't take into account higher frame rates. eg. If you have 120FPS footage, you're not going to see fine detail differences per frame than 12 FPS . SSIM and PSNR measure per frame, mathematically. But 120FPS whipping by is difficult to see differences for humans

[jagabo]

(Edit: The difference would be file size, not necessarily bitrate. See my next post).

But filesize is directly proportional to bitrate . So it has to be necessarily bitrate. Filesize = bitrate * running time

Not in the case he was describing -- doubling the frame rate and reducing the runtime by half. Ie, using AssumeFPS(framerate*2).

[poisondeathray]

(Edit: The difference would be file size, not necessarily bitrate. See my next post).

But filesize is directly proportional to bitrate . So it has to be necessarily bitrate. Filesize = bitrate * running time

Not in the case he was describing -- doubling the frame rate and reducing the runtime by half. Ie, using AssumeFPS(framerate*2).

My bad, sorry hello_hello I didn't read it clearly

[-Habanero-]

I refer anyone interested in bitrate benefits of VFR to TASvideos.org where they have established after numerous tests the clear advantage especially for their kind of material.

The core of it all is the fact that x264 has a limited number of frames it can reference, which is 16. Doubling the frame rate halves the amount of content it can reference. Certain content like classic video game footage benefits linearly from more refs so removing duplicates has a huge benefit. Same thing with animation. The more crudely animated, the better.
In all these cases, VFR is an obvious benefit.

[poisondeathray]

Yes - there is definitely a benefit on some types of content - but it's not as high as some people think, nor is it as low as some people think. Maybe there are some new test published, but most of the tests you see are not conducted properly, critical flaws in assumptions like CRF as a measure of "quality", or important factors like actually measuring quality were not done. It's difficult and very time consuming to do proper, comprehensive testing

[-Habanero-]

That is true. I did do what I believe were proper tests but good luck if I could find it in the mountain of logs. The general conclusion was that it is a good idea that reduces the bitrate between 10-40% without much hassle. But knowing how many clueless derpsters there are out there, I can see why this has potential to cause huge problems when not done correctly, especially if people try to edit the video after already converting to VFR. I did this and it took an hour just to edit 600 frames because of how careful I was not to screw up the frame ordering in the process. Who would spend an hour doing something as petty as this? Nobody but a bigger f*cking idiot like me.

[hello_hello]

-Habanero-,
Could I ask what process you use to encode video as VFR?

Here's a quick test I tried, never having considered the possibility of doing this before, so maybe that's why I couldn't get ExactDedup to work, but I managed to get my head around DeDup. I ran out of time to do much more today but I encoded 5001 frames of animation like this with the default x264 settings:

LSMASHVideoSource("E:\video.mp4")
Trim(0,5000)

x264 said it encoded 5001 frames and the bitrate was 357kbps.

Next I used Dedup to create a log file then encoded the video like this:

LSMASHVideoSource("E:\video.mp4")
Trim(0,5000)
DeDup(log="dup.txt", times="times.txt", maxcopies=10, maxdrops=10, decwhich=0)

When it was done x264 said it encoded 3486 frames and the bitrate was 452kbps. That's a bit deceiving though because DeDup was outputting a constant 23.976 even though it had removed a bunch of frames. You'd need to use the timecodes file DeDup created for muxing the output for the correct VFR result. Without that though, the video duration was reduced from 3.5 minutes to around 2.5 minutes, so even though the bitrate appeared to increase the file size was reduced (7.8MB vs 8.9MB when encoding all the frames).

None of the instructions I found suggested doing so, but I ran a third encode, this time giving the x264 encoder the timecodes file to play with so it'd know the frame rate is variable. I added "--tcfile-in times.txt" to the x264 command line and deleted it from the script.

LSMASHVideoSource("E:\video.mp4")
Trim(0,5000)
DeDup(log="dup.txt, maxcopies=10, maxdrops=10, decwhich=0)

Once again x264 reported encoding 3486 frames but this time the bitrate was 352kbps and the file size was only slightly less than the first encode (8.7MB vs 8.9MB)

That's obviously a very rough test, but it seems to indicate when the x264 encoder knows the video is variable frame rate, for a given CRF value it'll use roughly the same number of bits over a given duration as it would if the video was constant frame rate containing duplicate frames.

I should mention when I checked the dup.txt file created by DeDup, there wasn't a single frame reported as being an exact duplicate. I used the default setting, which is for DeDup to consider a frame a duplicate if the difference is 0.3% or less (I think). When I stepped through the frames manually it seemed to be getting it right, but I mention that as it occurred to me small differences between frames that are really duplicates would probably be due to noise or encoder artefacts etc, and when the duplicates aren't removed the differences increase the bitrate a little. Removing the duplicate frames would give VFR encoding a slight edge if that theory has merit. My source was a SD encode intended for an ipad that I'd recently encoded using a HD source, so it wasn't pristine.

I don't know what to make of all that yet in respect to quality, but I thought I'd add this from the log file.

Encoding all the frames:
---[Information] [26/07/16 4:01:23 PM] x264 [info]: frame I:67 Avg QP:16.92 size: 33601
---[Information] [26/07/16 4:01:23 PM] x264 [info]: frame P:1421 Avg QP:19.87 size: 3459
---[Information] [26/07/16 4:01:23 PM] x264 [info]: frame B:3513 Avg QP:24.11 size: 608
---[Information] [26/07/16 4:01:23 PM] x264 [info]: consecutive B-frames: 2.9% 8.0% 6.6% 82.5%

Removing duplicates and encoding at 23.976fps:
---[Information] [26/07/16 4:03:52 PM] x264 [info]: frame I:64 Avg QP:17.87 size: 30814
---[Information] [26/07/16 4:03:52 PM] x264 [info]: frame P:1025 Avg QP:20.97 size: 3896
---[Information] [26/07/16 4:03:52 PM] x264 [info]: frame B:2397 Avg QP:25.37 size: 941
---[Information] [26/07/16 4:03:52 PM] x264 [info]: consecutive B-frames: 4.4% 9.2% 7.7% 78.7%

Removing duplicates and encoding as VFR:
---[Information] [26/07/16 4:06:14 PM] x264 [info]: frame I:64 Avg QP:16.83 size: 33224
---[Information] [26/07/16 4:06:14 PM] x264 [info]: frame P:1025 Avg QP:19.88 size: 4455
---[Information] [26/07/16 4:06:14 PM] x264 [info]: frame B:2397 Avg QP:24.44 size: 1038
---[Information] [26/07/16 4:06:14 PM] x264 [info]: consecutive B-frames: 4.4% 9.2% 7.7% 78.7%

There were exactly the same number of I, P and B frames after the duplicates were removed, whether encoded at a constant or variable frame rate. The main difference seems to be the average quantizer for each type was a bit lower when the encoder knew the video was VFR.
I can't quite get my head around comparing number three (VFR encode) with number one (duplicates encoded). The average quantizer for each type of frame is almost identical, and so was the final bitrate, but for the first encode there were more frames, even if they were duplicates. I might need someone to explain that to me.....

[-Habanero-]

I encode the video normally after passing everything thru Dedup and then mux everything with MKVtoolnix including the times.txt.

Your test is ok but I might suggest leaving the framerate as it is after deduplicating when using CRF. x264 encodes with different quantizers depending on the FPS. The higher the fps, the higher the quantizers it will use at the same CRF. If you keep the FPS the same despite removing duplicates, you essentially have a sped-up video which x264 will treat as such where you won't notice compression defects. Since you won't be watching it at that speed once you mux it with its timecodes, it's best to leave it.

A quality control is also good, say SSIM but this is useless for a noisy video.

[hello_hello]

For anyone interested I ran some more test encodes. Not to necessarily advocate using a variable frame rate, but just to see. The source was animation at 720p (a random South Park episode), duration 21:44.
As well as repeating test encodes much the same as yesterday, I added one using the Dup plugin. For those who don't know, the purpose of Dup is to detect duplicate frames, but rather than remove them for a VFR output, it copies one frame and replaces the rest of the duplicates with that copy. If the duplicates aren't quite the same due to noise, making them all the same should improve compression.
DeDup was used again to remove the duplicate frames. It's based on Dup and I used the same parameters so with any luck it should have detected the same frames as duplicates. I can't say I checked that particularly thoroughly though.
I also added another encode into the mix. I used Dedup to remove the duplicate frames but instead of encoding at the original constant frame rate (23.976) I used the required frame rate for the duration to remain the same. In this case it was 19.19fps. I wanted to see if encoding at the original duration would make a difference.

For the first four encodes MeGUI used the following command line.
--level 4.1 --preset slower --tune animation --crf 18.0 --vbv-bufsize 78125 --vbv-maxrate 62500
Preset Slower and Tune Animation would normally result in --ref 16, but Level 4.1 limits --ref to 9 for 720p.
The fifth encode included the following in the command line so x264 could encode as VFR.
--tcfile-in times.txt

The results:
Encode 1, no duplicate frame filtering, total frames 31287, 1452.05 kb/s, 226.1MB
Encode 2, duplicate frames replaced by Dup, total frames 31287, 1396.27 kb/s, 217.4MB
Encode 3, duplicate frames removed by DeDup, total frames 25042, 1669.51 kb/s, 208.1MB (encoded at a constant 23.976fps)
Encode 4, duplicate frames removed by DeDup, total frames 25042, 1481.15 kb/s, 230.5MB (encoded at a constant 19.19fps)
Encode 5, duplicate frames removed by DeDup, total frames 25042, 1440.09 kb/s, 224.2MB (encoded at a variable frame rate)

Conclusion:
Maybe someone more clever than me can look at the statistics and offer some theories in respect to quality, but the results today seem pretty much the same as yesterday.
For a given CRF value, if you encode a video at the original constant frame rate after removing duplicate frames, then use a timecodes file when muxing to convert it to variable frame rate, the encoder won't use as many bits over-all (although it'll report a higher bitrate due to the reduced duration), and the file size will be reduced a little, but so will the quality.
If you encode as variable frame rate after removing duplicate frames, there appears to be no bitrate saving compared to keeping the duplicates and encoding at a constant frame rate.
Of course the above applies to x264 which is obviously VFR aware and has a constant quality encoding mode. The result may differ using other encoders.

I had one more thought relating to particularly noisy video. If there's a fair difference between frames that would otherwise be duplicates due to noise (visible grain etc) and you replaced the duplicates with exact copies or removed them and encoded as VFR, that could potentially result in a less pleasing output because the noise might appear to be noise for a bit, then suddenly it's static, then it'd move as noise does, then static.... if that was noticable I'd rather keep the noisy duplicates.
For the same reason, replacing duplicate frames with copies might reduce the effectiveness of noise filtering quite a bit. Even removing them completely might reduce the effectiveness of a noise filter. Maybe it'd sometimes pay to noise filter first?

For anyone interested, and understands the statistics better than I do:

Encode 1, no duplicate frame filtering:
frame I:295 Avg QP:12.21 size:138912
frame P:8454 Avg QP:15.03 size: 18000
frame B:22538 Avg QP:21.50 size: 1939
consecutive B-frames: 2.8% 4.8% 8.0% 69.8% 7.3% 7.4%
mb I I16..4: 14.4% 48.7% 36.9%
mb P I16..4: 1.4% 2.6% 0.7% P16..4: 29.0% 7.3% 5.9% 0.2% 0.1% skip:52.8%
mb B I16..4: 0.1% 0.1% 0.1% B16..8: 17.1% 1.3% 0.3% direct: 0.5% skip:80.5% L0:35.5% L1:61.1% BI: 3.4%
8x8 transform intra:51.7% inter:39.5%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 58.4% 67.6% 51.5% inter: 5.1% 7.3% 1.9%
i16 v,h,dc,p: 46% 31% 13% 10%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 14% 35% 5% 6% 6% 7% 6% 10%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 21% 15% 7% 8% 7% 8% 6% 10%
i8c dc,h,v,p: 47% 29% 19% 5%
Weighted P-Frames: Y:1.2% UV:0.8%
ref P L0: 67.1% 3.9% 13.6% 5.2% 3.9% 2.3% 1.9% 1.0% 1.0% 0.1% 0.0%
ref B L0: 80.5% 10.9% 4.5% 1.9% 0.9% 0.7% 0.5% 0.2%
ref B L1: 91.9% 8.1%
kb/s:1452.04

Encode 2, duplicate frames replaced by Dup:
frame I:295 Avg QP:11.80 size:140748
frame P:7573 Avg QP:15.03 size: 18984
frame B:23419 Avg QP:21.35 size: 1813
consecutive B-frames: 2.1% 4.0% 6.1% 48.0% 10.4% 29.3%
mb I I16..4: 13.8% 48.1% 38.0%
mb P I16..4: 1.5% 2.8% 0.7% P16..4: 28.8% 7.6% 6.1% 0.3% 0.1% skip:52.1%
mb B I16..4: 0.1% 0.1% 0.1% B16..8: 14.9% 1.2% 0.3% direct: 0.5% skip:82.8% L0:40.0% L1:56.3% BI: 3.7%
8x8 transform intra:51.4% inter:38.3%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 58.7% 67.9% 51.6% inter: 4.8% 6.7% 1.8%
i16 v,h,dc,p: 46% 31% 13% 10%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 35% 5% 6% 6% 7% 6% 10%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 21% 14% 7% 8% 6% 8% 6% 10%
i8c dc,h,v,p: 47% 29% 19% 5%
Weighted P-Frames: Y:1.3% UV:0.9%
ref P L0: 66.7% 4.0% 13.5% 5.2% 4.0% 2.4% 2.0% 1.1% 1.1% 0.1% 0.0%
ref B L0: 81.7% 10.1% 4.1% 1.7% 0.9% 0.7% 0.5% 0.2%
ref B L1: 92.3% 7.7%
kb/s:1396.27

Encode 3, duplicate frames removed by DeDup, encoded at 23.976fps:
frame I:286 Avg QP:12.63 size:134917
frame P:6870 Avg QP:15.60 size: 19723
frame B:17886 Avg QP:21.93 size: 2453
consecutive B-frames: 3.2% 5.4% 11.7% 62.0% 10.1% 7.7%
mb I I16..4: 14.2% 49.4% 36.4%
mb P I16..4: 1.6% 3.0% 0.8% P16..4: 31.3% 8.1% 6.3% 0.3% 0.1% skip:48.5%
mb B I16..4: 0.1% 0.1% 0.1% B16..8: 19.2% 1.7% 0.4% direct: 0.7% skip:77.7% L0:38.5% L1:57.6% BI: 3.8%
8x8 transform intra:51.2% inter:39.9%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 57.3% 67.6% 50.8% inter: 5.8% 8.4% 2.1%
i16 v,h,dc,p: 45% 32% 13% 10%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 35% 5% 6% 6% 7% 6% 10%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 21% 15% 6% 8% 6% 8% 6% 10%
i8c dc,h,v,p: 47% 29% 19% 5%
Weighted P-Frames: Y:1.5% UV:1.0%
ref P L0: 66.1% 4.1% 13.9% 5.1% 3.9% 2.4% 2.1% 1.1% 1.2% 0.1% 0.0%
ref B L0: 80.1% 10.9% 4.6% 1.9% 1.0% 0.8% 0.5% 0.3%
ref B L1: 93.2% 6.8%
kb/s:1669.50

Encode 4, duplicate frames removed by DeDup, encoded at 19.19fps:
frame I:286 Avg QP:11.86 size:142396
frame P:6870 Avg QP:14.83 size: 21892
frame B:17886 Avg QP:20.96 size: 2720
consecutive B-frames: 3.2% 5.4% 11.7% 62.0% 10.1% 7.7%
mb I I16..4: 13.8% 49.2% 37.0%
mb P I16..4: 1.6% 3.2% 0.8% P16..4: 31.6% 8.8% 6.9% 0.3% 0.1% skip:46.6%
mb B I16..4: 0.2% 0.2% 0.1% B16..8: 20.5% 1.8% 0.5% direct: 0.8% skip:76.1% L0:39.3% L1:56.8% BI: 3.9%
8x8 transform intra:52.3% inter:40.5%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 59.4% 68.3% 52.7% inter: 6.4% 8.9% 2.4%
i16 v,h,dc,p: 46% 31% 13% 10%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 14% 35% 6% 6% 6% 7% 6% 10%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 21% 15% 7% 8% 7% 8% 6% 10%
i8c dc,h,v,p: 47% 29% 19% 5%
Weighted P-Frames: Y:1.5% UV:1.0%
ref P L0: 66.9% 4.0% 13.9% 5.1% 3.8% 2.2% 1.9% 1.0% 1.1% 0.1% 0.0%
ref B L0: 79.7% 11.4% 4.6% 1.9% 1.0% 0.7% 0.5% 0.2%
ref B L1: 93.3% 6.7%
kb/s:1469.95

Encode 5, duplicate frames removed by DeDup, encoded as VFR:
automatic timebase generation 1001/24000
frame I:286 Avg QP:11.67 size:144360
frame P:6870 Avg QP:14.95 size: 21655
frame B:17886 Avg QP:21.69 size: 2507
consecutive B-frames: 3.2% 5.4% 11.7% 62.0% 10.1% 7.7%
mb I I16..4: 14.2% 48.7% 37.1%
mb P I16..4: 1.7% 3.2% 0.8% P16..4: 31.6% 8.5% 6.9% 0.3% 0.1% skip:46.8%
mb B I16..4: 0.1% 0.1% 0.1% B16..8: 19.8% 1.7% 0.4% direct: 0.7% skip:77.0% L0:39.0% L1:57.2% BI: 3.8%
8x8 transform intra:51.5% inter:39.0%
direct mvs spatial:100.0% temporal:0.0%
coded y,uvDC,uvAC intra: 58.7% 67.7% 51.7% inter: 6.3% 8.7% 2.3%
i16 v,h,dc,p: 46% 31% 13% 10%
i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 14% 35% 6% 6% 6% 7% 6% 10%
i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 21% 15% 7% 8% 7% 8% 6% 10%
i8c dc,h,v,p: 47% 29% 19% 5%
Weighted P-Frames: Y:1.5% UV:1.0%
ref P L0: 67.3% 4.0% 13.6% 5.0% 3.7% 2.2% 1.9% 1.1% 1.1% 0.1% 0.0%
ref B L0: 80.4% 11.0% 4.4% 1.8% 0.9% 0.7% 0.5% 0.2%
ref B L1: 93.3% 6.7%
kb/s:1440.09

[hello_hello]

Your test is ok but I might suggest leaving the framerate as it is after deduplicating when using CRF.

I submitted my last post with today's more comprehensive test before reading yours, but I didn't touch the frame rate when using DeDup yesterday. I just reported the output frame rate. It seems DeDup doesn't change the frame rate when deleting duplicates, and if there's an option to get it to do so I've missed it.
I did have the same thought however, so this time I added an additional encode where DeDup removed the duplicates as usual, but I followed it with AssumeFPS() to decrease the frame rate so the duration was the same as the original (to within half a second). I had to work out the new frame rate myself though. I couldn't find a way to do it automatically.

[poisondeathray]

Conclusion:
Unless someone more clever than me can look at the statistics and explain otherwise in respect to quality, the result today seems to be pretty much the same as yesterday.
For a given CRF value, if you encode a video at the original constant frame rate after removing duplicate frames, then use a timecodes file when muxing to convert it to variable frame rate, the encoder won't use as many bits over-all (although it'll report a higher bitrate due to the reduced duration), and the file size will be reduced a little, but so will the quality.
If you encode as variable frame rate after removing duplicate frames, there appears to be no bitrate saving compared to keeping the duplicate frames and encoding at a constant frame rate.
Of curse the above applies to x264 which is obviously VFR aware and has a constant quality encoding mode. The result may differ using other encoders.

Thanks for sharing those tests, hello_hello

"Bitrate savings" in the absence of some sort of quality assessment isn't very useful. This is an extreme - But I could use a mpeg2 encoder at lower bitrates and that would be a "bitrate savings" if we didn't look at quality. That is what is implied by "bitrate savings" - same quality , but smaller filesize

You cannot conclude anything about "quality" from those observations because "quality" was never assessed. Yes, avg frame QP's are inversely proportional , frame sizes and bitrate are proportional to quality, but those are just trends .

A common assumption people make is they think CRF equals some level of constant quality. It's just a rough approximation. All it truly is - it's just a method of rate control. Yes, there is an inverse relationship with quality , but that's it. As soon as the source changes (such as VFR vs. CFR framecounts, or --fps because x264 is frame rate aware), or any settings change, it's no longer valid to use a "quality" approximation

When using x264 adding --psnr --ssim and it will give you rough metrics (not per frame metrics) . But at least it will give you some measurements as to average I,B,P and total values. Then at least you can say something valid about quality (at least compared to the specific source used, not necessarily VFR vs CFR). Some people don't like using it because it may be biased (ie. you should use 3rd party tools), but more information is better than less information IMO , you just have to keep in mind where it's coming from.

Besides the quality measuring and matching issues - It's difficult to test VFR properly with proper per frame testing and curves, because you have a CFR stream with the same number of frames as source, but a VFR stream with fewer frames. When testing against the source, you can either (A) decimate the CFR stream and source using the same decimation method (otherwise you can get mismatched up frames) to compare with the VFR runs , or (B) add duplicates to the VFR stream (ie. convert the VFR to CFR) . But the 2nd method isn't exact and sometimes frames are "roughly" in the same position and don't always align perfectly, so that will penalize any measurements of VFR encodes unless they do happen to align perfectly (almost never). So the 2nd method usually isn't used. But the 1st method is problematic too, because you're not comparing against the "true" source. You're only comparing the remaining frames in the VFR encode. If the VFR decimation was accurate and only "true" duplicates were dropped, in a sense, that yields "better" quality because you don't get fluctuations during duplicates. e.g. If I have a completely source static scene, I,B,P fluctuations will cause the frame quality to fluctuate. For example, poor encoders will have "keyframe popping" and other temporal compression issues. But if that was in the source, that's what the objective measure tests against. ie. The job of the encoder is to emulate the source, even if there were artifacts and garbage

But thanks sharing for those test runs, and it does really take a lot of time and many encodes to do proper testing. If , at the same dB (and you have to check the entire curve, because large deviations can average out an "average" dB) that someone finds a VFR encode is smaller in filesize than it's CFR counter part - only then you can safely say there is "x" bitrate savings at the same quality

[Cornucopia]

Vfr will still have a quality penalty, because all past & current displays accept only cfr (and only a very small subset of valid rates), so at the end of the playback chain it MUST be converted again to cfr anyway.

And then there is the not insignificant problem of motion aliasing mentioned by pandy...

Scott

[poisondeathray]

Vfr will still have a quality penalty, because all past & current displays accept only cfr (and only a very small subset of valid rates), so at the end of the playback chain it MUST be converted again to cfr anyway.

VFR will look the same on a display as it's CFR counterpart, if the VFR was done correctly (ie. if only "true" duplicates were decimated) . In a sense, VFR will look "better" because there won't be IPB fluctuations on static frames. Each "hold" frame will be the same quality because it is 1 frame.

e.g 60Hz display . a 12FPS content section will show 5 repeats in a row per second using CFR. Both VFR and CFR will look the same. Physically,the CFR stream will have a 24FPS stream (12 FPS , each with it's hardcoded duplicate) . Instead of coding for those physical duplicates, VFR only codes those 12 unique frames, but each unique frame is displayed for twice as long on the screen





@hello_hello
So typically what is done to make testing easier, is a bunch of assumptions are made. You test against it's immediate source (VFR against the VFR frames, CFR against the CFR frames) . The assumption is you're checking unique frame quality, and decimation with VFR was done correctly. The truth is, it's not always done correctly. Sometimes "good" frames are dropped. I always try to check the full per frame curves, but if those are ok (no large deviations, no problem areas), you can get a total average PSNR or SSIM value for the entire video . So you if you wanted to , you can still use CRF, but vary the CRF. e.g. CRF 14,15,16,17,18 . Then you can make a plot of resulting dB from actual bitrate (or filesize if you want) . Most comparisons use 2pass for encoding to control the bitrate (makes plots look "nicer" ). Plots make it easier to see and compare the CFR vs VFR bitrate required to achieve a certain dB