Decoding DTS-HD via external decoder

[personaone]

Hi Guys,

More of a feature request: any chance there would be an option to decode DTS-HD using an external dll on Windows? This is something that's possible with Lav filters, cheers.

[ghost]

Which dll?

[rossy]

LAV uses Arcsoft's dtsdecoderdll.dll to decode DTS-HD MA. eac3to and MakeMKV use it too. It's closed source, but it was distributed for free with the trial version of TotalMedia Theatre. Unfortunately, it was for 32-bit Windows only. It would be interesting to add support for it to mpv, but it would probably require a lot of complexity to get it to work on Linux, OS X and 64-bit Windows. (MakeMKV can do it by decoding audio in an external 32-bit process.)

[ghost]

I'd rather wait until DTS-MA support is added to Libav (there's a patch). The patch is not bit-exact yet, but only dumbass audiophiles would pretend to be able to hear the difference.

[personaone]

Ah so it's being worked on. Hear the difference or not - just for completions sake I think that's good. Anyway closing this since it's matter of Libav getting this included. Cheers.

[foo86]

Just a side note: I've been working on a bit-exact DTS-HD MA decoder lately. Still experimental, but it already works for a lot of sample files I've tested and gives bit accurate results. It is a standalone command line application, so you can't use it to decode DTS-HD MA in realtime. But you can use it to convert MA track to FLAC for example and then add it as external audio track in mpv.

[ghost]

@foo86: well, that's interesting... though you couldn't have picked a worse language. (Well, maybe PHP...)

[foo86]

Sorry, but I used this project as an opportunity to learn new programming language, so I chose D. I didn't actually find it bad language at all. Sure, it's less portable than C and it's standard library (phobos) sucks, but the language itself is quite neat.

[ghost]

Sorry, but I used this project as an opportunity to learn new programming language, so I chose D. I didn't actually find it bad language at all. Sure, it's less portable than C and it's standard library (phobos) sucks, but the language itself is quite neat.

I've abandoned this language after I wrote a 100kloc project in it, and noticed how absolutely shitty the compiler and the language's corner cases are. Also, for practical use, the DTS code has to be converted to C (so that other projects actually can use it, especially without randomly freezing the whole process), so no matter.

[foo86]

Also, for practical use, the DTS code has to be converted to C (so that other projects actually can use it, especially without randomly freezing the whole process), so no matter.

OK, so I have converted the decoder into C, rewrote it in a more library-like fashion internally and added support for High-Resolution audio extensions that were previously missing. This is not a proper shared library yet, but can be converted into one if there are projects actually willing to use it. Before that I need to decide on API (there is a draft here but this is probably garbage) and fix some important things like error and seeking recovery mechanisms.

[ghost]

That's some really pretty awesome work! I don't know DTS, so I can't say anything about

The API looks a bit complicated: the decode function (dcadec_context_filter) has a lot of output parameters, and they overlap with two other info functions. Also I think it should provide some way to do zero-copy decoding (maybe allow the user to provide his own buffer). But it already looks pretty usable.

I'd suggest aiming to integrate your decoder into libavcodec (either as a wrapper to your lib, or merging your work or parts of it into libavcodec). I think Libav is quite interested in this decoder. They've also had someone add DTS-MA support to libavcodec's own decoder (and it will be merged soon), but it's not bitexact. AFAIK this is because the libavcodec decoder uses float instead of fixed point. You can also join #libav-devel on freenode or post on their mailing list to ask for advice.

Anyway, quite impressive. Sorry, my initial reaction was being sour on D.

[foo86]

That's some really pretty awesome work!

Thanks! Spent quite some time on it.

The API looks a bit complicated: the decode function (dcadec_context_filter) has a lot of output parameters, and they overlap with two other info functions.

I agree that having many output parameters is quite ugly. But the obvious winapi-like alternative of filling a user supplied structure is frowned upon is OSS I think.

Also I think it should provide some way to do zero-copy decoding (maybe allow the user to provide his own buffer).

Maybe, need to wrap my head around it.

I'd suggest aiming to integrate your decoder into libavcodec (either as a wrapper to your lib, or merging your work or parts of it into libavcodec). I think Libav is quite interested in this decoder.

Having a wrapper in libavcodec is an interesting option. Actually, over a year ago, when I did my first take on implementing DTS-HD MA decoder, I tried to base it on libavcodec implementation, but quickly realized this was not going anywhere as too many changes were required. Starting from scratch this year was much easier.

They've also had someone add DTS-MA support to libavcodec's own decoder (and it will be merged soon), but it's not bitexact. AFAIK this is because the libavcodec decoder uses float instead of fixed point.

Yes, that's because of floating point used for all DTS core computations and a different IDCT algorithm used. Also I think libavcodec has some output gain problem with DTS (it sounds louder than it should).

Anyway, quite impressive. Sorry, my initial reaction was being sour on D.

No problem at all, it actually motivated me to do a rewrite in C.

[kevmitch]

fyi: vlc has a 4000 € bounty on this if you need further motivation.

[ghost]

I agree that having many output parameters is quite ugly. But the obvious winapi-like alternative of filling a user supplied structure is frowned upon is OSS I think.

I don't think there's any API design specific to OSS. I don't think it'd be a problem to let your library return a pointer to a struct, which has all the information. (Then you could even add new fields to the struct without breaking ABI.)

For doing zero-copy, you could do one of two things:

• allow the user to allocate his sample data
• allocate it in the lib, and provide a function to free it (and make it the user's responsibility)

Both would work well with libavcodec's AVFrame refcounting.

Anyway, it's not important, so better don't think about it. Audio isn't even that big in volume, and there are likely more important things. I just think it'd be nice.

Having a wrapper in libavcodec is an interesting option. Actually, over a year ago, when I did my first take on implementing DTS-HD MA decoder, I tried to base it on libavcodec implementation, but quickly realized this was not going anywhere as too many changes were required. Starting from scratch this year was much easier.

I think it's likely that they would accept a wrapper for your lib. They want to improve their own decoder, but say a wrapper would be an acceptable temporary solution. In fact, I'd volunteer for writing such a patch.

fyi: vlc has a 4000 € bounty on this if you need further motivation.

Sounds like he has a chance to cash it in. There are other contenders, though. For example, the pending lavc patch "almost" decodes master audio.

[ghost]

PS: did you think about changing the license something like LGPL? This way, evil proprietary apps could use this decoder (but also other open source projects which dislike GPL).

[foo86]

I don't think it'd be a problem to let your library return a pointer to a struct, which has all the information. (Then you could even add new fields to the struct without breaking ABI.)

Might be the way to go.

I think it's likely that they would accept a wrapper for your lib. They want to improve their own decoder, but say a wrapper would be an acceptable temporary solution. In fact, I'd volunteer for writing such a patch.

That would be great.

fyi: vlc has a 4000 € bounty on this if you need further motivation.

Sounds like he has a chance to cash it in. There are other contenders, though. For example, the pending lavc patch "almost" decodes master audio.

Didn't know the bounty existed. I wonder if it includes lossless decoding requirement or not. From the wording it seems it doesn't, thus I'm probably late with this :)

PS: did you think about changing the license something like LGPL? This way, evil proprietary apps could use this decoder (but also other open source projects which dislike GPL).

I don't have strong objections to proprietary apps using it, the decoder can be relicensed as LGPL if/when released as a library.

[ghost]

I wonder if it includes lossless decoding requirement or not.

Probably does.

the decoder can be relicensed as LGPL if/when released as a library.

Nice.

[ghost]

The FFmpeg wrapper for foo86's libdcadec was merged. If FFmpeg was built with it, you can use it with --ad=lavc:libdcadec (otherwise the libavcodec native decoder will be used).

@foo86: great work. There were comments about how clean your code is, especially compared to lavc's decoder.