Higer quality videos

[NaturalDevCR]

All videos from youtube have at most 720p quality... is there a way to allow higer resolutions?

[fe80Grau]

Hello, for ytdlp2STRM to work I must obtain a single URL with the multiplexed media, that is, the video and audio track in a single "file". I have been testing with the command yt-dlp bestvideo+bestaudio/best ..., The problem with this is that it returns two urls, one for video and one for audio... My first intention was for flask to redirect the local url generated in strm to M3U content and with this, set the video and audio stream tracks separately with I hope that VLC will reproduce it. But it has not worked or I have not known how to do it correctly.

The structure I was testing for the M3U is:

#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=1280000
https://video-stream-url
#EXT-X-STREAM-INF:BANDWIDTH=128000
https://audio-stream-url

At the moment the only way for it to work correctly is with the 'best' option for yt-dlp and the URL obtained with the multiplexed video+audio is mostly 720p. I can work with the 'download' option of ytdlp2STRM to process the files once downloaded and serve the stream obtained by ffmpeg while the multiplexing is carried out, but it would not be as fast as the redirect mode since it must first completely download the audio tracks and video.

[AetherVoyager]

yeh, most of the videos are stuck at 720p, Hope you(@fe80Grau) can come up with a solution. Btw Thanks for this awesome project

[skijbal]

I was just about to ask about video resolutions myself. Glad I found this. I really enjoy this project.

[fe80Grau]

Hello, I know this is a highly anticipated feature for this project; however, it is quite challenging to make it as functional as a simple redirection. The options provided by yt-dlp (and the YouTube endpoints) only offer up to 720p quality with video and audio through a single thread, and the direct method essentially makes a 301 redirect to this thread.

To achieve the highest quality, it requires the parallel streaming of audio and video streams separately, then remuxing them in real-time and serving them.

WE ARE IN LUCK! I have gotten it to work with this logic, and you can try it out in the latest commit I have published by setting the bridge method for YouTube. Simply pull the project or download the latest commit and try it. Then, if you want to test it faster, you can manually edit an existing .strm file and replace /direct/ with /bridge/. With this and the new version, it will serve the highest available quality for the video in question.

Note that it is not perfect at all; navigation is not functional as it is extremely slow. The current navigation method with the bridge method becomes almost maddeningly slow, so I do not recommend using time navigation for videos set as bridge. I will continue investigating and testing with the hope of getting it to work sooner or later.

[IIIPr0t0typ3III]

Hey there. Since I needed this to work at least for one video quality I started to fiddle around with the idea of @fe80Grau mentioned in https://github.com/fe80Grau/ytdlp2STRM/issues/29#issuecomment-1894699893 to generate an m3u file and serve that.

Instead of doing that I tried to serve the manifest/m3u8 file from google directly (I extracted it via the manifest_url from yt-dlp -j <video-id>). This does work and jumping around in the video also works.

There is one small caveat though: Jumping in the player served with Jellyfin breaks if the video is realtively long and one tries to jump very far in the video.

I created a pull request (https://github.com/fe80Grau/ytdlp2STRM/pull/59) with the fix, but I am also very open to discuss this further and change the pull request.

[fe80Grau]

Thank you very much @IIIPr0t0typ3III , it works in direct mode and at maximum quality! And what an elegant solution!!! I'm very happy that this project is really becoming something truly collaborative and that together we are creating something useful, I find it fascinating!!

I am reviewing your other request, although lately I have been extremely busy with my job and end up exhausted, soon there will be a quieter period where I can dedicate more time to this project. Besides, there is a lot to do, solving the open issues, I plan to refactor all the code to make it simplified and readable, improve the GUI, etc.

That said, thank you very much for your wonderful solution.

[IIIPr0t0typ3III]

No problem, glad you like the solution!

Take your time. You are doing a great job with this project!

[fe80Grau]

I'm testing well with Jellyfin and Emby, it seems they are not able to readapt the quality once set and always start with the lowest quality due to the given manifest. I'm going to study this scenario to see how to force maximum quality from the start. Playing with VLC you can see the jump in quality a few seconds after starting it

[IIIPr0t0typ3III]

I had this once during testing but could not reproduce it, so I assumed it will not happen a lot. I had a look at it again and one possible fix is to pull the m3u8 file from google delete all unwanted video qualities and then serve the modified file. I should have done it this way from the beginning, but thought I could cut corners here... Sorry for that.

I will create the proper pull request now so that it should work as intended.

[IIIPr0t0typ3III]

I created the fix with this pull request https://github.com/fe80Grau/ytdlp2STRM/pull/60.

There is still a problem though: Computers that are not able to play such a high quality will now struggle to play the video. I also realized that the Jellyfin Android App is not able to play the videos served this way. I am unsure why this is but I will try to investigate this further.

[fe80Grau]

I added a filter function, it seems to work https://github.com/fe80Grau/ytdlp2STRM/commit/479b94cd5b0e42cebe54bef4222858d4fcf9cf2f

[IIIPr0t0typ3III]

This is a way better solution than what I did!

Thanks for creating this so quick!

[fe80Grau]

For Emby/Jellyfin users, if you played any videos before this update, you need to update the metadata for that video or it won't work.