youtube_personal/ETAPE17_13_WEB_SAFARI_HLS.md

Étape 17.13 - Windows 1080p avec HLS pré-muxé web_safari

Diagnostic après le test 17.12

Le test confirme :

• 1920x1080 est réellement décodé ;
• vidéo et audio mweb possèdent tous les deux un PO Token ;
• malgré cela, yt-dlp lui-même reçoit encore HTTP Error 403 sur les URLs DASH/GVS mweb ;
• l'audio échoue immédiatement ;
• la vidéo fonctionne environ 30 Mo puis est refusée.

Ce comportement correspond à des problèmes mweb + PO Token actuellement rapportés côté yt-dlp/YouTube : un format peut être exposé avec un PO Token valide mais son URL média retourner tout de même HTTP 403.

Nouveau chemin prioritaire pour 720/1080p

yt-dlp documente web_safari comme pouvant exposer des formats HLS pré-muxés :

vidéo + audio dans UNE seule URL m3u8

Le code Windows essaie donc maintenant :

web_safari
   ↓
HLS muxé 720/1080
   ↓
media_kit/libmpv

Cela supprime complètement :

• le flux audio DASH séparé ;
• AudioTrack.uri() ;
• le relais audio ;
• le GVS PO Token mweb pour le chemin 1080p.

Si YouTube ne fournit pas de HLS web_safari pour la session courante, le code retombe automatiquement sur le pipeline mweb existant afin que le diagnostic reste fonctionnel.

Limitation actuelle

Le HLS web_safari est destiné à stabiliser 720/1080p. Il ne constitue pas notre chemin 1440p/4K.

Depuis juillet 2026, YouTube ne renvoie ces HLS que pour certaines sessions jugées "trusted". Le log dira donc immédiatement s'ils sont disponibles sur cette machine/session.

Test

Extraire le ZIP à la racine :

cd "D:\07-Logiciels\23-youtube_personal"
flutter clean
flutter run -d windows

Tester 1080p.

Succès attendu :

[HD-WINDOWS][17.13] tentative HLS muxé web_safari cible=1080p
[HD-WINDOWS][17.13] HLS muxé trouvé: ... audio=...
[HD-WINDOWS][17.13] HLS AV confirmé: 1920x1080 (vidéo + audio muxés)

Si le HLS n'est pas disponible :

[HD-WINDOWS][17.13] aucun HLS muxé web_safari ...
[HD-WINDOWS][17.13] HLS muxé indisponible/illisible -> secours mweb adaptatif