Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve Twitch VOD best quality detection #20850

Closed
Felk opened this issue Apr 26, 2019 · 4 comments
Closed

improve Twitch VOD best quality detection #20850

Felk opened this issue Apr 26, 2019 · 4 comments

Comments

@Felk
Copy link

@Felk Felk commented Apr 26, 2019

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2019.04.24. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

  • I've verified and I assure that I'm running youtube-dl 2019.04.24

Before submitting an issue make sure you have:

  • At least skimmed through the README, most notably the FAQ and BUGS sections
  • Searched the bugtracker for similar issues including closed ones
  • Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser
  • Checked that all URLs and arguments with special characters are properly quoted or escaped

What is the purpose of your issue?

  • Bug report (encountered problems with youtube-dl)
  • Site support request (request for adding support for a new site)
  • Feature request (request for a new functionality)
  • Question
  • Other

Have a look at this:

PS D:\Videos\test> youtube-dl -F https://www.twitch.tv/videos/415411978
[twitch:vod] 415411978: Downloading vod info JSON
[twitch:vod] 415411978: Downloading vod access token
[twitch:vod] 415411978: Downloading m3u8 information
[info] Available formats for v415411978:
format code  extension  resolution note
Audio_Only   mp4        audio only  216k , mp4a.40.2
160p         mp4        284x160     286k , avc1.4D400C, mp4a.40.2
360p         mp4        640x360     705k , avc1.4D401E, mp4a.40.2
480p         mp4        852x480    1443k , avc1.4D401E, mp4a.40.2
720p         mp4        1280x720   2307k , avc1.4D401F, mp4a.40.2
1080p60      mp4        1920x1080  Source 3348k , avc1.64002A, mp4a.40.2
720p60       mp4        1280x720   3350k , avc1.4D401F, mp4a.40.2 (best)

It determines 720p60 as the best option. I assumed that's because it has the highest bitrate. However, the Source version is the best version by definition, because it's the video data that was originally streamed, and the other options are just re-encodes.

Twitch provides the metadata field format_note with value Source for easy identification (youtube-dl -j https://www.twitch.tv/videos/415411978):

{
    ...
    "source_preference": 10,
    "format_note": "Source",
    "format": "1080p60 - 1920x1080 (Source)"
}

Unfortunately, because format isn't filterable in the quality selection (only format_id is, which only contains e.g. 1080p60) it's not possible to directly query for the source version. The best approach I have is explicitly ask for a higher video resolution first, e.g. with: -f 'best[height>=1080]/best'.
Otherwise you could do -f 'best[format*=Source]/best' or something similar.

@Felk
Copy link
Author

@Felk Felk commented Apr 26, 2019

Actually, there's apparently already code in place intended to do this: https://github.com/ytdl-org/youtube-dl/blob/master/youtube_dl/extractor/twitch.py#L134

This also populates the above mentioned and source_preference field.

However, the source_preference property has lower precedence than a bunch of other properties when determining the format to use: https://github.com/ytdl-org/youtube-dl/blob/master/youtube_dl/extractor/common.py#L1380
At least that's how it looks to me. I'm not too familiar with the code.

@dstftw dstftw closed this in 60e67c5 Apr 26, 2019
@Felk
Copy link
Author

@Felk Felk commented Apr 26, 2019

Why is it closed? Should it be considered a bug now?

@Hrxn
Copy link

@Hrxn Hrxn commented Apr 26, 2019

Closed with the commit listed above. Should pick the 'source' format now, but please test for yourself if you actually want to verify.

@Felk
Copy link
Author

@Felk Felk commented Apr 27, 2019

Apparently I didn't read the close message correctly yesterday, sorry for that. Yes, I can confirm that it now successfully picks the source stream as best. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.