Kodi Community Forum

Never heard about videos with a variable framerate. Why should this be used?

many H265 releases are, unfortunately, with VFR

regarding to this: http://trac.kodi.tv/ticket/12012 it should work even if I dont have a clue how.
If I think about my TV, which needs approx 5 seconds to change the FPS, I dont understand how this can be work without problems.

(2015-12-14, 13:11)HCarvalho Wrote: [ -> ]many H265 releases are, unfortunately, with VFR

Variable frame rate or variable BIT rate? If you meant frame rate, what kind of file or video would want to do that? Seems like that is just asking to have problems on just about any playback device currently out there.

EDIT - I looked at your link and see you do mean variable frame rate. I didnt check the file, but I cannot imagine any movie coming out using a file like that, so my interest is minimal and I will bow out of that conversation.

From what I discovered earlier over in the WeTek Core thread:

Ok I've done a bit of reading, this is from your (HCarvalho's) Mediacodec info (H265):

Quote:Display aspect ratio : 2.40:1
Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps

Its actually a VFR (Variable Frame Rate). Not VBR. A bunch of encoders have been warning against encoding like this to prevent playback compatibility problems exactly like you have found.

Handbrake, which has been used to encode this H265, apparently foolishly defaults to VFR when encoding. Change it to a Constant Frame Rate otherwise it will be not just the Core that will have playback problems but other media players as well.

Whatever idiot is encoding this VFR H265 stuff in not taking enough care and just leaving Handbrake on default settings. Why you would want VFR complications in a highly compressed codec like H265 is beyond me and just leads to playback complications like we are finding. It would also likely lead to increased encoding times that are already in the order of 24-48 hours for a BD ISO Rip.

(2015-12-15, 05:52)wrxtasy Wrote: [ -> ]Whatever idiot is encoding this VFR H265 stuff in not taking enough care and just leaving Handbrake on default settings. Why you would want VFR complications in a highly compressed codec like H265 is beyond me and just leads to playback complications like we are finding. It would also likely lead to increased encoding times that are already in the order of 24-48 hours for a BD ISO Rip.

Actually, VFR is Handbrakes default setting.

It seems Kodi cannot even use all of its A57s for me. I plan to watch hi10p videos with it so I desperately wants more CPU power
The statistic OSD only shows CPU0 to CPU1, sometimes there is CPU2 but there is never CPU3

I am not sure if it is just the OSD saying bullshit
Because it was obviously stuttering when I tried software decoding 10bit HEVC, but the Kodi OSD told me there was zero frame drop and zero frame skip

(2015-12-15, 07:53)Tinwarble Wrote: [ -> ]

(2015-12-15, 05:52)wrxtasy Wrote: [ -> ]Whatever idiot is encoding this VFR H265 stuff in not taking enough care and just leaving Handbrake on default settings. Why you would want VFR complications in a highly compressed codec like H265 is beyond me and just leads to playback complications like we are finding. It would also likely lead to increased encoding times that are already in the order of 24-48 hours for a BD ISO Rip.

Actually, VFR is Handbrakes default setting.

have you got you glasses on T, you must have missed this bit...

(2015-12-15, 05:52)wrxtasy Wrote: [ -> ]Handbrake, which has been used to encode this H265, apparently foolishly defaults to VFR when encoding.

(2015-12-15, 09:13)wrxtasy Wrote: [ -> ]have you got you glasses on T, you must have missed this bit...

Yep, I have them on but their pretty dirty?

On the bright side, that makes me human and not some evil robot.

Your part of the Lollipop powered Android Army now !

(2015-12-15, 10:06)wrxtasy Wrote: [ -> ]Your part of the Lollipop powered Android Army now !

Almost apart of the Marshmallow powered. We're a squishy bunch!

What is more puzzling is that this file listed bellow as also VRF and I can play it on my wetek core, but this time i'm using a Samsung Led in my bedroom instead of my panasonic plasma in my media room.

Quote:General
Complete name : D:\Séries\A Mover\xxxxxxxxxxxxxxxx.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 725 MiB
Duration : 55mn 49s
Overall bit rate mode : Variable
Overall bit rate : 1 817 Kbps
Encoded date : UTC 2036-02-06 06:28:16
Tagged date : UTC 2036-02-06 06:28:16
Writing application : HandBrake 0.10.2 2015060900

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 55mn 49s
Bit rate : 1 651 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.033
Stream size : 659 MiB (91%)
Writing library : x265 1.5:[Windows][GCC 4.9.0][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=25 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=1 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=0.30 / psy-rdoq=1.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=23.6 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Encoded date : UTC 2036-02-06 06:28:16
Tagged date : UTC 2036-02-06 06:28:16
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : 40
Duration : 55mn 49s
Bit rate mode : Variable
Bit rate : 160 Kbps
Channel(s) : 2 channels
Channel(s)_Original : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Stream size : 63.9 MiB (9%)
Title : Surround / Surround
Language : English
Encoded date : UTC 2036-02-06 06:28:16
Tagged date : UTC 2036-02-06 06:28:16

Well, those Handbrake encoded VFR files aren't usually variable frame rate anyway. At least not in the since that the entire file is variable.

Usually what happens, and this only happens with some encodes, is that if VFR + "Same as source" is set it will cause only the first few seconds of the files to be something other than the source frame rate.

(2015-12-15, 09:13)wrxtasy Wrote: [ -> ]

(2015-12-15, 07:53)Tinwarble Wrote: [ -> ]

(2015-12-15, 05:52)wrxtasy Wrote: [ -> ]Whatever idiot is encoding this VFR H265 stuff in not taking enough care and just leaving Handbrake on default settings. Why you would want VFR complications in a highly compressed codec like H265 is beyond me and just leads to playback complications like we are finding. It would also likely lead to increased encoding times that are already in the order of 24-48 hours for a BD ISO Rip.

Actually, VFR is Handbrakes default setting.

have you got you glasses on T, you must have missed this bit...

(2015-12-15, 05:52)wrxtasy Wrote: [ -> ]Handbrake, which has been used to encode this H265, apparently foolishly defaults to VFR when encoding.

VFR has really little to do with compression rate
It is more about keep the original content in the format that it is supposed to be
If the original source is "VFR" in its nature, you have basically these choices:
1. Keep the video interlaced as the source. Most people probably do not want this because the quality of deinterlace in playback time is normally quite low, it also causes tons of trouble for config and hardware support.
2. Target one frame rate, ignore the other. This will make some part of the video choppy because frames are dropped.
3. Convert frame rate, normally through frame blending algorithm. This will result very bad picture quality and the process of frame rate conversion is not. reversible.
4. Makes everything 60p. This solution will waste a lot of bit rate. In addition, the playback of 60p is always much more demanding than the playback of 24p/30p.
5. VFR, which is neither harmful to video quality nor waste bit rate

Would VFR be used for streams that flip between i25 and p25 - like UK Freeview HD stuff which dynamically flips between p25 and i25 on a GOP-by-GOP basis at the encoder (not on a show-by-show basis)