Return actual height, width and fps for streams in /api/v1/videos #4586
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #4131
At the moment Invidious will return hardcoded data for the
size
,qualityLabel
andfps
of fields for streams, when hardcoded data is available, otherwise it just omits those fields from the response e.g. with the AV1 formats. Those issues are especially noticable when Invidious claims that 50fps streams have 60fps and when it claims that the dimensions for a vertical video are landscape. The DASH manifests that Invidious generates already use the correct information.This pull request corrects that issue by returning the information that YouTube provides instead of hardcoded values and also fixes the long standing bug of Invidious claiming that audio streams have 30 fps.
Here are two test cases:
50/25/13fps: https://youtu.be/GbXYZwUigCM (
/api/v1/videos/GbXYZwUigCM
)vertical video: https://youtu.be/hxQwWEOOyU8 (
/api/v1/videos/hxQwWEOOyU8
)Originally these problems were going to be solved by the complete refactor of stream handling in #3620, but as that pull request got closed by the stale bot over a month ago and has such a massive scope that it would require a massive amount of work to complete it, I decided to open this pull request that takes a less radical approach of just fixing bugs instead of a full on refactoring.
FreeTube generates it's own DASH manifests instead of using Invidious' one, so that it can support multiple audio tracks and HDR. Unfortunately due to the missing and inaccurate information in the API responses, FreeTube has to request the DASH manifest from Invidious to extract the height, width and fps. With this pull request FreeTube could rely just on the API response, saving that extra request to the Invidious instance. It would also make it possible for FreeTube to use the vp9 streams with Invidious, which would reduce the load on the video proxies.