This provides experimental support to play again all available video
resolutions, by combining audio and video "adaptive" elementary streams
using an input slave. Not in use by default; use at your own risks.
Again, by allowing to select resolutions lower than 360p, this also
provides mitigation against the throttling issue.
Ref #10237, #27227
This extends the old &fmt=[itag] URL syntax that we still supported all
along to force format selection, and allows choosing from "adaptive"
elementary streams without knowledge of itag specifics and in accordance
with normal resolution preferences.
This also allows playing only the audio part of music videos and
skipping the download of the video part entirely, greatly reducing
bitrate and providing mitigation against the throttling issue.
Ref #10237, #27227
Formats listed under that label are audio-only or video-only elementary
streams, but offer choice encompassing the full array of supported
resolutions, qualities and codecs; whereas classic multiplexed formats
have long been dwindling down to only two formats now, 720p and 360p, or
even 360p only for some content.
For now, these "adaptive" formats are only used if explicitly requested
by itag number.
Ref #10237
Due to the severely increased complexity of "n" descrambling code, a
quick fix is unfortunately not foreseeable. For now, let users know more
clearly what's going on and what's to expect or not.
Ref #27227
The descrambling script section was updated from a simple and linear
chain of calls, to a complex execution tree with conditional branches.
Failure to recognize and parse this call structure (or lack thereof)
resulted in a silent no-op. Add a check to properly report an error.
Ref #27227
It was possible, when encountering different code from what was expected
for some known transformations, to void the code parsing pointer instead
of advancing it, resulting in a subsequent crash of the script and total
playback failure. Add a fallback and check, to prevent and gracefully
deal with this, and still allow playback, even if throttled, in case of
descrambling failure.
The descrambling function is now called through an intermediate array
variable. This change has also added two extra ways to recover the
function name. Add support to parse and resolve any of them.
Fixes#26574
A new variant of compound transformation has the Base64 alphabet
generation and the compounding itself as two separate data array
elements, contrary to what was observed so far. Add support for those.
Fixes#26285
A new standalone compound transformation, taking its Base64 alphabet
as extra input argument, has revealed itself. We support parsing and
passing this one more argument from the script section.
Technically this last argument can be a function or rather the result
of its call, but with no argument, we know what's always returned, and
don't need to treat it as a function. This is less clean but simpler and
will do for now.
Newly observed transformations reveal that the uncertain character
code variable used as constant offset, really isn't one and is simply
supposed to be the alphabet's length. Thus even more so, it is a no-op
on the alphabet's algebraic modulo group, and probably just an artifact
of how modulo of negative numbers is handled in javascript. Simplify it
away.
User agents are apparently now expected to do this; failure to do so
results in the video file data transfer getting throttled down to rates
such as 80 kB/s, 60 kB/s or 40 kB/s, below playback rate, and usually
resulting in a video that hangs upon loading or every few seconds, and
is impossible to play. This behavior seems to have first appeared in
June, but been fully rolled out only last week.
Just like with URL signatures, we interoperate with YouTube by
fulfilling what's apparently expected from us, using the same approach
as so far: we parse the descrambling rules from the javascript code, and
apply them.
Fixes#26174
We'll be descrambling the "n" parameter in addition to the URL signature
using this same javascript web asset, so we want to be able to share and
reuse it.
After tightening access restrictions to it, the get_video_info YouTube
API was completely retired around July 2021, with an HTTP 410 Gone code.
All this fallback achieves anymore is poor UX.
In the past few days, YouTube has started redirecting requests for video
pages to a cookie consent and preference prompt, on a whole separate
page and domain; which prevents playback. We are not interested in
YouTube cookies, nor in consenting to them on behalf of our users, so
this just retries with cookies disabled. YouTube gets the hint and
simply redirects back to the original video page.
Fixes#25616
This URL is forwarded to the fallback API and the whole point of that is
in case the main stream configuration line can't be found and parsed,
so don't look for it only on that line. The URL can indeed be found in
several other places on the page.
This renders the fallback to the alternate video info API - which
doesn't provide the javascript URL itself - functional with many more
videos, and makes the script as a whole more resilient to future
failures.
This is required for the main configuration line, and possibly another
line before it. Until more is known, it seems more prudent to enable the
workaround unconditionally for now, than to try and guess what should
work correctly.
This new layout is apparently getting phased in. As major differences,
line splitting is more erratic (with overall 10 times fewer lines for a
slightly bigger HTML document), and the main stream configuration isn't
subjected to double JSON string encoding anymore.
Apparently the old parameter has been replaced by a new one, and is now
getting phased out. The signature descrambling javascript URL is still
available in several other places in the HTML page either way.
Fixes#25223
The name is used as fallback if the title is unset, but not conversely:
so setting the item title instead can have interesting side effects.
This was an odd one; like in most lua playlist scripts we really want to
set a name here.
Fixes#25124
The main configuration line is such a very long line, and has been
growing longer recently, frequently hitting the VLC core limit at
200 kB. This caused readline() to fail to return any data, and stop
parsing of the web page short, preventing playback as the stream URLs
were in that line that was never returned.
Instead this relies on peek() and sized read() calls to parse and
recover that line by hand. This effectively bumps things up to up to
1 MB of usable configuration data.
Fixes#24957
Pierre Ynard