You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 5, 2024. It is now read-only.
Transcoding has been implemented, but currently there are only two options, mp3v0 and aacv5.
Some reasons to transcode:
Compatibility. It is justified to transcode even from one lossy format to another lossy format for compatibility. The alternative is not playing. We need this for google assistant and mobile support.
Saving Bandwidth. It is justified to transcode to save bandwidth because streaming music on mobile is otherwise expensive. Your coffee shop's wifi might suck and not be able to send high quality audio. Not a high priority because there are other ways to save bandwidth but we should consider it just so our solution makes sense. This isn't a priority because high quality music can be played on mobile by aggressive caching. Also, we don't have mobile clients. Web clients usually don't care much (unless tethered, or on crap connections) about bandwidth.
To transcode for compatibility, the client should only choose from formats which it supports.
To transcode for saving bandwidth, the client should only choose from formats less than or equal to the quality of the input (otherwise wasteful). We shouldn't transcode if not necessary. If the target platform is capable of playing MP3 audio formats, at an unrestricted bandwidth and the file available is an MP3, it shouldn't be transcoded.
The client has two constraints.
Audio Format(s). The client can play a number of audio formats.
Bandwidth. This can be limited. This should be the maximum allowed bandwidth. VBR bitrates are upper bounded usually and will be part of the Audio Format(s). Interesting discussion on VBR vs CBR
The highest possible bitrate will be chosen with the compatible audio format. There will be a raw option which just streams the original file.
Questions
What turns these constraints along with available transcode targets into a chosen transcode target? The client? The server?
The client should probably decide. The request will end up being sent whenever the track changes. This happens before playback and could introduce a gap on latent networks.
Interface for making these choices.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Transcoding has been implemented, but currently there are only two options, mp3v0 and aacv5.
Some reasons to transcode:
Compatibility. It is justified to transcode even from one lossy format to another lossy format for compatibility. The alternative is not playing. We need this for google assistant and mobile support.
Saving Bandwidth. It is justified to transcode to save bandwidth because streaming music on mobile is otherwise expensive. Your coffee shop's wifi might suck and not be able to send high quality audio. Not a high priority because there are other ways to save bandwidth but we should consider it just so our solution makes sense. This isn't a priority because high quality music can be played on mobile by aggressive caching. Also, we don't have mobile clients. Web clients usually don't care much (unless tethered, or on crap connections) about bandwidth.
To transcode for compatibility, the client should only choose from formats which it supports.
To transcode for saving bandwidth, the client should only choose from formats less than or equal to the quality of the input (otherwise wasteful). We shouldn't transcode if not necessary. If the target platform is capable of playing MP3 audio formats, at an unrestricted bandwidth and the file available is an MP3, it shouldn't be transcoded.
The client has two constraints.
The highest possible bitrate will be chosen with the compatible audio format. There will be a raw option which just streams the original file.
Questions
What turns these constraints along with available transcode targets into a chosen transcode target? The client? The server?
The client should probably decide. The request will end up being sent whenever the track changes. This happens before playback and could introduce a gap on latent networks.
Interface for making these choices.
The text was updated successfully, but these errors were encountered: