Extractors for a full featured client for different video plattforms

[EmanuelLoos]

Using the NewPipeExtractor Tubefeeder could:

• provide search functionality (in a language selected by the user)
• extract video details
• show next/related videos
• extract comments
• extract video in h264 and VP9
• extract audio in aac and opus
• extract subtitles
• display general info about channels
• search channels

currently on

• YouTube
• YouTube Music
• SoundClud (beta)
• media.ccc.de (beta)
• any PeerTube instance (without P2P) Support peertube #18
• Bandcamp (beta)

NewPipe is a FOSS Android App available on the official F-Droid repository, NewPipes own F-Droid repository or NewPipes GitHub releases page (but not the Google Play Store since the Google Play Store Terms of Service forbid it) that provides a FOSS, privacy respecting alternative to the official YouTube app. The NewPipeExtractor works a lot like the well known youtube-dl which mpv uses to extract videos, but is intended to extract all information needed to provide a full UI. Supporting both seems like a good idea to me and might help to enhance Tubefeeders functionality.

NewPipe does not use any Google framework libraries, nor the YouTube API. Websites are only parsed to fetch required info, so this app can be used on devices without Google services installed. Also, you don't need a YouTube account to use NewPipe, which is copylefted libre software.

[Schmiddiii]

I already know about NewPipeExtractor, and already considered using it for the project.

The current main problem is that NewPipeExtractor is written in java, this project is written in rust.
It would definitly be possible to call java functions from rust, for example with j4rs.

Furthermore I do not know if basing on NewPipeExtractor would be even worth it. Are features like viewing comments even needed by the majority of the userbase?

As a frequent NewPipe-User I also experienced, that the app (or parts of it) just stops working every few months as YouTube changed something on their website and NewPipeExtractor needs to be fixed. They are usually very fast doing this, but there would still be some time between me noticing the app is not working and a fix be rolled out. In comparison to that the YouTube feed seems to always stay the same.

But if the userbase still wants these features, maybe the invidious api might be worth looking at.

All in all, I do not hate the idea of using NewPipeExtractor, but I think some discussion about whether the provided features are wanted is needed.

[EmanuelLoos]

As a frequent NewPipe-User I also experienced, that the app (or parts of it) just stops working every few months as YouTube changed something on their website and NewPipeExtractor needs to be fixed. They are usually very fast doing this, but there would still be some time between me noticing the app is not working and a fix be rolled out. In comparison to that the YouTube feed seems to always stay the same.

Well youtube-dl is a much lager project and therefore gets fixes normally faster, but NewPipeExtractor could be used to provide these additional features in times it works.

But if the userbase still wants these features, maybe the invidious api might be worth looking at.

I think that could be a good fallback, bit I'd choose a local software over a remote one. It could also be used to proxy videos.
Invidious has to extract comments and metadata or perform searches somehow. Maybe that code can be used better than NewPipeExtractor written in java.

[Schmiddiii]

Well youtube-dl is a much lager project and therefore gets fixes normally faster, but NewPipeExtractor could be used to provide these additional features in times it works.

What do you mean by "could be used to provide these additional features in times it works"? Do you think this app should use NewPipe for searching, comments and other additional features, but keep the already working things? I do not think mixing NewPipe and code I wrote myself would be a great idea.

I think that could be a good fallback, bit I'd choose a local software over a remote one.

I definitly agree that a local solution would be better.

[EmanuelLoos]

What do you mean by "could be used to provide these additional features in times it works"? Do you think this app should use NewPipe for searching, comments and other additional features, but keep the already working things? I do not think mixing NewPipe and code I wrote myself would be a great idea.

I thought of supporting all four: your code, (external) youtube-dl, (external) NewPipeExtractor and the Invidious API
Not by mixing code, but by using external youtube-dl and external NewPipeExtractor if installed. How about calling them from command line?
That way if at least one of them works it works.
I don't know how difficult that would be though.

[Schmiddiii]

I do not think that would be feasable as I would need to support four different ways of interacting with youtube.
Furthermore if one of them would not work, it is mosk likely because YouTube changed something and all of them would not work.
NewPipeExtractor from the command-line would be a great idea, but I believe that such a thing does not exist.

[EmanuelLoos]

Furthermore if one of them would not work, it is mosk likely because YouTube changed something and all of them would not work.

Invidious Instances could be fixed without the user having to do anything.

NewPipeExtractor from the command-line would be a great idea, but I believe that such a thing does not exist.

You might wnt to take a look at np-cli.

[Schmiddiii]

Invidious Instances could be fixed without the user having to do anything.

You are right about that.

You might wnt to take a look at np-cli.

This seems to be only a demonstration, not a program that should be used productively.
This is not a viable option.

[EmanuelLoos]

There are also the Extractors FreeTube (JavaScript) uses, just to mention it.

[Schmiddiii]

Freetube uses Invidious.

I think that we should also consider a self-written but more powerful extractor, as I would also like to support lbry/odysee in the future and none of the above mentioned can do that.

[Schmiddiii]

I think I will have to move this into "not possible with my current knowlege", as:

Why not use a existing extractor?

I would like to support lbry/odysee in the future. Currently I do not see any extractors that support youtube and odysee.
NewPipe may have it in some time, but I currently do not see any progress (see here).

Why not write a extractor?

I have already tested around a little bit and stumbled across the problem, that youtube and lbry/odysee will need javascript to display their content. I do not see any possibility of running the javascript in a uncomplicated way, and even if it would be possible it would be a pretty large security concern.

Why not use a extractor for youtube and the feed for lbry/odysee?

Mixing several different ways of retrieving content does not seem like a nice solution at all.

[EmanuelLoos]

I have already tested around a little bit and stumbled across the problem, that youtube and lbry/odysee will need javascript to display their content.

Odysee is an online service which uses LBRY and LBRY is a censorship resistant content network with its index saved in the LBRY blockchain. I don't think you need JavaScript to display LBRY content, but unless you want to code an implementation of the LBRY network in another programing language you will be stuck with the implemantations that exist which are not all written in JavaScript. Here is the lbry-sdk writen in Python Here is the lbry-android-sdk written in C, python, Assembly, Shell, TeX, Roff and others. Here is lbry-android written in Java. (also lbry-fdroid, the F-Droid version of the app) And finally lbry-desktop written in JavaScript.

YouTube on the other hand is completely different: It uses very complex JavaScript scripts to prevent things like youtube-dl or NewPipe or at least make them very difficult. I wouldn't really recommend you to develop your own extractor for that if others exist. A while ago the RIAA managed to take down the source code of youtube-dl via a DMCA takedown, but after some legal support from the EFF the source code was publicly available again on GitHub.

[Schmiddiii]

After a little bit of searching around, I found this, a youtube extractor written in Rust.
This seems to (somehow) extract everything wanted (see this frontend).

I will have to do more research but it might be worth looking at.

[spazziale]

After a little bit of searching around, I found this, a youtube extractor written in Rust. This seems to (somehow) extract everything wanted (see this frontend).

I will have to do more research but it might be worth looking at.
that sounds interesting. Are there any new developments?

[Schmiddiii]

Tubefeeder is currently using the api of piped.kavin.rocks (or any other Piped instance). This API should already expose everything needed for a fully-featured client, but I currently don't have the time to do that and I am also not sure that I will ever do that as I like Tubefeeder as it currently is.

Note that I do not use rusty_pipe as this would require me to constantly update this library if Youtube decides to change anything about their website (which is pretty often if you look at NewPipe). I don't have the time or resources to do so.