Closed sdaau closed 1 year ago
Hello,
nowadays videos on websites are typically fragmented in multiple streams for different video and audio quality. The selected streams must be muxed together by the player. Fortunately, Kodi offers this capability in form of an add-on named input stream adaptive. For kodi (or any other player) to understand the streams a stream manifest needed in which the urls for the individual streams and their meta data is stated (bitrate, if it is audio or video, etc.). As an experimental opt-in feature (see the settings) our add-on does support this functionality for websites exposing their manifest files. Youtube does unfortunately not expose their manifest files and we would have to create a temporary one within our addon and provide that one to the player. Tbh that is a good amount of work to get it robust for all the different websites and thus different kind of streams. This is what https://github.com/firsttris/plugin.video.sendtokodi/issues/34 is meant for.
Per default or as a fallback if you have the experimental setting activated, the add-on currently uses „the best available all in one audio and video stream“ for which no manifest is needed as it is simply a mp4 (or similar) file. Unfortunately, for YouTube this is just 720p. So even an option like "use the second best stream" would not work in case of youtube as all they offer for legacy streams is the the 720p stream.
So in essence you need https://github.com/firsttris/plugin.video.sendtokodi/issues/34 to choose something with lower resolution per default.
See also https://github.com/firsttris/plugin.video.sendtokodi/issues/33 and https://github.com/firsttris/plugin.video.sendtokodi/issues/62
an option like "use the second best stream" would not work in case of youtube as all they offer for legacy streams is the the 720p stream
I haven't used this addon since this summer, but up until then I played 480p just fine from YouTube. Are you saying that this has changed since then and that they no longer serve 480p?
Yes and No :)
As youtube is not exposing its manifest and https://github.com/firsttris/plugin.video.sendtokodi/issues/34 is still not implemented sendtokodi here simply falls back to the "best all in one" stream, the implementation of that is here. With the implementation of https://github.com/firsttris/plugin.video.sendtokodi/pull/74 the ability to chose something else via an additonal resolver option is not available anymore if you use the manifest feature (which is enabled by default).
If you turn off this feature you can still send additional format options
In case of Youtube it is not always predictable what is available or not concerning the streams which contain both audio and video. So for example let look at an older video of the more popluar youtuber Mark Rober. Streams containing both audio and video are just 144p, 360p and 720p (so no 480p).
yt-dlp -F https://www.youtube.com/watch?v=lg5wznn3IBE
[youtube] Extracting URL: https://www.youtube.com/watch?v=lg5wznn3IBE
[youtube] lg5wznn3IBE: Downloading webpage
[youtube] lg5wznn3IBE: Downloading android player API JSON
[info] Available formats for lg5wznn3IBE:
ID EXT RESOLUTION FPS CH │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb2 mhtml 48x27 0 │ mhtml │ images storyboard
sb1 mhtml 80x45 0 │ mhtml │ images storyboard
sb0 mhtml 160x90 0 │ mhtml │ images storyboard
599 m4a audio only 2 │ 5.12MiB 31k dash │ audio only mp4a.40.5 31k 22k ultralow, m4a_dash
600 webm audio only 2 │ 5.92MiB 36k dash │ audio only opus 36k 48k ultralow, webm_dash
139 m4a audio only 2 │ 8.11MiB 49k dash │ audio only mp4a.40.5 49k 22k low, m4a_dash
249 webm audio only 2 │ 8.61MiB 52k dash │ audio only opus 52k 48k low, webm_dash
250 webm audio only 2 │ 11.08MiB 67k dash │ audio only opus 67k 48k low, webm_dash
140 m4a audio only 2 │ 21.52MiB 129k dash │ audio only mp4a.40.2 129k 44k medium, m4a_dash
251 webm audio only 2 │ 21.11MiB 127k dash │ audio only opus 127k 48k medium, webm_dash
17 3gp 176x144 12 1 │ 13.27MiB 80k https │ mp4v.20.3 80k mp4a.40.2 0k 22k 144p
597 mp4 256x144 12 │ 5.29MiB 32k dash │ avc1.4d400b 32k video only 144p, mp4_dash
598 webm 256x144 12 │ 4.07MiB 25k dash │ vp9 25k video only 144p, webm_dash
394 mp4 256x144 24 │ 8.79MiB 53k dash │ av01.0.00M.08 53k video only 144p, mp4_dash
160 mp4 256x144 24 │ 8.22MiB 49k dash │ avc1.4d400c 49k video only 144p, mp4_dash
278 webm 256x144 24 │ 13.44MiB 81k dash │ vp9 81k video only 144p, webm_dash
395 mp4 426x240 24 │ 17.56MiB 106k dash │ av01.0.00M.08 106k video only 240p, mp4_dash
133 mp4 426x240 24 │ 14.05MiB 85k dash │ avc1.4d4015 85k video only 240p, mp4_dash
242 webm 426x240 24 │ 21.10MiB 127k dash │ vp9 127k video only 240p, webm_dash
396 mp4 640x360 24 │ 35.17MiB 212k dash │ av01.0.01M.08 212k video only 360p, mp4_dash
134 mp4 640x360 24 │ 26.97MiB 162k dash │ avc1.4d401e 162k video only 360p, mp4_dash
18 mp4 640x360 24 2 │ 82.62MiB 497k https │ avc1.42001E 497k mp4a.40.2 0k 44k 360p
243 webm 640x360 24 │ 38.67MiB 233k dash │ vp9 233k video only 360p, webm_dash
397 mp4 854x480 24 │ 64.10MiB 386k dash │ av01.0.04M.08 386k video only 480p, mp4_dash
135 mp4 854x480 24 │ 42.31MiB 255k dash │ avc1.4d401e 255k video only 480p, mp4_dash
244 webm 854x480 24 │ 59.85MiB 360k dash │ vp9 360k video only 480p, webm_dash
22 mp4 1280x720 24 2 │ ~104.13MiB 612k https │ avc1.64001F 612k mp4a.40.2 0k 44k 720p
398 mp4 1280x720 24 │ 114.67MiB 690k dash │ av01.0.05M.08 690k video only 720p, mp4_dash
136 mp4 1280x720 24 │ 80.27MiB 483k dash │ avc1.4d401f 483k video only 720p, mp4_dash
247 webm 1280x720 24 │ 100.41MiB 604k dash │ vp9 604k video only 720p, webm_dash
399 mp4 1920x1080 24 │ 211.96MiB 1275k dash │ av01.0.08M.08 1275k video only 1080p, mp4_dash
137 mp4 1920x1080 24 │ 318.69MiB 1917k dash │ avc1.640028 1917k video only 1080p, mp4_dash
248 webm 1920x1080 24 │ 275.91MiB 1660k dash │ vp9 1660k video only 1080p, webm_dash
Thanks, I see. I've taken a look now. You've been busy!
One thing at a time then:
If I understand you correctly then there is a solution to this issue already: disable the manifest feature and send format options to cap the video size. The problem described in the OP is why I added the capability in the first place (Edit: I mean, in the app — Tristan had already paved the way in the plugin as I recall :))
Even if 480p is missing sometimes, as you say, it doesn't matter; just put your resolution cap at 500 and you're fine on older devices, with regards to YouTube at least. That's why I implemented it as only a max resolution cap in the iOS app, and not an absolute resolution.
I get the impression that the benefits of using the manifest (I haven't looked this up but I'm guessing it's some standard attribute to a video tag or something, containing some manifest url) is that it's possible to find a stream that's actually playable on your device, making more URLs playable. I don't get the impression that it allows for actually making any resolution settings in Kodi though?
You're still setting format options in ydl even when using the manifest. What's the purpose of doing that?
Granted, I haven't looked up what the asterisk means in your format string ("return all video qualities"?).
In fact I just tested disabling manifest and it solved this issue immediately using YouTube, from my point of view.
Of course, you still have to actually send the correctly formatted request to Kodi, but the iOS app can help you with that. I use my own iOS shortcuts directly from the share sheet though.
bestvideo*+bestaudio/best
is the default if none provided in the standalone cli (at least for yt-dlp). I am not sure but I think it is still required to specify a format or otherwise it will not even provide a manifest? But I could be wrong. We will figure this out on the way when we implement full adaptive stream support.In fact I just tested disabling manifest and it solved this issue immediately using YouTube, from my point of view.
Perfect. Maybe you can share your steps and the exact format options for OP. Also, just to mention it, setting those options on the url sending device should not be required anymore once every video/audio is provided to kodi via the input stream adaptive addon. The input stream adaptive addon has options for max resolution etc. But this might still take some good time due to the above mentioned complexity.
Thanks for the in-depth answers, it's appreciated! It really helps when getting up to speed to not have to look up every piece separately.
So to sum up the OP issue: while the general explanation of the situation is interesting in its own right, it is a bit misleading to say that you need to wait for #34 in order to solve the problem. It can be solved now; by yourself if you control the request being sent, or by the app developer if you use an app to send it. iOS has a solution already, as mentioned.
You just plug e.g. this:
{\"ydlOpts\":{\"format\":\"best[height<=500]/best\"}}
into the request as seen in docs/DEVELOPMENT.md
I think I'm on the same page now, even though my skin crawls at the thought of needing a HTTP server to send some trivial piece of text to the application you're already running in...
setting those options on the url sending device should not be required anymore once every video/audio is provided to kodi via the input stream adaptive addon.
Sounds nice, when it lands. I still see value in letting the remote override it though. The quality is pretty integral to what you want to play, after all, and it would be weird to allow remotes to pick the url but not the quality.
A new parameter perhaps, that abstracts away the ytdl / ydl specifics. Best to format the URLs properly by then as well.
The input stream adaptive addon has options for max resolution etc.
I guess you refer to programmatic options, because I didn't see any such options in the Kodi UI for the addon.
I just realized I had one last question:
The addon manifest was changed to require input stream helper 0.4.2. The PR says "The changes to the addon.xml requires at least kodi 18" — why does it require 18? Input stream helper 0.4.2 itself requires Python 2.25 which isn't a problem.
Assuming it requires Kodi 18 we now have a Python 2 edition of the plugin that won't run properly on 17 or lower, effectively making it a Kodi 18 exclusive edition of the plugin? Isn't that kind of defeating the point of the split, especially for the sake of an "experimental" feature?
If we instead make both Python 3 and input stream helper requirements on the 19+ edition, it's rather simpler: one edition for < 19 and one for 19+, where the latter edition is for everyone who can actually follow.
I still fail to explain how I just managed to install plugin version 0.9.416 on Kodi 17 if the manifest requires Kodi 18 though...
There is InputStream adaptive and InputStream Helper. The first one has a setting page which list max resolution, max bandwidth, initial resolution, etc. The later helps to make sure InputStream adaptive is installed etc.
why does it require 18?
I am not 100 % sure but I think the helper addon is not available in the offical kodi addon repo for Kodi 18 or earlier and thus the addon xml will simply indicate unsolvable dependencies. I am therefore assuming it might need Kodi 19 to work at all. Also I am not quite sure about the InputSteam Adaptive version it self. During testing old versions of this did not support a lot of manifests in the first place. If care you might want to create a PR to fix the xml adjuster and other things?
Getting input stream (websites in 2023) working on a unmaintained kodi version (which is now two behind the latest) with the latest update in 2020 which is based on python2 with an (extended) EOL in 2020 sounds like it is not worth it. In my opinion we should leave the kodi18 and earlier versions to the old classic all in one stream to avoid the hassle. Additionally, in my opinion all work concerning input stream adaptive should focus on getting it to work with the addon version which is available in the current kodi version.
I think I'm on the same page now, even though my skin crawls
Oh boy I do have the exact same feeling!
I still fail to explain how I just managed to install plugin version 0.9.416 on Kodi 17 if the manifest requires Kodi 18 though...
Me too :D Maybe it simply ignores it. I do not know!
If we instead make both Python 3 and input stream helper requirements on the 19+ edition, it's rather simpler: one edition for < 19 and one for 19+, where the latter edition is for everyone who can actually follow.
I totally agree!
There is InputStream adaptive and InputStream Helper.
Thanks. You're right, I got confused by the two similar names...
The later helps to make sure InputStream adaptive is installed etc.
...and I possibly got confused by the fact that my Kodi 19.0 instance does not have adaptive installed, but does have helper. I have to conclude that the latter doesn't really make sure to install the former (its manifest doesn't list adaptive as a dependency at least). I can install it manually, but...
Am I missing something important here?
If care you might want to create a PR to fix the xml adjuster and other things?
I might take a look later if it seems necessary. My initial test managed to both install and resolve at least a direct m4v url on Kodi 17. Any complications (with YouTube etc.) will become clear in the coming week I suspect.
Am I missing something important here?
The helper readme says (and that is the reason InputStream Adaptive is not in OUR addon xml):
It is recommended to not add your InputStream add-on as a dependency in addon.xml. It can cause confusion with users not being able to install your add-on because the InputStream add-on is disabled. InputStream Helper addresses issues such as these and helps the user to install/enable required InputStream components.
I'm again not sure but this whole helper thing might makes most sense for DRM/Widevine stuff where due to licensing not everything can be bundled together. If you look at the helper api, we check here if InputStream Adpative is installed and if not throw a notification. sendtokodi never directly calls the helper addon to install InputStream Adapative. In the API there is only a widevine_install
method in the helper API. I do not know if that would be the correct call as we do not need the whole DRM stuff that comes with that (or let me phrase in a different way: I try to avoid any hassle where this fails due to an exotic plattform or so). But the mentioned check seems to install the InputStream Adaptive addon as well (that is not documented).
Makes sense. Good observations.
Well, it seems to just work on Kodi 17. Since there's no "use manifest (experimental)" in plugin settings I'm assuming there's no such property to be queried, and that that code branch is never hit. Otherwise I'd have seen that notification at least.
I'm closing this as solved. Feel free to ask if the instructions are unclear.
Describe the bug
I have just recently noticed, that if I send a youtube link ( say https://www.youtube.com/watch?v=xP6LQviQwaM ) to Kodi 19.4 on my Android 9 device which is limited to 480p resolution, the highest quality stream is chosen; this means that my Android device has to start downsampling the video, and it has such a hard time with it, that I get a new video frame rendered as a still only every 5 or 10 seconds.
To Reproduce
I've experienced the problem on https://www.youtube.com/watch?v=xP6LQviQwaM - but unless you have a low resolution Android 9 device, it is likely you might not be able to reproduce the bug.
Expected behavior
Expected behavior is that the video plays, instead of showing one new frozen frame each 5-10 seconds
Kodi and sendtokodi version (please complete the following information):
Provide a Kodi log
Screenshots
Screenshots cannot demonstrate this problem - but I think the solution would be an option to manually choose quality in case of a provider with multiple quality streams; for instance, I've recently seen this option in the DR addon ( https://github.com/xbmc-danish-addons/plugin.video.drnu/issues/7 ) - once live stream is played, there is a "Select Program" option:
...and from there, various stream qualities can be chosen:
Would be great if SendToKodi had some sort of an option like that; or if not that - then at least a switch in Configure/Addon Settings, something like "always prefer lowest quality stream in case of a multiple choice"; would be very helpful for low capability devices like mine.
Additional context
(none)