Audio Track Selection with Roku Ultra 4670x

[roaku 817]

Thanks, but I already know how to do it with ffmpeg and don't have MKVToolNix installed yet.

Good enough for a one off experiment.

[roaku 817]

Well, I'm excited to share that switching to MKV did the trick.

I now get the following behavior:

1st - DTS-HD MA 5.1 Default (passed through from source) - Direct Play of standard DTS
2nd - AAC 5.1 - Remux to DD 5.1
3rd - AAC stereo (commentary)  - Direct Play with PCM Stereo

I don't have to intervene with 'Attempt playback correction' or any other work around. Everything works as expected and desired.

Thanks to everyone that chimed in to help on this.

Sorry it came down to me not knowing how stuff works.

[speechles 1962]

2 hours ago, roaku said:

Sorry it came down to me not knowing how stuff works.

 

We can try and do better as well. We will see if there is anything we can do to make this more seamless and automatic. Give things a little bit more intelligence.

[ebr 15186]

So it appears I was correct and it is related to the container.  All we need to do is not allow secondary audio with MP4.  We already have a flag for that for some devices so we just need to expand that logic.

[speechles 1962]

Not quite. The problem is we do not allow DTS in MP4 in our capabilities profile on Roku. That DTS was marked as default though. This causes the problem. It isn't the fact of the secondary streams. It is the fact the DTS stream is marked as default when we don't allow DTS in MP4.

Secondary audio works just fine in MP4. It does not with DTS inside MP4 when that is marked as default and mainly because our profile doesn't want that to happen. So it becomes AC3. I believe the reason he could not select the secondary audio track is because it then tried to direct play which it cannot because the default is on the DTS.

So to fix this when the first codec is set as default to a codec that we do not support in that container we must not allow secondary streams. This is why it is complicated. We do not want to remove all secondary audio stream support for MP4 as that is like cutting off the nose because it has a wart. Instead focus on the wart.

We need to know when DTS is inside MP4 and that DTS is set as default that any time you try to change tracks it is going to try to Direct Play which normally it can. In this case and only this case do we disable secondary audio support.

Problem 1: We do not know the codec, which defaults are set, or the container ahead of time during capabilities posting. It is abstracted.
Problem 2: We might not have a way to adapt the capabilities profile to do this because of problem 1.

Knowing those 2 problems is what complicates this further. Do not want to make transcoding happen more than it should. But at the same time do not want users required to use playback correction when we should be automating that process. A huge catch-22 that needs to be figured out.

Edited November 6, 2020 by speechles

[ebr 15186]

8 minutes ago, speechles said:

The problem is we do not allow DTS in MP4 in our capabilities profile on Roku. That DTS was marked as default though. This causes the problem.

How does that cause the Roku player itself to not allow switching the audio?

[speechles 1962]

Because when it direct plays it will choose track 1 (the default with DTS) regardless of what we tell it. Then we convert that to ac3 and wind up where we are. Or you can play the track 2 (the first AAC track). Because that isn't supported and it is AAC 5.1 that we convert to AC3 5.1. But that 3rd track.. AAC stereo.. can direct play. So it chooses to direct play. Default is the DTS. We convert that DTS to AC3. It isn't the commentary track.

That is what is happening.

Edited November 6, 2020 by speechles

[ebr 15186]

2 minutes ago, speechles said:

Because when it direct plays it will choose track 1 (the default with DTS) regardless of what we tell it. Then we convert that to ac3 and wind up where we are. Or you can play the first AAC track. Because that isn't supported and it is AAC 5.1 that we convert to AC3 5.1. But that 3rd track.. AAC stereo.. can direct play. So it chooses to direct play. Default is the DTS. We convert that DTS to AC3. It isn't the commentary track.

That is what is happening.

That does not explain why the Roku player sees ONLY the first track when direct playing this item.  To me, that indicates that the player does not support multiple audio tracks in the container.

[speechles 1962]

Because it is marked as default. When it direct plays that is the audio. To get any other audio track other than that default when you direct play you must transcode the audio and turn it into a direct stream not direct play.

But marking all secondary streams not allowed in MP4 would make direct play impossible when changing tracks which isn't the problem. The problem is the Roku will only play the default track when direct playing and it can be set to track unsupported in the profile. As demonstrated...

The fact they encoded this against how the container should function and the encoder application allowed them to do this is the main problem. But we should be able to detect this "foul up" and work around it somehow.

@ebr This might be something the server could do better and the Roku doesn't need to be aware. The server can know Roku has this issue and solve it there perhaps?

Basically.. if (any audio tracks are marked default or forced) disable secondary stream support

 

Edited November 6, 2020 by speechles

[ebr 15186]

17 minutes ago, speechles said:

Basically.. if (any audio tracks are marked default) disable secondary stream support

Okay, so nothing to do with the codecs or anything else, just the default audio flag.  That shouldn't be too hard to work around.

Surprised this is the first we've heard of this...

[speechles 1962]

Yeah so am I. But I do have problems with some files unable to change audio and I can go back and probably find the same problem with defaults during direct play. Can play with this more as I work on other things too. Pretty confident this is the cause and effect though and we have the right suspect.

[ebr 15186]

I just quickly confirmed that remuxing to an mkv with no track selected as default allowed direct play and audio switching among all three tracks.  Set one to default and switching no longer works.

[speechles 1962]

Good thing people rarely use default or forced settings on their audio streams. It is only certain ripping programs that tend to do this "automagically".

Edited November 6, 2020 by speechles

[roaku 817]

In addition to handling the case programmatically where someone has done the bad thing, I think it would be a good idea to update the Direct Play section of this page with the clarification that Roku supports both MP4 and MKV, but that codec support varies between the two container formats. In this case, DTS is only supported for MKV.

https://developer.roku.com/docs/specs/media/streaming-specifications.md#!

I still find it humorous that my Roku devices are all *technically* capable of passing through DTS in an MP4 with no issue if an app just does it without first asking if it's possible.

Edited November 6, 2020 by roaku

[speechles 1962]

We can probably update our profile to add support for DTS in MP4 on newer device. That may indeed be possible. That was your problem with DTS being coverted to AC3.
We might be able to solve 2 problems here.

1) Add DTS to MP4 (direct play only - non HLS) since technically it does work when supported.
2) Solve the direct play always plays default audio track issue

Thank you for bringing this to our attention and both of these problems will be corrected. We appreciate the help. Any other issues you find, inconsistencies, missing features, etc.. We would love to hear what about them. Thanks again.

Edited November 6, 2020 by speechles

[speechles 1962]

22 minutes ago, roaku said:

In addition to handling the case programmatically where someone has done the bad thing, I think it would be a good idea to update the Direct Play section of this page with the clarification that Roku supports both MP4 and MKV, but that codec support varies between the two container formats. In this case, DTS is only supported for MKV.

https://developer.roku.com/docs/specs/media/streaming-specifications.md#!

I still find it humorous that my Roku devices are all *technically* capable of passing through DTS in an MP4 with no issue if an app just does it without first asking if it's possible.

Yeah.. Having @Roku fix their documents is the equivalent of "The NeverEnding Story" and always an adventure. You get to ride on Falkor. The giant rock guy becomes your friend. But they never update the document. I have asked them to update things so many times and for small things. Updating documentation that isn't full of advertising that makes them money isn't high on priorities.

I even left a message inside an old r2d2 unit in the hope they would find it.

https://community.roku.com/t5/Roku-Developer-Program/Please-give-us-onDestroy-as-an-event/td-p/515902

See the bottom part of my post. In some universes the message inside the r2d2 unit never gets to the Princess. We always hope she might hear it.

Edited November 6, 2020 by speechles

[roaku 817]

13 minutes ago, speechles said:

Good thing people rarely use default or forced settings on their audio streams. I think "The Scene" specifically forbids it. So these would mainly be homemade or p2p type rips. People are allowed to make mistakes on those as their is never a risk on "Nuke".

In my specific case, I believe Handbrake was the app that decided to declare a Default track.

I didn't explicitly set it, and I can't find any option to change that behavior in *that* app.

I was also oblivious to it being a problem.

As I convert my mp4s to mkv with MKVToolnix, I'm seeing that it also likes to set tracks to Default, but it provides a mechanism to override that behavior.

Since, I'm now in the process of trying to get my personal library closer to standardized and broad compatibility...

Is it the case that I should never have an audio track with a Default disposition in my mkvs?

 

[speechles 1962]

If you are not an English speaker and you may have English content you probably need that automagic. But if you are English speaking usually you won't need defaults. English is the assumed default usually. But when English is the secondary audio. Perhaps a Thai copy of some movie may have English listed second. Have a default for English prevents the first track from being assumed default.

Emby will remember the last audio track you played on an item. The next time you play it that track is used. Defaults complicate this. Not having defaults is better always. But for certain regions with multiple languages always used as the first track having defaults is preferred. This is the paradigm and duality of that area. There is yin and yang and a reason to do both. It is personal choice.

But know that not using defaults will always let Emby do the right thing.

Edited November 6, 2020 by speechles

[roaku 817]

Great. That all makes sense. Thanks again.

[ebr 15186]

Actually, I'm back to thinking this is related to the container (mp4) because I can now no longer produce any problem switching audio tracks with an MKV - regardless of default tag.

[speechles 1962]

@ebr Because Emby server has a default now for that item. You want to do it fresh so Emby has no used audio track value for the ID yet. Then it should have that issue. I still have the file that I cannot change tracks on too. It is also MP4 and it might be that container that has a sticky default only. Not MKV.

Edited November 7, 2020 by speechles

[ebr 15186]

20 minutes ago, speechles said:

Because Emby server has a default now for that item. You want to do it fresh so Emby has no used audio track value for the ID yet. Then it should have that issue. I still have the file that I cannot change tracks on too. It is also MP4 and it might be that container that has a sticky default only. Not MKV.

That would not impact the ability to switch tracks during playback - which works just fine direct playing both MKV versions of this item.  One has a default audio track and the other doesn't but both will switch tracks at will.

[speechles 1962]

Do you have DTS equipment to test? Does DTS pass-through inside an MP4 with Direct Play? You will need to alter the profile to add DTS, DCA to MP4 inside the capabilities.

If so.. we can fix that and get that in.. and then know if DTS is set default in an MP4 it will not allow changing to another codec and use that in the logic. Pinpoint the exact issue we have identified here. Without risking altering other behaviors that might be at risk of being damaged.

Edited November 7, 2020 by speechles

[ebr 15186]

I don't think it has anything to do with DTS.  The behavior is inconsistent so I'm not positive what the issue is.  It probably needs a more deep investigation.

[speechles 1962]

@ebr Which firmware version is on your Roku? Is this 9.3.x or 9.4.x? I am suspect Roku has fixed this problem on 9.4 and it exists on 9.3. I can test too. I have one Roku TV on 9.3 and one Roku TV on 9.4 and today I plan to find out. Both Roku TV are same exact model only difference is firmware version.

Specifically this mention in 9.4.x might fix things. Might also be able to use those new attributes to help.

 

Or.. it may be the 9.4.x that is breaking things. This new overlay is weird and purpley. The audio track setting clearly wants to consume default.

Need to dig into this new firmware more closely. One thing clear is that the 9.4 update has improved black levels, and colors actually pop even better now with HDR. I am impressed. Need to test Live TV and MPEG2 and see if this gets any better.

 

Edited November 8, 2020 by speechles