{vf} Rounds Down?

[Draik]

I'm using OS X 10.11.5, Filebot 4.7.2 (4210)

On some certain files, the {hdi} expression produces "718p", while the {vf} expression produces "578p". SDHD also produces "SD" quality.



I would expect {vf} to round to the closest value (Up in this case)

vf: 720p
hpi: 718p
sdhd: HD

[rednoah]

{hdi} is height plus first letter of scanType.

{vf} is normalized to the next standard quality value and always "p" even if ScanType is interlaced (because people want it to say "720p" even if it's "720i").

{sdhd} will give you HD for videos where width >= 1280 and height >= 720.

[Draik]

{hdi} seems to be working properly to me. (I presented it to clarify the properties of the file)

Q1.
Are you saying that for something like the example above, where the height is 718, the appropriate {vf} value should be the next standard quality, which is "576p" in this case?
Pre-2014/2013, it used to go up to "720p". Can I achieve that again, if this is not perceived as a bug?

My current formula uses: {vf.match(/240[pP]|360[pP]|480[pP]|720[pP]|1080[pP]|2160[pP]/)+', '}
The result "576p" simply yields no result under this function at all. (My goal is to produce "720p")

Q2.
I understand why {sdhd} functions that way. Is there a way for me to make it more loose, for example, giving HD for width >= 1270 and height >= 710, or if {vf} >= 720p?

Edit:
Now that I think about it, is there a way to round {hpi} to the closest value from my selection?
E.x.
240/360/480/720/1080/2160, while maintaining the p/i letters?

[rednoah]

1.
Yes, 576p is PAL TV standard. 480p is NTSC TV standard.


2.
Find first value that is close enough:

Code: Select all

{[1080, 720, 480].find{ it*0.9 <= dim[0]}}

First letter of first video stream scan type:

Code: Select all

{video[0].ScanType[0].lower()}

[Draik]

Thanks!
Works like a charm