MediaInfoLib
MediaInfoLib copied to clipboard
MediaArea
Dolby E audio track element contains multiple tracks
I have a file that has a Dolby E stream. The XML payload groups the two tracks into one track element. I don't see an easy way to retrieve the fact that there are two tracks other than by string parsing the slash between the ID string. It also makes the type order or stream kind position one less than the actual relative audio track number (i.e. the 16th track has StreamKindPos = 15).
<ID>9 / 10</ID>
Am I missing anything that would explicitly tell me that the dolby stream takes up two tracks? It seems like I have to implicitly know that a Dolby E stream is two tracks with one channel each, and re-number accordingly, in order to enumerate the tracks correctly e.g. for a transcoder.
Your thoughts on this are appreciated.
I don't see an easy way to retrieve the fact that there are two tracks other than by string parsing the slash between the ID string. [...] Am I missing anything that would explicitly tell me that the dolby stream takes up two tracks?
There is no explicit field for that, but we could add one for tests in MediaConch. Note that there could be more than 2 streams for an audio content e.g. a Dolby ED2 content may be on 4 streams.
It also makes the type order or stream kind position one less than the actual relative audio track number (i.e. the 16th track has StreamKindPos = 15).
This becomes complicated there, we didn't define enough StreamKindPos for such case. Initially it is the more or less internal position in the list of audio tracks i.e. a content, which was matching the position of the audio stream i.e. the physical order in the file.
And it would be more or less random, because it depends on the count of "services" in the Dolby E content e.g. if you have 3 services in the Dolby E content, StreamKindPos of the 16th stream becomes 17.
Changing the behavior now may break some scripts, so if there is a need of "stream order" per track kind (because for a stream order per file, there is already StreamOrder, which is usable with FFmpeg e.g. -map 0:17 rather than - map 0:a:15 in the case of your file).
Do you need the stream order per track type for your transcoder?
Thanks for the quick response.
Do you need the stream order per track type for your transcoder?
Yes, we basically rely on MediaInfo to tell us where the physical tracks are in the media, especially for audio. The stream order would break if e.g. for some reason, there was a text track in between the audio tracks, correct?
There is no explicit field for that, but we could add one for tests in MediaConch. Note that there could be more than 2 streams for an audio content e.g. a Dolby ED2 content may be on 4 streams.
Yes, for now I am just hard coding the fact that I know Dolby E takes up two channels but it would be much better for media info to report that. But in addition to the number of channels, we really need a way to know how many tracks make up the stream e.g. for Dolby E is it one track two channels or two tracks one channel each.
The stream order would break if e.g. for some reason, there was a text track in between the audio tracks, correct?
The StreamOrder field is for all streams/tracks, so if there is a track not audio between the audio tracks, it will increment the field.
Your encoder has not possibility to use StreamOrder ( -map 0:17 with FFmpeg) and needs a type (video, audio, text...) specific field ( - map 0:a:15 with FFmpeg), right?
But in addition to the number of channels, we really need a way to know how many tracks make up the stream e.g. for Dolby E is it one track two channels or two tracks one channel each.
You can compute if by analyzing the ID, the ID is in the form "A / B-C", with A & B the track ID so count of stream for this track is count of " / " + 1, and C is the position of this track in the stream si count of tracks in a stream is max of C + 1. But I guess that it is better if I show them directly in the API...
I am basically working on exactly the above as a workaround but yes, in a future release, it would be good to have MediaInfo enumerate all physical tracks in the file in some universal way.
Your encoder has not possibility to use StreamOrder ( -map 0:17 with FFmpeg) and needs a type (video, audio, text...) specific field ( - map 0:a:15 with FFmpeg), right?
Unfortunately, we deal with several encoders both free and commercial, some of which support channel numbers, some support absolute tracks, and some only support relative track numbers.