(2024-11-20, 09:34)jim_p Wrote: b) You are right, webm is a container. I wanted to write vp9. I do not like vp9 and I want to avoid it everywhere.
My cheap Android box has the same problem, with YouTube's WebM (VP9) desyncing from the audio due to slow software decoding, and MP4 (AVC) doing fine because of hardware decoding, even at 1080 height.
I noticed that WebM (VP9) at 360 height does play fine though, it stays synced and keeps up with the video, so what I did here was to change the way the MPD manifest is built, so that all "video/mp4" streams appear first and are sorted by descending quality (biggest first, smallest last), and then comes the "video/webm" streams sorted in ascending quality (smallest first, biggest last).
This means that InputStream.Adaptive will first try to play the MP4 streams, and if none are found or if it's a modern codec not yet supported (happened on my Kodi 18 Leia), it goes to the smallest webm stream like 360 that does keep up with audio, like I said before.
The same with audio streams, placing any "audio/webm" streams last among the audio streams in the manifest so that I.S.Adaptive will try the faster ones first, like AAC.
Quote:I have explained why above, it is because the api now requires credentials.
Unfortunately now there are no more pre-muxed streams (a stream that comes with both audio+video), even using credentials. It was only for a few days where they were asking for credentials to get them. Now it seems pre-muxed was removed altogether.
Edit: actually, some videos still offer itag 18, a pre-muxed 360 height video. But it's only that one.
Right now the only playable streams are the "adaptiveFormats", separate audio and video streams through MPEG-DASH, which in Kodi can only be played through InputStream.Adaptive or some other InputStream plugin that supports this.
(And that's if Youtube doesn't add yet another obstacle to get those like a captcha mechanism like the PO token that they require on the WEB client).
