Small TypeType idea for LibreTube :)

[Priveetee]

Hello LibreTube community :)

I hope u are all doing well.

I wanted to share a small idea and introduce TypeType to u.

TypeType is an open-source self-hosted video application for YouTube, NicoNico and BiliBili:

https://typetype.video

https://github.com/Priveetee/TypeType

It has its own web client and self-hosted backend for things like accounts, subscriptions, playlists, history, progress, settings and playback.

I know LibreTube already has its own direction and architecture, so this is not a request to change anything, replace Piped, or make LibreTube dependent on another project.

But I was wondering if, one day, an optional TypeType integration could be interesting for LibreTube users who run their own TypeType instance.

The basic idea would be simple: someone who self-hosts TypeType could optionally connect LibreTube to their own instance.

Maybe this could allow a user to keep part of their personal library and account data in their own self-hosted environment, while still using LibreTube as the Android experience they already love. For example, subscriptions, playlists, watch history, progress or settings could maybe follow the user between their TypeType web app and LibreTube.

I am not coming with a finished technical plan or asking anyone to build something immediately. The integration could be very small at first, or maybe the community could decide that it is not useful at all.

I also know maintaining LibreTube already means a lot of work, and that supporting Piped is already an important part of the project.

TypeType and PipePipe already take a lot of time for me too. I have been active around the PipePipe community for some time, building TypeType on top of PipePipeExtractor and trying to keep the work useful for the wider ecosystem instead of creating an isolated project.

Android client-side work is clearly not my strongest area compared to backend and extraction work. That is also why I thought there could maybe be a nice complementarity one day, instead of everyone trying to build everything alone.

If LibreTube is not interested in this idea, if TypeType is still not mature enough, or if it simply does not fit the direction of the project, I completely understand. Really, there is no problem :)

Also a small side thing, because I always end up talking about SABR 😂

TypeType supports SABR too now. Thanks to the incredible work of Infinity and the PipePipe extractor ecosystem, the progress in playback performance has honestly been huge.

LibreTube already has its own native SABR work, so I do not know if any of this would be useful for u. But if anyone is currently investigating SABR, playback recovery, seeking, UMP responses, BotGuard or attestation, I would be happy to help where I can.

I wrote public documentation around the PipePipe SABR work:

https://priveetee.github.io/Docs-PipePipe/developer-guide/introduction

https://priveetee.github.io/Docs-PipePipe/extractor/sabr.html

And these are the two main SABR PRs I made for PipePipe:

• Android Media3 SABR playback:
  feat(player): SABR playback (chunk-based, seekable) InfinityLoop1308/PipePipeClient#47

• YouTube SABR extraction:
  feat(youtube): SABR extractor support InfinityLoop1308/PipePipeExtractor#69

There are also several later SABR fixes around memory, audio selection, downloads, initialization metadata and cold-start tracks.

Maybe none of this is useful for LibreTube, but I wanted to share it in case it can help someone working on similar YouTube playback problems :)

Thx for reading and have a great day!

[FineFindus]

Hi,
thanks for showcasing your project.

But I was wondering if, one day, an optional TypeType integration could be interesting for LibreTube users who run their own TypeType instance.

While I can't say anything about the future, the Piped integration has caused us enough head-aches already, so we're currently not planning to support another instance back-end. But of course you're welcome to create Piped-compatible API.

Maybe this could allow a user to keep part of their personal library and account data in their own self-hosted environment, while still using LibreTube as the Android experience they already love. For example, subscriptions, playlists, watch history, progress or settings could maybe follow the user between their TypeType web app and LibreTube.

We're currently working on a sync server (#8367) which allows exactly that. It's explicitly made in mint with third-party support, feel free to read the docs and integrate it into your project: https://sync.libretube.dev/docs

LibreTube already has its own native SABR work, so I do not know if any of this would be useful for u. But if anyone is currently investigating SABR, playback recovery, seeking, UMP responses, BotGuard or attestation, I would be happy to help where I can.

Thanks for the offer. Our SABR playback generally works well, though some users have been having some issues recently (#8586). Considering that it has been working well for more than half a year and hundreds of hours of playback, it's mostly likely a recent A/B change. If you have any insight into that, I would appreciate it :) Feel free to either comment here or reach out on matrix.

[Priveetee]

Hi,

Thx u for the detailed answer!

Your sync server is actually very interesting and much closer to what I had in mind for subscriptions, playlists, watch history and progress.

TypeType already has its own frontend, server and OIDC authentication, so I need to study how everything could fit together, but I will explore how TypeType could integrate with your sync API from our side :)

About SABR, I took a closer look at #8586 and tested both reported videos with the latest PipePipeExtractor.

Both videos currently start correctly on our side. I also tested the 251 audio and 243 video formats shown in the LibreTube log, at position zero, and received both streams without any SABR error.

The important line is sabr.no_video_selected. The unhandled PLAYBACK_START_POLICY part is not the cause.

One difference caught my attention. In the LibreTube/NewPipe revision I inspected, the SABR URL, UMP configuration and formats come from an Android player response, while the StreamerContext identifies itself as WEB and the PO token is also generated for WEB.

PipePipe keeps the same client profile throughout the session. From what I saw while working on SABR in PipePipe and TypeType, the mixed Android/WEB identity is the cause here. The recent A/B change probably made YouTube enforce client consistency more strictly, which explains why it only started affecting some users now.

We also fixed some related audio/video state problems recently:

• InfinityLoop1308/PipePipeExtractor@71ddbbb
• fix(youtube): respect active SABR tracks on cold start InfinityLoop1308/PipePipeExtractor#80

I did not find a PipePipe report containing this exact error, but these fixes are relevant because they address how the active audio and video tracks are represented in the first SABR request.

If u want, I can try a fix on my fork instead. U can then look at the code whenever u want and take whatever u find useful for LibreTube :)

[FineFindus]

Thanks for testing it.

One difference caught my attention. In the LibreTube/NewPipe revision I inspected, the SABR URL, UMP configuration and formats come from an Android player response, while the StreamerContext identifies itself as WEB and the PO token is also generated for WEB.

NewPipeExtractor currently doesn't support WEB (and if I add it back I only get 403 responses). There also appears to be a different issue, where playback stops after 59 seconds which is present even if I set the ClientInfo for Android.