Kodi Community Forum
AudioEngine branch - DO NOT REQUEST BINARY BUILDS - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: AudioEngine branch - DO NOT REQUEST BINARY BUILDS (/showthread.php?tid=78289)



- ashlar - 2010-11-25

spiff Wrote:you know that anssi is a team member right? Smile
Big Grin You devil! Wink


- danconti - 2010-12-09

gnif Wrote:I got the new receiver today, very nice unit but wont be able to do anything for at-least a couple of days as I am out of town. Very excited to get things started, will be nice to finally have TrueHD support and DTS-MA working as they have been missing for a long time now.

hey,

i did all of the hd audio work in boxee. on my todo list is making a backport for xbmc, but since you guys are forking it's probably easier if i help where needed. i can check back here or you can get in touch with me, dan at boxee dot tv

one note - we didn't implement eac3 bitstream. on the box it's handled for us by the platform sdk, and on the desktop we don't have it. but i can certainly help out with dts-hd and truehd.

cheers


- erhnam - 2010-12-09

danconti Wrote:hey,

i did all of the hd audio work in boxee. on my todo list is making a backport for xbmc, but since you guys are forking it's probably easier if i help where needed. i can check back here or you can get in touch with me, dan at boxee dot tv

one note - we didn't implement eac3 bitstream. on the box it's handled for us by the platform sdk, and on the desktop we don't have it. but i can certainly help out with dts-hd and truehd.

cheers

Thanks for the support dan! Very nice!


- dlmh - 2010-12-14

danconti Wrote:hey,

i did all of the hd audio work in boxee. on my todo list is making a backport for xbmc, but since you guys are forking it's probably easier if i help where needed. i can check back here or you can get in touch with me, dan at boxee dot tv

one note - we didn't implement eac3 bitstream. on the box it's handled for us by the platform sdk, and on the desktop we don't have it. but i can certainly help out with dts-hd and truehd.

cheers

Will this allow for bitstreaming with Linux? Or just Windows?


- Anssi - 2010-12-15

For the record, and as a summary:
  • We know how to make E-AC-3 / DTS-HD / TrueHD bitstreaming work on Linux, and it is planned to implement this in AudioEngine (I've also confirmed the bitstream syntax with danconti).
  • Windows support is possible (MSDN), but this of course requires a Windows developer to do it Smile (which I am not)

E-AC-3 should work (at least on Linux) on all cards that have 192kHz stereo support, which is probably everyone except ATI cards (see below). Also (again, at least on Linux) DTS-HD streams that are below 6.144 Mbps should work on all cards that have 192kHz stereo support (i.e. e.g. ION / GF9400 is enough) (I tested with the only full-length sample I have and the stream never peaked over 6.144 Mbps for the duration of the movie, so these do exist). This is not possible for low-bitrate TrueHD streams, though.

Support status of full (over 6.144 Mbps) DTS-HD / TrueHD (from a driver/hw standpoint; not yet in XBMC):
  • NVIDIA GeForce 200 series works partially (I believe it is slightly buggy and it depends on the A/V receiver if it works or not), but on *Linux only*; the 200 series is not supported on Windows at all
  • NVIDIA GeForce 400 series works
  • ATI cards do not work on Linux; they seem to have a non-standard interface for anything else than 48kHz stereo audio, some information from AMD about that will be needed to get it working (or some serious trial-and-error by someone who has such a card Smile)
  • ATI cards work on Windows, but I don't know which ones have bitstreaming support
  • INTEL HDMI graphics chipsets that should work, at least on Linux: IbexPeak (0x80862804), CougarPoint
  • INTEL HDMI graphics chipsets that have no hw support: Cantiga, Eaglelake
  • INTEL HDMI graphics chipsets that I don't know about: Bearlake, IbexPeak (0x80860054), Crestline
Note that the NVIDIA information above is mostly gathered from the relevant nvnews.net and Phoronix threads. I could be wrong on the other entries as well, as this hasn't been very widely tested at this point (for example, no actual Intel testers).

You can check DTS-HD/TrueHD support on Linux by checking for "HBR" text in "Pincap" line in /proc/asound/cardX/codec#Y (as previously mentioned, low-bitrate DTS-HD can be done without HBR). For actually testing it, you can see the above threads (or just wait for XBMC to get support :p).


- Anssi - 2010-12-15

furii Wrote:i'm curious though. will adding the hd audio support to the AE branch allow for xbmc to differentiate between dts-hd and standard dts tracks in the ui? currently a dts-hd track in the mkv container still shows up as being a regular dts track. i assume that is just because there is not dts-hd support as of yet.
DTS-HD is just normal DTS with some extra data in the end, so it is a bit tricky to differentiate them. HD audio passthrough in AE will need to differentiate them, but we probably want a solution for the UI that does not depend on passthrough Smile

I guess this could be added as some extra check for a DTS-HD signature at the DTS stream when probing the streams. However, this is not dependant or related to the AE branch, AFAICS.

Also, there is the issue if we should show the stream as DTS-HD in the UI if we are only going to decode the DTS core part (which is done when HD passthrough is not in use), and the stream information (channel count, sample rate) is really the information from the DTS core, not DTS-HD... So it is, as usual, not simple at all Smile


- furii - 2010-12-15

Anssi Wrote:DTS-HD is just normal DTS with some extra data in the end, so it is a bit tricky to differentiate them. HD audio passthrough in AE will need to differentiate them, but we probably want a solution for the UI that does not depend on passthrough Smile

I guess this could be added as some extra check for a DTS-HD signature at the DTS stream when probing the streams. However, this is not dependant or related to the AE branch, AFAICS.

Also, there is the issue if we should show the stream as DTS-HD in the UI if we are only going to decode the DTS core part (which is done when HD passthrough is not in use), and the stream information (channel count, sample rate) is really the information from the DTS core, not DTS-HD... So it is, as usual, not simple at all Smile

thanks for the info. from my point of view the ui should differentiate between dts and dts-hd tracks, and ac3/truehd for that matter. in its current form xbmc shows you what audio codec a file has, regardless of the format it is output as to the user. for instance flac decoded as pcm, or even an ac3 or dts track decoded to pcm if a user does not have an ac3 or dts capable receiver.

(i must admit my reason for wanting this is selfish Smile a good majority of my remuxes use the core dts track, however in recent months i've gotten lazy, and less worried about saving hard drive space, and just used the dts-hd track. now that bitstreaming hd audio is on the horizon i'd love to know at a glance which movies are remuxed with the core track vs. the hd track)


- liquidskin76 - 2010-12-15

Anssi Wrote:[*]Windows support is possible (MSDN), but this of course requires a Windows developer to do it Smile (which I am not)
[/LIST]

Albain (the dev who did Windows/ffdshow hd audio bistreaming) is now a member of the forum. Maybe someone on the xbmc team can persuade him?! Nod


- ArtVandelae - 2010-12-15

Anssi Wrote:For the record, and as a summary:
  • Windows support is possible (MSDN), but this of course requires a Windows developer to do it Smile (which I am not)

I have a patch for the Windows audio sinks that I've been meaning to get submitted and one of the things that I added was code to do bitstreaming of the new "HD" formats. I'll get it cleaned up and submitted soon.


- SpectreX - 2010-12-16

Anssi Wrote:For the record, and as a summary:
  • We know how to make E-AC-3 / DTS-HD / TrueHD bitstreaming work on Linux, and it is planned to implement this in AudioEngine (I've also confirmed the bitstream syntax with danconti).
  • Windows support is possible (MSDN), but this of course requires a Windows developer to do it Smile (which I am not)

E-AC-3 should work (at least on Linux) on all cards that have 192kHz stereo support, which is probably everyone except ATI cards (see below).

Support status of DTS-HD / TrueHD (from a driver/hw standpoint; not yet in XBMC):
  • NVIDIA GeForce 200 series works partially (I believe it is slightly buggy and it depends on the A/V receiver if it works or not), but on *Linux only*; the 200 series is not supported on Windows at all
  • NVIDIA GeForce 400 series works
  • ATI cards do not work on Linux; they seem to have a non-standard interface for anything else than 48kHz stereo audio, some information from AMD about that will be needed to get it working (or some serious trial-and-error by someone who has such a card Smile)
  • ATI cards work on Windows, but I don't know which ones have bitstreaming support
  • INTEL HDMI graphics chipsets that should work, at least on Linux: IbexPeak (0x80862804), CougarPoint
  • INTEL HDMI graphics chipsets that have no hw support: Cantiga, Eaglelake
  • INTEL HDMI graphics chipsets that I don't know about: Bearlake, IbexPeak (0x80860054), Crestline
Note that the NVIDIA information above is mostly gathered from the relevant nvnews.net and Phoronix threads. I could be wrong on the other entries as well, as this hasn't been very widely tested at this point (for example, no actual Intel testers).

You can check DTS-HD/TrueHD support on Linux by checking for "HBR" text in "Pincap" line in /proc/asound/cardX/codec#Y. For actually testing it, you can see the above threads (or just wait for XBMC to get support :p).

The Ati HD5xxx/6xxx series support HD audio bistreaming, the 4xxx series and below support lossy DTS/DD only (and PCM)


- Anssi - 2010-12-16

Anssi Wrote:E-AC-3 should work (at least on Linux) on all cards that have 192kHz stereo support, which is probably everyone except ATI cards (see below).
Actually, this is enough for less-than-6.144-Mbps DTS-HD streams as well. I.e. e.g. GF9400 / ION cards can do that. (I tested with one full-length sample, and it never peaked above 6.144 Mbps)


- Targettio - 2010-12-16

Great work, keep it up Big Grin


- dlmh - 2010-12-16

Will these patches find their way into custom XBMC builds (for Windows/Linux)? Or will I have to compile these myself?


- danconti - 2010-12-16

the windows support is very straight forward since you are packetizing already. it is a few different calls to set up the audio device with the proper clocking data for hdmi, that is all.

getting the right stream info is a bigger problem. ffmpeg does not have a DTS-HD codec type and doesn't know how to probe. i think patching ffmpeg to cover both of these is probably the right call. otherwise you are always dealing with the wrong data from the demuxer. it also saves you a lot of runtime detection logic down the road (where you have to save off DTS frames for a while until you get a DTS-HD frame so you can decide how to bitstream, etc.)

note that there is no rule that the dts and dts-hd packets come in pairs at the start of the stream (i have seen some where we get 4-5 dts packets before seeing a dts-hd one).

you do need to check for dts-hd streams if you are decoding dts in software, otherwise it's a huge perf penalty of trying to sync dts on every byte of the hd frame. you also need to check if you are bitstreaming just the dts-core track (either over spdif or hdmi) and peel off the hd frames in that scenario too.

parsing the dts-hd frame is pretty simple - 10 lines of code to check the syncword and calculate the frame size.


- Anssi - 2010-12-16

danconti Wrote:note that there is no rule that the dts and dts-hd packets come in pairs at the start of the stream (i have seen some where we get 4-5 dts packets before seeing a dts-hd one).
Does there exist a sample showing this?

If we are going to add DTS-HD probing to ffmpeg (not sure yet), we are going to need to decide how much dts data without dts-hd should be read before we can trust the stream is non-dtshd.