The media3 library has a method Tracks.isTypeSupported which is very likely more accurate than the logic in this app's logic in CodecSupport.
However, Tracks relies on loading the media first. So this means the app would have to first attempt a direct play, check the resulting tracks, and then make the direct vs transcode decision. This would presumably take longer, but would probably be more accurate since the tracks can check things like h264 profiles and levels which CodecSupport cannot (the server doesn't provide these in the API).
I'm also not sure about the overrides the app does currently. For example, by default, CodecSupport assumes audio tracks with AAC or AC3 or PCM can be direct played even if the hardware APIs do not explicitly report this support. I assume Tracks handles this, but would need to verify.
The media3 library has a method
Tracks.isTypeSupported
which is very likely more accurate than the logic in this app's logic inCodecSupport
.However,
Tracks
relies on loading the media first. So this means the app would have to first attempt a direct play, check the resulting tracks, and then make the direct vs transcode decision. This would presumably take longer, but would probably be more accurate since the tracks can check things like h264 profiles and levels whichCodecSupport
cannot (the server doesn't provide these in the API).I'm also not sure about the overrides the app does currently. For example, by default,
CodecSupport
assumes audio tracks with AAC or AC3 or PCM can be direct played even if the hardware APIs do not explicitly report this support. I assumeTracks
handles this, but would need to verify.