ffdshow tryout project : HD audio discussion

[Andy o]

Yeah, whurlston is using another player, but I'm using MPC-HC. Different renderers yield different degrees of this problem for me. madVR doesn't seem to have it, but VMR9 seems to make it worse. This doesn't seem to happen at all with 4000 cards.

[pcm1ke]

I still can't get m2ts files with TrueHD to be bitstreamed (using 5850 w/ latest mphc svn, ffdshow svn, all from xvidvideo.ru). DTS-MA is passed through no problem. In FFA I only have DTS-MA and TrueHD checked in the passthrough options. Where should I start reading to try and fix this? Thank you.

[Andy o]

I think you need to have AC3, E-AC3, TrueHD and possibly MLP (probably not this one, but just in case) enabled in the codecs section.

[albain]

Hello guys,

got your logs Seb, thank you again and again

I will analyze those today if I have some time but expect a feedback rather tomorrow

Have a nice day

[albain]

Okay, I had a quick look on it with a great tool (araxis merge) that makes comparisons, and guess what...

1/ The media types are identical except the mediasubtype but I don't think this is the cause (as the ATI receives different media types)
2/ The timestamp are identical : they are different in values but this is not what matters. The important is the delay between 2 consecutive timestamps and it is even

BUT :

3/ The bitstreams are mostly identical but not all the time :

For example FFDShow :

72F81F4E1104CC290001000000000000FEFEC029FE

TMT

72F81F4E1104D8290001000000000000FEFEC029FE

This should be the cuase, this is the coded length of the buffer which is part of the IEC header.

I will work on this later

Cheers

Damien

[Sebastiii]

Hi Damien

Cool that the log are usefull
And you find the way to make working, great and great again
And the log for DTS-MA and HR will it be usefull too ?

Thx again
And have a good launch and have a nice day too
Seb.

[Andy o]

Thanks a lot albain! Again.

[SamuriHL]

Originally Posted by albain

Okay, I had a quick look on it with a great tool (araxis merge) that makes comparisons, and guess what...

1/ The media types are identical except the mediasubtype but I don't think this is the cause (as the ATI receives different media types)
2/ The timestamp are identical : they are different in values but this is not what matters. The important is the delay between 2 consecutive timestamps and it is even

BUT :

3/ The bitstreams are mostly identical but not all the time :

For example FFDShow :

72F81F4E1104CC290001000000000000FEFEC029FE

TMT

72F81F4E1104D8290001000000000000FEFEC029FE

This should be the cuase, this is the coded length of the buffer which is part of the IEC header.

I will work on this later

Cheers

Damien

I guess I didn't look close enough. That's awesome that you found the difference. I hope you're able to find a fix for it! Thanks!!

[jimwhite]

Originally Posted by SamuriHL

Ah, Seb, you da man! The bitstream data is identical between the two. *HOWEVER*....

TMT3:

19:54:14-330 DumpWFEX
WAVEFORMATEX
  wFormatTag : WAVE_FORMAT_PCM
  Channels : 2
  Bits per sample : 16
  Samples per second :48000
  nBlockAlign : 4

ffdshow:

WAVEFORMATEX
  wFormatTag : 577
  Channels : 8
  Bits per sample : 16
  Samples per second :192000
  nBlockAlign : 16

This is the same kind of difference I saw between PDVD9 and ffdshow that albain said was crazy. So, maybe it's not so crazy after all. At least you were able to confirm the bitstream data blocks are identical, so, that's good. Thanks, Seb, nice work!!

It would seem that here, FFDshow is describing the actual sound stream (8ch) while TMT3 is descrining the AC3 type container which is always PCM stereo @ 48khz.

[SamuriHL]

Originally Posted by jimwhite

It would seem that here, FFDshow is describing the actual sound stream (8ch) while TMT3 is descrining the AC3 type container which is always PCM stereo @ 48khz.

It's very possible. It looks as though albain found the difference that's likely to be causing the problem, so, hopefully tomorrow he'll release an updated build for us to try. If this leads to better compatibility then it was worth the effort IMO.

[albain]

Hi, for now I didn't find out what makes that difference and that doesn't sound logical to me.

There are 4 hexa (2 bytes) after 72F81F4E1104 which is the size.
The bytes have to be swapped.
For example :
72F81F4E1104 C828
gives 28C8 = 10440 bytes = 12 extra bytes (0001000000000000FEFE just after) + size of the DTS block + size of DTS-HD block
This rule sound right and is respected most of the time.

But sometimes there is a difference on TMT logs : there are a few more bytes (4, 8, 12 it depends)

I thought that this was some kindof modulo but this isn't.

Weird....

[SamuriHL]

Uhhhh, that's not good. How do we figure out what those extra bytes are and what they should be and when they should be used?? Yikes.

[albain]

Those extra bytes are always there : they are 12 bytes long,

I made a little program to calculate the difference between the FFDShow size (size of the buffer actually) and TMT size which is higher sometimes :

Here is an extract.
Value 1 : length that is different sometimes
Value 2 : length of the buffer
Value 3 : value 2 - value 1 - 12 (the extra bytes)

When value 3 is 0, this is normal

3256;3236;8
5272;5248;12
5240;5220;8
5288;5264;12
5256;5240;4
5240;5220;8
5304;5280;12
5800;5776;12
5784;5764;8
5800;5788;0
5784;5764;8
5832;5820;0
5880;5864;4
5816;5792;12
5864;5848;4
5816;5792;12
5864;5852;0
5784;5764;8
5720;5704;4
5768;5744;12
5768;5752;4
5736;5720;4
5768;5744;12
5768;5744;12
5752;5740;0
5736;5720;4
5784;5760;12
...
...
17544;17520;12
17048;17036;0
17528;17508;8
17608;17592;4
17720;17700;8
17688;17664;12
18120;18104;4
17432;17416;4
17736;17716;8
17752;17728;12
17432;17420;0
17960;17940;8
17752;17728;12
17272;17248;12
18136;18116;8
17560;17544;4
17256;17244;0
17384;17360;12
17720;17704;4
17624;17612;0
17272;17256;4
17496;17476;8
17624;17612;0
16824;16812;0
17160;17140;8
17000;16984;4
17448;17424;12
17448;17436;0
17176;17164;0
16616;16596;8
17160;17136;12
17080;17064;4

[SamuriHL]

Um, that's a lot of "not normal" in there!

[albain]

I still think this is some kind of modulo because the values added are always 4, 8 or 12.

Maybe Madshi will have an idea (he found out for TrueHD!)

[SamuriHL]

I really hope so cause I'd love to see this issue get fixed so we have max compatibility.

[SamuriHL]

How is the buffer size calculated? I'd like to take a peak at this and see if I can see any kind of pattern in it that may help.

[BSalita]

Value1 = (Value2 & ~0xf) + 0x18

C'est vrai?

[albain]

Originally Posted by SamuriHL

How is the buffer size calculated? I'd like to take a peak at this and see if I can see any kind of pattern in it that may help.

Here is how it works

Each buffer is formatted as follows :

1/ 72F81F4E1104 : IEC header including format type
2/ calculated size (2 bytes or 4 hexas) : the size which is wrongly calculated by FFDShow.

This size corresponds to the bytes starting at 3/ (so it starts with the extra bytes)

3/ 0001000000000000FEFE : extra bytes (12 bytes)
4/ data size (2 bytes) sum of size of the DTS block + the DTS HD block. => normally this data size + 12 = calculated size.
After this data size (starting at 4/) you will get zeros to fill in the rest of the buffer which is always 32768 long
4/ DTS block starting with FE7F
5/ DTS HD block following starting with 58642520
68160001000000000000FEFE5016

[albain]

Originally Posted by BSalita

Value1 = (Value2 & ~0xf) + 0x18

C'est vrai?

You're right my friend !!!

I updated my little program and this formula works for every buffers !

Thank you so much!!