FreeTubeApp / FreeTube

An Open Source YouTube app for privacy
https://freetubeapp.io/
GNU Affero General Public License v3.0
13.08k stars 810 forks source link

[Feature Request]: 1440p and 2160p qualities when using the local API #2013

Closed absidue closed 5 days ago

absidue commented 2 years ago

Guidelines

Problem Description

When the Invidious API is used 1440p and 2160p show up in the quality selector and can be played without any issues, however when the local API is selected it only displays DASH qualities up to 1080p.

Proposed Solution

It would be nice to be able to choose 1440p and 2160p when using the local API, additionally being able to select 1440p and 2160p as the default quality in the settings would be appreciated.

Alternatives Considered

Leaving it as it is :(

Issue Labels

display more information to user, improvement to existing feature, visual improvement

Additional Information

No response

dtbj commented 2 years ago

Hmm, I also want this feature.

dtbj commented 2 years ago

One more thing I would like to mention that whenever you watch live stream recording then you can't adjust quality it starts in low quality so please take a look at this also.

elvindsouza commented 2 years ago

this is just a temporary workaround and not a fix for Linux users, you can lauch with mpv as an external player and it plays highest available quality by default(with yt-dlp instead of youtube-dl) take advantage of hardware acceleration and the yt-dlp backend using the mpv.conf file, these options will be set by default when you click "launch in external player" in FreeTube

absidue commented 2 years ago

Okay so I've looked into this a bit with this video https://www.youtube.com/watch?v=UGmGlaxf5tM and here are my findings. Video streams up to 1080p are available in video/mp4 and video/webm (vp9) formats, the 1440p and 2160p are only available in the video/webm (vp9) format.

It looks like FreeTube will only play the video/mp4 streams. FreeTube generates the DASH manifest correctly including the 1440p and 2160p streams, FreeTube might be filtering them out somewhere along the line but I haven't found it yet.

The way I've come to this conclusion is because if I filter out the streams in the video/mp4 format with the patch below, I get the following error message on the player Playback cannot continue. No available working or supported playlists.

diff --git a/src/renderer/store/modules/ytdl.js b/src/renderer/store/modules/ytdl.js
index db8895db..e1ad3ca1 100644
--- a/src/renderer/store/modules/ytdl.js
+++ b/src/renderer/store/modules/ytdl.js
@@ -347,6 +347,8 @@ const actions = {
         lang: 'en-US',
         requestOptions: { agent }
       }).then((result) => {
+        result.player_response.streamingData.formats = result.player_response.streamingData.formats.filter(f => !f.mimeType.startsWith('video/mp4'))
+        result.player_response.streamingData.adaptiveFormats = result.player_response.streamingData.adaptiveFormats.filter(f => !f.mimeType.startsWith('video/mp4'))
         resolve(result)
       }).catch((err) => {
         reject(err)

I don't know if FreeTube is filtering the video/webm (vp9) formats out, video.js doesn't support them (everything I can find online says it's supported) or if there is a video.js setting that needs to be turned on somewhere.

PrestonN commented 2 years ago

From what I remember, it isn't that Video.js doesn't support both formats, rather that they don't support playing both formats at the same time. I'm not sure why it has this limitation but that's what I remember when I was trying to figure out why it behaved this way.

Having said that, we're a few versions behind the latest version of Video.js and they may have resolved it since the last time I've tried. I believe there's some small issues prevent us from upgrading, but I'd be curious if that solves the issue or not.

absidue commented 2 years ago

I have upgraded video.js to no avail unfortunately. I have observed some interesting behaviour before upgrading video.js, unfortunately updating it breaks the quality selector so I can't really test it properly.

Weird issues that happened without me changing anything on the latest commit at the time of writing (099c877):

Number 1: This video shows 1440p and 2160p streams in the quality selector as well as 2 choices each for 1080p and below. However it falls back to the legacy formats immediately with this error in the console Uncaught (in promise) DOMException: Failed to load because no supported source was found. https://youtu.be/uNt_ReLwk40

Number 2: This video has the same qualities available as the other video, interestingly though on this one if you select a DASH 720p stream you can then select the 1440p and 2160p streams after that, so it's supported by video.js some how ??? https://youtu.be/kXIOuUUZO2s

efb4f5ff-1298-471a-8973-3d47447115dc commented 1 year ago

Retrieved from https://github.com/FreeTubeApp/FreeTube/issues/3457#issuecomment-1532787037

I'll comment regarding the 1440p and higher qualities. YouTube provides the DASH streams in multiple formats, MP4 h264, MP4 AV1 and WebM VP9 (audio in M4A and WebM opus). YouTube only provides h264 streams up to 1080p, they provide AV1 and VP9 streams for all resolutions. The video player we use video.js only supports MP4 DASH, so we can't support playback of the WebM VP9 DASH in FreeTube, that leaves us with the h264 and AV1 streams. While the h264 ones are available for all videos all the time, YouTube doesn't have AV1 formats for all videos and even on the few videos that they do have them, they only occasionally return them in the API response, so we can only use them when they are provided.

What does that mean exactly? By default you are limited to 1080p, if you enable the "Allow AV1" setting in FreeTube it will use the AV1 formats when they are available, so if you are lucky with that setting enabled, you'll sometimes be able to get the higher resolution formats.

If you wondered why we don't just simply switch to a different player, it is something we want to do eventually but it will be a lot of work to do. It's also not one of those changes that you could only half do and then forget about the rest of it.

CodingMadness commented 2 months ago

how far is this feature from being complete?