ffdshow tryout project : HD audio discussion

[SamuriHL]

I'll try it with PDVD9 and my ATI shortly. I've had enough fun with the Xonar anyway. We've confirmed the exact same problem with DTS-HD MA on both cards so I can safely go back to my regularly scheduled single card solution. I'll leave the Xonar installed for now, but, eventually it'll come back out as it's really not needed anymore.

[Perls]

I'm using a 4550 card so I can't test the HD formats, but
- software decoding and a3 passthrough over hdmi with ffdshow -> dropouts
- software decoding and ac3 passthrough over hdmi with ac3filter -> ok
So maybe not everything should be put down on the ati driver...

A reboot fixed the issue with ffdshow, so the problem was probably related to something not being cleaned up properly after a lot of setting changes. Sorry if I caused confusion.

[rica]

By Arcsoft Jason:

ArcSoft is happy to announce support for bistreaming HD Audio on ATI 5xxx series cards.

This feature will be on display in ArcSoft's suite at CES along with a variety of other technology. If you're attending the show,
you'll need to contact ArcSoft's sales/marketing group with your business or media credentials for an appointment to see a demonstration.

I don't believe it will be available for walk-up viewing on the show floor.

The feature will be included in an upcoming release of the retail version of TMT3 along with similar support for bitstreaming on Intel's codename Clarkdale/Ironlake hardware.

Some of the other demos will be revealed in press releases over the coming days, but one was not scheduled for this particular item. I recieved permission to share the details today
given the lack of a more official announcement.

Some media contacts are already lined up to see the full array of demos, so watch the usual places to see if any further details surface after the show gets rolling.

Guys i hope Arcsoft will be ready after CES.

[Sebastiii]

Good news :) Thx Rica :)

[SamuriHL]

See....the speculation about CES was good, no? ;) It made sense that they would announce it there. Now we wait for the release to come. Considering it's been several months, I'd say we're likely to see one by the end of the month, but, that is again speculation. :)

[rica]

Considering it's been several months, I'd say we're likely to see one by the end of the month, but, that is again speculation. :)

I don't know Jason personally but i think i've recognized him.
Believe me i don't think it's a speculation.

[SamuriHL]

I don't know Jason personally but i think i've recognized him.
Believe me i don't think it's a speculation.

It's speculation cause none of us have any inside information that I'm aware of. We can only assume that because it's been several months, that a new build has to be coming soon, and that it'll likely contain bitstreaming support for ATI and Clarkdale. Unless you have confirmed information that we don't know about? Jason hasn't said anything that I'm aware of about when to expect a new release. Did I miss something?

[rica]

He didn't want to say anything. :)

[SamuriHL]

Who can blame him? :) He doesn't actually work on TMT. He just helps out in the forum for that product. He's been a HUGE advocate for us end users. As a result, TMT3 has gotten remarkably better over time. And now it's about to get better still. It's still without any doubt my favorite player. PDVD9 is decent, but, lacks a lot compared to TMT. Of course, ffdshow ROCKS and being able to bitstream files, discs, and mounted ISOs is absolutely awesome.

[mikelebron]

See midway down:
http://www.arcsoft.com/forum/forum_posts.asp?TID=3680&PN=20

Its confirmed at CES

It's speculation cause none of us have any inside information that I'm aware of. We can only assume that because it's been several months, that a new build has to be coming soon, and that it'll likely contain bitstreaming support for ATI and Clarkdale. Unless you have confirmed information that we don't know about? Jason hasn't said anything that I'm aware of about when to expect a new release. Did I miss something?

[SamuriHL]

See midway down:
http://www.arcsoft.com/forum/forum_posts.asp?TID=3680&PN=20

Its confirmed at CES

Ah, I see, no that's not what I was referring to for speculation. I know that the feature is confirmed, however, WHEN it gets released to the public is what's in question now. :) My guess says it'll be available this month, but, that's, again, speculation.

[rica]

Samuri, my friend:
it was impossible for PDVD for you too before you bought it :p
So i suppose PayPal has missed you in advance :)

[SamuriHL]

LOL! PDVD has certainly been a decent player for the past few weeks, but, it's not without its flaws. Still, I'm not unhappy that I bought it again. The fact that I now have SO many choices for bitstreaming with my 5870 is superb!!!

[rica]

The fact that I now have SO many choices for bitstreaming with my 5870 is superb!!!

agreed :)

[Andy o]

A reboot fixed the issue with ffdshow, so the problem was probably related to something not being cleaned up properly after a lot of setting changes. Sorry if I caused confusion.

Thanks for letting us know! That was one piece of the puzzle that didn't fit.

So, guys, I think it's safe to say now that this DD/DTS dropout problem is a 5000 series problem.

[SamuriHL]

Thanks for letting us know! That was one piece of the puzzle that didn't fit.

So, guys, I think it's safe to say now that this DD/DTS dropout problem is a 5000 series problem.

Stellar. :rolleyes:

[kkozma]

So is the bitstream support for Arcsoft going to be available as a patch to current users because I *JUST* bought tmt3 last week even though I said I wasn't going to...

[rica]

So is the bitstream support for Arcsoft going to be available as a patch to current users because I *JUST* bought tmt3 last week even though I said I wasn't going to...

I hope so.

[SamuriHL]

No hope required. Yes, it will be in a future patch for TMT3.

[rica]

So, guys, I think it's safe to say now that this DD/DTS dropout problem is a 5000 series problem.

I can't say it's safe to say....

[David602]

Samuri and others,

Since some of you have now compared using a Xonar with a commercial player (TMT/PDVD) vs. FFDSHOW, have you noticed any difference in sound quality?

I know that technically its bitstreaming and the receiver is decoding it but I just wanted to make sure there wasn't a difference.

Is FFDSHOW really as good as TMT in handling the audio?

I'm also curious about the video side of things. I've been very happy with TMT3's video quality and i'm trying to confirm that MPC's video quality will be as good. I've been using the gabest/MPC codecs and so far things look good but I haven't done extensive testing. I had to enable alternative vsync to smooth things out but again, i've only played a few clips. Has anyone tried CoreAVC 2.0?

The reason I ask is because I have all my BD rips in ISO and I'm considering making the jump to MKV for faster loading (TMT3 + VCD takes like 15-20 seconds just to load an image) and I want to make sure I'm not losing on quality.

[David602]

Yes i made log, i just verify with ffdshow the number channel detection.
With TMT3 the sample is play fine :) 7.1 DTS-HR detected by my AVR :)

So the link to the iso that i use :) ISO DTS-HR 7.1 (http://sebinternet.free.fr/test_7.1_dts-hd_hr.iso) and M2TS DTS-HR 7.1 (http://sebinternet.free.fr/test_7.1_dts-hd_hr.m2ts)


Thanks for these samples. I'm trying to confirm MPC/FFDSHOW works for E-AC3 on my system.

Do you have any E-AC3 / Dolby Digital + samples? The only content with E-AC3 that I have are HD-DVDs in EVO and TMT3 plays it as LPCM.

I haven't been successful in muxing it from the .EVO container into .MKV or .m2ts for testing with MPC/FFDSHOW yet. If you have any ideas on this, please let me know. I've tried BDClown, EAC3to cmd line and MAKEMKV so far...

[rica]

Samuri and others,

Since some of you have now compared using a Xonar with a commercial player (TMT/PDVD) vs. FFDSHOW, have you noticed any difference in sound quality?

I know that technically its bitstreaming and the receiver is decoding it but I just wanted to make sure there wasn't a difference.

Is FFDSHOW really as good as TMT in handling the audio?

I'm also curious about the video side of things. I've been very happy with TMT3's video quality and i'm trying to confirm that MPC's video quality will be as good. I've been using the gabest/MPC codecs and so far things look good but I haven't done extensive testing. I had to enable alternative vsync to smooth things out but again, i've only played a few clips. Has anyone tried CoreAVC 2.0?

The reason I ask is because I have all my BD rips in ISO and I'm considering making the jump to MKV for faster loading (TMT3 + VCD takes like 15-20 seconds just to load an image) and I want to make sure I'm not losing on quality.

On the audio side no difference since both applicatons bitstream and the the resulting quality is up to the decoder of your AVR.
On the video side it is up to you. You may select different video decoders you wish in MPC-HC. (DXVA mode must be selected for the time being btw.)

[SamuriHL]

Samuri and others,

Since some of you have now compared using a Xonar with a commercial player (TMT/PDVD) vs. FFDSHOW, have you noticed any difference in sound quality?

I know that technically its bitstreaming and the receiver is decoding it but I just wanted to make sure there wasn't a difference.

Is FFDSHOW really as good as TMT in handling the audio?

I'm also curious about the video side of things. I've been very happy with TMT3's video quality and i'm trying to confirm that MPC's video quality will be as good. I've been using the gabest/MPC codecs and so far things look good but I haven't done extensive testing. I had to enable alternative vsync to smooth things out but again, i've only played a few clips. Has anyone tried CoreAVC 2.0?

The reason I ask is because I have all my BD rips in ISO and I'm considering making the jump to MKV for faster loading (TMT3 + VCD takes like 15-20 seconds just to load an image) and I want to make sure I'm not losing on quality.

Rica pretty much summed up my thoughts on this, as well. Bitstreaming is bitstreaming so the quality is literally identical. However, I want to share a thought with you and whoever else is wondering about ffdshow vs TMT vs PDVD vs WinDVD. TMT/PDVD/WinDVD all have to "play by the rules". This means they are inundated with tons of security layers, extra crap they have to do in order to protect the streams, and all that fun nonsense. Each layer adds another potential area to break. albain's amazing work on ffdshow is pure. It's a soup to nuts solution that simply implements bitstreaming at a very basic level without PAP, protection of AACS keys in memory, protection against debugging of any kind, etc. As such it's lighter code, easier to maintain code if something should break, and all around just a better approach. It's the approach all the commercial guys WISH they could take.

Rica also summed up the video side of things quite well, as well. You have LOTS of options here. Using MPC-HC's built in DXVA solutions (or albain's new DXVA ffdshow implementation) you're going to get the same quality video as the commercial guys. CPU usage will be non-existent for the most part with bitstreaming + ffdshow. Another benefit (for some) is that mpc-hc simply jumps to playing the movie. No ads. No menus. No BS. Just put the disc in, select it, and watch the movie.

In short, MPC-HC + ffdshow gives you a no nonsense, easy to use, *FREE*, playback solution that is as easy or complex as you want to make it. Having this as an option...I can't see that as a bad thing. At all.

[rica]

Thanks for these samples. I'm trying to confirm MPC/FFDSHOW works for E-AC3 on my system.

Do you have any E-AC3 / Dolby Digital + samples? The only content with E-AC3 that I have are HD-DVDs in EVO and TMT3 plays it as LPCM.

I haven't been successful in muxing it from the .EVO container into .MKV or .m2ts for testing with MPC/FFDSHOW yet. If you have any ideas on this, please let me know. I've tried BDClown, EAC3to cmd line and MAKEMKV so far...

Demux them to individual media files via eac3to and remux to mkv with MkvToolnix.

[rica]

In short, MPC-HC + ffdshow gives you a no nonsense, easy to use, *FREE*, playback solution that is as easy or complex as you want to make it. Having this as an option...I can't see that as a bad thing. At all.

Samuri summed up everything, great :thanks:

[Andy o]

I can't say it's safe to say....

Why? Is anyone else with a 4000 series having this exact same problem, or is anyone with a 5000 series not?

[rica]

Why? Is anyone else with a 4000 series having this exact same problem, or is anyone with a 5000 series not?

Again:

I just tested this using a recorded show (1080i MPEG2/AC3) using the MPC-HC MPEG2 Video Decoder (Gabest) and ffdshow audio decoder (SVN 3164, AC3 bitstream) and I don't get any dropouts at all. I tested using GraphStudio and the 5770 w/ 9.12.

[Andy o]

He's using another player. I don't have the problem even with MPC-HC and madVR. It might be a renderer problem, but the fact is that so far it's only happening with 5000 cards.

[rica]

I thought you are talking about MPC-HC :)
Dunno what player he uses but i thought we were talking about the difference between 5*** and 4*** series cards' capabilities on MPC-HC?

[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]

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]

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.

:cool:

[SamuriHL]

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.

:cool:

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]

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]

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!!