View Full Version : ffdshow tryouts project: Discussion & Development
SamuriHL
16th November 2009, 14:43
Nope. No change. I'll post logs if you need them, but, testing the release version with TrueHD and DTS-HD MA tracks I get exactly the same situation as before. DTS only light, no audio. TrueHD light, no audio.
albain
16th November 2009, 15:37
I have another hope on the dumper tool to retrieve the buffering values that I need for wasapi
Could you post the logs for truehd ? (I need those to check the delays) Thanks
Also maybe the 5xxx drivers are buggy, there is no compatible & working bitstream player yet
This is the reason why the dumper is still useful : with the right values, if the renderer work with the xonar and not on the ati then the ati driver is faulty
SamuriHL
16th November 2009, 15:42
http://pastebin.com/pastebin.php?dl=d5abd370d
TrueHD with debug renderer.
SamuriHL
16th November 2009, 15:43
Also, has anyone used Process Hacker before? It's a source forge task manager replacement. On 32 bit it says it can unprotect and protect processes. Might be useful.
Skinleech
16th November 2009, 17:27
Also, has anyone used Process Hacker before? It's a source forge task manager replacement. On 32 bit it says it can unprotect and protect processes. Might be useful.
I'll give it a blast, but looks like it prob won't unprotect on 64 bit.
SamuriHL
16th November 2009, 17:31
I'll give it a blast, but looks like it prob won't unprotect on 64 bit.
Yea, that was my thought, too. It doesn't seem to even show the options on 64 bit from what I can see. But, it's at least another tool that the 32 bit users can play with.
albain
16th November 2009, 18:54
Hi,
thanks to Sebastii we have the new logs, this will help to make bitstream work for the xonar
The same waveformat tag is used for DTSHD,TrueHD and EAC3
More insteresting :KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL is used for all bitstream formats (and I didn't try that one in my betas).
One weird thing : IAudioClient is loaded but no IAudioRenderClient is raised (loaded from IAudioClient), which is necessary for wasapi. So maybe wasapi is not used after all (asio ?). I am lacking of skills on that part
Any expert point of view ?
I will build a new FFDShow with this new structure in output
For all : TrueHD/DTSHD/EAC3
Format type : FORMAT_WaveFormatEx
Sub type : KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL
TrueHD
WAVEFORMATEX
wFormatTag : 577
Channels : 8
Bits per sample : 16
Samples per second :192000
nBlockAlign : 16
DTSHD MA
WAVEFORMATEX
wFormatTag : 577
Channels : 8
Bits per sample : 16
Samples per second :192000
nBlockAlign : 16
DTSHD Hires
WAVEFORMATEX
wFormatTag : 577
Channels : 8
Bits per sample : 16
Samples per second :192000
nBlockAlign : 16
EAC3
WAVEFORMATEX
wFormatTag : 577
Channels : 2
Bits per sample : 16
Samples per second :192000
nBlockAlign : 4
SamuriHL
16th November 2009, 18:57
Fascinating. I wish I had the knowledge you're looking for. I'm glad his new log helped you though. Maybe it'll help the 5xxx bitstreaming, as well. If they're not using WASAPI excl mode, though, how are they bypassing the windows audio stuff?
Sebastiii
16th November 2009, 19:12
Great news :)
Coooooooool :)
Seb.
madshi
16th November 2009, 19:13
Fascinating. I wish I had the knowledge you're looking for. I'm glad his new log helped you though. Maybe it'll help the 5xxx bitstreaming, as well. If they're not using WASAPI excl mode, though, how are they bypassing the windows audio stuff?
The windows audio stuff can't do damage to bitstream. Unless you suggest that they decode the bitstream, process the PCM data and then recompress to TrueHD/DTS-HD bitstream on the fly... ;)
SamuriHL
16th November 2009, 19:14
The windows audio stuff can't do damage to bitstream. Unless you suggest that they decode the bitstream, process the PCM data and then recompress to TrueHD/DTS-HD bitstream on the fly... ;)
No, I'm not suggesting that. However, if that's the case then we shouldn't need an audio renderer using wasapi excl mode.....right?
mrcorbo
16th November 2009, 19:16
Fascinating. I wish I had the knowledge you're looking for. I'm glad his new log helped you though. Maybe it'll help the 5xxx bitstreaming, as well. If they're not using WASAPI excl mode, though, how are they bypassing the windows audio stuff?
S/PDIF bitstream output has worked with standard renderers all along. I'd expect the new formats are just an extension of that functionality.
A WASAPI+exclusive renderer may still be a way for devices that don't have explicit support to bitstream the new HD formats (by spoofing as Multichannel PCM). I loaded up the old beta 9 build and even with all the changes to the renderer this still gives me a stream out of my 4870 that is detected as TrueHD by my receiver. It doesn't make any sound, but it's something. :) Also, an open source WASAPI+exclusive renderer is a worthy project for its own sake.
SamuriHL
16th November 2009, 19:18
S/PDIF bitstream output has worked with standard renderers all along. I'd expect the new formats are just an extension of that functionality.
A WASAPI+exclusive renderer may still be a way for devices that don't have explicit support to bitstream the new HD formats (by spoofing as Multichannel PCM). I loaded up the old beta 9 build and even with all the changes to the renderer this still gives me a stream out of my 4870 that is detected as TrueHD by my receiver. It doesn't make any sound, but it's something. :) Also, an open source WASAPI+exclusive renderer is a worthy project for its own sake.
I would agree in theory, however, the wasapi excl renderer is complicating things right now when we should be trying to simplify. First rule of development...simplify simplify simplify. (Henry David Thorough was a genius and ahead of his time, I tell you. :D) If we don't NEED it right now, I suggest maybe we do without it for now. If that's possible.
madshi
16th November 2009, 19:25
I would agree in theory, however, the wasapi excl renderer is complicating things right now when we should be trying to simplify. First rule of development...simplify simplify simplify. (Henry David Thorough was a genius and ahead of his time, I tell you. :D) If we don't NEED it right now, I suggest maybe we do without it for now. If that's possible.
I guess that albain thought WASAPI exclusive mode would be necessary to bitstream TrueHD/DTS-HD. Now if it's not that simplifies things, of course. But for LPCM + FLAC etc playback it would still be very nice to have WASAPI exclusive mode.
whurlston
16th November 2009, 19:51
I loaded up the old beta 9 build and even with all the changes to the renderer this still gives me a stream out of my 4870 that is detected as TrueHD by my receiver. It doesn't make any sound, but it's something. :) I know I got these results previously but I can't get them now for some reason. Which driver are you using?
SamuriHL
16th November 2009, 20:01
I guess that albain thought WASAPI exclusive mode would be necessary to bitstream TrueHD/DTS-HD. Now if it's not that simplifies things, of course. But for LPCM + FLAC etc playback it would still be very nice to have WASAPI exclusive mode.
Absolutely agree that wasapi excl would be nice for LPCM, but, in order to get past the bitstreaming hurdles it might make sense to forget about it for the moment and revisit it when bitstreaming support is done. Is there a way to test this theory? What audio renderer could I use to try bitstreaming without wasapi excl mode? It'd still need to know about the bitstream types and pass them, right? So, I'm guessing we still need some custom renderer to do this? (As you can probably tell, my knowledge on this stuff is pretty much near 0. :))
SamuriHL
16th November 2009, 20:08
Well, removing the MPC audio renderer that albain gave us and using MPC-HC's default (output to system default), I get the exact same results as with the custom renderer, except, in the case of DTS-HD MA, I actually get DTS core audio bitstreamed. So no audio in TrueHD, but, the TrueHD light comes on. So it would seem that you are correct that wasapi excl does not seem to be necessary, but, there's still a bug somewhere preventing it from working. And why is it only seeing DTS on DTS-HD MA tracks?
mrcorbo
16th November 2009, 20:58
Well, removing the MPC audio renderer that albain gave us and using MPC-HC's default (output to system default), I get the exact same results as with the custom renderer, except, in the case of DTS-HD MA, I actually get DTS core audio bitstreamed. So no audio in TrueHD, but, the TrueHD light comes on. So it would seem that you are correct that wasapi excl does not seem to be necessary, but, there's still a bug somewhere preventing it from working. And why is it only seeing DTS on DTS-HD MA tracks?
Interesting results. Clearly there's still a missing ingredient or two. Still, the fact that a normal renderer can get a TrueHD syream through (even a malformed one) is encouraging, though
SamuriHL
16th November 2009, 21:01
Interesting results. Clearly there's still a missing ingredient or two. Still, the fact that a normal renderer can get a TrueHD syream through (even a malformed one) is encouraging, though
Yea, that was my thought, too. I figured it couldn't hurt to try it. And sure enough, the TrueHD light lit up just fine. So that would indicate the current issue isn't a timing problem in the custom renderer I would think. Something else seems to be awry here. Hopefully by being able to eliminate the custom renderer, albain can figure it out.
rica
16th November 2009, 22:06
For THD i get DolbyDigital light and sound.
Here is the log:
http://www.mediafire.com/?wvyvanmxoo4
Sample:
[4424] TffdshowDecAudio::deliverSampleBistream Delivering IEC sample format type 1 - sample size 2560 - buffer length 6144
00000106 0.06650028 [4424] Media Type Structure
00000107 0.06650028 [4424] Format type : FORMAT_WaveFormatEx
00000108 0.06650028 [4424] Sub type : MEDIASUBTYPE_PCM
00000109 0.06650028 [4424]
00000110 0.06650028 [4424] WAVEFORMATEXTENSIBLE :
00000111 0.06650028 [4424] subFormat : {00000000-0000-0000-0000-000000000000}
00000112 0.06650028 [4424]
00000113 0.06650028 [4424] wSamplesPerBlock : 0
00000114 0.06650028 [4424] Valid bits per sample : 0
00000115 0.06650028 [4424]
00000116 0.06650028 [4424] WAVEFORMATEX :
00000117 0.06650028 [4424] wFormatTag : Dolby AC3 SPDIF
00000118 0.06650028 [4424] Channels : 2
00000119 0.06650028 [4424] Bits per sample : 16
00000120 0.06650028 [4424] Samples per second : 48000
00000121 0.06650028 [4424] nBlockAlign : 4
00000122 0.06650028 [4424]
00000123 0.06689384 [4424] Write 3236 bytes (809 frames), total available 3236 bytes, frame size 4 bytes, maximum size in buffer 2048 frames
00000124 0.06696528 [4424] CMpcAudioRenderer::DoRenderSampleWasapi Sleep2 for 21 ms
00000125 0.08739735 [4424] Write 2908 bytes (727 frames), total available 3888 bytes, frame size 4 bytes, maximum size in buffer 2048 frames
00000126 0.08768014 [4424] Subframe : 218,
SamuriHL
16th November 2009, 22:10
According to your log, it isn't detecting that it's a THD track. The second line says something about "lossless check failed". I would maybe try a different track?
albain
16th November 2009, 22:14
Well, removing the MPC audio renderer that albain gave us and using MPC-HC's default (output to system default), I get the exact same results as with the custom renderer, except, in the case of DTS-HD MA, I actually get DTS core audio bitstreamed. So no audio in TrueHD, but, the TrueHD light comes on. So it would seem that you are correct that wasapi excl does not seem to be necessary, but, there's still a bug somewhere preventing it from working. And why is it only seeing DTS on DTS-HD MA tracks?
This is interesting but in that case I don't understand why the default renderer wouldn't give any sound.
I will release a custom version of ffdshow that output the same media structure as TMT.
I hope that it will work with arcsoft renderer and confirm that ffdshow implementation is correct
To use it you will have to register asaudiorenderer.dll file (with regsvr32) and it will appear in the renderers list
@Rica : do you have more logs before the beginning point because it seems that ffsdshow switched back to AC3 core which happens if the output filter (renderer) will refuse the bitstream format. But I can confirm that ffdshow sees the true hd frames because of all the major frame/subframe traces (specific to truehd)
rica
16th November 2009, 22:16
According to your log, it isn't detecting that it's a THD track. The second line says something about "lossless check failed". I would maybe try a different track?
I used albain's sample here and used dpinpurr and graphstudio.
rica
16th November 2009, 22:22
@Rica : do you have more logs before the beginning point because it seems that ffsdshow switched back to AC3 core which happens if the output filter (renderer) will refuse the bitstream format. But I can confirm that ffdshow sees the true hd frames because of all the major frame/subframe traces (specific to truehd)
I will create another log as well.
But if it works i'll return back to Vista SP1 and TMT2; i mean can i use TMT audio renderer with your ffdshow?
Another question albain: what if i give it a go with a pure thd (without an ac3 core) like an HD-DVD track?
EDIT: as for the second q; sorry... I haven't noticed your response to samuri.
SamuriHL
16th November 2009, 22:41
I used albain's sample here and used dpinpurr and graphstudio.
Hmmm. I guess I'm seriously confused as to what you're trying to do. dpinpurr isn't necessary to see if a file will bitstream using ffdshow. It's only needed for the hook tool.
SamuriHL
16th November 2009, 22:42
This is interesting but in that case I don't understand why the default renderer wouldn't give any sound.
I will release a custom version of ffdshow that output the same media structure as TMT.
I hope that it will work with arcsoft renderer and confirm that ffdshow implementation is correct
To use it you will have to register asaudiorenderer.dll file (with regsvr32) and it will appear in the renderers list
It's worth a shot. I can certainly try it.
rica
16th November 2009, 22:43
Hmmm. I guess I'm seriously confused as to what you're trying to do. dpinpurr isn't necessary to see if a file will bitstream using ffdshow. It's only needed for the hook tool.
I know but it was just a trial :)
albain
16th November 2009, 22:44
In Ffdshow I strip off the ac3 blocks already (as well as tmt).
For dtshd this is different as the dts core is complementary to hd blocks
Concerning arcsoft renderer I don't think it holds any protection but I may be wrong.
SamuriHL
16th November 2009, 22:53
So, I try to use the ArcSoft renderer with what I have now. I get some freaky results. ffdshow defaults back to libavcodec and decodes it to LPCM. I'm guessing it no likey the fact that I'm using an ATI card with it. :D I guess I'll have to switch to the Xonar to try this.
SamuriHL
16th November 2009, 22:54
With the Default DirectSound device renderer, however, I get TrueHD lights and no audio in GS.
SamuriHL
16th November 2009, 23:01
And even with the Xonar set as default device, it defaults back to libavcodec and decodes to LPCM with the arcsoft renderer.
rica
16th November 2009, 23:07
Given it a go with Arcsoft AR (of TMT3) in SP2.
No light, no sound but the log is interesting i suppose.
http://www.mediafire.com/?yj2nmwnndfn
Skinleech
16th November 2009, 23:15
And even with the Xonar set as default device, it defaults back to libavcodec and decodes to LPCM with the arcsoft renderer.
THis is what I saw when I tired the arcsoft renderer a day or 2 back.
SamuriHL
16th November 2009, 23:17
THis is what I saw when I tired the arcsoft renderer a day or 2 back.
I haven't looked at a log on this yet but my gut feeling is that the log will tell us the renderer refused the bitstream. I guess we have to wait for albain's new version.
SamuriHL
16th November 2009, 23:23
00000046 0.01536511 [4872] TaudioParser::checkOutputFormat :
the output sample format (compressed stream to bitstream) Bitstream Dolby True HD is not accepted by the renderer for codec bitstream Dolby True HD
Yup. That sucks.
Skinleech
16th November 2009, 23:32
Here are mine: the exact same message is contained within.
TrueHD: http://pastebin.com/m6b5b174e
DTS-HD MA: http://pastebin.com/m73e61917
SamuriHL
16th November 2009, 23:34
Yea, no renderer I've tried wants to play nice. I tried the Cyberlink PDVD9 audio renderer. Nearly keeled over from the horrifying noise coming out of the speakers. sigh. :D Actually, check this out from the PDVD9 renderer:
00000043 0.02003592 [4740] TaudioParser::checkOutputFormat :
the output sample format (compressed stream to bitstream) Bitstream Dolby True HD is accepted by the renderer for codec bitstream Dolby True HD
Fascinating.
rica
16th November 2009, 23:39
A little bit more detais from the log:
00000000 0.00000000 [5504] TffdshowDecAudio::StartStreaming
00000001 0.00047527 [5504] TffdshowDecAudioInputPin::NewSegment
00000002 0.00051508 [5504] TffdshowDecAudio::NewSegment
00000003 0.00444575 [5504] TaudioParser::checkOutputFormat for codec AC3 s/pdif with sample format 16
00000004 0.00452076 [5504] Media Type Structure
00000005 0.00452076 [5504] Format type : FORMAT_WaveFormatEx
00000006 0.00452076 [5504] Sub type : MEDIASUBTYPE_PCM
00000007 0.00452076 [5504]
00000008 0.00452076 [5504] WAVEFORMATEXTENSIBLE :
00000009 0.00452076 [5504] subFormat : {00000000-0000-0000-0000-000000000000}
00000010 0.00452076 [5504]
00000011 0.00452076 [5504] wSamplesPerBlock : 0
00000012 0.00452076 [5504] Valid bits per sample : 0
00000013 0.00452076 [5504]
00000014 0.00452076 [5504] WAVEFORMATEX :
00000015 0.00452076 [5504] wFormatTag : Dolby AC3 SPDIF
00000016 0.00452076 [5504] Channels : 2
00000017 0.00452076 [5504] Bits per sample : 16
00000018 0.00452076 [5504] Samples per second : 48000
00000019 0.00452076 [5504] nBlockAlign : 4
00000020 0.00452076 [5504]
00000021 0.00464878 [5504] TaudioParser::checkOutputFormat : the output sample format (compressed stream to bitstream) ac3 is accepted by the renderer for codec AC3 s/pdif
00000022 0.00468872 [5504] TffdshowDecAudioInputPin : switching codec from liba52 to AC3 s/pdif
00000023 0.00472295 [5504] TffdshowDecAudioInputPin::Receive : Initialize audio codec AC3 s/pdif
00000024 0.00488952 [5504] TaudioCodecBitstream::init
00000025 0.00496669 [5504] Major frame :320
00000026 0.00500776 [5504] TaudioParser::checkOutputFormat for codec bitstream Dolby True HD with sample format 256
00000027 0.00507083 [5504] Media Type Structure
00000028 0.00507083 [5504] Format type : FORMAT_WaveFormatEx
00000029 0.00507083 [5504] Sub type : MEDIASUBTYPE_PCM
00000030 0.00507083 [5504]
00000031 0.00507083 [5504] WAVEFORMATEXTENSIBLE :
00000032 0.00507083 [5504] subFormat : KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_MLP
00000033 0.00507083 [5504]
00000034 0.00507083 [5504] wSamplesPerBlock : 16
00000035 0.00507083 [5504] Valid bits per sample : 16
00000036 0.00507083 [5504]
00000037 0.00507083 [5504] WAVEFORMATEX :
00000038 0.00507083 [5504] wFormatTag : WAVE_FORMAT_EXTENSIBLE
00000039 0.00507083 [5504] Channels : 6
00000040 0.00507083 [5504] Bits per sample : 16
00000041 0.00507083 [5504] Samples per second : 192000
00000042 0.00507083 [5504] nBlockAlign : 12
00000043 0.00507083 [5504]
00000044 0.00510987 [5504] TaudioParser::getSupportedFormat Official format not supported, trying {EB27CEC4-163E-4CA3-8B74-8E25F91B517E}
00000045 0.00514639 [5504] TaudioParser::getSupportedFormat Second format not supported, trying {4288B843-610B-4E15-A53B-43007FCFF614}
00000046 0.00518048 [5504] TaudioParser::getSupportedFormat Third format not supported
00000047 0.00521854 [5504] TaudioParser::checkOutputFormat : the output sample format (compressed stream to bitstream) Bitstream Dolby True HD is not accepted by the renderer for codec bitstream Dolby True HD
00000048 0.00525199 [5504] TaudioParser::getCodecIdFromStream truehd
00000049 0.00528705 [5504] TffdshowDecAudioInputPin : switching codec from AC3 s/pdif to truehd
00000050 0.00532065 [5504] TffdshowDecAudioInputPin::Receive : Initialize audio codec truehd
00000051 0.00747763 [5504] Subframe : 166,
00000052 0.00751702 [5504] TaudioParser::checkOutputFormat for codec bitstream Dolby True HD with sample format 256
00000053 0.00764008 [5504] Media Type Structure
00000054 0.00764008 [5504] Format type : FORMAT_WaveFormatEx
00000055 0.00764008 [5504] Sub type : MEDIASUBTYPE_PCM
00000056 0.00764008 [5504]
00000057 0.00764008 [5504] WAVEFORMATEXTENSIBLE :
00000058 0.00764008 [5504] subFormat : KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_MLP
00000059 0.00764008 [5504]
00000060 0.00764008 [5504] wSamplesPerBlock : 16
00000061 0.00764008 [5504] Valid bits per sample : 16
Skinleech
16th November 2009, 23:39
That is pretty interesting. And that's not you using the bitstream patch that was supposed to come out a week or so back I guess?
SamuriHL
16th November 2009, 23:41
PDVD9 bitstream full version comes out this Friday. The patch won't come out until the 27th. You like that? :) So no, this is not a bitstreaming version of PDVD9.
@rica, yea, your renderer told you where to go and it wasn't nice. LOL :)
SamuriHL
16th November 2009, 23:49
@albain
When you get a chance, check out this log. This is a TrueHD file played through the PDVD9 audio renderer in GS. I did NOT get TrueHD lights on the receiver, but, I did get LPCM audio (although it was horribly garbled and nearly killed me til I hit mute LOL). Might be worth looking at?
http://pastebin.com/pastebin.php?dl=d2273fc6a
mrcorbo
16th November 2009, 23:51
I know I got these results previously but I can't get them now for some reason. Which driver are you using?
ATI-sourced from catalyst beta (for 5800 series).
rica
16th November 2009, 23:51
Log with PDVD9 (unpatched) audio renderer:
Same results with yours samuri and it's clear it is not an audio renderer issue:
http://www.mediafire.com/?wnyqyjzn1wm
I did NOT get TrueHD lights on the receiver, but, I did get LPCM audio (although it was horribly garbled and nearly killed me til I hit mute LOL).
Confirmed.
SamuriHL
17th November 2009, 00:11
ATI-sourced from catalyst beta (for 5800 series).
The October 15th driver? I'm using Catalyst 9.10 official release. People tell me I'm crazy but it mostly seems to work for me. :D
SamuriHL
17th November 2009, 00:14
Log with PDVD9 (unpatched) audio renderer:
Same results with yours samuri and it's clear it is not an audio renderer issue:
http://www.mediafire.com/?wnyqyjzn1wm
Confirmed.
Sweet. Good to have someone confirm it. I've tried several times to make a connection to the ReClock renderer but it doesn't play nice. So, we have a few renderers to play with:
albain's custom MPC renderer
default directshow renderer
Cyberlink's PDVD9 renderer
TMT3's renderer
All give varying, but consistent, results. So this is good. If we can use one of the other renderers that may free up albain from having to continually mess with his. In that case, maybe he can find the root of the no sound issue. That'd be nice to get this working right before he gets his card. :) And so close to the official PDVD9 release. :D
rica
17th November 2009, 00:33
Ok but don't forget we have not similar results except the one which is gotten by PDVD renderer.
PDVD renderer and thd:
Same result:
No light, unbelieavable noise from the speakers.
ArcSoft Audio renderer and thd:
Me: No light, no sound.
You:Get LPCM.
MPC Audio renderer and thd:
Me: Dolby Digital light and core ac3 sound.
You:THD light but no sound :):)
SamuriHL
17th November 2009, 00:43
We also have different hardware, no? :)
rica
17th November 2009, 00:49
We also have different hardware, no? :)
Yes, sure; i have 5770+Denon1910+Ati 13.10 drivers on WinVista32 SP2.
You have 5800 series card and ?AVR?
SamuriHL
17th November 2009, 00:54
I've got a 5870 running 9.10 drivers on W7 x64 connected to an Onkyo 606. I also have a Xonar using the 17_73 driver.
rica
17th November 2009, 00:57
So i don't think it's related with HW but with 32/64?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.