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 `-I cli` no longer starts the lua CLI, luacli does not work
either, only `-I luaintf --lua-intf cli` does actually start the Lua
CLI interface properly.
improves movie info (show name, season and episode number) matching by
trying meta data as well as the cleaned up filename and trying out
additional patterns
Since last month, requests without a valid referrer get rejected with an
HTTP 403 error.
We might want to consider that the lua script API should track and pass
such referrers by itself.
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.