MediaInfo(Lib) 0.7 - Reading information about media files

[Q-the-STORM]

I sent you a PM with a link.

[Selur]

Small question about 'MasteringDisplay_ColorPrimaries', what to use for R, G, B, WP, when it only reports 'Display P3'?

[Atak_Snajpera]

Good question because there are two variants! Older version was reporting values for DCI-P3 D65. Now the same file is being detected as Display P3.

DCI-P3 D65 0.3127 0.3290 0.680 0.320 0.265 0.690 0.150 0.060
DCI-P3 Theater 0.314 0.351 0.680 0.320 0.265 0.690 0.150 0.060

[kolak]

These are 2 different standards.
1 is P3 with D65 white point, another is P3 DCI standard with different white point (this is rather not to be used with TVs, but DCI projectors).
It's either one or another in reality, they can't be both :)

[Selur]

Hoping that Zenitram can tell :)

[Zenitram]

These are 2 different standards.
1 is P3 with D65 white point, another is P3 DCI standard with different white point (this is rather not to be used with TVs, but DCI projectors).
It's either one or another in reality, they can't be both :)

This is what (D65 not associated with DCI) I understood too :)
There is definitely some debate about naming, and I guess it is not a closed topic, but what I understood is that "DCI-P3 D65" was misleading for some people (critisism of older version of MediaInfo), as DCI is associated to theaters (DCI = Digital Cinema Initiatives) and theater don't (IIUC) use D65.

So "Display P3", name used by Apple (https://developer.apple.com/videos/play/wwdc2017/821/), was prefered.

DCI-P3 D65 = SMPTE EG 432-1 = MPEG value 12 = Display P3 = Used by e.g. Apple
DCI-P3 Theater = SMPTE RP 431-2 = MPEG value 11 = "original" DCI P3 = used in theaters

values of R/G/B/WP for both were indicated by Atak_Snajpera, D65 (MPEG value 12) being used by "Display P3" in MediaInfo, the theater version (MPEG value 11) being "DCI P3" in MediaInfo.

[Selur]

D65 (MPEG value 12) being used by "Display P3" in MediaInfo, the theater version (MPEG value 11) being "DCI P3" in MediaInfo.
Thanks for that info!

[Atak_Snajpera]

There is definitely some debate about naming, and I guess it is not a closed topic,
Again. I would definitely prefer neutral SMPTE names being used everywhere if possible instead of names associated with some specific company (apple). They haven't invented this standard so why do we promote them?

[Zenitram]

They haven't invented this standard so why do we promote them?

I already answered (https://forum.doom9.org/showthread.php?p=1827770#post1827770).
Seriously, doing the difference between 431-2 and 432-1 is not fun for people. and SMPTE didn't invented it too (EG = Engineering Guidelines, RP = Recommanded Practice. None is ST = STandard, so your sentence is wrong when you use "standard").
It is not about Apple, it is about what users can easily read (also 1 of the reasons I prefer AVC/HEVC over H264/H265) and use (the choice was made from a discussion with users).

I will always have some people angry with naming, whatever I choose, this time it is your turn, that's all.

If there are enough people angry with such naming and ready to sponsor the option, I have no problem to develop an option (or config file) for outputting different names (not only for colors, also for e.g. formats, I have such kind of discussion from day 1 of MediaInfo) or just technical things (for colors: the formulas or raw coordinates?).

Note that I don't close the discussion, but I listen to all arguments (not only the ones here), I need more convincing arguments for changing back / modifying default output.

[nevcairiel]

It is not about Apple, it is about what users can easily read

If thats your primary motiviation, then using "Display P3" is utterly pointless. I'm a user and I have no idea that this refers to (since I don't interact with Apple at all, I also don't know their odd choices in naming) what I know as DCI P3 D65. Why not call it "DCI P3 D65" and "DCI P3 Theater", that clearly communicates the two different DCI P3 variants.

[Atak_Snajpera]

"Display P3" means nothing if I can't easily find color space parameters like with "DCI P3 D65". You are trying hard to invent a wheel again with those "friendly commercial names" (apples's Display P3). x265 documentation also uses "P3 D65" name.


--master-display <string>

SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max,min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content.

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.

[Zenitram]

(...) with some specific company (apple). They haven't invented this standard so why do we promote them?

Having arguments based on "alternative facts" does not help to convince, it actually makes some people like me (liking real facts) angry when such error is discovered.
https://developer.apple.com/documentation/coregraphics/cgcolorspace/1408916-displayp3
"The name of the Display P3 color space, created by Apple Inc. This color space uses the DCI P3 primaries, a D65 white point, and the same gamma curve as the sRGB color space."

Looking for DCI documents (not Wikipedia links) indicating that this is "standadized" on DCI side.

If thats your primary motiviation, then using "Display P3" is utterly pointless. I'm a user and I have no idea that this refers to

Sorry but you are not my only user and some other don't know "DCI P3 D65", if I make you happy I make others unhappy, why should I prioritize you and not others?
This is not an argument, if you want to convince please argue in a better way, less centered on 1 person only.

x265 documentation

I already answered to such argument (summary: x265 is one side, there are others), and you don't take in account my answers, so it is a bit frustrating and does not help.

I stop here as this is not a constructive debate.

[nevcairiel]

Sorry but you are not my only user and some other don't know "DCI P3 D65", if I make you happy I make others unhappy, why should I prioritize you and not others?
This is not an argument, if you want to convince please argue in a better way, less centered on 1 person only.

The only important argument is that this is the official name. DCI-P3 D65, as defined by the Digital Cinema Initiatives, and standardized/published by SMPTE. Any other names are aliases invented by specific vendors.

The argument you listed with how people were confused with the old name is also quite "me" centric on those users, isn't it? Double standards? Its a simple fact that both are called DCI-P3, one for D65 and one for Theater. There is no confusion.

[Atak_Snajpera]

I already answerd to such argument (summary: x265 is one side, there are others), and you don't take in account my answers, so it is a bit frustrating and does not help.

Yeah let's forget about huge base of users using x264/x265/ffmpeg libraries with those well recognized names.
http://i.cubeupload.com/UA1noc.png

Having arguments based on "alternative facts" does not help to convince, it actually makes some people like me (liking real facts) angry when such error is discovered.
https://developer.apple.com/document...8916-displayp3
"The name of the Display P3 color space, created by Apple Inc. This color space uses the DCI P3 primaries, a D65 white point, and the same gamma curve as the sRGB color space."

Just another alias for DCI-P3 D65. That's it! Has apple contributed to DCI-P3 specification? It looks like another corporation trying to promote own fancy names. Nothing new here.

[Zenitram]

Yeah let's forget about huge base of users using x264/x265/ffmpeg libraries with those well recognized names.

Again "alternative facts" with "well recognized names"...
You think that x264/x265/FFmpeg are the center of the universe, this is your right to lie to yourself, I just inform you that arguing with such mistake (e.g I already said that "PQ" was requested by a sponsor from the industry who uses this wording and not the SMPTE number whose he does not understand) will not help to convince me that you suggest the right names to use in MediaInfo (MediaInfo is used by a lot of users who have never heard about x264/x265/FFmpeg). Note also that MediaInfo can live only due to sponsoring and sponsors have a priority (not a veto right, but I also listen to them) and most of sponsors really don't care at all of a "it is used by FFmpeg" argument.

BTW, you did not source your arguments, and I did not find something about "P3" in DCI specs (http://dcimovies.com/specification/DCI_DCSS_v12_with_errata_2012-1010.pdf) (and erratas (http://www.dcimovies.com/specification/index.html)), as you know that it is DCI I think it would be easy for you to link to the corresponding docs and pages, it would help in an objective debate.

If you are interested in being constructive, please argue in an objective manner, respecting different points of view, instead of just trolling without listen to arguments from people not agreeing with you and not having the same priorities as you.
I spent too much time in trying to explain that there are different communities using MediaInfo and that you are not the only ones, if such fact is not accepted I don't see a reason to keep trying to debate based on wrong assumptions (here I spent most of my time to explain basic things like communities, which prevents to focus on a good debate)

[Atak_Snajpera]

Just use DCI-P3 D65 and Theater for god sake! Why do you have to ride on apples's d$%k in this case? Was that also a sponsored decision to use "Display P3"?
If yes then i'm ok with your decision.

[wiggaz]

Are we still with this Display P3 nonsense ? :(

[Zenitram]

Are we still with this Display P3 nonsense ? :(

"nonsense" for you does not mean nonsense for other people.
Are we still with such "argument"?

[wiggaz]

The previous method was clear, all the values were display and understandable. If necessary, they were usable to who encodes and who doesn't. Now we should take reference to other documents to acknoledge them.
I really don't understand the benefit of this.

[PCU]

please support this format too: Bink Video - The Video Codec for Games
http://www.radgametools.com/bnkmain.htm

[LoRd_MuldeR]

I'm using MediaInfo with XML output to analyze media files and extract the cover artwork.

But, unfortunately, I noticed that latest MediaInfo (v18.03.1) does not output <Cover_Data> tag anymore, even with --Full option set :eek:

I suspect this has something to do with:
Attachments: do not provide anymore attachments content in XML by default, reducing XML output size

What CLI option do I have to set to get the cover data again? :confused:

:thanks:

[Zenitram]

I'm using MediaInfo with XML output to analyze media files and extract the cover artwork.

But, unfortunately, I noticed that latest MediaInfo (v18.03.1) does not output <Cover_Data> tag anymore, even with --Full option set :eek:

I suspect this has something to do with:


What CLI option do I have to set to get the cover data again? :confused:

:thanks:

Right, I removed the presence of cover data by default, as it is not often used and make MediaInfo creating big XML files and with some (little) performance impact by default.

But it definitely lacks of documentation about how to active it, [documentation is on my ToDo-list](https://mediaarea.net/Vote/Mediainfo-Usage-Documentation-127).

Magic hidden setting: add " --Cover_Data=base64" (or MediaInfo::Option("Cover_Data", "base64").

As usual when there are lot of users, a change in default value has some impact on a couple of users :(, sorry for that.

[LoRd_MuldeR]

But it definitely lacks of documentation about how to active it, [documentation is on my ToDo-list](https://mediaarea.net/Vote/Mediainfo...umentation-127).

Yeah, writing documentation is pain. Not only it takes a whole lot of time (if you want to do it properly), it tends to be outdated the very next day ;)

Magic hidden setting: add " --Cover_Data=base64" (or MediaInfo::Option("Cover_Data", "base64").

Thanks for the quick reply. That works like a charm! :)

As usual when there are lot of users, a change in default value has some impact on a couple of users :(, sorry for that.

No problem. I understand why the "new" default makes sense for most use-cases. And with the "magic setting" all is good for my use-case.

[Selur]

@Zenitram: Small follow-up question regarding 'Mastering display color primaries'. :)
So far we know that

'Display P3' <> 'DCI-P3 D65' <> 'R(x=0.680, y=0.320), G(x=0.265, y=0.690), B(x=0.150, y=0.060), White point(x=0.3127, y=0.3290)'
'DCI P3' <> 'DCI-P3 Theater' <> 'R(x=0.680, y=0.320), G(x=0.265, y=0.690), B(x=0.150, y=0.060), White point(x=0.314, y=0.3510)'

But now I encountered a source where 'Mastering display color primaries' just states 'BT.2020'.
What values does this refer to?
Also are there other constants used?

Cu Selur

[Zenitram]

But now I encountered a source where 'Mastering display color primaries' just states 'BT.2020'.
What values does this refer to?

From H.265 specs:
Rec. ITU-R BT.2020-2
primary x y
green 0.170 0.797
blue 0.131 0.046
red 0.708 0.292
white D65 0.3127 0.3290

Also are there other constants used?

For the moment, no more values are mapped, but hypothetically all values from H.265 (and more) could be mapped.

[Selur]

Thanks! :)

[Murvel]

Thanks for a great app.

I use it sometimes to compare different edits of the same clip, and I think it would be helpful if the app would always report the exact duration of a clip, down to seconds or even frames. As of now, you see duration in seconds for shorter clips only, whereas hours and minutes is all you see for longer clips.

Thanks again.

[LoRd_MuldeR]

Thanks for a great app.

I use it sometimes to compare different edits of the same clip, and I think it would be helpful if the app would always report the exact duration of a clip, down to seconds or even frames. As of now, you see duration in seconds for shorter clips only, whereas hours and minutes is all you see for longer clips.

Thanks again.

Try with options --Full and --Language=raw, which should give you output like this:
.\mediainfo.i686.exe --Full --Language=raw "C:\Path\to\Movie.mkv"
General
[...]
Duration : 5764920
Duration/String : 1h 36mn
Duration/String1 : 1h 36mn 4s 920ms
Duration/String2 : 1h 36mn
Duration/String3 : 01:36:04.920
Duration/String4 : 01:36:04:23
Duration/String5 : 01:36:04.920 (01:36:04:23)
[...]

Or, alternatively, use --Output=XML option:
.\mediainfo.i686.exe --Output=XML "C:\Path\to\Movie.mkv"
<?xml version="1.0" encoding="UTF-8"?>
<MediaInfo
xmlns="https://mediaarea.net/mediainfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://mediaarea.net/mediainfo https://mediaarea.net/mediainfo/mediainfo_2_0.xsd"
version="2.0">
<creatingLibrary version="18.05" url="https://mediaarea.net/MediaInfo">MediaInfoLib</creatingLibrary>
[...]
<FileSize>4334673157</FileSize>
<Duration>5764.920</Duration>
[...]

[Zenitram]

Dear MediaInfo users (and developers!),

Due to the increasing complexity, while keeping compatibility with legacy decoders, of audio formats, the way MediaInfo was displaying audio related information was worse and worse.
This was actually becoming difficult when we implement a better support of E-AC-3 in Bluray (mixed with core AC-3) and also Atmos (can be in E-AC-3, or TrueHD, TrueHd may be mixed with AC-3 or alone...), and DTS-HD features were not well displayed enough.

We change how we display formats with support of legacy decoders:
- the Format line in the text output contains now the name of the base format + list of features needed for outputting the best result.
- the "Format" field in XML or API (or "full" text output) contains the base format, "Format_AdditionalFeatures" field in XML or API contains the list of features, "Format/String" for the sum of both.
- Note that there are sometimes some differences between "Format/String" and the 2 other fields for commercial reasons.
- "Profile" field has changed for AAC, now contains the profile/level as found in MP4_IOD_Tag MP4 descriptor.
- We don't display anymore by default information about how legacy decoders would play the file.
- We change the way we display channel layout, with a list of channels. The previous method was not sustainable with the incoming 3D audio (16 or 24 channels). Note that issue with having channel names is that each format stipulates different channel names, we listed the mapping we do at https://mediaarea.net/AudioChannelLayout . Channel layout names will be in MediaInfo 18.08 and above, with a list ordered by the expected output order from the decoder, the former method is still available with "full" text, XML or API (list is ordered by "layer" so comparison is doable between formats, but similar channels have the same name and/or it is not well implemented, be careful with this field if you work with 16- or 24-channel content)
- We do the difference between technical name and the marketing name, e.g. "E-AC-3 JOC" for Dolby Atmos in E-AC-3, "MLP FBA" for TrueHD and "MLP FBA 16ch" for Atmos in TrueHD.
- We support now the channel configuration and the count of objects in an Atmos stream, either in E-AC-3 or TrueHD. But we don't "merge" the Atmos channels in the core channel count, we display Atmos channel info in separate fields.

Example of new output with a Dolby Atmos "9.1.4" stream with 1 dynamic object:


Audio
Format : E-AC-3 JOC
Format/Info : Enhanced AC-3 with Joint Object Coding
Commercial name : Dolby Digital Plus with Dolby Atmos
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Service kind : Complete Main
Number of dynamic objects : 1
Bed channel count : 14 channels
Bed channel configuration : L R C LFE Ls Rs Lb Rb Tfl Tfr Tbl Tbr Lw Rw

Most of changes are reversible through options (" --File_HighestFormat=0 --File_ChannelLayout=0 --LegacyStreamDisplay=1" on the command line) but I hope that these option are used not so much.

We would like that you test the development snapshots at https://mediaarea.net/download/snapshots/binary/mediainfo-gui/ and also check the channel layout mapping at https://mediaarea.net/AudioChannelLayout ; due to sponsors behind these changes (they have priority), we will not change a lot the output but we would like to anticipate issues and bugs for advanced users like people here before we do a more public release.

[manolito]

As already announced by Zenitram, the latest version 18.08 breaks compatibility with most (if not all) third party software which uses MediaInfo. AVStoDVD for example can neither recognize video nor audio formats with this latest version.

This means that software which is still maintained will have to be updated to become compatible with the new MediaInfo output. For older applications which are no longer developed users have no choice but sticking with version 18.05.


Cheers
manolito

[Zenitram]

For older applications which are no longer developed users have no choice but sticking with version 18.05.

If there is some demands I could release a specific version of the DLL with the old behavior activated by default so new formats and bug fixes can be used with old apps, else for the lazy developers it is just the options above (but I recommend to adapt the tool to the new fields as it is a more detailed nd more future proof).

AVStoDVD for example can neither recognize video nor audio formats with this latest version.

Wondering a bit how the API was used, as most old fields stay as is (maybe except for AAC) when called from the API e.g. "Format" field for AC-3, E-AC-3 or DTS are same. Anyway, true that this is possible, apologizes for this but this is really something I don't do often, and here it was something I had to do at some point for making some sponsors happy and prepare the future (I bet that this will be even more complex formats and hacks in the formats).

[manuelin]

Hello Zenitram, thank you very much for the new version with so many changes.

One question, would it be possible for the next version to re-enable all the parameters that show information about all the audios and not only the main one?
I explain:

Before:
Audio #1
ID : 2
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
ID códec : A_DTS
Duración : 1 h 26 min
Tipo de tasa de bits : Variable / Constante
Tasa de bits : 2 860 kb/s / 1 509 kb/s
Canal(es) : 8 canales / 6 canales
Posiciones del canal : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Velocidad de muestreo : 48,0 kHz
Velocidad de fotogramas : 93,750 FPS (512 SPF)
Profundidad bits : 16 bits
Modo de compresión : Sin pérdida / Lossy
Tamaño de pista : 1,72 GiB (4%)
Título : Castellano DTS-HD MA 7.1 @ 2860 Kbps
Idioma : Español
Default : Sí
Forced : No

Now:
Audio #1
ID : 2
Formato : DTS XLL
Formato/Info : Digital Theater Systems
Nombre comercial : DTS-HD Master Audio
ID códec : A_DTS
Duración : 1 h 26 min
Tipo de tasa de bits : Variable
Tasa de bits : 2 860 kb/s
Canal(es) : 8 canales
Channel layout : C L R LFE Lb Rb Lss Rss
Velocidad de muestreo : 48,0 kHz
Velocidad de fotogramas : 93,750 FPS (512 SPF)
Profundidad bits : 16 bits
Modo de compresión : Sin pérdida
Tamaño de pista : 1,72 GiB (4%)
Título : Castellano DTS-HD MA 7.1 @ 2860 Kbps
Idioma : Español
Default : Sí
Forced : No

I have marked in bold two examples, although there are more, but I think those 2 are some of the most important.


In short, before you could see the information of the main audios and also the core/embedded, now only the main.

And that previously worked very well to be able to see if the audio contained core/embedded, and also to be able to see its corresponding bitrate.


Thank you very much!
Regards ;)

[Zenitram]

One question, would it be possible for the next version to re-enable all the parameters that show information about all the audios and not only the main one?


In the last years I got lot of complains about the presence of too much information, now I have a request to provide more information :).
I was liking to provide info about the core stream but some sponsors (in addition to several users complaining about a non understandable output) were disliking that and they have priority. Maybe in the future such information will come back by default (in a different display? Possible, the previous one is considered too weird by several people).

For CLI and DLL, this is possible to revert to previous behavior by using the options (in the post above).
For GUI, we plan to have options but this is not the priority right now, you can vote for prioritizing options in the GUI (https://mediaarea.net/Vote/Mediainfo-Gui-Display-Options-184)

[Megalith]

If MediaInfo doesn't show a field regarding dialnorm, is it safe to assume the audio track/s do not have dialnorm applied? I thought that dialnorm couldn't be removed from DTS-HD MA tracks, though...

[Zenitram]

If MediaInfo doesn't show a field regarding dialnorm, is it safe to assume the audio track/s do not have dialnorm applied? I thought that dialnorm couldn't be removed from DTS-HD MA tracks, though...

No.
It is safe to assume that the field is not present in the stream or that analysis is not implemented.

For dialnorm in DTS / DTS-HD MA, it is the second possibility.

[Murvel]

Try with options --Full and --Language=raw, which should give you output like this:
.\mediainfo.i686.exe --Full --Language=raw "C:\Path\to\Movie.mkv"
General
[...]
Duration : 5764920
Duration/String : 1h 36mn
Duration/String1 : 1h 36mn 4s 920ms
Duration/String2 : 1h 36mn
Duration/String3 : 01:36:04.920
Duration/String4 : 01:36:04:23
Duration/String5 : 01:36:04.920 (01:36:04:23)
[...]

Or, alternatively, use --Output=XML option:
.\mediainfo.i686.exe --Output=XML "C:\Path\to\Movie.mkv"
<?xml version="1.0" encoding="UTF-8"?>
<MediaInfo
xmlns="https://mediaarea.net/mediainfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://mediaarea.net/mediainfo https://mediaarea.net/mediainfo/mediainfo_2_0.xsd"
version="2.0">
<creatingLibrary version="18.05" url="https://mediaarea.net/MediaInfo">MediaInfoLib</creatingLibrary>
[...]
<FileSize>4334673157</FileSize>
<Duration>5764.920</Duration>
[...]

Thanks for the suggestion, but I know of no way to accomplish this for the following (and most common?) scenario: The way I launch MediaInfo is I use Windows Explorer, in which I browse to the video file, right-click it, and in the context menu I click MediaInfo. The program launches and displays the properties for the video in question. If there's a way to inject your options to there, that would be a done deal, but I'd like to know how.

[Zenitram]

If there's a way to inject your options to there

Not yet implemented in the GUI. You can prioritize the feature if you are interested in it (https://mediaarea.net/Vote/Mediainfo-Gui-Display-Options-184) .

[Selur]

Small question latest version shows Width, Height, Stored_Width, Stored_Height, Sampled_Width, Sampled_Height, what is their relationship and how does it relate to the 'old' 'Original Width' and 'Original Height'?

[Zenitram]

Small question latest version shows Width, Height, Stored_Width, Stored_Height, Sampled_Width, Sampled_Height, what is their relationship and how does it relate to the 'old' 'Original Width' and 'Original Height'?

"Original XXX" is for when there is a conflict between 2 info which should be same but are not (container vs stream).

For the others, they are completely different values. in short:
- "Stored XXX" is what is stored in the stream i.e. before cropping, usually different than XXX when you use non multiples of 16 (e.g. AVC can not compress 1080 lines, it compresses 1088 lines and crop 8 lines, so height is 1080 and stored height is 1088. Stored height is very important for hardware limits, because in that case the HW mus support 1088 lines even if only 1080 are shown). Some streams are a bit crazy, e.g. they are encoded with 1120 lines with cropping to 1080, and an HW limited to 1088 lines will fail to decode this "fake" 1080 line stream.
- "Sampled XXX" was a tentative for something from 1 customer, not relevant, discard it for the moment (I may remove it in the future, nobody would cry for this field IMO). Should be now more or less similar to "XXX" alone (was more useful when there was no "clean aperture" metadata).
- "Clean aperture XXX" is the clean aperture size i.e. what is expected to be good enough, just a piece of metadata from the container relevant to people who know what clean aperture is.

[qyot27]

There seems to be some kind of character limit/buffer issue in the CLI when trying to display --info-parameters:

E:\Documents\MediaInfo_CLI_18.08.1_Windows_x64>mediainfo --version
MediaInfo Command line,
MediaInfoLib - v18.08.1

E:\Documents\MediaInfo_CLI_18.08.1_Windows_x64>mediainfo --info-parameters | grep colour
colour_range : Colour range for YUV colour space
colour_description_presen : Presence of colour description
colour_primaries : Chromaticity coordinates of the source primaries
colour_description_presen : Presence of colour description
colour_primaries_Original : Chromaticity coordinates of the source primaries
colour_description_presen : Presence of colour description
colour_primaries : Chromaticity coordinates of the source primaries
colour_description_presen : Presence of colour description
colour_primaries_Original : Chromaticity coordinates of the source primaries
There's no way to be able to know what those fields are supposed to be, because of the truncation. Also, why are those HDR-related fields in lower-case? Does that mean they're not supposed to be public options?

I've seen this occur with both the official build, but with my own (GCC 8.2.0, MinGW-w64 6.0.0) build as well.

[danissimo]

Is it possible to add Escape key as the shortcut for closing MediaInfo window?
Thank You.

[Selur]

mediaarea.net/MediaInfoOnline <- any plans to show 'full' data?

Any plans to support HDR-10+ HEVC files?
(I can create HDR10+ files using x265 and verify that the file contains HDR-10+ metadata using hdr10plus_parser, sadly mediainfo doesn't show any hints about the HDR-10+ data atm.)

Cu Selur

[Zenitram]

mediaarea.net/MediaInfoOnline <- any plans to show 'full' data?

I didn't think it is useful and I saw no interest on my side, but if it is it should not be long to implement (note: at some point I may decide to offer options only to MediaArea members (https://mediaarea.net/SupportUs/Individual)).

Any plans to support HDR-10+ HEVC files?

Provide files please.
I was not finding HDR10+ specs, but as hdr10plus_parser is open source it should be easy to understand the new metadata parts.

[Selur]

Provide files please.
My GoogleDrive (https://drive.google.com/open?id=1-PymgpSkhvYs2XmiAbX82ySLdknMPaGC) contains a HDR-10+ mp4 file I created from another file and HDR-10+ json data, hope that helps.

[Zenitram]

Any plans to support HDR-10+ HEVC files?

OK, I was motivated, I started something (https://github.com/MediaArea/MediaInfoLib/pull/1088), without being sure about what would be interesting to show e.g. only HDR10+ presence?

For the moment (work in progress, can change in the future), MediaTrace (https://mediaarea.net/MediaTrace) dump is

0006733 sei (62 bytes)
0006733 Header (6 bytes)
0006733 size: 58 (0x0000003A)
0006737 nal_unit_type: 39 (0x27) - (6 bits)
0006737 nuh_layer_id: 0 (0x00) - (6 bits)
0006738 nuh_temporal_id_plus1: 1 (0x1) - (3 bits)
0006739 sei message - user_data_registered_itu_t_t35 - SMPTE ST 2094 App 4 (51 bytes)
0006739 sei message header (2 bytes)
0006739 payload_type_byte: 4 (0x04)
000673A payload_size_byte: 49 (0x31)
000673B itu_t_t35_country_code: 181 (0xB5)
000673C terminal_provider_code: 60 (0x003C)
000673E terminal_provider_oriented_code_message_idc: 1 (0x0001)
0006740 application_identifier: 4 (0x04)
0006741 application_version: 1 (0x01)
0006742 num_windows: 1 (0x1) - (2 bits)
0006742 targeted_system_display_maximum_luminance: 0 (0x0000000) - (27 bits)
0006745 targeted_system_display_actual_peak_luminance_flag: No
0006745 window (38 bytes)
0006745 max_luminance_r: 0 (0x00000) - (17 bits) - 0.00000 cd/m2
0006747 max_luminance_g: 0 (0x00000) - (17 bits) - 0.00000 cd/m2
000674A max_luminance_b: 0 (0x00000) - (17 bits) - 0.00000 cd/m2
000674C avg_luminance: 233 (0x000E9) - (17 bits) - 0.00233 cd/m2
000674E num_distribution_maxrgb_percentiles: 9 (0x9) - (4 bits)
000674E distribution_maxrgb - 1 (0x1) - 0 (0x0) (3 bytes)
000674E distribution_maxrgb_percentile: 1 (0x01) - (7 bits)
000674F distribution_maxrgb_data: 0 (0x00000) - (17 bits)
0006751 distribution_maxrgb - 5 (0x5) - 6886 (0x1AE6) (3 bytes)
0006751 distribution_maxrgb_percentile: 5 (0x05) - (7 bits)
0006752 distribution_maxrgb_data: 6886 (0x01AE6) - (17 bits)
0006754 distribution_maxrgb - 10 (0xA) - 88 (0x58) (3 bytes)
0006754 distribution_maxrgb_percentile: 10 (0x0A) - (7 bits)
0006755 distribution_maxrgb_data: 88 (0x00058) - (17 bits)
0006757 distribution_maxrgb - 25 (0x19) - 0 (0x0) (3 bytes)
0006757 distribution_maxrgb_percentile: 25 (0x19) - (7 bits)
0006758 distribution_maxrgb_data: 0 (0x00000) - (17 bits)
000675A distribution_maxrgb - 50 (0x32) - 146 (0x92) (3 bytes)
000675A distribution_maxrgb_percentile: 50 (0x32) - (7 bits)
000675B distribution_maxrgb_data: 146 (0x00092) - (17 bits)
000675D distribution_maxrgb - 75 (0x4B) - 412 (0x19C) (3 bytes)
000675D distribution_maxrgb_percentile: 75 (0x4B) - (7 bits)
000675E distribution_maxrgb_data: 412 (0x0019C) - (17 bits)
0006760 distribution_maxrgb - 90 (0x5A) - 858 (0x35A) (3 bytes)
0006760 distribution_maxrgb_percentile: 90 (0x5A) - (7 bits)
0006761 distribution_maxrgb_data: 858 (0x0035A) - (17 bits)
0006763 distribution_maxrgb - 95 (0x5F) - 1583 (0x62F) (3 bytes)
0006763 distribution_maxrgb_percentile: 95 (0x5F) - (7 bits)
0006764 distribution_maxrgb_data: 1583 (0x0062F) - (17 bits)
0006766 distribution_maxrgb - 99 (0x63) - 4170 (0x104A) (3 bytes)
0006766 distribution_maxrgb_percentile: 99 (0x63) - (7 bits)
0006767 distribution_maxrgb_data: 4170 (0x0104A) - (17 bits)
0006769 fraction_bright_pixels: 0 (0x000) - (10 bits)
000676B mastering_display_actual_peak_luminance_flag: No
000676B window (0 bytes)
000676B color_saturation_mapping_flag: No

and MediaInfo output is:
Format : HEVC
Format/Info : High Efficiency Video Coding
Commercial name : HDR10+
Format profile : Main 10@L5@Main
Codec ID : hev1
Color range : Limited
Matrix coefficients : BT.709
HDR_Format : SMPTE ST 2094 App 4 version 1

With Dolby Vision, SL-HDR, HDR10, and now HDR10+, it becomes messy and not coherent (no common field name for the same stuff, too many lines dedicated to HDR), I am thinking to how I can improve the output for having something coherent between all HDR formats.

[Selur]

don't forget HLG :)
HDR-10, HDR-10+, Dolby Vision and HLG are probably the HDR formats to encounter.

[XinHong]

I'm trying to get the audio "Commercial name" field through the MediaInfo dll with this file: https://we.tl/O0BfDADZbu

MediaInfo gives me:

ID : 2
Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD
Codec ID : A_TRUEHD
Duration : 11 s 11 ms
Bit rate mode : Variable
Maximum bit rate : 6 423 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Language : English
Default : Yes
Forced : No


But when I check the "Commercial Name" field I have only "TrueHD" instead of "Dolby TrueHD"

I'm using this request, is it right ?
MediaInfo_Get(Handle, Stream_Audio, StreamID, 'Format_Commercial', Info_Text, Info_Name)

Thanks

[Selur]

@Zenitram: When does MediaInfo report an jpg as Video and when as Image?
I got a folder with 431 images and when I analyse for example image 00001.jpg it's reported as Video, same for 00401.jpg but 004009.jpg and upwards is only reported as Image.
-> this really is a pain, is there a way to force detecting jpg always as Image or Video ?

[Zenitram]

Any plans to support HDR-10+ HEVC files?

Suffering a bit with all the HDR metadata I have to handle.
Now moving to a dedicated line for HDR format.

Below are some examples of the expected line for HDR10 (actually SMPTE ST 2086), HDR10+ (actually SMPTE ST 2094-40 with lot of restrictions, I finally got the specs so I have the exact restrictions), Dolby Vision, SL-HDR (1&2), any potential issues you see?

HDR format : SMPTE ST 2086, HDR10 compatible
HDR format : SMPTE ST 2094-40, Version 1, HDR10+ Profile A compatible
HDR format : Dolby Vision, Version 1.0, dvhe.04.06, BL+EL+RPU
HDR format : SL-HDR1, Version 1.0, Parameter-based, constant
HDR format : SL-HDR1, Version 1.0, Parameter-based, non-constant
HDR format : SL-HDR2, Version 0.0, Parameter-based


Notes:
- HLG is not listed as it is not additional metadata, "just" a specific transfer characteristics.
- HDR10 & HDR10+ are actually commercial names, but other HDR formats have no difference between technical and commercial name (SL-HDR is listed in ETSI 103-433 but they stipulate the name in specs as they do with e.g AC-3 in ETSI 102-366) so I think it is not good to add a new line for HDR format commercial name, to be debated.
- HDR10 & HDR10+ are listed also if other constraints are met e.g. PQ transfer characteristics.
- I have constraints from sponsors so I'll not able to accept all advice even if I want to.

[Zenitram]

But when I check the "Commercial Name" field I have only "TrueHD" instead of "Dolby TrueHD"

I have it fine when I test with latest DLL and the C++ interface (C++ interface should not change the content of the field compared to the programming language you use) so I don't plan to investigate more.