2012-02-05, 20:40
DanielaE Wrote:Thanks for testing! While I have cherry-picked your patch into my repo to play with it for a while, I came to the conclusion that neither the original code nor your fix is correct - for two reasons:
Basically, this mess is due to a hierarchy violation in the code abstraction layers. The duration of an audio frame must be supplied by the active codec rather than figured out at an codec-agnostic level which simply put has no real clue on how to accomplish that in the first place.
- The idea of calculating the duration of an audio frame is a linear function of the size of a chunk of data is true for coding schemes with constant coding gain only. None of the codecs in question has this property. Thusly the calculated duration is a raw estimate - at best. Even more so after pushing it through the output muxer.
- The DTS coding scheme has a multiple frame sizes (but I may be wrong here)
@DanielaE - that's very much an issue. From what I've found the DTS-MA extended info is variable-length data. There's currently guesswork even in the AE code. More guesswork is involved in TrueHD decoding - both formats are locked at 16bit, and I have samples of TrueHD in 24bit.
As you say, there are hierarchy issues here - info should be passed from the decoder methods and instead is hard-coded after the fact in the audio handlers.