Les services en un coup d'oeil

YouTube a sa propre page. Les six autres services sont plus petits, mais chacun a une particularité qui vaut le coup d'être connue avant d'ouvrir son code. Tous implémentent le même contrat StreamingService ; ce qui change, c'est leur façon de récupérer les données et ce qu'ils supportent.

SoundCloud (id 1)

Audio et commentaires. Il dialogue avec l'API REST api-v2.soundcloud.com. Le piège : il n'y a pas de clé d'API fixe, le client_id est récupéré à l'exécution depuis le JavaScript du frontend de SoundCloud (un motif ,client_id:"..." dans un script sndcdn.com) puis ajouté à chaque appel. Les charts sont un kiosque ; il propose aussi des suggestions et l'import des abonnements. Pas de vidéo.

BiliBili (id 5)

Vidéo, commentaires, bullet comments et SponsorBlock, le service le plus complexe. Les URL de flux viennent du JSON api.bilibili.com, mais la plupart des appels doivent être signés WBI : il récupère une table de permutation tournante depuis /x/web-interface/nav, construit une clé mixin, et estampille les requêtes avec w_rid + wts. Il fabrique aussi un jeu de cookies/tickets (buvid3/4, b_lsid, bili_ticket, ...). Les bullet comments (danmaku) arrivent de deux façons : un dump binaire compressé en zlib pour la VOD, et un flux WebSocket DANMU_MSG pour le direct. Le contenu premium passe par un endpoint PGC distinct. Les flux adaptatifs (DASH) portent des plages d'octets par flux (init + index), parsées depuis le SegmentBase Initialization / indexRange sur les pistes audio et vidéo, donc chacune se lit comme sa propre représentation DASH. Attendez-vous à ce que la signature et les histoires de table demandent de la maintenance.

NicoNico (id 6)

Vidéo et bullet comments (les commentaires ordinaires sont désactivés). Hybride : il scrape la page de visionnage pour un blob JSON script#embedded-data, puis appelle nvapi.nicovideo.jp avec des en-têtes X-Frontend-Id. La lecture est une négociation : POST vers .../access-rights/hls avec les résolutions et l'audio voulus, on récupère une URL HLS chiffrée (réponses gzip). Plusieurs classes de contenu sont protégées par une connexion.

PeerTube (id 3)

Vidéo et commentaires, et le seul à être fédéré. Il n'y a pas de backend unique : le service est lié à une instance (par défaut framatube.org, configurable par l'utilisateur), et l'URL de l'instance est la base de l'API (/api/v1/...). Du JSON simple, sans signature. Trending / Most-liked / Recent / Local sont des kiosques ; les channels exposent des onglets CHANNELS et PLAYLISTS.

Bandcamp (id 4)

Audio et commentaires. Surtout du scraping HTML : les données d'album et de piste viennent d'un attribut JSON data-tralbum sur la page. Deux kiosques : Featured, et l'émission radio hebdomadaire, cette dernière via une API bcweekly dédiée et son propre extracteur de flux radio (sélectionné selon l'URL).

media.ccc.de (id 2)

Audio et vidéo, pas de commentaires. Une API JSON publique et propre (api.media.ccc.de/public/events/{id}). Le contenu est organisé autour des conférences : une conférence est un channel, et les kiosques sont conferences / recent / live. Récupération en deux étapes : les métadonnées de l'événement d'abord, puis la conférence parente via une URL contenue dans l'événement.

Référence rapide

Service	id	Média	Récupération	À surveiller
SoundCloud	1	audio, commentaires	REST api-v2	client_id dynamique depuis le JS
media.ccc.de	2	audio, vidéo	API JSON publique	centré conférence, pas de commentaires
PeerTube	3	vidéo, commentaires	JSON par instance	fédéré, instance = base de l'API
Bandcamp	4	audio, commentaires	scrape HTML + JSON	blob data-tralbum, émission radio
BiliBili	5	vidéo, commentaires, danmaku, SponsorBlock	JSON api.bilibili.com	signature WBI + cookie/ticket
NicoNico	6	vidéo, danmaku	HTML + nvapi	connexion requise, POST access-rights HLS