Suboptimal Audio Track Selection for Playback on Apple TV

[solabc16 379]

Evening

 

Emby Server doesn't (in this case) pick the optimal audio track when playing a movie with multiple audio tracks on Apple TV.

 

As an example, the following movie has both TrueHD and AC3 audio tracks.

 

 

The TrueHD track is available for clients that support it, however clients that don't support it have the AC3 track available.

 

When playing back the movie on Apple TV, the TrueHD track is selected even though it is not natively supported by Apple TV and as a result is transcoded. For hardware with limited CPU resource available, this can be problematic. This is what is seen in the transcoding log :-

Stream mapping:
  Stream #0:0 -> #0:0 (vc1 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

As a workaround, this behaviour can be addressed by switching the default audio tracks. However this is not a desirable/permanent solution, but can be seen to produce a better optimised approach to transcoding and saving a reasonable amount of CPU resource:-

Stream mapping:
  Stream #0:0 -> #0:0 (vc1 (native) -> h264 (libx264))
  Stream #0:2 -> #0:1 (ac3 (native) -> ac3 (native))

Best

- James

 

[ebr 14910]

The problem is we have no way of knowing what the actual content of the audio track is so we really need to respect the fact that you marked it as default.

 

If we just moved on to the AC3 track because it wouldn't require transcoding, in many instances, you could end up with a director's commentary or something like that...

[Luke 37060]

We can always add a setting for this because in some cases this can be an optimization. it's just difficult to determine by default.

[solabc16 379]

Evening

 

Well, I would say this is a 'yes and no', as we need to conside why the AC3 track in this specific case exists in the first place.

 

I suspect this is an area which may require a little bit of future thought and consideration.

 

In this case, the AC3 track is the fallback track for TrueHD, which is required to maintain compatability with the minimum specification for media players. DTS-HD MA handles this differently (and arguably more elegantly), as it uses a single stream that contains the core + extensions. The extensions are transparent if you do not support DTS-HD, so players don't need to worry about handling alternate streams. With TrueHD the track is often hidden from the user and metadata 'trickery' is used to feed the correct stream to player's that don't support it.

 

The end result is that this only really works effectively in the context of its original purpose, within the closed traditional media/player environment.

 

There was discussion (a long time ago) about making sure MakeMKV persisted the relationship between tracks of this type, I'd have to go and look at the MKV in more detail to confirm whether that is actually happening with the current releases. The container format itself can support it, and other MKV generation tools in the past were doing this correctly.

 

The GUI at least shows the correct relationship...

 

 

If this relationship isn't being maintained or a manual way of re-instating the relationship cannot be found, then yes, this is going to prove problematic for Emby.

 

However, given the mantra "TAKE YOUR HOME MEDIA ANYWHERE" it's perhaps a challenge in need of some thought and a solution.

 

For reference, the observed CPU overhead for AppleTV playback is 12% for TrueHD; this 'broke' an otherwise reliable NAS based implementation of Emby.

 

re. Luke's comment above, yes a simple flag that allowed audio tracks to be marked as the 'Main Audio Track' would work, then you just iterate through them and find the highest quality format supported by the client device. Having said that, there is nothing preventing multiple tracks having their default_track flag set to '1', which could be used to achieve the same result, but would likely cause issues elsewhere or unexpected behaviour in other applications.

 

Best

- James

[Luke 37060]

Ok yea in this case because it has a direct relationship to the truehd track as a fallback I think you are right. I just need to look at how to detect that but I don't think it should be a problem.