La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: hamzarb3 le 31 janvier 2013 à 17:13:10
-
Bonjour,
Veuillez nous éclaircir les points suivants (aux experts) et merci par l'avance;
1. Y a t-il un différence au niveau hardware entre une plateforme IPTV et une plateforme OTT (Over The Top) ?
ou IPTV/OTT reposent sur la même plateforme hardware, et la différence réside dans le soft uniquement ?
2. Si un opérateur dit qu'il veut déployer une plateforme 100% OTT ? ça veut dire quoi exactement ?
En fait, ça revient a déployer une plateforme IPTV ? OTT est juste un mode de fonctionnement de la plateforme, non ?
-
Et s'il s'agissait plus simplement de proposer une solution IPTV qui diffuserait le nanarissime film Over The Top (http://www.nanarland.com/Chroniques/chronique-overthetop-over-the-top.html) en boucle ?
Pas taper, je suis pas expert.
-
Je parle de la technologie OTT, non plus d'un film
-
Médekoikicos?
-
In the fields of Broadcasting and Content Delivery, Over-The-Top Content (OTT) means Broadband Delivery of Video and Audio without the Internet Service Provider being involved in the control or distribution of the content itself.
D'après cette définition (Wikipedia) :
- Service de TVIP/VoD d'un FAI = pas OTT
- Service de TVIP/VoD façon YouTube ou Google TV = OTT
Donc, pour répondre aux questions :
1. Les infrastructures (serveurs) des fournisseurs de contenus sont forcèment distinctes, et - sauf cas très particulier, style lecteur YouTube intégré dans le décodeur TV du FAI - le client (passerelle multimédia) utilisé pour accéder au service également
2. Qu'il va s'appuyer sur le réseau IP d'un FAI pour amener son service jusqu'à l'utilisateur (donc deux abonnements à payer, et aucune garantie de qualité de service)
-
Est-ce qu'il y a un moyen d'utiliser le multicast pour fournir le service OTT?
Si oui, comment?
Si non, est-ce que ça pourrait être considéré comme un abus de monopole?
-
Est-ce qu'il y a un moyen d'utiliser le multicast pour fournir le service OTT?
Le trafic multicast est filtré par les FAI ?
-
Pour moi la question est :
Est-ce que les FAI proposent des routeurs multicast utilisables par n'importe qui?
-
Ce qui revient un peu au même.
En IPv4, j'ai cru comprendre que le bloc 233.0.0.0/8 permettait à tout détenteur d'un numéro d'AS 16 bits de disposer d'un préfixe multicast valide.
Si les FAI ne filtrent pas - volontairement ou non - le trafic associé à ce bloc, je ne vois pas de raison pour qu'il ne puisse pas être utilisé par leurs abonnés pour joindre le service multicast d'un éditeur de contenus tiers.
-
On peut tester ça?
-
Avec un AS 16 bits valide, et un serveur situé sur le réseau associé à cet AS, je dirais que oui
Deux choses dont je ne dispose pas, donc je ne te propose pas d'essayer (sinon, ce serait avec plaisir) ...
Mais peut-être qu'un des valeureux FAI qui parcourent ces forums voudra tenter l'expérience pour faire avancer la science et étancher notre curiosité ?
-
Clairement, je ne connais aucun FAI qui accepte du trafic "internet" multicast.
A ma connaissance, l'Internet actuel ne permet quasiment pas de faire du multicast. Sur des réseaux privés, ou au sein d'un unique AS (RENATER), oui, ça fonctionne, mais il doit faloir être autorisé/déclaré pour le faire. Et entre 2 réseaux Internet, ça doit exister ponctuellement, mais je ne pense pas que ça soit possible de manière généralisée.
Il faut bien voir que le multicast nécessite des ressources supplèmentaires dans les routeurs et aussi les switches! Gérer des centaines de milliers de flux multicast, je ne sais pas si ça se fait avec les équipements d'aujourd'hui!
Avec un AS 16 bits valide, et un serveur situé sur le réseau associé à cet AS, je dirais que oui
Si on permettait à n'importe qui d'envoyer un flux multicast, ça serait le bazard, et on pourrait facilement dépasser les ressources du réseau avec peu de moyens au départ (un petit serveur). Imagine qu'une dédibox à 50€ pourrait à elle seule surcharger monstrueusement l'ensemble du réseau de Free. Donc clairement, c'est non!
Leon.
-
2. Si un opérateur dit qu'il veut déployer une plateforme 100% OTT ? ça veut dire quoi exactement ?
En fait, ça revient a déployer une plateforme IPTV ? OTT est juste un mode de fonctionnement de la plateforme, non ?
Quand tu parles d'opérateur, tu parles de FAI? Si c'est le cas, je te ferais une réponse assez différente de celle de Seb.
Un FAI qui déploie une infrastructure IPTV "classique", va normalement repenser son réseau, pour y inclure la possibilité de rajouter cette IPTV (VLANs, serveurs dédiés). Ca se fait essentiellement avec des solutions fermées et dédiées. Actuellement, avec les "Box", les vidéos (TV directe ou VoD) passent sur des réseaux (VLANs) séparés, et avec des protocoles spécifiques.
Faire de la vidéo "OTT", c'est au contraire changer le moins de choses au réseau dédié à Internet, et faire passer la VOD par dessus (d'où le terme over the top). C'est faire de la vidéo sur le même réseau que celui qui sert à faire de l'Internet, avec les mêmes protocoles. Ca permet de prendre des solutions standardisées, avec des protocoles standards. Ca permet aussi d'externaliser les serveurs de VoD "dans le cloud" (comme on dit en ce moment), auprès d'un prestataire. Ca permet enfin de gérer avec la même plate-forme de serveurs les différents équipements (tablette, PC) qui se connectent sur les différents réseaux fixe et mobiles de l'opérateur, qui se connectent de la même façon aux serveurs.
Les infrastructures (serveurs) des fournisseurs de contenus sont forcèment distinctes, et - sauf cas très particulier, style lecteur YouTube intégré dans le décodeur TV du FAI - le client (passerelle multimédia) utilisé pour accéder au service également
C'est la où je ne suis pas d'accord. En fait, le fournisseur de contenu et l'opérateur peuvent être un seul et unique acteur. Et même dans ce cas, il est possible de déployer une solution de vidéo-OTT. Dans ce cas, ça consiste à installer des serveurs sur son réseau IP, mais avec des solutions logicielles différentes, utilisant les standards d'internet, c'est tout.
Leon.
-
Leon, je veux bien que tu éclaires ma lanterne, parce que je ne vois pas bien ce qu'un flux multicast émis par un serveur, et auquel seraient abonnés 10 clients, aurait de plus lourd que 10 flux unicast entre ce même serveur et ces mêmes clients.
Si le multicast existe, et est employé par les FAI pour diffuser leurs offres TV, c'est bien parce que ça consomme moins de ressources, non ?
D'autre part, dans le bloc 233.0.0.0/8, les octets 2 et 3 correspondent au numéro d'AS.
Tu es donc limité à 250-et-quelques flux multicast par AS, et je ne vois pas comment - selon toute vraisemblance, dans ces conditions - tu te retrouverais à devoir gérer des centaines de milliers de flux multicast.
Imagine qu'une dédibox à 50€ pourrait à elle seule surcharger monstrueusement l'ensemble du réseau de Free. Donc clairement, c'est non!
Dans la mesure de ma compréhension des mécanismes du multicast (qui est très limitée, je peux donc me tromper), le trafic multicast issu de cette machine n'aboutirait qu'aux clients qui y sont abonnés.
Le flux n'atteindrait donc même pas la dorsale de Free s'y personne n'y est abonné.
-
Leon, je veux bien que tu éclaires ma lanterne, parce que je ne vois pas bien ce qu'un flux multicast émis par un serveur, et auquel seraient abonnés 10 clients, aurait de plus lourd que 10 flux unicast entre ce même serveur et ces mêmes clients.
Si le multicast existe, et est employé par les FAI pour diffuser leurs offres TV, c'est bien parce que ça consomme moins de ressources, non ?
Pas de problème pour "éclairer ta lanterne". En fait, l'unique flux de 5Mb/s envoyé vers 10 abonnés sera beaucoup moins cher à créer pour le fournisseur de contenu que les 10x5Mb/s. Et le gérer, ça sera plus cher pour le FAI qui va devoir router ça. Il est donc normal que ça ne soit pas autorisé.
1) Comme je l'ai dit plus haut, le multicast, ça nécessite des opérations particulières dans les routeurs et switches de l'opérateur. Le nombre de flux multicast que sait gérer un routeur est limité. Donc les ressources multicast d'un réseau sont clairement limitées. Si mes souvenirs sont bons, ça se compte en milliers/dizaines de milliers de flux seulement.
2) Le mode de facturation du multicast n'existe pas aujourd'hui. Faisont l'hypothèse que le multicast soit autorisé avec le même tarif de transit qu'aujourd'hui. En utilisant du multicast, un serveur très basique (donc peu cher) va pouvoir envoyer ce flux vers plein de branches du réseau FAI en même temps. OK, ça va soulager le backbone. Mais le reste du réseau (collecte locale) sera plus facilement encombré par de petits fournisseurs de contenu qui ne payent quasiment rien. Le fournisseur de contenu devrait donc payer son transit en fonction du nombre de clients atteints. Je ne sais même pas si les moyens techniques actuels permettent le paiement en fonction du nombre d'utilisateur du signal multicast.
Bref, si on autorise le multicast, tous les fournisseurs de contenu iront, petits et gros. Ca leur simplifiera encore plus la vie, et ça complexifiera encore plus la vie de FAI.
D'autre part, dans le bloc 233.0.0.0/8, les octets 2 et 3 correspondent au numéro d'AS.
Tu es donc limité à 250-et-quelques flux multicast par AS, et je ne vois pas comment - selon toute vraisemblance, dans ces conditions - tu te retrouverais à devoir gérer des centaines de milliers de flux multicast.
C'est très simple : tu multiplies une centaine de flux de chaque "fournisseur de contenu" par une centaine ou un millier de ces fournisseurs de contenu.
Leon.
-
Pour finir d'exposer mon propos, je pense que si le multicast-peering se développe un jour, ça se fera avec des interconnexions différentes, et ça sera clairement facturé de manière spécifique par le FAI au le fournisseur de contenu. Mais on n'y est pas du tout aujourd'hui.
Leon.
-
Merci pour ces explications limpides. :)
Du coup, à moins que l'opérateur de la solution OTT n'ait un accord avec l'opérateur de réseau pour diffuser son trafic en multicast, une solution de TV sur IP en mode OTT risque d'être fort chère pour l'abonné, puisqu'il faudra que l'opérateur de la solution dépense des sommes folles en transit IP.
Je remets donc une pièce dans la machine :
Si non, est-ce que ça pourrait être considéré comme un abus de monopole?
On en revient au principe de neutralité, et sans parler forcèment de monopole, les solutions de TVIP des opérateurs conventionnels - qui refuseraient tout accord de multicasting - pourraient être considérées comme de la concurrence déloyale, non ?
-
Je remets donc une pièce dans la machine :On en revient au principe de neutralité, et sans parler forcèment de monopole, les solutions de TVIP des opérateurs conventionnels - qui refuseraient tout accord de multicasting - pourraient être considérées comme de la concurrence déloyale, non ?
Neutralité ne veut pas dire gratuité des interconnexion. Ce sont 2 concepts complètement différents. J'ai l'impression que tout le monde ne l'a pas assimilé, même chez les gros opérateurs.
Si on prouve que ça coute au FAI de router/transporter du multicast (ce qui sera facile), et qu'en plus ça diminue les couts pour le fournisseur de contenu (hors interconnexion), alors la facturation est indispensable.
Mais pour que la facturation permette au réseau du FAI d'être neutre, il faut qu'elle soit :
1) raisonable : en liaison avec ses couts réel du FAI (le FAI a le droit à une marge, mais elle doit être raisonnable).
2) non discriminatoire : sans privilégier un acteur plus qu'un autre, donc de manière donc plus transparente
Bref, interconnexion neutre ne veut pas dire gratuite.
Leon.
-
Je n'ai pas dit que ça devait être gratuit, mais que si l'opérateur de réseau refuse tout accord commercial dans des conditions raisonnables pour les deux parties, alors il y a possible distorsion de la concurrence.
-
Je remets donc une pièce dans la machine :On en revient au principe de neutralité, et sans parler forcèment de monopole,
Si, forcèment.
Un telco est un monopole, toujours.
-
Mais pour que la facturation permette au réseau du FAI d'être neutre, il faut qu'elle soit :
1) raisonable : en liaison avec ses couts réel du FAI (le FAI a le droit à une marge, mais elle doit être raisonnable).
2) non discriminatoire : sans privilégier un acteur plus qu'un autre, donc de manière donc plus transparente
J'ajoute que la transparence est indispensable pour vérifier le 1) et le 2).
-
Bonjour,
Veuillez nous éclaircir les points suivants (aux experts) et merci par l'avance;
1. Y a t-il un différence au niveau hardware entre une plateforme IPTV et une plateforme OTT (Over The Top) ?
ou IPTV/OTT reposent sur la même plateforme hardware, et la différence réside dans le soft uniquement ?
2. Si un opérateur dit qu'il veut déployer une plateforme 100% OTT ? ça veut dire quoi exactement ?
En fait, ça revient a déployer une plateforme IPTV ? OTT est juste un mode de fonctionnement de la plateforme, non ?
La différence réside surtout dans le protocole utilisé pour diffusé les contenus.
Dans le cas des telco (hors numéricable) , que ce soit pour la VoD ou le Live, la diffusion est faite via RTSP. Les fournisseur de contenus eux, se basent sur de l'HTTP Progressive Download (ex : youtube) ou de l'HTTP Adaptive Streaming (ex : M6Replay, Pluzz ...).
Le cas de la France est un peu particulier à cause des FAI et de leurs box. Aux Etats-unis c'est plus simple : on a un FAI qui propose une connexion à internet (ADSL, cable, FTTH ...), et par dessus ça les founisseur de contenus style Netflix, Google vont te fournir leurs services vidéos. En France c'est "la box" qui fait tout.
Si un opérateur dit qu'il veut déployer une plateforme 100% OTT ? ça veut dire quoi exactement ?
Tu à un exemple d'opérateur qui a pour projet de faire une plateforme 100% OTT ?
J'ai eu vend qu'un opérateur Français avait pour projet de migrer la diffusion de ses VoD en mode OTT.
--> Quel est l'avantage de passer d'un réseau managé avec une qualité de service garantie à un transport en mode Best Effort ?
-
Tu à un exemple d'opérateur qui a pour projet de faire une plateforme 100% OTT ?
J'ai eu vend qu'un opérateur Français avait pour projet de migrer la diffusion de ses VoD en mode OTT.
--> Quel est l'avantage de passer d'un réseau managé avec une qualité de service garantie à un transport en mode Best Effort ?
J'ai eu une information qu'un opérateur a l'idée de déployer une plateforme 100% OTT,
1. Est ce que c'est réalisable techniquement ? Si oui, merci de nous communiquer une brève description.
2. Comment bénéficiera-t-il de sa plateforme si ça sera le cas ? (services/facturation/abonnement...)
-
J'ai eu une information qu'un opérateur a l'idée de déployer une plateforme 100% OTT,
Merci de nous donner le nom de cet opérateur.
Leon.
-
Merci de nous donner le nom de cet opérateur.
Leon.
Bonjour,
Je ne suis pas de la France, je suis tunisien et je travaille sur ce sujet,
je désire enrichir mes connaissances sur ce sujet et avoir l'aide nécessaire de la part des experts, et est ce possible qu'un opérateur pourra mettre en place une plateforme 100% OTT,
Merci.
-
Je ne suis pas de la France, je suis tunisien et je travaille sur ce sujet,
OK, je comprends mieux. Tu aurais pu le dire tout de suite.
est ce possible qu'un opérateur pourra mettre en place une plateforme 100% OTT,
Oui, je ne vois pas ce qui empêcherai ça. Un opérateur/FAI peut très bien mettre en place pour lui même, sur son réseau, une plate forme Vidéo-OTT. Ca doit surement être le cas quelque part dans le monde.
Leon.
-
S'il fait cela, il valide que c'est techniquement faisable et raisonnablement efficace, donc il devra accepter que d'autres le fassent aussi sur son réseau - éventuellement en le facturant.
-
Quand tu dis 100% OTT, ça veut dire les flux Live + VoD + Catchup ?
-
Quand tu dis 100% OTT, ça veut dire les flux Live + VoD + Catchup ?
Oui, l’étude portera sur tous les services: Live TV, VoD et Catchup,
Avez-vous un document descriptif d'une telle solution ?
Et comment l'opérateur pourra bénéficier de sa plateforme OTT par rapport à une IPTV classique ? (Marketing, revenus...)
Merci.
-
Et comment l'opérateur pourra bénéficier de sa plateforme OTT par rapport à une IPTV classique ? (Marketing, revenus...)
Le gros argument avancé par les boites qui proposent de telles solutions TV OTT, c'est le fait d'être compatible de tout type d'écran (TV, PC, tablette, smartphone). Tous ces "écrans" se connectent en IP, donc de la même façon, que ça soit sur le réseau mobile ou fixe.
A mon avis, il n'y a aucun autre argument "visible du client" possible. Si l'opérateur décide juste de faire de la VOD et TV classique sur de vrais téléviseurs avec une solution "OTT", alors ça ne sera pas visible du client. L'opérateur y verra peut-être un intérêt économique (vraiment pas certain) par rapport à une solution classique, mais ça sera invisible du client final.
Leon.
-
Aussi, l’opérateur peut procéder à ce genre de plateforme afin de ne pas dépenser du temps de de ressources pour configurer son réseau (vlans spécifiques dédiés pour la véhiculer les flux TV, et aussi garantir une QoS.
En OTT, l’opérateur cherche à ne pas faire de grands efforts, juste il fait le transfert via le flux internet (via http) sans QoS,
-
La conception d'une plateforme OTT est relativement simple comparé aux plateformes classiques IPTV (diffusion RTSP), ce sont de simple serveur WEB (Apache et/ou IIS 7.0)
La diffusion vidéo est basé sur de l'HTTP, généralement de l'HTTP Adaptive Streaming. Comme le dit leon_m, la plupart des terminaux sont compatibles (Tablettes, STB, PC, Smartphones) mais a condition que l'opérateur prépare les contenus dans les deux formats populaire : Microsoft Smooth Streaming (PC, Windows phone) et HTTP Live Streaming (HLS de Apple : pour Iphone et Android).
Avantage :
- Permet de mieux gérer les problématiques d'éligibilité
- Trick modes avec image dégradée mais plus rapide et fluide qu'en RTSP
- Meilleur compatibilité aux services multi-screen, watch and record ...
- Facilité d'intégration d'un CDN (il s'agit de simples caches HTTP contrairement aux CDN dédié RTSP)
Inconvénients :
- Transport HTTP plus gourmand (génère un trafic remontant, parfois problématique)
- Techno jeune, nombreux protocoles disponibles, pas d'implèmentation universelle sur tous les OS
- Pas de multicast possible pour diffuser le live
-
Merci pour les précisions :)
-
Merci bien pour votre explication :)
-
Inconvénients :
- Meilleur compatibilité aux services multi-screen, watch and record ...
???
-
Je pense ça fait partie des avantages, non ?
-
Exact, c'est une ligne copier/coller des avantages. Par contre j'avais oubliéqu'on ne peut pas faire de multicast avec ce genre de protocole qui repose sur TCP. J'ai éditer tout ça dans mon message précédent.
-
Exact, c'est une ligne copier/coller des avantages. Par contre j'avais oubliéqu'on ne peut pas faire de multicast avec ce genre de protocole qui repose sur TCP. J'ai éditer tout ça dans mon message précédent.
Donc, je comprend que la TV en direct (ou Live TV) n'est pas possible en OTT ?
Dans ce cas aussi, l'opérateur n'a pas besoin d'installer une partie tête du réseau (head-end) qui comporte des paraboles pour l'acquisition du signal depuis les différents satellites ?
Les services à fournir seront la VoD principalement..., et quoi d'autres ?
Merci
-
Le Live est possible en OTT (flux TCP Unicast) mais si 10 000 abonnés regardent le même flux c'est 10 000 fois le débit qui est consommé.
En multicast un seul flux est nécessaire pour tous.
Donc c'est possible mais ce n'est pas son domaine de prédilection.
Il y a déjà des direct sur Dailymotion (Youtube, je n'ai pas vu de direct mais cela doit exister)
-
Donc, je comprend que la TV en direct (ou Live TV) n'est pas possible en OTT ?
C'est possible, mais à faible echelle. Même avec l'aide d'un CDN, la bande passante consommer sera énorme.
Pour une diffusion OTT il va falloir adapter les flux TV :
- Réencodage en différents niveaux de qualités
- Découpage en fragments
- Transmission sur les POP vidéos
Pour des flux liveTV, cela implique souvent un décalage important par rapport au temps réel.
Les services à fournir seront la VoD principalement..., et quoi d'autres ?
Du Live pour un publique plutôt restreint, des VoD, Catch-up, services de TV Perso à la Free, du stream de vidéo à partir du Cloud par exemple.
-
Pour pouvoir se différencier des services OTT VoD comme NetFlix, comment un opérateur télécom peut-il valoriser ses services ?
- Appliquer une QoS pour assurer une qualité maximum à ses services par rapport aux concurents ?
- Restreindre de ces services à accéder son réseaux ?
- Faire payer ces fournisseurs de services pour leur offrir une priorisation sur le réseau ?
Ces pratiques s'apparentent toute de même à des pratiques anti-neutralité ...
-
- Appliquer une QoS pour assurer une qualité maximum à ses services par rapport aux concurents ?
- Restreindre de ces services à accéder son réseaux ?
- Faire payer ces fournisseurs de services pour leur offrir une priorisation sur le réseau ?
Oui pour le point en gras, le reste n'est que logique : pas besoin de paramétrer sa box pour avoir la télé pendant que les 3 gosses surfent au ralenti. Cela va de soi.
Pour le dernier point, cela a déjà fait l'objet de moultes débats.
-
Bonjour,
Quelles peuvent être les différentes méthodes pour intégrer une solution OTT au réseau de l’opérateur ?
- Cloud-based: pour gagner des ressources en termes de hardware et bénéficier de la virtualisation
- Plateforme complète à installer et la connecter au réseau,
- autres ?
-
Pour des raisons de performances je ne conseillerai pas de virtualiser ce type de composant.
Une plateforme OTT pour de la vidéo, au final c'est simplement des serveurs WEB :
- Windows Server avec IIS pour du Microsoft Smooth Streaming (clients PC, Windows Phone)
- Linux avec Apache pour du HLS, streaming HTTP à la sauce Apple (clients Android, Iphone)
La diffusion se fera généralement via un CDN style akamai ou le CDN de l'opérateur pour qui tu travail.
Et le provisionning des vidéos sur ta plateforme OTT dépend du fournisseur (externe ou interne).
-
C'est vaste comme terme "virtualiser". J'ai bosse avec des inges Intel, avec de la virtualisation "bare metal" tu obtiens un delta de perf de l'ordre du pourcent. C'est fini les grosses plateforme avec un OS / machine physique.
-
Attention, le terme Cloud ne signifie pas forcèment virtualisation! Ce sont 2 concepts différents.
Ici, faire de l'OTT dans le Cloud, ca peut très bien vouloir dire que les serveurs sont externalisés. Dans ce cas, le prestataire fourni les serveurs, le soft, l'administration des serveurs, etc...
On appelle ça du SAAS, je crois: Software As A Service.
Leon.
-
J'ai entendu dire que ça coutait moins cher pour opérateur de diffuser ses VoD en HTTP Streaming en OTT contrairement à du RTSP classique sur réseau managé.
Quelqu'un saurait me dire pourquoi ?
Quelques suppositions dont je ne suis pas sur du tout :
- CDN moins complexe (simple cache HTTP)
- Peu d'ingénierie réseaux pour le transport: pas de VC/VLAN VoD sur les DSLAM, Box etc
...
-
En HTTP Streaming pas besoin de prioriser les flux, pas besoin de protocole pour renvoyer les paquets perdus (RTP-R), possibilité d'utiliser de l'open source (Apache2).
Bref, je ne serais pas étonné que demain la VoD des opérateurs soit en HTTP Streaming (ce n'est pas le cas aujourd'hui)
-
Bref, je ne serais pas étonné que demain la VoD des opérateurs soit en HTTP Streaming (ce n'est pas le cas aujourd'hui)
On s'en rapproche petit à petit. Les clients en zone non éligible d'Orange (ceux qui reçoivent les flux TV via satellite) sont en HTTP Progressive Download pour les VoD. Les composants utilisés pour du HTTP Streaming sont les mêmes.
-
Bonjour,
Quels impacts y aura sur le réseau dans le cas ou 10,000 abonnés par exemple regardent simultanèment un programme TV en direct (match de football par exemple) via leurs STBs au sein d'une plateforme OTT TV ?
-
Ca te fait 20Gb/s de traffic qui arrive sur un seul point du réseau (avec des flux vidéo à 2Mbits/s). Même sans cache HTTP ça reste faisable.
-
un seul point du réseau, càd ?
-
Tu vas écouler vers ton opérateur en question ton trafic en un ou deux points de ton réseau en gros selon comment tu es interconnecté.
-
Merci,
Quelques points restent à éclaircir,
Supposons que la plateforme OTT TV est mise en place par l’opérateur,
1. Les flux live TV et VoD seront acheminés via le trafic internet (comment cela est-il réalisé techniquement ? plateforme connectée vers les PoPs des
FSI ?)
2. Il n'y a aucun impact sur le réseau de l’opérateur ? pas de limitations ? même dans le cas ou plus que 10,000 abonnes regardent simultanèment
un programme TV en direct ?
3. L’opérateur, peut-il appliquer une QoS pendant les événements importants live ? si oui, comment ?
4. CDN = cache HTTP, en terme de prix, ça coute moins cher qu'un CDN classique dédié RTP/RTSP pour IPTV ? en terme de hardware et software, c'est
moins complexe ? et nécessite moins de capacité de stockage ?
Merci pour vos commentaires.
-
1. Si ce n'est pas toi qui est l'opérateur du réseau ton flux sera transporter via "l'internet" avec une QoS en Best Effort, donc aucune qualité garantie (après ça peut très bien fonctionner, exemple : pluzz, M6replay etc...)
2. Je pense que le traffic est assimilé à un simple flux HTTP comme tu pourrai consulter un site web classique.
4. Hardware plutôt semblable, idem en terme de stockage. Un flux vidéo de 2Mbits/s est sensiblement le même qu'ils soit diffusé en HTTP Streaming ou en RTP. Software : on se retrouve avec des serveurs web classique style apache ou IIS.
-
1. Si ce n'est pas toi qui est l'opérateur du réseau ton flux sera transporter via "l'internet" avec une QoS en Best Effort, donc aucune qualité garantie (après ça peut très bien fonctionner, exemple : pluzz, M6replay etc...)
Comment l’opérateur fait réellement si c'est lui qui possède une plateforme OTT ?
-
Il tage le flux (champ DSCP par exemple).
Pour la place occupée par les serveurs, il un serveur de 2u gère 4 Gb/s de trafic.
Donc pour gérer 20 Gb/s, il te faut 5 serveurs de 2u équipé chacun de 4 interfaces 1 Gb/s cuivre et un swith avec 20 ports 1 Gb/s cuivre et 2 ports 10 Gb/s (plus si tu souhaites faire un peu de redondance).
-
Il tage le flux (champ DSCP par exemple).
Le champ DSCP marqué pour une QoS best effort implique l'acheminement du trafic avec le flux internet,
comment est la procédure de marquage ?
-
Comment marquer DSCP pour acheminer les flux sur internet ?
-
En général le champs DSCP est remis par à 0 par le FAI, je me trompe?
-
Le flux non prioritaire est à 0, les autres flux ont par contre un champs DSCP qui n'est pas a 0.
Pour faire un test pour voir des paquets avec DSCP différent de 0, le plus simple est généralement de s'abonner à un flux multicast.
-
Est-ce que, par exemple, un fournisseur de vidéo pourrait envoyer des flux multicast à travers le réseau By?
-
Oui, nous avons plusieurs fournisseur de flux multicast et il serait possible, après accord, de rajouter un nouveau fournisseur.
-
De point de vue utilisateur (service OTT transparent pour lui),
on a un client (navigateur web, application...) installé sur sur son ordinateur ou son STB,
Ce client doit contenir les informations relatives au serveur TV OTT de l’opérateur (adresse IP...) ?
Les flux provenant de ce serveur TV OTT de l’opérateur sont marques comme best effort (champ DSCP mis à 0) sur tous les équipements de transmission et d’accès qui séparent le serveur de l'utilisateur final,
est ce la procédure de véhiculer ainsi le flux TV via le flux internet (comme ça on arrive a l'OTT) ?
-
Avec un champ DSCP à 0 le flux doit êtr impérativement dans TCP et non UDP.
hamzarb3, pourriez-vous nous présenter un peu votre projet ?
Vous posez beaucoup de questions, mais ici c'est un lieu d'échange dans les deux sens.
-
L’opérateur en question désire acquérir sa propre plateforme TV en mode OTT pour offrir des services similaires au mode purement IPTV, (c'est un peu bizarre puisque en OTT, les fournisseurs sont indépendants de l’opérateur de télécommunications comme par exemple Netflix et Hulu..., l’opérateur est considéré comme pipe/tuyau dans ce cas),
franchement je suis débutant dans ce domaine, et j'ai voulu poser des questions afin de bien comprendre les choses,
-
Avec un champ DSCP à 0 le flux doit êtr impérativement dans TCP et non UDP.
Sinon, ça explose?
-
Merci hamzarb3 pour l'explication.
Su les flux ne sont pas priorisés, dès que le client fait un téléchargement (donc débit max) il y a des pertes de paquets (c'est normal en TCP, c'est pour voir où est la limite).
En UDP un paquet perdu est perdu et donc cela entraîne une dégradation pur le client. 0,01% de perte de paquet suffit a rendre un flux illisible. C'est pour cela que TCP est recomandé car il ré-èmet les paquets perdus.
Il est aussi possible de mettre un système de ré-émission de paquets en UDP mais c'est plus compliqué.
En France le premier opérateur à avoir mis en place ce mécanisme est SFR => SFR active sa technologie PurePixel (https://lafibre.info/sfr-les-news/sfr-active-sa-technologie-purepixel/)
-
La réservation de capacité pour un flux, à la façon des circuits ATM à capacité fixe, c'est mort?
-
En France le premier opérateur à avoir mis en place ce mécanisme est SFR => SFR active sa technologie PurePixel (https://lafibre.info/sfr-les-news/sfr-active-sa-technologie-purepixel/)
Il me semble bien que Free avait dégainé avant sur cette techno de retransmission de paquets pour la TV, y compris pour le multicast. Ils n'avaient pas fait autant de pub, mais on en avait pas mal parlé sur la toile. C'était à l'époque où Free innovait, et était devant les autres en terme d'innovation. Ils disait que c'était un développement interne qui faisait intervenir le DSLAM (maison) pour les retransmissions.
Leon.
-
La technologie
Nitro PhyR implèmente la retransmission directement au niveau du ATM, donc c'est très rapide et ça marche pour tout et pas seulement pour la TV.
-
Nitro, c'est un gain de débit ATM par compression des en-têtes ATM. Cela ne corrige rien.
C'est la techno PhyR de Brodcom (qui depuis qui a été standardisée en G.INP) qui est utilisée par de nombreux FAI aujourd'hui.
Ce n'est pas du bout en bout : Les pertes sur le réseau de collecte ou le CPL chez le client ne sont pas corrigées. PhyR / G.INP est donc une technologie complèmentaire a une technologie de correction couche haute (RTP-retry, la techno que SFR appelle pure pixel) ou le FEC.
-
C'est la techno PhyR de Brodcom (qui depuis qui a été standardisée en G.INP) qui est utilisée par de nombreux FAI aujourd'hui.
De nombreux FAI dont By?
Ce n'est pas du bout en bout : Les pertes sur le réseau de collecte ou le CPL chez le client ne sont pas corrigées. PhyR / G.INP est donc une technologie complèmentaire a une technologie de correction couche haute (RTP-retry, la techno que SFR appelle pure pixel) ou le FEC.
Sur le réseau de collecte, le FAI peut faire ce qu'il faut pour que ses services gérés soient prioritaires.
Après, chez Free il n'y a rien. Tu perds un paquet, c'est pour ta pomme.
C'est un gros reproche que je fais à la Free TV.
-
Des pertes de paquets sont possible sur le réseau de collecte pour de nombreuses autres raisons que la surcharge des liens.
Tous les opérateurs priorisent la TV sur leur réseau.
Bouygues Telecom propose à certains de ses clients PhyR et à d'autres G.INP.
-
J'étais resté dans l'idée que seul Free proposait DSLSafe = PhyR.
D'autres FAI le proposent?
Tant mieux.
-
SFR et Bouygues Telecom (quand box et DSLAM compatibles) proposent également du PhyR.
Orange ne propose pas de PhyR car ses box sont avec un chipset Ikanos (Livebox v2 et Livebox v3).
Je pense que G.INP va arriver prochainement chez Orange (la normalisation est récente) pour les possesseurs de Livebox v3 et d'un DSLAM compatible G.INP.
-
Bravo SFR, bravo By!
Cela fait une raison forte de moins de préférer Free en ADSL.
-
Bonjour,
1. Vu que l’opérateur voudra déployer tout seul une plateforme OTT TV, cela veut dire qu'il n'y aura plus de dégroupage de la boucle locale ?
ou le dégroupage peut avoir lieu avec des offres séparées (offre FSI et Opérateur) ?!!
2. Véhiculer le flux TV via le trafic internet = garder la même session login et pwd (PPPoE ou PPPoA) fournis par le FSI ?
Sinon, comment faire ?
-
Il y a des modèles qui séparent complètement les opérateurs :
- de réseau physique
- de réseau actif
- de fourniture de service
Avec des rétributions dans tous les sens.
Mais je ne sais pas si c'est efficace au final.
-
Bonjour,
1. Mise en service d'une plateforme OTT TV (véhiculer les flux par le trafic internet) veut dire que ça sera via la même session PPPoE (login et mot de passe au niveau du modem ADSL) ?
Donc, ce cas c'est le FSI/FAI qui devrà avoir la plateforme et pas l’opérateur (en cas de dégroupage) ? comment est la situation s'il n'y aura plus de dégroupage ?
2. Le protocole HLS employé dans ce modele OTT segmentent le flux en des morceaux de multiples bit-rates, lesquels seront fournis à l'abonné selon la qualité de sa ligne,
Possible de ragarder de la HD avec un abonnement ADSL de 2 Mbps ?
-
Tout passe dans la même session PPPoE.
Pour de la HD, il faut 5,6 Mb/s IP chez Youtube en 1080p. En ADSL, un débit de 6,7 Mb/s est donc nécessaire.
(https://lafibre.info/images/tuto/201108_youtube_1080p.png)
Penser pouvoir faire mieux que Youtube me semble difficile, par contre il est possible de réduire de faire de la HD avec moins de débit (720p ou dégrader la qualité de chaque image)
A l'avenir le protocole le VP9 va permettre de réduire le débit utilisé pour une même qualité => WebM : Le VP9 (gratuit) va concurrencer H.265 (payant) (https://lafibre.info/tv-numerique-hd-3d/webm-vp9/)
-
D'accord,
OTT = via le flux internet en http = même session PPPoE
en architecture purement IPTV, c'est de l' IPoE directement ?
-
En architecture purement IPTV on est sur de l'UDP
Au passage la courbe de consommation de la VoD est assez spéciale :
Ce n'est pas du tout cette courbe :
(https://lafibre.info/images/bistro/201201_fermeture_megaupload_01.jpg)
C'est plus des pic très haut que des montagnes. presque pas de trafic en journée et ça explose en soirée.
-
Il manque la courbe de la VOD!
-
J'ai pas la coubre mais justement elle ne resemble pas a celle d'internet.
Internet : La consommation monte tranquillement de 5h du matin à 21h00 redescendent ensuite (la descente est plus rapide que la montée)
VoD : La consommation reste faible tout le temps sauf de 20h à minuit.
-
En architecture purement IPTV on est sur de l'UDP
D'accord, le fait qu'on est sur deux protocoles de transport différents implique qu'on n'est pas sur la même session.
-
Bonjour à tous,
je suis nouveau dans ce forum.
J'ai une question à propos de ce sujet.
Quelqu'un pourrait m'expliquer :
Le cas d'usage de la gestion de QoS data (Intérêt pour un OTT fournisseur de contenu video comme Netflix)
-
Le meilleur exemple que j'ai c'est cet article de ZDNet : http://www.zdnet.fr/actualites/svod-contre-pay-tv-aux-etats-unis-le-choc-des-titans-39797246.htm (http://www.zdnet.fr/actualites/svod-contre-pay-tv-aux-etats-unis-le-choc-des-titans-39797246.htm) .
La situation est aux US, mais avec netflix qui arrive, voire même les FAI qui se prennent pour des content-manager ( http://www.lefigaro.fr/secteur/high-tech/2014/01/16/01007-20140116ARTFIG00517-google-play-box-la-bonne-surprise-de-sfr.php (http://www.lefigaro.fr/secteur/high-tech/2014/01/16/01007-20140116ARTFIG00517-google-play-box-la-bonne-surprise-de-sfr.php) ) , on va assister à de drôle de choses en 2014.
Hopus ( https://lafibre.info/gix/hopus/ (https://lafibre.info/gix/hopus/) ) arrive à point nommé pour les FAI nationaux, semble-t-il ... Un hasard ? :o
Aux US c'est AT&T qui ouvre les hostilités ( http://beta.slashdot.org/story/196517 (http://beta.slashdot.org/story/196517) ) à la suite de la décision de justice qui stipule que la FCC n'a pas à imposer la neutralité du net : http://bgr.com/2014/01/14/net-neutrality-court-ruling/ (http://bgr.com/2014/01/14/net-neutrality-court-ruling/) .
Techniquement parlant la QoS peux prendre plusieurs forme, soit l'installation d’équipements dédiés (sous linux on peut aisèment faire ça avec l'outil "tc", quand les flux sont plus important on peut utiliser les fonctionnalités des routeurs.
On peux aussi, c'est ce que fait Free, laisser certaines routes saturer, afin de "naturellement" limiter le débit. Ainsi, les abonnés de Free qui veulent regarder Youtube en savent quelque chose, les vidéos en deviennent inregardables.
Quand c'est Youtube c'est déjà chiant, mais quand en plus , on paye le service (comme pour la VOD avec Netflix) ben là, ça devient un pb économique (tu vas pas payer netflix si chaque soir, c'est saturé & que tu peux pas en profiter. Certes tu peux changer de FAI... mais en France, t'a pas 50 choix non plus en ADSL).
-
Merci Obinou.
Les informations sont vraiment intéressantes. En fait, ce qui m'intéressent beaucoup c'est le côté technique et surtout les impacts de la QoS sur les sessions Netflix (ou OTT) durant la congestion ... etc.
ensuite, je cherche un exemple où l'idée de faire un schéma d'un OTT qui serait interconnecté à au moins 2 PCRF* de 2 opérateurs différents. Chaque opérateurs pourrait vendre une option akamai* de sous 2 formes différentes, l'un pourrait vendre une option à ses abonnés à xEuros / mois en illimité et l'autre opérateur pourrait proposer une offre au volume comme par exemple 3 Go de contenu akamai par mois.
Qu'est ce qui serait différent comme paramètres sur la Rx* d'un opérateur à l'autre ?
PCRF= une entité fonctionnelle qui inclut les fonctionnalités de policy control et flow based charging control.
Akamai= Fournisseur d'OTT
Rx= interface qui relie les deux entités PCRF et AF
-
Ah ok, tu parlais de l'inverse: comment "prioritiser" , de multiple manière & selon plusieurs type d'offres la QOS du point de vue technique, où les FAI proposeraient à leurs abonnés une sorte de "pass Youtube" , ou "pass Netflix" selon plusieurs modalités ? Principe curieux, mais après tout, si il y un marché...
Sur ce plan-là, mes connaissances sont limitées à ce qu'on peut trouver dans Linux (et c'est déjà pas mal, notamment avec les dernières versions) mais bon, on est pas du tout sur des niveaux de trafic d'un réseau national ou régional.
J'avoue que je sais pas comment ça pourrait marcher à l'échelle d'un gros réseau. à un niveau local, si j'avais à faire ça, je placerais au plus près de mes abonnés un PC sous linux avec des cartes réseau Intel, et j’utiliserai "tc" pour classifier le trafic en fonction de l'IP source (akamai) & ip cible (client); avec des scripts pour interroger régulièrement et mettre en BDD les compteurs de paquets/taille, avec une qdisc 'premium' et une autre 'regular'. les poids & la discipline de ces 2 qdisc devraient être évalués , mais globalement ça devrait remplir l'objectif.
Mais bien sur, ça va pas tenir 50.000 clients un tel système: A mon avis, des routeurs haut de gamme doivent savoir faire ce genre de truc, le plus chiant après étant de faire le système de facturation en interaction avec netflow ou snmp pour récupérer les valeurs des files d'attente par clients.
-
obinou, cela m'étonne ces conseils de ta part, c'est pas très neutre...
-
J'ai pas dis que j'étais pour un tel système chez un FAI ouvert au public ! Néanmoins, techniquement , ça reste faisable, et là je ne connais pas le contexte.
Après tout , chez moi je fais bien de la QoS sur mon LAN, sinon le soir quand on télécharge un fichier, on peut plus aller sur le net, avec le sat ... :-)
Sur un FAI grand public je pense que c'est une connerie, mais bon, tu sais ce que c'est: Si c'est faisable, alors ça sera fait :-)