Invidious Integration within reach?

Invidious allows streaming YouTube videos as audio, and can present channels as RSS feeds, meaning AntennaPod could manage them as podcasts, as observed by @ByteHamster in this GitHub comment.

Adding an Invidious channel through RSS already works 90%, but the missing 10% is the most important, i.e. audio streaming: AntennaPod simply displays an “item does not contain a media file” message, I assume because the Invidious feed has no <enclosure> tag pointing AP towards an audio file.

On the Invidious repo there’s a very recent ticket asking for podcast compatible feeds, and this comment has relevant information concerning obstacles on their side.

One of them is that the audio is provided as a DASH stream, while most podcatchers expect a file that can be streamed the plain ole HTTP way.

This might not be a show stopper, though, as AntennaPod relies on ExoPlayer, which in turn supports DASH streaming through the additional module exoplayer-dash.

Audio streaming from Invidious has already been done, e.g. the FOSS music player Holoplay mentioned in the AP ticket linked above. Listening to a podcast video in Holoplay is feasible, but very unwieldy as the app does not have the notion of what a channel is.

Assuming for a minute there are no problems with DASH streaming and AntennaPod, then, and trying to think forward:

  1. The user should be presented with an option to mark an RSS feed as Invidious, as the XML file does not contain that information explicitly, although some instances could be automatically recognized, having “invidious” as part of the URL.

  2. Once AntennaPod is made aware of that, it needs to stop looking for an enclosure in that feed, and go fetch the video link from the <link> tag instead, then append the parameters &raw=1&listen=true so to have the instance return a link to the DASH stream that AP can play.

  3. Because of the no-downloading-from-the-tube policy mentioned by ByteHamster, it might be a good idea for AntennaPod to hide the Download controls for Invidious feeds.

I tried to cover all bases and avoid wasting everybody’s time, but inevitably I will have missed something.

So tell me: what do you think?

I’m afraid that manually marking a podcast/feed as a specific type, which in turn will alter the way AntennaPod interpreds/deals with that podcast/feed, is not something that is in line with the project’s keep-it-simple policy. Especially given that it’s something really for a niche audience. So I don’t think this part of the equation would ever be implmented (at least not under the current core team).

So I think the path forward is to lobby with the Invidious people to find workarounds for the obstacles on their end. For example, for the URL with temporal availability, I can imagine a service that serves ‘static’ URLs in a feed, and when visited, are effectively a ‘redirect’ to a ‘temporal’ URL that is generated on the fly.

And from the Invidious GH issue you linked it seems an <enclosure> tag could be added to the invidious feed.

1 Like


My immediate reaction would be to point out that there should be a pretty big audience for an app as fully featured and polished as AntennaPod which lets users access podcast content that is only available on YouTube.

Let me say this again: AntennaPod implementing YouTube podcatching! Think about it! Savor the thought in your mind’s mouth.

Now users would have to jump through a few, easy hoops which might discourage some, but historically people will jump much worse, as long they want something hard enough.

And I really, truly think this is something a lot of people want.

Maybe you meant something different with that remark and I’m jumping to conclusions and we’ll laugh about the misunderstanding, however it is such an important point to put across that it would be remiss to let it go even in case I got your meaning wrong.

Speaking in general I do understand that unpaid volunteers might not want to work on features they don’t care about themselves. (but I’d be surprised if the devs don’t listen to YT podcasts and then I’d like to know how they pull it off with AntennaPod - as long as it’s not script voodoo and shortcuts like those)

OTOH and while I don’t own a crystal ball, I’m be amazingly surprised if AntennaPod enabling in a relatively simple way YouTube podcatching would NOT be BIG for the app.

And I think if devs ultimately are happy when people use and love the app they poured so much effort in, they should really think hard before passing on a feature like this.

As for convincing the Invidious devs to do a double take, my impression is that that’s not going to happen, but maybe others here have better persuasion skills than I do.

If not, the risk is getting caught in a match of table tennis in which nobody wants to meet halfway or otherwise and this feature ends in limbo.

And that would be utterly sad.

Hehehe. Ok, fair enough. I agree it is cool.

But really: imagine a friend or a family member who never really listened to podcast, but read about a nice one in the newspaper. They happen to have installed AntennaPod for that. How would their journey to/through Invidious look like?
(I’m thinking of my father, in his 60s, and there’s no way he would find out about any of this on his own. He would search for podcasts in AntennaPod, using the title in the newspaper, and start listening. Even though he has installed and uses the YouTube app, he wouldn’t connect the two.)

In other words: you and I are niche. We know (more or less) what we’re doing and we’re engaged in open source projects. Remember AntennaPod has many ‘regular’ users (who are no power listeners). From that general audience there’s only a subset (aka niche) that would be interested in following YouTube as a podcast (I think I wouldn’t - there is plenty of original podcast content out there).

My main point in reference to the current core team, was not about ‘scratching your own back’ or not (the current lead developer has implemented stuff they don’t really care for personally in the past and they’ll probably do it again).

The point was about our understanding of and agreement with the keeping-it-simple principle. And the solution you propose is not that, IMHO :wink:

Well, in all fairness: their project is all about YouTube. Our project is about decentralised podcasts (and YouTube is not decentralised). I get where you’re coming from, but from where I stand it would be weird to expect AntennaPod to put aside its core principles for a bit to be able to integrate with another project. Like, why would we engage in a match of table tennis when badminton is our sport? :wink:

See also the discussion that took place about integration with Spotify - some arguments overlap.

Again: not saying AntennaPod cannot have support for what you want (YouTube channels as podcasts). Just not in the way you propose.

PS. Did you know that you already can subscribe to YouTube channels in AntennaPod? And a next version of AntennaPod will make it easier to ignore video and play audio only.

1 Like

I just created this forum account as I would really love the ability to subscribe to YouTube channels, especially if video is supported as is for some podcasts atm.

Specifically though, I wanted to add a pertinent detail to this discussion which is that invidious devs are working on adding an “invidious” tag to invidious rss feeds, so that clients know they are from invidious. Once this is done, it would remove the need for invidious feeds to be manually categorised as being from invidious by the user.

Here is the relevant invidious pull, where using the ni://invidious/sha256 Uri is implemented. :

Hoping that this might make this proposal a bit more feasible. @keunes @fernlover

Dist bit