MediaInfoLib
MediaInfoLib copied to clipboard
MediaArea
DTS-HD core bit rate not displayed unless LegacyStreamDisplay is set
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
@JeromeMartinez Hello, sorry to bother but do you plan to add this back?
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?
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.
--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.
If this is not something that will be removed, I can keep using the option. Maybe it should be renamed, I agree. Thank you.
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).
@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?
(removed due to code of conduct violation)
if a DTS-HD/TrueHD track contains a core it should be shown by default...the assumption being that if no core track is visible in the mediainfo then it doesn't have a core track.
(removed due to code of conduct violation)
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).
(removed due to code of conduct violation)
The core infos are literally one line additions to existing lines. if you don't care about the core... (removed due to code of conduct violation)
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.
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.
what difference would that make? The current version hides core info by default, your solution is to add more lines...and hide them by default again? it's literally reinventing the wheel. there's no need for new lines - it's restoring the old behavior of showing the core without having to use a flag. surely reverting the LegacyStreamDisplay changes in 1943b9b can't be that resource intensive?
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.
I'm also interested in the maximum features of a stream. Do you not consider backwards compatibility a feature? I understand MI has nothing to do with playback, it is however the de facto program used to look at stream info and bundled with many media players. when people ask why they're not getting any sound on their video, or their playback is extremely choppy, or the audio only plays in spanish...the first response is "post mediainfo"
Returning to "maximum features"...let's say I have a TV which can decode DTS but not HD audio. which mediainfo output is more useful in determining which file is most suitable?
19.04:
Format/Info : Digital Theater Systems
Format profile : MA
Bit rate : 4 490 kb/s
Channel(s) : 8 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE
Compression mode : Lossless
18.05:
Format/Info : Digital Theater Systems
Format profile : MA / Core
Bit rate : 4 490 kb/s / 1 509 kb/s
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
Compression mode : Lossless / Lossy
any sane person would choose 18.05, simply because it provides more info. If I were looking over the mediainfo of that file and I wasn't aware of this change (as most people won't be, because who the hell checks github changelogs on every program update?) my assumption would be that it has no core stream, therefore is useless to me. (would also like to note there doesn't seem to be any mention of this flag in the command line help text, or an option in the GUI that I could find)
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.
the fact that a lot of people were requesting 3rd party developer options for restoring the stream shows that it was a bad change, wouldn't you say? and that people actually want to see core info? Personally, I saw no problem with how it was displayed and thought it was pretty clean.
In all cases the way it was previously displayed was problematic, lot of people were not understanding the meaning of the output.
MA / Core
4 490 kb/s / 1 509 kb/s.
really - that is confusing to some people? (removed due to code of conduct violation)
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)
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).
You will never be able to fix "issues" that stem from ignorance. if I don't understand something that is shown, for example: frame rate: 93.750 FPS (512 SPF), then it's on me to do my own research, not insist it be removed because I don't get it. Keep following that line of thinking and by version 25 the output will be nothing more than "Has video: Yes, Has audio: Yes". instead of placating people too lazy to do their own research point them to a wikipedia page and tell them you're not their personal tech support. they have the entire internet at their fingertips, I'm sure they can manage to formulate a semi-coherent question to put into google even if it does take them a couple of hours.
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.
they may be important but they were wrong this time and MediaInfo is worse off because of it.
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.
I gave you an example. a TV with DTS support but not HD audio. an MKV played on windows media player that supports AC3 but not TrueHD. shit, even uploading an MKV file to Google Drive and wondering if you can stream it or not. will Google let you stream a video file with TrueHD in your browser?
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.
You're right, there is no perfect display - but 18.05 was a lot clearer than what it is now. despite saying your intent is to simplify the output it looks like every new version of MI gets even more convoluted. we've gone from this:
Audio #1
Format : TrueHD / AC-3
Format profile : TrueHD+Atmos / TrueHD / AC-3
Muxing mode : Stream extension
Codec ID : 131
Duration : 3 h 2 min
Bit rate mode : Variable / Constant
Bit rate : 448 kb/s
Maximum bit rate : 8 199 kb/s
Channel(s) : Object Based / 8 channels / 6 channels
Channel positions : Object Based / Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : / 48.0 kHz / 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Stream size : 585 MiB (1%)
Service kind : Complete Main
to this:
Audio #1
Format : AC-3 MLP FBA 16-ch
Format/Info : Audio Coding 3 + Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 3 h 2 min
Bit rate mode : Variable
Bit rate : 448 kb/s
Maximum bit rate : 8 199 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 585 MiB (1%)
Service kind : Complete Main
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE
Aside from the wrong info the first layout looks far better to me. Format...TrueHD / AC-3? Nah, gimme dat AC-3 MLP FBA 16-ch! I love my audio codecs looking like a US military fighter jet production code. zozzle
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
usefulness is subjective. I find it useful because I want to know exactly what a stream contains. object based, HD only, HD with core, etc. from every response you've made so far it appears your reason for removing it wasn't down to how useful it was, but rather the amount of people whining because it was too complicated for them to understand.
(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)
I'd need a file to see the output as I'm working with DTS-HD & TrueHD files mostly...but if Text1 / Text2 / Text3 is too complex for the people using this program, is there even any point in trying to find a format? If you have trouble with the most simplistic of format separation what hope do they have of understanding any format proposed to them?
Returning to my original comment: "if a DTS-HD/TrueHD track contains a core it should be shown by default...the assumption being that if no core track is visible in the mediainfo then it doesn't have a core track." I've yet to hear a reason why this shouldn't be the case other than "people can't read good"
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.
will Google let you stream a video file with TrueHD in your browser?
Yes. But it reencodes it... e.g. https://drive.google.com/file/d/1e0gfDIsNQKfJSrKV7eaL3izQWZg1XUQ-/view?usp=drivesdk
You can say since ffmpeg can see AC3 stream in THD it can be AC3 that gets reencoded, but no... Since AC3 in Dolby samples in not the same as TrueHD (it has recorded audio that ac3 does not support Atmos). So that means that track is not reencoded.
AC-3 MLP FBA 16-ch
It now does not see AC3 at all. A bug. LOL.
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.