MP uses AAC audio decoder for MKVs and MP4s! (2 Viewers)

[tourettes]

- In MP Configuration, under Videos -> Video Player: set AC3Filter as the "MPEG / AC3 audio decoder". Set ffdshow audio decoder as the "AAC audio decoder".

Unfortunately MP graph building is not wise enough to handle such situations. It loads only the filters and lets directshow to do the rest. In your case ffdshow has bigger filter merit valua and directshow will use that instead of the AC3Filter.

MPII will handle graph building in different way (most likely).

 

[damaster]

- In MP Configuration, under Videos -> Video Player: set AC3Filter as the "MPEG / AC3 audio decoder". Set ffdshow audio decoder as the "AAC audio decoder".

Unfortunately MP graph building is not wise enough to handle such situations. It loads only the filters and lets directshow to do the rest. In your case ffdshow has bigger filter merit valua and directshow will use that instead of the AC3Filter.

This is incorrect: on my system AC3Filter has much higher merit than ffdshow. The only reason it's using ffdshow is because of the bug in the code: it is putting ffdshow in the graph because I have ffdshow configured as my "AAC audio decoder":

          if (extension.Equals(".mp4") || extension.Equals(".mkv"))
          {
            if (strH264VideoCodec.Length > 0)
            {
              h264videoCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strH264VideoCodec);
            }
[B]            if (strAACAudioCodec.Length > 0)
            {
              aacaudioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAACAudioCodec);
            }
[/B]          }

That bolded portion of code above should be instead:

[B]            if (strAudioCodec.Length > 0)
            {
              audioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAudioCodec);
            }[/B]

Since AAC is much less likely to be in an MKV, then it should add the audioCodecFilter to the graph, and if the audioCodecFilter doesn't support AAC, such as AC3Filter, then it will rely on DirectShow as a back-off to use the filter with higher merit. In that case, I would configure ffdshow with higher merit and allow DirectShow to use ffdshow as a back-off to AC3Filter only for any MKVs that actually have AAC encoded audio.

 

[tourettes]

Ah, actually it should put the both:

            if (strAACAudioCodec.Length > 0)
            {
              aacaudioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAACAudioCodec);
            }
            if (strAudioCodec.Length > 0)
            {
              audioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAudioCodec);
            }

and let the filter merits and directshow handle the rest. That way AAC is also working with .mkvs. As that would allow user to configure AAC code as directshow will prefer the loaded codecs more than the ones that arent loaded but have higher merit.

 

[damaster]

Ah, actually it should put the both:

            if (strAACAudioCodec.Length > 0)
            {
              aacaudioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAACAudioCodec);
            }
            if (strAudioCodec.Length > 0)
            {
              audioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAudioCodec);
            }

and let the filter merits and directshow handle the rest. That way AAC is also working with .mkvs. As that would allow user to configure AAC code as directshow will prefer the loaded codecs more than the ones that arent loaded but have higher merit.

Doesn't the order matter? Shouldn't it be this instead:

            if (strAudioCodec.Length > 0)
            {
              audioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAudioCodec);
            }
            if (strAACAudioCodec.Length > 0)
            {
              aacaudioCodecFilter = DirectShowUtil.AddFilterToGraph(graphBuilder, strAACAudioCodec);
            }

 

[tourettes]

Doesn't the order matter? Shouldn't it be this instead:

Order doesn't matter.

 

[stoked]

damaster,

Would you mind posting a fixed compile that you're using for this svn?

 

[damaster]

damaster,

Would you mind posting a fixed compile that you're using for this svn?

Sure, see first post. I've attached a patch there for SVN 21688 and will continue to update the first post with the latest patch until this gets fixed in the official stream.

 

[stoked]

damaster,

Would you mind posting a fixed compile that you're using for this svn?

Sure, see first post. I've attached a patch there for SVN 21688 and will continue to update the first post with the latest patch until this gets fixed in the official stream.

Awesome, thanks!

 

[htpcfreak]

Hi,

I have the same problem on some, not all mkvs since i thing the last two SVNs. On the Final it was working.
The patch in the first post help me also. Thx.

But this must be fixed i thing

 

[ronilse]

Hi,
Added to Mantis, since thread also have a fix it should not take to long before fixed.

Regards
Roy