Local API: Improve audio quality by sorting streams, highest bitrate first #6807
Conversation
Higher bitrate audio streams consistently coming first mean the player selects a high-quality audio stream, rather than potentially a very low-quality one.
There was a problem hiding this comment.
This is already a much better approach that the previous pull request, but it won't work for live streams as we use the DASH manifest from YouTube for those and as you mentioned yourself it doesn't cover the Invidious API.
A better implementation would do the sorting inside of manifestPreprocessorTXml in the src/renderer/components/ft-shaka-player/ft-shaka-video-player.js file. Additionally this time please edit this PR instead of opening a new one again.
|
I'll look at
I opened a new PR because I considered it a different approach, I didn't consider it an improvement of the old PR. Though I guess they are both sorting things. |
|
That function is passed to shaka-player and runs after shaka-player has parsed the XML into objects but before it starts processing it. The function already has some code to sort the adaptation sets based on their codec. You will want to add some code that will sort the representations inside of the adaptation sets, for performance reasons you only need to sort them in the audio adaptation sets (the video, text (subtitles) and image (thumbnail previews)) don't need sorting. |
This reverts commit aba6803.
The player currently selects the first audio stream. So, sort to ensure that, for a specific codec, the first stream has the highest bitrate.
Head branch was pushed to by a user without write access
|
I think this works. Tested it (local API) on various videos/livestreams until I got temp-banned by YouTube and it was selecting the highest bitrate audio stream on each (and not crashing or anything). |
src/renderer/components/ft-shaka-video-player/ft-shaka-video-player.js
Outdated
Show resolved
Hide resolved
Co-authored-by: absidue <48293849+absidue@users.noreply.github.com>
Head branch was pushed to by a user without write access
Head branch was pushed to by a user without write access
|
I can play the video but how do I know if I get highest/lowest/random quality audio stream with this PR? |
|
Easier way but less exhaustive: Right-click the video and click "Show Stats", then look for the itag number next to the audio codec and compare it to a list of itags, e.g. yt-dlp's: https://github.com/yt-dlp/yt-dlp/blob/421bc72103d1faed473a451299cd17d6abb433bb/yt_dlp/extractor/youtube.py#L1333 (bitrates are not exact) Opus 251 is good, it's something like 130kbps. Opus 249 is bad, it's 40-50kbps. mp4a 140 is good too. Need to check multiple videos because some (recently-posted?) videos only have high-quality audio. More exhaustive way: Open devtools with F12 before viewing video, look for the request to At least, this is how best I know. |
…first (FreeTubeApp#6807) * Sort streams, highest bitrate first Higher bitrate audio streams consistently coming first mean the player selects a high-quality audio stream, rather than potentially a very low-quality one. * Revert "Sort streams, highest bitrate first" This reverts commit aba6803. * Sort audio adaptation sets by bitrate The player currently selects the first audio stream. So, sort to ensure that, for a specific codec, the first stream has the highest bitrate. * startsWith instead of split Co-authored-by: absidue <48293849+absidue@users.noreply.github.com> * Fix missing paren --------- Co-authored-by: absidue <48293849+absidue@users.noreply.github.com>
* development: (58 commits) Convert FtSubscribeButton and watch-video-info SCSS to CSS (FreeTubeApp#6814) Use numbers instead of strings for the DBActions and SyncEvents constants (FreeTubeApp#6815) Translated using Weblate (English (United Kingdom)) Fix: search history text overflows if search term is long (FreeTubeApp#6728) Check if a keyboard composition session is active when pressing 'Enter' on ft-input (FreeTubeApp#6799) use hq img (FreeTubeApp#6826) Move the choose default folder logic to the main process (FreeTubeApp#6811) Translated using Weblate (French) Translated using Weblate (Turkish) Set process.platform at build time (FreeTubeApp#6784) Use logical spec for float (FreeTubeApp#6783) Migrate DataSettings to the composition API (FreeTubeApp#6785) Local API: Improve audio quality by sorting streams, highest bitrate first (FreeTubeApp#6807) Bump sass from 1.84.0 to 1.85.0 (FreeTubeApp#6825) Bump webpack from 5.97.1 to 5.98.0 (FreeTubeApp#6820) Bump postcss from 8.5.1 to 8.5.2 in the stylelint group (FreeTubeApp#6819) Bump the babel group with 2 updates (FreeTubeApp#6817) Bump globals from 15.14.0 to 15.15.0 (FreeTubeApp#6823) Bump sass-loader from 16.0.4 to 16.0.5 (FreeTubeApp#6822) Bump eslint from 9.20.0 to 9.20.1 in the eslint group (FreeTubeApp#6818) ... # Conflicts: # src/renderer/components/watch-video-info/watch-video-info.scss # src/renderer/components/watch-video-info/watch-video-info.vue
Local API: Improve audio quality by sorting streams, highest bitrate first
Pull Request Type
Related issue
closes #6138
Description
The player seems to select the first audio stream it sees (I do not know its precise behavior). YouTube often puts a 40-50kbps audio stream first in the format list, which means FreeTube selects it and gives low quality audio.
Higher bitrate streams consistently coming first due to sorting means the player selects a high-quality audio stream, rather than potentially a very low-quality one. See #6138 for more info.
Testing
Try watching videos with/without this patch, e.g. https://youtu.be/G4qVG_FL4_s
Desktop
Additional context
This doesn't break the quality selector.
I didn't touch the Invidious API because there were no working instances, can't test.