• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

How to feed reclock for TrueHD, DTSHD, EAC3 bitstream?

albain

Member
Thread Starter
Joined
Sep 27, 2009
Messages
14
Likes
0
Hi,

I am a FFDShow developer and we now have a TrueHD and dolby digital plus decoder (from ffmpeg team).

But we now would like to be able to bitstream those formats plus some others (DTSHD, LPCM) to the HDMI outputs in order to be decoded by the HT receiver.
Today, only a dedicated audio renderer as Reclock can do this.

Other audio renderers are commercial, so you're the only ones

I know that you made things to work with arcsoft total media theatre decoders.

Could you tell us what mediatypes and format tags, i.e how the directshow structure should be fed in for those formats ?

I saw that Reclock accept several mediatypes : DRM_Audio, IEEE_Float, SPDIF_Tag_241h...
which one of those should be used, maybe another (hidden) one ?

*EDIT* : I may have misunderstood, maybe this is not possible today to send a compressed format to reclock for bitstreaming ?

Thank you for your support

Regards,

Damien BT
 
Last edited:
When I saw this message this morning I thought I'd find Thousand of answers this evening...
Why isn't there any more interest ?
I'd die for such a fonctionality... :bowdown:
 
When I saw this message this morning I thought I'd find Thousand of answers this evening...
Why isn't there any more interest ?
I'd die for such a fonctionality... :bowdown:

Me too.

I've been really disappointed here :(
 
*EDIT* : I may have misunderstood, maybe this is not possible today to send a compressed format to reclock for bitstreaming ?

Correct. ReClock likes to receive already decoded LPCM data.
 
Correct. ReClock likes to receive already decoded LPCM data.

OK, but would it be possible to add DTSHD, TrueHD, EAC3, and maybe other mediatypes in the supported list so that they would be sent directly to HDMI output ? New radeon 5xxx will support it and it may be possible to add support on radeon 4xxx and of course the HDMI 1.3 audio cards

Today, the big lack on HTPCs is the bitstream support of compressed format, especially for DTSHD where no (opened) decoders are out yet.

This is possible only with a WASAPI audio renderer because of windows reenderer downgrades everything.

From Doom9 forum there is a big discussion going on on that subject : http://forum.doom9.org/showthread.php?t=120465&page=408

As far as I understand, adding those media types would be a first step, then the Reclock functionalities would be necessary to keep audio/video in sync, as you do for AC3/DTS.
But I may help on those parts, as I developed the FFDShow internal parsers on Dolby TrueHD, EAC3, and DTS-HD

Thank you for your interest

Regards,

Damien BT
 
James,

Do you confirm ReClock can make pass-through ac3 and dts over S-PDIF?

If the answer is "yes", i believe you are able to implement the same thing for HD audio formats over HDMI; no, i don't believe; i'm sure...

Sorry btw, our expectations are increasing day by day :)

take care.
 
James,

Do you confirm ReClock can make pass-through ac3 and dts over S-PDIF?

If the answer is "yes", i believe you are able to implement the same thing for HD audio formats over HDMI; no, i don't believe; i'm sure...

I'm in the same boat as OP albain - I don't know how to "tell" the driver.

@albain: maybe sending the bitstream as PCM through Wasapi exclusive (setting ReClock in a mode where it says "bit exact") will do the trick?
I used this method to verify ReClock's "bit exactness" by playing a DTS stream as wave. The receiver was able to detect and decode DTS. I don't know if this will work with HD formats, but if it does, this would allow bitstreaming with older ATI cards.
 
Exactly, this is my assertion

If you could add those media types in the list of accepted ones we could do the tests with it. Those are standards ones from Microsoft headers.

I have made FFDShow test builds with TrueHD/EAC3/DTS-HD passthrough

DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS ,0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD ,0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);
DEFINE_GUID(MEDIASUBTYPE_DTS_HD ,0xa2e58eb7, 0xfa9, 0x48bb, 0xa4, 0xc, 0xfa, 0xe, 0x15, 0x6d, 0x06, 0x45);

Thank you

Meanwhile, I am going to try a shot asking arcsoft about how they do this (moreover they managed to bring support for radeon HD5xxx whereas they were supposed to be bitstreamed with powerdvd only)
 
James,

Do you confirm ReClock can make pass-through ac3 and dts over S-PDIF?

If the answer is "yes", i believe you are able to implement the same thing for HD audio formats over HDMI; no, i don't believe; i'm sure...

I pass through AC-3 and DTS with ReClock and ATI 4670 HDMI, is that the same for your purposes? After one of the newer builds though, I had to set the SPDIF audio interface to WASAPI exclusive in order for it to work.
 
I'm in the same boat as OP albain - I don't know how to "tell" the driver.

@albain: maybe sending the bitstream as PCM through Wasapi exclusive (setting ReClock in a mode where it says "bit exact") will do the trick?
I used this method to verify ReClock's "bit exactness" by playing a DTS stream as wave. The receiver was able to detect and decode DTS. I don't know if this will work with HD formats, but if it does, this would allow bitstreaming with older ATI cards.

But the 4000 series cards can't take 24-bit audio for bit-exactness...
 
But the 4000 series cards can't take 24-bit audio for bit-exactness...

I don't know if the compressed bitsream really requires 24 bit audio. Actually, little do I know.... but I doubt it.
 
Exactly, this is my assertion

If you could add those media types in the list of accepted ones we could do the tests with it. Those are standards ones from Microsoft headers.

I have made FFDShow test builds with TrueHD/EAC3/DTS-HD passthrough

DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS ,0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD ,0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);
DEFINE_GUID(MEDIASUBTYPE_DTS_HD ,0xa2e58eb7, 0xfa9, 0x48bb, 0xa4, 0xc, 0xfa, 0xe, 0x15, 0x6d, 0x06, 0x45);

Thank you

Meanwhile, I am going to try a shot asking arcsoft about how they do this (moreover they managed to bring support for radeon HD5xxx whereas they were supposed to be bitstreamed with powerdvd only)

You don't need or want to use these for a test. I mean, just play the bitstream as if it is LPCM. Unfortunately I do not know how you must process it first with some kind of "SPDIFer" or "HDMIer" in this case. I can only assume (as I said, little do I know) that the bitstream is sent via HDMI with a constant bitrate and that the audio data needs to be "packetized" in some way. I haven't found good documentation for this, it is probably in the HDMI specs.
 
You're right, this a good idea : trick the renderer with PCM whereas this is compressed format

For SPDIF, it must be packetized indeed.

But for HDMI, I hope that "bitstream" really means what it is supposed to
Our internal parser will send the stream frame by frame so I hope that this will be enough

Thanks for your input !
 
You're right, this a good idea : trick the renderer with PCM whereas this is compressed format

For SPDIF, it must be packetized indeed.

But for HDMI, I hope that "bitstream" really means what it is supposed to
Our internal parser will send the stream frame by frame so I hope that this will be enough

Thanks for your input !

I assume HDMI must be packetized as well. Otherwise the decoder won't be able to distinguish PCM from coded "bitstream"....? Anyway, let me know what you find. If you can get it to work, I'll be happy to include native HD audio support.
 
This file may be helpful to someone trying to develop bitstreaming software:
http://www.hdmi.org/download/HDMISpecification13a.pdf

The most relevant info appears to be on page 79, 90, and 122-123. (Page numbers are based on the PDF file, not the numbers printed on the lower right corner.) It appears that high bitrate compressed audio uses a different packet header than LPCM and SPDIF. Packets are based on the IEC 60958 and IEC 61937 standards, which seem to describe I2S and SPDIF. There is some documentation in IEC 61937 about how DTS (including the HD variant) and "MAT/MLP" (TrueHD) is stored, but most of this is not freely available and I do not have access to it. Only the abstracts are available without paying IEC, not the details.
 
Hi James,

you were right about the encapsulation of the stream : it is required for compressed streams with IEC 61937 (after that the driver encasulates it in the HDMI format), which is the same encapsulation format as SPDIF, but it has been extended since for TrueHD, DTSHD, WMAPRO...
... however, as shown on the IEC webstore (http://webstore.iec.ch), all the technical data must be payed.

To conclude, we have the format for AC3/DTS over IEC 61937 but not for the others, so if you have technical specs about it, I would be grateful...
 
let s hope James have the contacts/network to provide you with this information.
 
Hi James,

you were right about the encapsulation of the stream : it is required for compressed streams with IEC 61937 (after that the driver encasulates it in the HDMI format), which is the same encapsulation format as SPDIF, but it has been extended since for TrueHD, DTSHD, WMAPRO...
... however, as shown on the IEC webstore (http://webstore.iec.ch), all the technical data must be payed.

To conclude, we have the format for AC3/DTS over IEC 61937 but not for the others, so if you have technical specs about it, I would be grateful...

Wonder whether this IEC61937-9_100_1198_CDV.pdf is relevant at all?
http://bbs.bylm.net/read.php?tid=314703
 
I guess it is, but I think that a subscription to the forum is necessary and this is in japanese
 
Back
Top