MediaArea / MediaInfoLib

Convenient unified display of the most relevant technical and tag data for video and audio files.
https://mediaarea.net/MediaInfo
BSD 2-Clause "Simplified" License
621 stars 170 forks source link

DTS-HD core bit rate not displayed unless LegacyStreamDisplay is set #1035

Open amazingdash opened 5 years ago

amazingdash commented 5 years ago

Hello, I do not understand why this was removed (https://github.com/MediaArea/MediaInfoLib/commit/1943b9b2ece9ed066b6c501f7d79ffc919eace0b). It is useful, just like the number of channels (still there) and their positions (gone).

 Format/Url                               : https://matroska.org/downloads/windows.html
 Format/Extensions usually used           : mkv mk3d mka mks
 Commercial name                          : Matroska
-Format version                           : Version 4 / Version 2
+Format version                           : Version 4
 File size                                : 39513879
 File size                                : 37.7 MiB
 File size                                : 38 MiB
@@ -39,6 +39,8 @@
 Duration                                 : 00:00:21.355
 Duration                                 : 00:00:21;08
 Duration                                 : 00:00:21.355 (00:00:21;08)
+Overall bit rate mode                    : VBR
+Overall bit rate mode                    : Variable
 Overall bit rate                         : 14802671
 Overall bit rate                         : 14.8 Mb/s
 Frame rate                               : 23.976
@@ -154,15 +156,15 @@
 Duration                                 : 21 s 355 ms
 Duration                                 : 00:00:21.355
 Duration                                 : 00:00:21.355
-Bit rate mode                            : VBR / CBR
-Bit rate mode                            : Variable / Constant
-Bit rate                                 : Unknown / 1509000
-Bit rate                                 : Unknown / 1 509 kb/s
-Channel(s)                               : 8 / 6
-Channel(s)                               : 8 channels / 6 channels
-Channel positions                        : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
-Channel positions                        : 3/2/2.1 / 3/2/0.1
-Channel layout                           : C L R LFE Lb Rb Lss Rss / C L R Ls Rs LFE
+Bit rate mode                            : VBR
+Bit rate mode                            : Variable
+Channel(s)                               : 6
+Channel(s)                               : 6 channels
+Channel(s)_Original                      : 8
+Channel(s)_Original                      : 8 channels
+Channel positions                        : Front: L C R, Side: L R, Back: L R, LFE
+Channel positions                        : 3/2/2.1
+Channel layout                           : C L R LFE Lb Rb Lss Rss
 Samples per frame                        : 512
 Sampling rate                            : 48000
 Sampling rate                            : 48.0 kHz
@@ -171,8 +173,8 @@
 Frame rate                               : 93.750 FPS (512 SPF)
 Bit depth                                : 24
 Bit depth                                : 24 bits
-Compression mode                         : Lossless / Lossy
-Compression mode                         : Lossless / Lossy
+Compression mode                         : Lossless
+Compression mode                         : Lossless
 Delay                                    : 0
 Delay                                    : 00:00:00.000
 Delay, origin                            : Container
amazingdash commented 5 years ago

@JeromeMartinez Hello, sorry to bother but do you plan to add this back?

JeromeMartinez commented 5 years ago

Sorry for lack of answer. At short term I don't plan to add core bitrate. Lot of opposite requests from users, some willing to have it, some others not willing (willing to have the complete bitrate, here it is not available so empty; similar for other fields e.g. the list of core channels was considered too complex, reason it is in an option now).

Issue on my side is that some users consider that info about core stream is too much. Is LegacyStreamDisplay to be set on command line an issue?

amazingdash commented 5 years ago

Can't you just add it when --Full is used? I can use the legacy option but I'm afraid some day it gets removed and then there is no way to see the information at all.

JeromeMartinez commented 5 years ago

--Full is for listing more lines, not for changing lines. --LegacyStreamDisplay is not expected to be removed, this is not supporting legacy features, it is legacy "streams" i.e. core stream. Maybe I should rename the option to CoreStreamDisplay in order to avoid the misunderstanding.

amazingdash commented 5 years ago

If this is not something that will be removed, I can keep using the option. Maybe it should be renamed, I agree. Thank you.

JeromeMartinez commented 5 years ago

If this is not something that will be removed

No plan. It is a verbosity setting, that's all. but great to know that it is useful, because I heard more often that this verbosity is useless (reason it is no more active by default).

Nadahar commented 5 years ago

@JeromeMartinez A slightly related question: Is there any way via the API to get information for each "codec layer" for "multi layer codecs"? I understand that the "legacy" option allows us to continue parsing the different properties from the "multi value string" as usual, but without knowing exactly how your code make decisions it can be hard to "rebuild" the layers in a consistent way (e.g, can I trust that there will always be the exact same number specified for each property even if some of the properties might be unparsed for some layer).

It seems to me that we will just see more of this, at least when it comes to audio. Since some "layers" can be on top of several different "core" layers, it's essential to rebuild the information about each layer to know how to deal with the stream. I assume that MI already have this structure internally, so I'm simply wondering if the "layers" are in any way available directly?

JeromeMartinez commented 5 years ago

if a DTS-HD/TrueHD track contains a core it should be shown by default..

Sponsors have priority, and this is not their point of view. And lot of users also complain about the complexity of the output, not carrying about core info.

(removed due to code of conduct violation)

I don't think that such communication method is positive, please read carefully our code of conduct.

if you want to get rid of useless info how about the FOUR different ways you describe AC3 one after another, zozzle.

We show only one method by default. Other displays are from code we had in the past for other features we wanted. If you want to get such info by default in the full output (not by default), this is possible, don't hesitate to contact us directly for a quote for this extra work.


Sorry for the lack of answer to this ticket, but we handle free support on our spare time and we currently want to prioritize some other tasks which are considered more urgent by us, especially with the options we added for keeping the previous behavior (so with core info).

JeromeMartinez commented 5 years ago

I think that [...] (removed due to code of conduct violation)

MediaInfo is open source, if you fail to convince the main developer and think that you are better than him, don't hesitate to fork and offer a "better" version.

The core infos are literally one line additions to existing lines.

This is something we could add, right, even if I am always a bit reluctant to add lines (if I accept every request to add a line, I would have 1000+ lines in default output) but this line could be also hidden by default and in all cases this is still more code to add so development time. If you think it is really useful for lot of people, I could add this request to our vote system and I'll let you convince people to vote for this request.

don't leave people scratching their heads trying to figure out why their video isn't working

I have no idea about what you are talking about. Users I know are interested in the maximum features of a stream, this is the reason we accepted a sponsor request when he asked us to do as lot of other people were already asked us to do (we have a lot of different people using MediaInfo, not with the same ideas about what is best, we try to find something good for most people), and MediaInfo has nothing to do with video playback. & remind the license "this software is provided as is", if you want that we care more about your needs we can do it but this is a support contract.

On our side, the decision when we implemented a sponsor request + request from lot of people was to offer third party developers an option for getting back core stream info, and I currently don't understand how it is complex for third party developer to add such option when MediaInfo version is updated. We also indicated such change in the Changes.txt file. In all cases the way it was previously displayed was problematic, lot of people were not understanding the meaning of the output.


I removed comments violating our code of conduct, this is the second warning. Next time I just block.

JeromeMartinez commented 5 years ago

there's no need for new lines - it's restoring the old behavior of showing the core without having to use a flag.

The old behavior had issues e.g. not understood by users who send me emails or post for complaining about the output, and if I add back such information I want to think to another method for showing it (some other tools write e.g. "8 channels (Core: 6 channels)", could be a clue but we need to think to all corner cases).

Do you not consider backwards compatibility a feature?

I was considerations that and was the reason it was present in the past, but MediaInfo is not from one person only and sponsors & users are also involved in the decision, you may consider sponsors as not important but they are for me and it is what makes MediaInfo alive.

the first response is "post mediainfo"

Does the core info useful in that case? I understood that this was not so important, please provide a use case where current output is not enough for debugging.

really - that is confusing to some people?

Yes, it is. Worse with HE-AACv2 (there was 3 parts) Note: I removed the rest of the paragraph, you are falling back again in aggressive reaction when people are not like you.

There is no unique perfect display, but we could see how we could fit all needs (--> Not considering other point views as bad, but finding something acceptable for everyone, consensus) in a default display. Please stop to imagine that change was done just for fun, and consider all people involved.

first, I need to be convinced that knowing about the core info is useful for most people. Speaking about some third party willing such info is not enough, providing an example about how the copy paste of the default output would be more useful for you for debugging could help, and how it could be displayed in a different manner that would be more understandable (please test with e.g. HE-AACv2 having 2 legacy levels, I need to see how you imagine an understandable output with your future suggestion about a nice display)

Nadahar commented 5 years ago

I'd like to add that, at least for now, the "lower layers" often are the most interesting. The reason for this is that those have the widest support, and the primary reason you want this information is to handle compatibility. If the target device/software supports the "top layer" that's great, but that is only "a bonus". What you need to figure out is if the media is decodable in a given situation.

I also think backwards compatibility should be given more weight. Having different versions of MI following different "rules" is problematic as I see it. We've had to take the MI version into consideration and adapt the code to what MI version is installed on the system. This complicates things and increases the probability of bugs.

As a general note, I'd also like to emphasize that as always, you only hear the voices that doesn't like how something is. That doesn't mean they are a majority, there's no reason for those that are content with the current solution to voice their opinion about the matter.

As far as I can understand, those that want "only the top level" (sponsors or otherwise), probably doesn't care about figuring out compatibility and think it's an extra hassle to parse. IMO, simply adding a new field with only the "top layer" for them to use would be much better than replacing the contents (and reducing the information) in an existing field.

That said, the damage has already been done, as everybody using MI in their software already have to make their code use different rules for different versions, even if this should now be reversed.

JeromeMartinez commented 2 years ago

It now does not see AC3 at all. A bug. LOL.

A choice was made to hide the "legacy" part, definitely not ideal and we need to see how we can improve the display.