* use WEB_CREATOR when po_token with WEB_EMBEDDED_PLAYER as a fallback
* remove unrelated comment
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
Before this PR, the comment/description content was not HTML escaped when 'parse_description()'
was called with a JSON object lacking the "commandRuns" entry.
Closes issue 4727
This PR:
* gets thumbnail and channel name from the initial request
* gets videos, shorts and streams via autogenerated channel playlists
Test Url: /channel/UCbfnHqxXs_K3kvaH-WlNlig
Closes issue 3513
The /api/v1/videos endpoint does not proxy the formatStreams URLs when
'local=true' is passed, whereas the adaptiveFormats URLs are correctly proxied.
The Web UI does proxy when clicking "Download" with 'fmt=18' for example, so
this is probably an oversight. This PR aims to fix that.
No related issue
This PR adds two new config option, to pass a PO token (config 'po_token') and
a visitor ID (config 'visitor_data') to Youtube. These two strings are required
to play videos using the WEB client.
Warning: These strings gives much more identifiable information to Google!
If the po_token setting is filled in, then the WEB client is used. If not, the
Android client is used. TvHtml5ScreenEmbed will still be used as a fallback.
Script for generating po_token and visitor_data:
https://github.com/iv-org/youtube-trusted-session-generator
Helps with issue 4734
This PR adds support for inv_sig_helper, which offloads the player fetching,
function extraction and signature parsing, which in turn allows to use the
web client to watch videos.
When the new config option "signature_server" is not set, the logic for the
external signature server is not enabled and invidious behaves like before.
This PR also updates the crystal overrides because the stdlib changed quite
a while ago (See issue 11049 at crystal-lang/crystal) and those were required
to properly use TCP/unix sockets.
Closes issue 4649
Note: Does not add rel="noreferrer noopener" to:
* links in channel description
* links in video descriptions
* links in video comments
Related to issue 4267
This PR adds support for parsing the newer channel header format
(banner + subscription parsing)
Before this change:
* 0 subscribers
* No banner image
After this change:
* Example with Mr Breast channel: 299M
* Image banner is visible
Closes issue 4783
Before this PR, Invidious assumed that every playlist had at least one video.
When a playlist had no videos, Invidious was throwing an "Index out of bounds"
exception.
The following API endpoints were impacted:
* api/v1/playlists/:plid
* api/v1/auth/playlists/:plid
Fixes issue 4679
Videos of a playlist cataloged as podcast are called "episodes" therefore
Invidious was not able to find video in the text value inside the stats array.
Test case: "/playlist?list=PLDu-Eh5lUs1a4irCbnxMIB6FrUMaTXgVF"
Fixes issue 4688
This pull request fixes that bug that was causing the query parameters to get
doubled in the streaming URLs when '?local=true' is passed to the
'/api/v1/videos/{id}' API endpoint.
Before: host/path?parameters?parameters
After: host/path?parameters
No associated open issue
At the moment Invidious will return hardcoded data for the 'size',
'qualityLabel' and 'fps' fields for streams, when such 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.
Closes issue 4131
Before this PR, setting the modified code repo URL through the preferences
page in Invidious was broken:
* the HTML input tag for this field had invalid type "input"
(though browser falls back on text input)
* the URL was used to set the "checked" property and not as a plain value,
which makes no sense for a text-based input (and resulted in a blank field)
* when the submitted field is empty, the retrieved value was an empty 'String'
instead of 'nil', causing the "modified source code URL" to be an empty
'href' link which just pointed to the current page
No associated open issue
