# É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 : ```text vidéo + audio dans UNE seule URL m3u8 ``` Le code Windows essaie donc maintenant : ```text 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 : ```powershell cd "D:\07-Logiciels\23-youtube_personal" flutter clean flutter run -d windows ``` Tester 1080p. Succès attendu : ```text [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 : ```text [HD-WINDOWS][17.13] aucun HLS muxé web_safari ... [HD-WINDOWS][17.13] HLS muxé indisponible/illisible -> secours mweb adaptatif ```