PAL framerate fail: "must be 25" but has value "25.000"

[pjotrek-b]

Applying "Standards Mismatch (PAL)" profile, ran into the problem that MediaConch (v15.11) reports "fail" for framerate, although it's correct:

General FrameRate must be 25
Context (field): FrameRate
Context (value): 25

tracktype	tracktypeorder	trackid	actual	outcome	reason
General			25.000	fail	is not equal

[dericed]

argh, does it work when the test value is "25.000"? I suspect we'll need to make a decision on whether each policy should be a string or numerical test.

[pjotrek-b]

Works with test "is equal 25.000": pass.

[dericed]

@JeromeMartinez, any data in MediaInfoLib where a value could be associated to a data type (decimal, integer, string, etc)?

[pjotrek-b]

Is it possible to use XSLT functions like "round"?
(I completely understand if you don't. It could make things messy)

[dericed]

Yes the XSLT can use some mathematical functions but the XSL would have to know the data-type of the value to know if this is appropriate or not.

For instance framerate=25.000 should mean the same as framerate=25 because framerate is a decimal. But title=1984.000 isn't the same as title=1984 because title is a string. In the XSD all of these elements https://github.com/MediaArea/MediaAreaXml/blob/master/mediainfo.xsd#L24 are currently listed as strings but I think we need to refine the data types of these where we can.

[pjotrek-b]

sounds reasonable.

[JeromeMartinez]

@JeromeMartinez, any data in MediaInfoLib where a value could be associated to a data type (decimal, integer, string, etc)?

I could add the unit for each XML element but I am not fan of increasing the size of the XML for each instance.
https://github.com/MediaArea/MediaInfoLib/tree/master/Source/Resource/Text/Stream has the unit (4th column, 4th character: I=Integer, F=Float, T=Text) so we could use this data for updating the XSD.

[dericed]

In this case such info can be in the XSD, not necessary to exist in each instance of the XML.

[dericed]

Um. I'm not sure I know the answers well enough. MI has these rare oddities like a frame rate of "123 / 456" where many numbers are listed with a slash delimiter. Not sure if frame rate is an accurate sample but I've found that presuming a MI value is a number isn't always safe.

[dericed]

At any rate I'll make the PR for the XSD and assign verification to Jerome.

[JeromeMartinez]

this is the case for e.g. channel numbers, it is used for showing what a legacy decoder can decode (e.g. a legacy DTS decoder decodes 6 channels but a new DTS decoder decodes 8 channels, it is displayed "8 / 6"). I can disable this feature for XML output, and we discuss in another ticket about how to show (if we show) such legacy information.

So you can consider MI fields with "I" or "F" in the CSV files as real integers / floats without any " / ".

[dericed]

Not sure if this is a better consideration for short term or long term but there is some risk in maintaining the XSD and the CSV separately. Perhaps we should have a makefile that generates one from the other. I'll use the I and F values as you note to change the xsd:types.