L'une des grandes nouveautés de VLC 3.0 était le support de la technologie Cast de Google. L'intégration d'un premier moteur de rendu externe qui ouvre la voie de la diffusion sur les clés Chromecast, les appareils sous Android TV, etc. Mais dans la pratique, comment est-ce que ça fonctionne ?
Cela fait maintenant plusieurs mois qu'on le sait : VLC a travaillé à une implémentation « maison » de la fonctionnalité Cast de Google. Celle-ci permet au départ de lire du contenu sur une clé Chromecast, une box sous Android TV ou même les enceintes connectées de la gamme Google Home.
Mais il faut se contenter du peu de liberté offerte par le Cast SDK, qui impose notamment une implémentation via Android ou iOS et dans Chrome pour les ordinateurs. Or VLC y est proposée sous la forme d'une application sous Linux, macOS ou Windows, il fallait donc une solution qui fonctionne également avec ces plateformes.
C'est finalement avec la version 3.0 du lecteur multimédia que cela a été implémenté, mais nous avions alors rencontré quelques problèmes avec des appareils sous Android TV. Un problème corrigé par la version 3.0.1. L'occasion de faire un petit point sur le fonctionnement pratique de tout ça.
Le support du Cast par VLC, une très bonne nouvelle
La première chose que l'on peut noter, c'est que c'est une bonne chose qu'un projet open source comme VLC ait pu développer une implémentation « maison » du Cast de Google. Cela ouvrira la voie à d'autres applications, mais surtout, cela permet d'étendre les possibilités autour de cette technologie.
En effet, pour le moment il était surtout possible d'utiliser Cast avec des services en ligne. L'URL du contenu à lire est ainsi transmise à l'appareil distant qui se contente de le charger. L'utilisateur a alors la main, depuis son smartphone ou son navigateur, sur la lecture, le volume, etc.
Des services comme Plex, qui s'installent sur un PC ou un NAS avaient contourné le problème en utilisant une interface web. Ainsi, on pouvait lancer depuis celle-ci la lecture d'un contenu stocké sur la machine ou depuis un appareil du réseau à sur un terminal Google Cast. Mais c'était un brin complexe et encore un peu limité.
Il était presque toujours impossible de lire un contenu stocké sur la machine sans lancer de navigateur. Pouvoir le faire en profitant de la puissance de VLC, tant au niveau de ses performances de (dé)compression que des formats supportés, est donc une bonne chose. Surtout que c'est permis depuis presque toutes les plateformes.
On l'oublie trop souvent, mais VLC n'est en effet pas qu'un simple lecteur, il peut aussi faire office d'outil de conversion et de serveur de diffusion. Ainsi, n'importe quel format géré par VLC sera supporté, ce dernier modifiant le fichier vidéo si nécessaire. Dans ce cas un avertissement sera affiché, prévenant que les performances peuvent être revues à la baisse.
Sous Android : pas de différence avec une autre application
Android est une plateforme où le support de Google Cast est natif. Ici, l'équipe de VLC a respecté le fonctionnel classique, à savoir un bouton avec l'icône officielle qui est présente dans la barre principale.
Vous pouvez donc cliquer dessus pour initialiser la connexion. Si un seul appareil compatible est présent sur le réseau, vous serez automatiquement connecté dessus. Sinon vous aurez le choix. Une fois la lecture d'un contenu commencé vous pourrez vous servir de votre appareil Android comme d'une télécommande.
Sous Linux, macOS et Windows : choisir un autre moteur de rendu
Avec l'application classique de VLC, pensée pour ordinateur, aucun bouton de ce genre n'est présent. L'équipe a travaillé le support de Cast comme une première étape pour le support de « renderer », des moteurs de rendu qui sont externes à la machine. Comme nous l'expliquions en juin 2016, l'objectif est à terme de supporter d'autres solutions comme UPnP/DLNA, AirPlay, WiDi et DIAL (Miracast). De quoi ouvrir également la porte à OCast d'Orange.
Ainsi, dans le menu Lecture, vous trouverez désormais un élément Rendu (ou Renderer selon les cas). Il listera l'ensemble des appareils compatibles présents sur le réseau. Dans le cas de notre test : une SHIELD Android TV. Un modèle ne gérant que l'audio, comme une enceinte Google Home, apparaîtra aux côtés d'une icône en forme de note de musique.
Il vous suffit alors de sélectionner le moteur de rendu puis de lancer la lecture d'un fichier. Les fonctionnalités de contrôle de l'application seront toujours fonctionnelles, le résultat étant lu sur l'écran distant. Ici, VLC fera office de serveur de diffusion, il faudra donc veiller à disposer d'une connexion réseau suffisante, surtout dans le cas de grosses vidéos comme des éléments en 4K par exemple.
Nous avons effectué nos essais avec la dernière session de Questions au gouvernement récupérée sur LCP via Captvty, le film Big Buck Bunny 1080p (MP4) et Tears of steel 1080p (4K Rendered), sans rencontrer de problèmes dans nos différentes configurations. Le débit nécessaire était au maximum de 15 Mo/s. De quoi mettre à mal certaines configurations Wi-Fi (voir notre test).
Lecture depuis un appareil sur le réseau, conversion de format
Là où les choses peuvent se corser, c'est concernant la lecture depuis un NAS par exemple. En effet, VLC doit récupérer le flux vidéo sur le réseau, puis le renvoyer à l'appareil via Google Cast en passant là encore par le réseau. Si la vidéo est lourde, cela peut poser problème.
C'était notamment la vidéo 4K de Tears of steel qui ne pouvait pas être correctement lue depuis notre NAS par VLC sur notre Mac Mini. Cela n'était pas mieux une fois le rendu sur Android TV activé. Dans l'idéal, il faudrait que VLC puisse dire à l'appareil réseau de lire directement le contenu depuis l'emplacement où il se trouve, mais cela poserait trop de problèmes pratiques : protocoles supportés, protection par un mot de passe, etc.
Autre élément à prendre en compte : les performances de votre machine. En effet, il faut que celle-ci soit capable de lire et de transmettre la vidéo, parfois de la compresser lorsque son format n'est pas nativement supporté par l'appareil distant. Un vieux processeur pourra donc poser problème.
Le support dans iOS et l'application UWP pour plus tard
Les plus attentifs remarqueront que nous n'avons pas évoqué deux versions de VLC : celle pour iOS et l'application universelle accessible depuis le Windows Store. La raison est simple : Google Cast n'y fonctionne pas encore.
Néanmoins, l'équipe a déjà indiqué que ce serait le cas dans de prochaines mises à jour. Il faut donc seulement s'armer d'un peu de patience. Le travail va continuer de se faire pour améliorer le support de Cast, qui pose encore parfois quelques petits soucis quand on change de fichier, ou l'arrivée de nouveaux protocoles.
Il serait d'ailleurs intéressant que VLC puisse à terme être utilisé non pas comme un moyen de diffuser du contenu vers un appareil distant, mais comme un récepteur Google Cast exploitable depuis des appareils tiers. Pour le moment, cela ne semble néanmoins pas à l'ordre du jour.
Une chose est sûre, avec cette fonctionnalité, VLC continue d'être une référence de poids dans le secteur des lecteurs multimédias. Et son équipe démontre une fois encore sa capacité à ne pas se laisser bloquer par les solutions plus ou moins ouvertes mises en place par les géants du Net.
Commentaires (60)
#1
Merci pour le travail abattu.
#2
C’est vraiment le truc qui me manquait perso, très content de cette évolution (et de la news).
#3
Ce que je reproche principalement à Chromecast, en plus d’être propriétaire, est qu’il utilise obligatoirement le Wi-Fi alors qu’un lien ethernet est quand même plus approprié au débit vidéo. Cela fait que je ne l’ai jamais utilisé bien que ma nouvelle TV le supporte.
#4
Beau travail de Videolan.
Perso je trouve cet empilement de protocole horriblement compliqué (CAST, DIAL, UPNP, SSDP …).
C’est le genre de truc qui aurait été plus simple si on avait laissé faire les développeurs plutot que les gros acteurs du secteur. Ca me rappelle SOAP vs REST/JSON. " />
#5
Testé depuis un MBPr vers la Shield TV : pas concluant…
Testé depuis un Note 8 : ok, mais pas de sous-titre affichés.
Je crois que je vais rester un peu avec BubbleUPnP pour cet usage.
Mais en tout cas belle initiative. J’espère qu’elle va se stabiliser, améliorer. C’est un truc qui me manquait depuis que j’ai lâché WMP et la XBox 360, puis mon Mac et Kodi sur la TV avec AirPlay.
#6
Testé avec un .mp4 et un .avi mais rien de concluant, ça charge sans rien afficher. Une autre vidéo m’a demandé de convertir et là ça marche mais sans être très beau (wifi pas très costaud)
#7
Tester chez moi avec une config assez récente ( core i5 6500 et GTX 1060) des fichiers mkv et mp4, aucun ne passe j’ai droit à une image de chargement sur la TV avec le nom du fichier mais rien ne se passe
#8
idem, soit VLC 3.0 est tout simplement pas pret, soit ma free 4k est nul a chier, je penche pour les deux
#9
#10
Jamais eu de souci à diffuser de la full HD sur la clé chromecast et ceci malgré le fait qu’elle est à l’opposé de la box dans l’appartement et la dizaine de réseaux wifi autour.
A+
#11
#12
VLC 3 et chromecast ça ne marche pas chez moi, comme l’upnp. Il ne détecte pas mon NAS. Bref bcp de bruit pour pas grand chose.
A+
#13
#14
alors du coup, malheureusement, mon vlc 3.0.1 ne voit aucun périphérique, alors que le cast depuis chrome fonctionne parfaitement, et que le firewall windows est ouvert pour vlc.exe … :‘(
Une idée de ce qui ne va pas ?
#15
Ton LAN est considéré comme privé ou public (sous Windows) ?
#16
Un bien bel article de David qui au final semble avoir l’effet contraire de celui escompté. " />
#17
En tout cas le bond de vlc en termes de décodage du h265 est vraiment impressionnant surtout sur des fichiers 4k. Un grand bravo à l’équipe.
Je peux maintenant lire des fichiers 4k de gros porc sur ma Freebox 4k alors que c’était au petit bonheur avant et quel que soit le lecteur.
Sur mon pc portable vieux de sept ans pareil ,c’est englouti sans saccade. Chapeau.
#18
#19
#20
privé, mais j’ai même testé en autorisant vlc aussi bien en réseau public que privé … nada
il m’a bien mis la popup me demandant de l’autoriser lors que je suis allé sur rendu >, mais depuis … rien, ça reste bloqué sur “en recherche”
#21
#22
ah je ne connaissais pas tiens, je testerai ça demain
#23
Google propose depuis plusieurs années un adaptateur secteur (que je possède) présentant une entrée ethernet.
Ainsi, le chromecast n’utilise plus le réseau et les chargements de vidéos sont bien plus rapides et les lags quasi inexistant (je le confirme personnellement).
#24
Il me semble qu’ils vendent un connecteur rj45.
https://store.google.com/product/ethernet_adapter_for_chromecast
#25
Merci les gens qui passent leur temps libre à travailler sur VLC.
Pour ce qui est de hosting ChromeCast, apparement c’est assez complexe et il est question d’avoir un clé privé, qui n’est pas dispo (il faut l’extraire de l’appareil, ce qui n’est pas possible) :https://github.com/thibauts/node-castv2/issues/2https://github.com/ii/iigadget/issues/7
#26
J’ai beaucoup de problèmes pour lire une vidéo depuis un PC vers ma Chromecast.
Depuis un smartphone c’est bien mieux.
#27
Il serait d’ailleurs intéressant que VLC puisse à terme être utilisé non pas comme un moyen de diffuser du contenu vers un appareil distant, mais comme un récepteur Google Cast exploitable depuis des appareils tiers. Pour le moment, cela ne semble néanmoins pas à l’ordre du jour.
C’est effectivement la fonctionnalité que j’attends le plus. Ca permettrait de transformer un HTPC en clef Chromecast pour streamer directement de son téléphone vers sa télé. Voire à terme de streamer Netflix depuis mon téléphone vers mon Raspberry Pi, le pied….
Mais avoir VLC qui émet en Chromecast c’est déjà une grosse grosse étape, encore une fois félicitations à JB et son équipe, c’est vraiment un boulot de fou qu’ils effectuent.
#28
un rx chromecast sur pi/kodi ce serait bien aussi
#29
Yep ce serait le rêve absolu. Vu que VLC est open source et fonctionne par greffons, si un jour VLC sort une lib de reception CC il y a fort parier qu’un plugin verra le jour rapidement pour Kodi y compris sur le Pi. Ne serait-ce que pour tous les gens qui veulent pouvoir y streamer Netflix, alors qu’aujourd’hui c’est quasiment infaisable sauf à passer par un PC tiers avec Chrome et des options à la noix…
#30
c’est utilisable en ligne de commande ?
Je cherche justement à faire un peu ‘parler’ un Google Home mini avec des ressources locales, et il semblerait qu’il n’y ait pas d’autre solution que via le protocole chromecast.
Edit: à tester
vlc –sout=“#chromecast{ip=ip_address}” ./myRessourceFile.mp3
#31
manquerais plus qu’un pi4 avec décodage h265 HW :) et un pi0 3 avec un vrai DAC pour faire du multiroom facilement
#32
Ah ouais ça le décodage hardware H.265 c’est gros manque du Pi côté lecture média vu comme ce format est en train de supplanter les autres. C’est ce qui me fait considérer l’achat d’un HTPC sur x86, mais c’est loin d’être le même budget, donc pour l’instant je m’en passe…
#33
problème d’un pc c’est l’absence de hdmi cec, il y a bien un boitier supplémentaire mais c’est pas la panacée.
#34
Super ! J’ai enfin trouvé une utilité aux Chromecast ! " />" />" />" />" />
À voir pour la suite, ça fait une possibilité d’utilisation de plus de VLC. Tout de suite, chez moi, je vois pas, mais on ne sait jamais.
#35
Et pour le Fire Stick cela se passe comment du coup ?
#36
tu parles d’un adaptateur comme celui ci?
Quel est le problème ?
Je compte justement investir dans ce genre de boitier.
#37
Peut-on me dire à combien monte le débit du Chromcast. J’arrive pas à trouver d’information fraîche.
Dans mes souvenirs c’était du wifi b c’est à dire 11 mb/s.
Et comme certain de mes BD ripper atteignent les 35 Mbits/s c’était impossible d’utiliser un wifi en dessous de Ac.
#38
Le problème c’est déjà le surcoût (à lui tout seul il vaut plus cher qu’un Raspberry Pi avec accessoires) et le surplus de place / câblage, sachant qu’un HTPC en général on cherche à le garder discret et esthétique vu qu’il est dans les pièces de vie.
Je n’étais pas conscient de ce problème, effetivement c’est nul de la part des fabricants de GPU / APU de ne pas le supporter, je ne comprends pas ce choix…
Bon après perso je peux m’en passer, je fais le contrôle depuis le téléphone, la seule fonctionnalité que j’utilise en CEC c’est l’allumage de la télé dès que j’active l’IHM, je devrais pouvoir vivre avec ;)
#39
Je viens de tester (sur Windows 10), le flux vidéo/audio marche parfaitement, par contre les sous-titres ne fonctionnent pas :(
#40
D’après Wikipédia la dernière version (2016) fait du 802.11ac, donc si tu utilises tous les canaux tu peux en théorie monter à 866Mbps… (bon après faut pas rêver hein, la théorie et la pratique c’est différent).
#41
Je contrôle et démarre mon HTPC avec une Logitech Harmony infrarouge. Je n’ai pas encore essayé de configurer celle ci pour allumer ma TV et ma barre de son.
Ça fait tellement longtemps que je fais de cette manière que j’avais oublié les possibilités de mon Harmony…. " />
Je vais explorer cette piste avant d’acheter ce petit boitier.
#42
Ah ben c’est clair que là pour le coup tu as tout ce qu’il faut !
#43
ba juste un boitier en plus en plus, ça me gonfle
#44
#45
Mouais, le surcoût m’a l’air minimal et même si ça touche peu de gens ça peut être un critère de choix. Surtout dans le cas des IGP.
#46
#47
Ben justement, tu fais la R&D une fois, tu l’appliques partout, l’amortissement est vite fait…
#48
#49
Non, mais elle n’est pas non plus réinventée à chaque fois. Là c’est inclus dans les specs HDMI et dans la partie contrôleur HDMI, c’est un copier / coller, les coûts de R&D seront quasiment nuls, seuls les coûts d’intégration et de test & validation seront là. Et ce sera peanuts sur le prix total.
#50
Autrement en ligne de commande il y a aussi stream2chromecast
#51
#52
Super ! Parce que regarder les vidéos du mobile en partage d’écran vers Chromecast ça empêche de l’utiliser comme télécommande et ça le fait quand même bien chauffer (ce qui fait déconner la vidéo de temps en temps)… même si je suppose que c’est moins un problème avec les mobiles d’aujourd’hui que ceux d’il y a 5 ans ?
Sinon, il n’y a toujours pas moyen d’utiliser une Chromecast sans routeur dédié ?
#53
Excellent article, dont je suis passé à coté… (vacances post 3.0)
C’était notamment la vidéo 4K de Tears of steel qui ne pouvait pas être correctement lue depuis notre NAS par VLC sur notre Mac Mini. Cela n’était pas mieux une fois le rendu sur Android TV activé. Dans l’idéal, il faudrait que VLC puisse dire à l’appareil réseau de lire directement le contenu depuis l’emplacement où il se trouve, mais cela poserait trop de problèmes pratiques : protocoles supportés, protection par un mot de passe, etc.
Oui, c’est un peu relou, et j’ai pas de bonne solution: prober pour voir si le format est supporté et ensuite envoyer le lien si c’est le cas?
Autre élément à prendre en compte : les performances de votre machine. En effet, il faut que celle-ci soit capable de lire et de transmettre la vidéo, parfois de la compresser lorsque son format n’est pas nativement supporté par l’appareil distant. Un vieux processeur pourra donc poser problème.
On va activer QSV, nvenc dans la prochaine version pour ça.
Néanmoins, l’équipe a déjà indiqué que ce serait le cas dans de prochaines mises à jour. Il faut donc seulement s’armer d’un peu de patience. Le travail va continuer de se faire pour améliorer le support de Cast, qui pose encore parfois quelques petits soucis quand on change de fichier, ou l’arrivée de nouveaux protocoles.
Fin avril, normalement.
Il serait d’ailleurs intéressant que VLC puisse à terme être utilisé non pas comme un moyen de diffuser du contenu vers un appareil distant, mais comme un récepteur Google Cast exploitable depuis des appareils tiers. Pour le moment, cela ne semble néanmoins pas à l’ordre du jour.
Oui, je confirme: c’est pas encore notre focus. Notre focus, ça va être plus Airplay et UPnP Renderer.
#54
#55
#56
#57
#58
#59
#60