Bonjour
@Christian17300 a écrit :
Bonjour
Probablement mal interprété mes renseignements.
Le réseau en Giga existe, il est même en 2,5 Giga depuis quelques temps, mais pas chez moi, je n'ai pas la bonne box ni la bonne carte réseau sur ma carte mère.
Peut-être un mélange entre les unités Gb (gigabit) et GB (gigabyte)... Pour ma part, je ne les utilise jamais (pas plus que Gbps) :
- Go c'est tellement adapté au français pour le gigaoctet (correspondant à l'anglais gigabyte)
- Gbit c'est « l'autre » écriture disponible pour le gigabit, et même Wikipédia l'utilise préférentiellement dans son tableau d'unités informatiques (ICI), sans doute pour éviter ces confusions 😇
- et l'on aura compris, pour être précise concernant un débit, je recommande précisément alors Gbit/s (mon premier choix, comme celui préférentiel de Wikipédia en gras ICI, que je préfère à Gb/s et de loin à Gbps « à l'anglo-saxonne »)
@clohr a écrit :
,
la question n'est pas vraiment la surabondance de gigabits de débits sur le lan aujourd'hui. Le protocole DLNA (UPnP-AV) a été inventé il y a plus de vingt ans, à une époque où les débits étaient cent fois moindres. Il a été conçu pour offrir une expérience utilisateur tout à fait acceptable, même sur des faibles débits lan.
Je ne résumerai pas les choses comme cela : à mon avis, DLNA ne s'est jamais vraiment préoccupé de produire une expérience utilisation acceptable "même sur des faibles débits".
- C'est un simple protocole de streaming (concernant les contenus)
- Auquel est ajouté un système d'échange de fichier descriptifs en XML pour "informer" le client sur les contenus disponibles sur le serveurs (le contenus des répertoires, les infos annexes, etc.)
=> bref à mon avis, ils font et ont toujours fait avec le réseau existant, tel qu'il est, et avec son débit.
Et donc à l'époque de son introduction il fonctionnait avec les résolutions et qualité de l'époque comme aujourd'hui il fonctionne (identiquement) avec les résolutions qualités et débits d'aujourd'hui
- DLNA c'est de 1994 d'après Wikipédia ICI
- à l'époque les réseaux locaux c'était possiblement du 10 Mbit/s (et le 100 Mbit/s apparaissait tout juste puisque le "fast ethernet" à 100 Mbit/s a été publié en 1995, d'après ICI)
- donc à l'époque DLNA aurait difficilement fait passer une très bonne vidéo de haute qualité 1080p (qui peut facilement dépasser 10 Mbit/s)... sauf que c'est aujourd'hui qu'on a des vidéos de cette qualité et qu'à l'époque c'était bien moindre et le problème ne se posait pas...
Bref, pour moi, DLNA ne fait aucun effort particulier pour s'accommoder d'une faible bande passante... Ça passe si ça passe, c'est tout.
D'ailleurs, dans le DLNA il n'y a pas de "réencodage" (par exemple pour réduire le débit), cependant quelques rares serveurs DLNA le font "à la volée" (càd qu'ils font semblant de proposer un contenu différent au client que celui qui est stocké sur leur disque dur, par exemple pour limiter la résolution ou le débit nécessaire du côté de la réception du client).
@clohr a écrit :
,
Et c'est effectivement le cas,
Comme je l'ai dit, pour moi c'est une simple concordance d'usages :
- on utilise DLNA pour streamer des vidéos dont le débit binaire n'est pas supérieur au débit binaire du réseau sur lequel on l'utilise...
- mais si on l'utilisait sur un réseau trop faible, ben ça coincerait, ça bugguerait, ça saccaderait : aucune adaptation du débit, ni qualité progressive comme il peut y en avoir pour les diffusion IPTV par exemple.
@clohr a écrit :
,
pour peu que le protocole soit implémenté correctement, tant qu'à faire en utilisant les librairies existantes (ce qui est le cas de la box TV sfr), et de le faire correctement (ce qui n'est plus le cas de la box TV sfr depuis plus d'un an).
Pour la partie DLNA intégré aux box, oui le plus souvent ils utilisent en effet des bibliothèques (ou plutôt carrément des logiciels) existants :
- côté serveur : par exemple SFR et Numericable ont souvent intégré Twonky Media Server (c'est le cas sur la box-modem que j'ai actuellement)
- côté client DLNA: (càd la partie du décodeur qui visionne et affiche les contenus proposés par le serveur) ils peuvent aussi réutiliser des bibliothèques existantes (par exemple des SDK de clients DLNA) mais aussi refaire eux-mêmes leur cuisine de consultation du serveur (cuisine qui est très légère puisque le protocole DLNA ça a été conçu sur des échanges simples : utilisable dans des petits appareils, des ampli, dans des radios, tout ce qui est multimédia...).
Mon avis (donc personnel) est qu'ici sur le Décodeur Plus concerné par le bug :
- le dialogue de consultation des contenus DLNA exporté par le serveur est très vraisemblablement en grande partie écrit par le auteurs du logiciel interne du décodeur SFR, ou au moins une large surchouche au-dessus d'un potentiel existant
- en effet, parmi les raisons de ce "gros pépin" en interne, on nous a parlé de la volonté délibérée (je ne sais pas si c'est une contrainte qui vient de l'extérieur de SFR ou non) qu'il fallait filtrer les DivX dès l'affichage des listes de contenus
- (pour ma part, pour évincer ce format à la légalité discutable en effet, je n'aurais pas filtré ces contenus listés en les testant un par un, mais j'aurais fait échouer le décodage ensuite en associant un codec non fonctionnel à ce format... mais bon c'est leur choix).
Pour le reste, je pense
- que quoi qu'il en soit, il est évidemment possible de faire du "bon travail" pour obtenir un résultat acceptable si SFR demande à ses développeurs de se pencher sérieusement là-dessus
- et que si à ce jour ce n'est pas réalisé, c'est que SFR a clairement préféré les occuper sur d'autres tâches
@clohr a écrit :
on n'a pas de véritables interlocuteurs (je ne dis pas ça pour nos sympathiques community managers, certes compatissants, mais qui ne sont pas les développeurs.) Bref, ça ne peut pas avancer...
Ce n'est pas l'exact reflet de la réalité d'après moi.
- D'une part il est évident que même s'ils n'interviennent pas ici, les développeurs sont maintenant au courant de ce bug qui touche le Décodeur SFR (certains lisent de temps à autre, sans intervenir, d'autres sont mis au courant par les CM, et au final après plus d'un an c'est clair que c'est remonté depuis longtemps).
- D'ailleurs on a eu ici l'intervention transitoire d'un des salariés SFR de l'équipe de développeurs : ce qui démontre que chez les développeurs, on est au courant.
Je le redis, mon opinion est que si ça n'avance pas des masses, ce n'est pas parce qu'ils ne le savent pas, mais parce que ce n'est pas dans les tâches à faire que SFR priorise à son équipe de développeurs.
D'ailleurs, le fait que ce Décodeur Plus (alias STB7) ait disparu complètement des nouvelles offres actuelles aux clients (plus d'offre STARTER qui le propose, et l'offre au-dessus c'est directement avec un décodeur Connect TV) n'est pas bon signe pour les efforts de maintenance sur ce matériel.
Si mon hypothèse est avérée, ce ne serait malheureusement pas une nouveauté : pour ma propre box (BOX THD 4K) j'ai bien compris que plusieurs bugs apparus ces dernières années ne seraient finalement JAMAIS corrigés (et il y en a plusieurs, et de fort longue date) quand j'ai commencé à entendre depuis plusieurs années des retours d'officiels autour de "oui mais c'est un matériel vieillissant... plus proritaire... etc.".
À+
Digiclient NC → parti de sa planète disparue, pour une nouvelle terre d'accueil ♥
LaBox THD 4K (V3) - Connexion FttLA à 1000↓↑40 Mbit/s
