EAC-3 support #230
Comments
|
See this note here, #100 (comment). There were 83 files in archive.org using |
|
E-AC-3 is stored with CodecID A_AC3, just like normal AC-3. Nothing to do here. |
|
It may be good to know when an AC3 is actually of the enhanced kind, without having to parse the codec data. And since |
|
I disagree strongly. With the same argument, you could reintroduce |
|
We can add an optional CodecPrivate to store which format is used if a codec ID is not desired. Players supporting A_AC3 will see no difference. But IMO we need a way to indentify th variants before playback. It lets the user known which one has better quality when downloading/selecting a track. |
|
The problem is that all players that support E-AC-3 do so with the codec ID |
|
I know that VLC and ffmpeg/libav based one support A_EAC3 already. But like I said a codecprivate/profile would be better, for the future.
…On 3 Jun 2018 at 16:20 +0200, Moritz Bunkus ***@***.***>, wrote:
The problem is that all players that support E-AC-3 do so with the codec ID A_AC3. It isn't given that they also support the codec ID A_EAC3 — which means that using A_EAC3 would be a drawback without any real benefit.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
What, exactly, would be better? Why is doing it like it is done in MP4, MPEG-TS, AVI etc. not enough and insufficient? |
|
And the real issue aren't VLC and ffmpeg, in fact, quite the opposite — those are the ones that are updated the most often in the wild. What is a problem is hardware devices which often never get updated at all. Switching to a different codec ID will only break support on those for no apparent benefit. |
MP4 has 2 dedicated atoms (dac3 and dec3, depending on the stream bsid). So if you want to do "like it is done in MP4, MPEG-TS", you need a CodecPrivate part with atom or descriptor (i.e. something not needed for decoding, but described in a "track header"). |
|
Alright, I'm obviously wrong about the other container formats. Sorry. Still, my question remains: what actual benefits are there that would outweigh having to update software & hardware even if they can already play E-AC-3-as- |
|
I didn't say I am in favor of changing the codec ID. actually I am in favor not to change it ;-). |
|
If helpful here is a list of public files with A_EAC3 |
|
A way to identify the proper codec flavour is crucial for players. For example VP9 doesn't tell which profiles it's using (because there wasn't in the first place) but now there are hardware that can decode new profiles and some that don't. The player has to go to lengthy analysis (a pre-decoder does the job) before deciding if it can use the hardware or not. Historically we have been using the CodecPrivate to store some codec init that usually include the profile. We do not have a proper way to add profiles properly. And I think it's too late for that now. We may rename it to CodecInit because it ain't so private anymore. |
|
Now do we want to know if a track is E-AC3 or basic AC3 ? IMO yes. It makes sense on the player side. IMO it makes sense on the cataloging side as well. All that without parsing inside the codec to know which is it. We also want to use the fact that E-AC3 plays in regular AC3 setup since it works. So we should keep using |
I am not against an extra element, but I am not in favor of using CodecPrivate/CodecInit, because I think it should be used only for bytes needed for decoder init. Not the case here. Worse, it could break some players (you don't know what they do with CodecPrivate with AC-3/E-AC-3, possible side effect due to generic code) |
|
On the player side the CodecPrivate is usually provided to the decoder if it exists (no matter the codec) and it uses it if needed. It's not something you just append to the codec data stream. There is no (E)AC3 decoder that would use it right now. The proper way would be to have an element defining profiles (still a binary blob depedent on the codec). But that would mean all other codecs with the profile currently in the CodecPrivate would need to have this data copied/moved in that new element. Or we have two ways to do it (the old one and the new one) that sucks for existing files/players. So even if it's not ideal I think it's better in the CodecPrivate/CodecInit/CodecBlob. |
Steve, you simply cannot know what all codecs out there will or won't do if they encounter CodecPrivate. I've had so many weird bug reports from people about their hardware not accepting Matroska files simply because one tiny little thing wasn't how they expected it to be. It is very, very dangerous to change currently used mappings that way.
Again, what would be the use? Decoders cannot rely on such an element being present. So they have to do the work of analyzing the bitstream anyway. And what about changing profiles? For e.g. AVC/HEVC, there are tons of streams out there where SPS/PPS parameters change in the middle of the stream, often multiple times, at arbitrary places. Having a single static descriptor in the track headers wouldn't provide anything of real value here from a decoder's point of view — it would still have to handle the stream not being decodable from somewhere in the middle. I really, really fear you're imposing a lot of work on a lot of people here (spec writers, people doing codec-/container-mappings, implementers of multiplexers) for very little actual benefit. Anyway, all of this is very much off-topic for an issue dealing with |
I am in favor of:
|
|
That's what I'd prefer, too. |
|
I just realized |
I watched a mkv with EAC-3 before，but I can't see EAC-3 CodecID in the spec
The text was updated successfully, but these errors were encountered: