Serving AAC sound through AviSynth

[Konrad Klar]

DirectShowSource("D:\Anims\sample.mkv", fps=25, convertfps=true)
BilinearResize(720,302)

sample.mkv is H264 video with AAC sound 48000 Hz stereo.

Filters used for AAC are CoreAAC or FFDShow (realaac/libaad2).
Sample is opened by MPC,WMP and CCE without error, but sound is not played.

Is any way of loading AAC through AVS script?
Or maybe this is MKV specific problem (Haali Media Splitter 1.6.224.23).

[foxyshadis]

audio=true on directshowsource? iirc you need to have two separate dss, one with and one without audio=true, and audiodub them together. But... sometimes it works with only one! Try it.

[Konrad Klar]

WIDEO = DirectShowSource("D:\Anims\sample.mkv", fps=25, convertfps=true, audio=false)
AUDIO = DirectShowSource("D:\Anims\sample.mkv",audio=true, video=false)
AudioDub(WIDEO, AUDIO)
BilinearResize(720,302)

gives me following output:
DirectShowSource : Timeout waiting for graph to start.
(C:\temp\ConverterOutput\SampleAAC.avs, line 2)

I suppose (maybe wrong) that problem is on AAC DS filter level or on level of communication between AviSynth and DS sound filters.
Or AAC requires special syntax from AVS scripts.
BTW. AAC sound in RMVB container also cannot be played via AVS.

[Wilbert]

iirc you need to have two separate dss, one with and one without audio=true
No, that's only the case when loading graphs with dss. Perhaps it helps to higher the timeout value (which is 60000 by default)?

Btw, make sure your mkv has only with video and only one audio stream (and no subs).

[IanB]

The two seperate DirectShowSource(... audio=..) is irrelevant here. DirectShowSource internally does exactly as the script above is doing, you just get a little more control and feedback doing it manually. (line 2 implies the audio chain is choking).

"Timeout waiting for graph to start" is pretty catastrophic. Normal local disk based sources should start almost immediatly (network streamed sources can take a long time to start).

Try adding a logfile="blah.log", logmask=-1 to your DSS call (2.5.7 .dll required) and submiting the log here for some extra help.

Also use GraphEdit to examine your Direct Show environment for playing these streams. DSS uses the same logic as RenderFile.

[Konrad Klar]

Try adding a logfile="blah.log", logmask=-1 to your DSS call (2.5.7 .dll required) and submiting the log here for some extra help.


In which place of script exactly? "logfile" is not keyword of DirectShowSource IFAIK. I have AVISynth 2.60 Aug 11-2006 installed.

[Konrad Klar]

GraphEdit gives following results:

sample.mkv [Video --> Xform In] CoreAVC Video Decoder [Xform Out --> VMR Input0] VideoRenderer

sample.mkv [Audio --> In] MPA Decoder Filter [Out --> In] AC3Filter [Out --> Audio Input pin (rendered)] Default DirectSound Device

@Wilbert timeout=1200000 does not help. File does not have any subtitles and contains only one video and one audio stream (on the basis information given by Haali Media Splitter tray)..

[IanB]

(2.5.7 .dll required) 2.60 has not had most of the 2.57 fixes and changes applied. Do not use it for real work only use it to explore how the new colour spaces work. 2.5.7 is also pre-release but that version of DSS has the log options needed here.

Turning the timeout up will not help. If a local file sourced graph doesn't start in a few seconds it is not going to start ever. It will be internally deadlocked.

At a rough guess I would say your splitter is outputing the wrong stream ID as far as I know MPA Decoder does not decode AAC only MP1, MP2 and MP3.

If you delete the video path back to the splitter from the graph does the audio actually play correctly.

[Konrad Klar]

Output of GraphEdit for avs script:
SampleAAC2.avs (AviSynthvideo#1 --> XFormIn) AVIDecompresor (XForm Out --> VMR Input0) VideoRenderer

quite different graph than that for sample.mkv.

Audio is played correctly for sample.mkv in GraphEdit.

blah.log is too big to quote it.

[Konrad Klar]

Properties Page of MPA Decoder Filter
Option "AAC Decoder Setting" indicate that this filter is able to decode AAC.

- Connected to:
CLSID: {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}
Filter: D:\Anims\sample.mkv
Pin: Audio

- Connection media type:

Audio: AAC 48000Hz stereo

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {000000FF-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 23

WAVEFORMATEX:
wFormatTag: 0x00ff
nChannels: 2
nSamplesPerSec: 48000
nAvgBytesPerSec: 0
nBlockAlign: 0
wBitsPerSample: 0
cbSize: 5 (extra bytes)

pbFormat:
0000: ff 00 02 00 80 bb 00 00 00 00 00 00 00 00 00 00 ˙...€»..........
0010: 05 00|13 10 56 e5 98 ....Vĺ˜

[IanB]

Use the .dll from here (http://avisynth2.sourceforge.net/directshowsource.zip). Submit the log! Zip it if it's to big.

Use this script for the purpose of reportingWIDEO=BlankClip()
AUDIO = DirectShowSource("D:\Anims\sample.mkv", video=false, logfile="mkv.log", logmask=-1)
AudioDub(WIDEO, AUDIO)MPA Decoder does AAC, I obviously need to get a newer version. :D

[Konrad Klar]

DirectShowSource : Timeout waiting for graph to start.
(C:\temp\ConverterOutput\MKV.avs, line 2)

Log attached 6105

[IanB]

@Konrad Klar,

Sorry if this gets to technical, debugging problems like this is complicated. Please ask for help if you don't understand any step.

Apart from the Timeout the log looks pretty normal. The MKV splitter tried very hard to connect the Video stream, it tried 14 different Media types. For the audio it tried 2 Media types, a raw stream and then the decoded PCM, which of course succeded.

My best guess at this point is the video chain didn't clean itself up after being refused 14 times and without a renderer to drain the video data it causes the splitter to deadlocked (and not feed any audio samples).

To test this theory, in GraphEdit render the MKV file. Delete the video renderer, leaving the video chain unconnected. Save the graph for latter. Click play.

Does the remaining audio stream play correctly or does it hang?

If it hangs. Kill the Graphedit and start a new one and load the previously save graph. Add a NULL renderer to the graph (you may need to install it from the SDK) Link the amputated video pin to the NULL renderer. Click Play. Does it now play the Audio correctly?

If it plays, delete the audio renderer. Save the graph and load that .GRF file into DirectShowSource instead of the the MKV file for audio.

Report your findings here.

[Konrad Klar]

In meantime problem has been resolved! Merit of MPA Decoder Filter has been lowered to 00200001. Currently AAC is handled by CoreAAC Audio Decoder.
Thanks for help!

@IanB
Obviously all changes can be reverted for purposes of tests with GraphEdit, if you are still interested.

[IanB]

Obviously if changing the AAC decoder resolves the issue then the problem must be a bug in MPA Decoder and nothing too do with the splitter as I was surmissing.

[mroz]

I've been having similar issues to the OP. I'd have posted a week ago, but despite occasional reading of this forum for several years I'd not needed to register before. I did on Monday only to discover you didn't want my contribution for five days (& yes, I've now read the threads discussing this issue in the past). Suffice it to say I wasn't convinced & was sorely tempted to not bother posting. However I really like AVISynth, so...

I've been encoding to avc/aac in mp4 on several machines on my home lan, mostly via Nero Recode with occasional use of Belight & Yamb, for around a year, with no great problems encoding or playing the results back.

Just this week I needed to transcode such an mp4 to xvid/ac3 in avi. As I've done plenty of encoding to xvid with mp3 or ac3 & have no problems playing avc/aac, I naively assumed this wouldn't present any problems.

To cut a long, 48 hour, story short, nothing I tried would work. I found at best, video encoded fine, but audio was missing. Investigating further, audio decoding in the context of whatever transcoding software I tried to use seemed to result in an unexpected error which caused the transcoder to skip the audio. This occurred for several different mp4 files.

Eventually I attempted to use avisynth to serve audio from an mp4 containing a single aac track via DirectShowSource. This was with Avisynth 2.56 & the DirectShowSource dll you posted
here supporting logging.

Here's an example of the avs file:
DirectShowSource("D:\Path\VideoWork\kmb.mp4", video=false, logfile="kmb.log", logmask=-1)

In this case, the kmb.mp4 plays fine in a number of players including GraphEdit.

An attempt to play the avs suggests there are filter conflicts in Zoomplayer; in GraphEdit I get the error (the most helpful so far, I think):

Could not construct graph
...
The specified module could not be found
(Return code 0x8007007e)

The log file produced in this case by DirectShowSource is attached.


Here's another example avs:

VIDEO=BlankClip()
AUDIO = DirectShowSource("D:\Path\VideoWork\pf.mp4", video=false, logfile="pf.log", logmask=-1)
AudioDub(VIDEO, AUDIO)

Once more, the mp4 plays fine including in GraphEdit. This time playing the avs in Zoomplayer gives me a 10s blank clip with no audio. GraphEdit tells me:

Some of the streams are in an unsupported format

And creates a graph for the video only.

The DirectShowSource log is again attached.


Incidentally, I did solve the transcoding issue in the end, simply by creating a graph in GraphEdit for an audio only mp4 with output via the FileWriter filter & use of ffdshow's ac3 output option.

Hence that's no longer the reason I'm posting. Rather, I'd like to understand what's going on here in AviSynth & find out whether the problem is one local to my machines or indicative of a fault in Avisynth.

I hope someone can help.

[IanB]

Stripping out the the (very) few informative lines from the logs.

mp4-log-kmb2.rar00:00:00.112 001 0x0188A398 GetSample::QueryAccept(audio) MEDIATYPE_Audio
00:00:00.112 001 0x0188A398 *** Audio: Accepted! Channels:2. Samples/sec:44100. Bits/sample:32. Type:8
00:00:00.112 008 0x0188A398 GetSample::ReceiveConnection(0x01a3c08c, pmt)

00:00:00.115 008 0x0188A398 GetSample::SetSyncSource(0x00000000), was 0x00000000
00:00:00.115 010 0x0188A398 StartGraph(audio) enter...
00:00:00.115 008 0x0188A398 GetSample::Pause(), state was 0

00:00:00.117 008 0x0188A398 GetSample::Run(1000000), state was 1
00:00:00.118 002 0x0188A398 GetSample::NewSegment(0, 2210307482, 1.000000) (audio)
00:00:00.119 010 0x0188A398 StartGraph(audio) mc->Run() = 0x0
00:00:00.119 010 0x0188A398 StartGraph(audio) ... exit 0x0

00:00:00.120 002 0x0188A398 Receive: Got 8192 bytes of audio data.
00:00:00.120 002 0x0188A398 Receive: audio sample time span x100ns 0 to 232199 (232199)
00:00:00.120 200 0x0188A398 ...Receive() waiting for DoneWithSample. (audio)

00:00:00.120 005 0x0188A390 New Audio: audio_dur 2210307482x100ns.
00:00:00.202 080 0x0188A390 ~DirectShowSource.

00:00:00.206 080 0x0188A398 ~GetSample.
00:00:00.206 fff 0x00000000 Close audio log 1.221 seconds of 2 channel, 44100 samples/second 32bit Audio.

mp4-log-pf.rar00:00:00.148 001 0x0188A410 GetSample::QueryAccept(audio) MEDIATYPE_Audio
00:00:00.148 001 0x0188A410 *** Audio: Accepted! Channels:6. Samples/sec:48000. Bits/sample:32. Type:8
00:00:00.148 008 0x0188A410 GetSample::ReceiveConnection(0x01cbe3fc, pmt)

00:00:00.151 008 0x0188A410 GetSample::SetSyncSource(0x00000000), was 0x00000000
00:00:00.151 010 0x0188A410 StartGraph(audio) enter...
00:00:00.151 008 0x0188A410 GetSample::Pause(), state was 0

00:00:00.152 008 0x0188A410 GetSample::Run(1000000), state was 1
00:00:00.153 002 0x0188A410 GetSample::NewSegment(0, 88834986666, 1.000000) (audio)
00:00:00.154 010 0x0188A410 StartGraph(audio) mc->Run() = 0x0
00:00:00.154 010 0x0188A410 StartGraph(audio) ... exit 0x0

00:00:00.156 002 0x0188A410 Receive: Got 24576 bytes of audio data.
00:00:00.156 002 0x0188A410 Receive: audio sample time span x100ns 0 to 213333 (213333)
00:00:00.156 200 0x0188A410 ...Receive() waiting for DoneWithSample. (audio)

00:00:00.156 005 0x0188A408 New Audio: audio_dur 88834986666x100ns.
00:00:11.376 080 0x0188A408 ~DirectShowSource.

00:00:11.385 080 0x0188A410 ~GetSample.
00:00:11.385 fff 0x00000000 Close audio log 1.148 minutes 3.5 seconds of 6 channel, 48000 samples/second 32bit Audio.

This looks quite normal. However no audio samples were ever fetched. I am guessing your encoding applications do not like 32 bit avi audio data. Not many do. Try adding...
Normalize()
ConvertAudioTo16bit()to the end of your scripts.

[mroz]

Thanks. That does indeed avoid the problems I was having.

It still leaves me curious, however, as to why when GraphEdit is given the mp4, it can construct a graph directly (involving ffdshow) to play the file, but when DirectShowSource attempts to decode (again using ffdshow), it selects 32 bit output which GraphEdit can't handle as input.

I don't understand the m$ filter api, but I'd assumed the construction of a filter chain in GraphEdit utilised DirectShow in a way that DirectShowSource either uses or duplicates.

Do you know why they'd behave differently?

In the former case I assume there's some form of negotiation, where ffdshow offers 16, 24 & 32 bit output & GraphEdit selects 16, whereas DirectShowSource chooses 32. Is that vaguely correct?

To complicate matters, I have three machines I sometimes use for transcoding. Previously I'd seen this issue on two. Today I discovered I don't get this problem on the third, so it must be a result of a change in one of the components or in their configuration.

They all have ffdshow.
ffdshow version May 26 2006 15:27:36 (msvc 2003, x86, ansi)
&
ffdshow version Aug 21 2006 22:49:45 (msvc 2003, x86, ansi)
are problematic

ffdshow version Dec 21 2005 11:40:50 (gcc 4.0.2 sse, ansi)
isn't.

All configs have output set to 16, 24 or 32 bit.

[IanB]

In the former case I assume there's some form of negotiation, where ffdshow offers 16, 24 & 32 bit output & GraphEdit selects 16, whereas DirectShowSource chooses 32. Is that vaguely correct?In all cases there is negotiation. It is not GraphEdit doing the negotiation, it is the components themselves.

In the GraphEdit case the output uses the system default renderer (sound card driver/video card driver).

In the DirectShowSource() case we provide our own renderer which likes to accept data in the highest quality available, hence the 32 bit (if available).

For your 3rd machine my guess is that the older decoder is incapable of decoding to 32 bit audio and offers a lower quality 16 bit audio which our custom renderer gladly accepts.

The ffshow config only say to try for this quality, not mandate it.

Really the only problem you had was your encoding application doesn't know how to interprete high quality audio wrapped in an avi stream. And as I said not very many apps yet handle this, so don't be dissapointed, just down convert to 16 bit.

[mroz]

Thanks very much for your informative replies. You've been a great help :)

Regards,

Michael.

:thanks: