Netflix mise sur H.264 AVCHi et VP9 pour améliorer la qualité des vidéos sur mobile

Netflix mise sur H.264 AVCHi et VP9 pour améliorer la qualité des vidéos sur mobile

Des différences visibles sur la facture

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

09/12/2016 3 minutes
36

Netflix mise sur H.264 AVCHi et VP9 pour améliorer la qualité des vidéos sur mobile

Pour contrôler sa consommation de données, Netflix commence à compresser ses vidéos avec deux nouveaux formats, pour la lecture hors-ligne sur mobile pour l'instant. Par rapport H.264 AVCMain classique, le AVCHi-Mobile et le VP9-Mobile (de Google) proposent des gains de place pour la même qualité perçue.

Certains craignent de recevoir leur facture d'électricité, d'autres celle de transit Internet. Pour s'éviter toute déconvenue, Netflix cherche constamment de nouveaux moyens d'économiser de la bande passante : installer les serveurs chez les opérateurs (via son programme OpenConnect), bloquer la qualité vidéo sur mobile et, bien entendu, réduire le poids des contenus qu'il distribue.

Dans un billet de blog du 1er décembre, l'entreprise détaille la manière dont elle réduit la taille de ces vidéos sur mobile, via l'usage de deux « nouveaux » formats de compression : H.264 AVCHi-Mobile (AVC High Profile) et VP9-Mobile. Le premier est une amélioration face au format H.264 AVCMain, devenu le standard de l'industrie. Le second est conçu par Google et supporté par Android, en concurrence de H.264, sans les royalties de ce dernier. Depuis un mois, la société traite son catalogue avec ces deux formats.

D'abord pour la lecture hors-ligne, puis le streaming sur mobile

Pour justifier ce travail, Netflix rappelle le lancement dans 130 pays (dont certains aux connexions limitées) et l'arrivée toute récente de la lecture de vidéos hors-ligne, une fonction attendue de longue date par ses clients. En mai, la société a aussi supprimé la limite de qualité vidéo à 360p sur mobile, après un scandale aux États-Unis.

Ces deux « encodages mobiles » servent d'abord à la lecture de vidéos hors-ligne sur Android et iOS, avant d'être généralisés au streaming sur mobile. Cela avec des paramètres de compression optimisés face à ceux utilisés avec H2.64 AVCMain. Autre changement : la compression d'une vidéo n'est plus définie en fonction de l'intégralité du contenu, mais par des segments ce qui permet une meilleure granularité.

Des chutes de poids pouvant atteindre près de 36 %

Après un premier mois de travail, quels sont les gains constatés ? Sur un échantillon de 600 films et épisodes de séries populaires avec une source en 1080p, soit environ 85 millions d'images traitées, l'entreprise montre des gains substantiels selon le format utilisé. À qualité vidéo perçue « équivalente », AVCHi-Mobile permet de réduire de 15 % à 19 % la taille de la vidéo, contre près de 36 % pour VP9-Mobile.

La qualité perçue est définie selon deux méthodes : l'une par l'entreprise, l'autre par le Bjontegaard-delta rate (BD-rate), ou PSNR, largement utilisé dans l'industrie. Selon Netflix toujours, ces deux formats permettent donc d'afficher une meilleure qualité vidéo avec un même bitrate, avec des différences de 7 % et 10 % en moyenne.

Dans les faits, les principaux gains de qualité vidéo devraient être perçus sur Android. Le système d'exploitation de Google supporte en effet le codec maison, contrairement à iOS. Sur ce dernier, les gains restent tout de même importants. Sur le fond pourtant, il n'est pas dit que les utilisateurs s'en rendent vraiment compte, au-delà des chiffres. Quand elle a admis bloquer la qualité vidéo à 360p sur la plupart des réseaux mobiles mondiaux, l'entreprise affirmait que très peu d'utilisateurs percevaient la différence sur de si petits écrans.

36

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

D'abord pour la lecture hors-ligne, puis le streaming sur mobile

Des chutes de poids pouvant atteindre près de 36 %

Commentaires (36)


En H.265/HEVC il gagnerait plus, bon faut que le matos soit assez récent pour qu’il arrive à le lire.


Il était sans doute temps d’opter pour le profil High, qui existe depuis les débuts du format. Je pensais même que c’était déjà le cas, avec tout le blabla autour du thème Netflix optimise l’encodage…

http://techblog.netflix.com/2015/12/per-title-encode-optimization.html



En gros, la société commence à peine à utiliser ce que les internautes trouvent depuis près de dix ans sur la toile. À ce rythme, l’HEVC pourrait être adopté à l’horizon 2028


H265 sinon? Puisqu’ils utilisent une version Android, je suppose que le matos peut faire du décodage Hardware, ou alors j’ai pas compris.


Comme tout le monde ici, je n’ai pas compris pourquoi ils ne sont pas passés en H265 ?



Problème de décodage hardware non présent sur une grande partie du parc ?



Pourquoi ne pas avoir fait une compression en H264,VP9 et une autre en H265 ? En fonction de ses capacités, le client aurait l’un ou l’autre format. CA prendrait plus de place mais permettrait de diminuer encore plus la bande passante.

Quand je vois la différence de taille des fichiers de certaines vidéos de vacances en H264 et H265, c’est parfois 2 fois moins gros pour une qualité identique.


et oui c’est souvent le hardware des clients qui est à la traîne, j’utilise un petit pc portable peut performant avec ma télé pour regarder netflix… et souvent il en bave pour rendre le contenu, j’ose pas imaginer avec un codex encore plus gourmand en puissance.








Borée a écrit :



Il était sans doute temps d’opter pour le profil High, qui existe depuis les débuts du format. Je pensais même que c’était déjà le cas, avec tout le blabla autour du thème Netflix optimise –l’encodage– la compression…

http://techblog.netflix.com/2015/12/per-title-encode-optimization.html





C’est vrai pour le profil “High”, c’est celui que je sélectionne pour Handbrake, je ne sais pas quelle contraintes il entraine sur les décompresseurs, je suppose que ça demande plus de puissance, ou peut-être des variantes algorithmiques que tout le monde n’implémente pas par défaut.

NB : attention, utiliser plutôt “compression” voire “codage” que l’anglicisme “encodage”.







Borée a écrit :



En gros, la société commence à peine à utiliser ce que les internautes trouvent depuis près de dix ans sur la toile. À ce rythme, l’HEVC pourrait être adopté à l’horizon 2028





J’ai remarqué qu’ici pas mal s’excitent sur l’HEVC, mais oublient que tout le monde n’est pas un geek avec du matériel récent. Entre la création du H264 et son usage répandu, il s’est passé du temps aussi.







Guénaël Pépin a écrit :



en concurrence de H.264, sans les royalties de ce dernier





Attention, ces royalties n’ont de sens et de validité qu’aux États-Unis (certes, la boîte est américaine), car dans le reste du monde on ne peut pas breveter de logiciel et d’algorithme.





L’article oublie de dire aussi que Netflix découpe toutes ses vidéo en segment de 1-3 minutes afin d’optimiser la compression



http://variety.com/2016/digital/news/netflix-offline-downloads-codecs-vp9-120193…







For its new download option, the company is taking the idea one step further: Instead of changing these settings per title, Netflix is cutting each and every video into one-to-three-minute-long chunks. Computers then analyze the visual complexity of each and every of these clips, and encode with settings that are optimized for its visual complexity.


 





misterB a écrit :



L’article oublie de dire aussi que Netflix découpe toutes ses vidéo en segment de 1-3 minutes afin d’optimiser la compression





Je dirais que tu te trompes <img data-src=" /> :





la compression d’une vidéo n’est plus définie en fonction de l’intégralité du contenu, mais par des segments ce qui permet une meilleure granularité.




 D'ailleurs je ne pige pas bien cette histoire de découpage ; la compression peut se faire au fil de l'eau d'un fichier en fonction du degré de compression nécessaire à la qualité, il n'y a pas besoin de le découper, c'est comme les modes de compression des sons en MP3/Vorbis, il y a le CBR (Constant BitRare), le ABR (Adaptative), le VBR (Variable).     





Et quand on fait une compression en 2 passes, c’est aussi pour compresser avec plus d’informations les scènes qui bougent beaucoup, et moins d’information celles plus tranquilles, pour qu’au final la qualité perçue soit meilleure.



Ça permet peut être de changer la compression de la vidéo à la volée en fonction de la qualité de la connexion (en mobilité par exemple).


&nbsp;Autre changement : la compression d’une vidéo n’est plus définie en fonction de l’intégralité du contenu, mais par des segments ce qui permet une meilleure granularité.



Ce n’est pas ça comme indiquer dans l’article ?



Bref certains commentaire devrait se remettre en question. Déjà Netflix consomme pas mal en batterie (écran, réseau), si en plus il faut ajouter de la consommation processeur non merci.

Pas besoin d’un smartphone à 800€ pour ça.


Bien qu’ils optimisent leur compression video, mais pour moi, c’est dans l’audio qu’ils ont des problèmes. Les son est souvent mauvais. Certes, les voix sont claires et les basses présentes, mais le rendu des musiques est souvent très en-dessous d’un streaming sur youtube, par exemple.



A voir si cela s’améliore…








OlivierJ a écrit :



Je dirais que tu te trompes <img data-src=" /> :






 D'ailleurs je ne pige pas bien cette histoire de découpage ; la compression peut se faire au fil de l'eau d'un fichier en fonction du degré de compression nécessaire à la qualité, il n'y a pas besoin de le découper, c'est comme les modes de compression des sons en MP3/Vorbis, il y a le CBR (Constant BitRare), le ABR (Adaptative), le VBR (Variable).     





Et quand on fait une compression en 2 passes, c’est aussi pour compresser avec plus d’informations les scènes qui bougent beaucoup, et moins d’information celles plus tranquilles, pour qu’au final la qualité perçue soit meilleure.





<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Oui tu peux utiliser un VBR, mais c’est plus rapide de découper les vidéo que de laisser le soft analyser 2h de film et encoder <img data-src=" />



OlivierJ: “Attention, ces royalties n’ont de sens et de validité qu’aux États-Unis (certes, la boîte est américaine), car dans le reste du monde on ne peut pas breveter de logiciel et d’algorithme.”



On peut dans beaucoup de pays dans le monde breveter un logiciel. C’est le cas en Europe et en France.

&nbsp;

La loi française (et la CBE) précise qu’un logiciel n’est pas brevetable, mais il n’est pas brevetable “en tant que tel”, et toute la finesse réside justement dans ce “en tant que tel”.



On parlera donc plutôt “d’inventions mises en œuvre par ordinateur” plutôt que de “logiciel”. Concrètement, on peut protéger un programme d’ordinateur mettant en œuvre un procédé brevetable.

&nbsp;

Après, certain juge aime bien jouer la provocation en France, cf. Orange vs Free.



&nbsp;








Nikoap a écrit :



OlivierJ: “Attention, ces royalties n’ont de sens et de validité qu’aux États-Unis (certes, la boîte est américaine), car dans le reste du monde on ne peut pas breveter de logiciel et d’algorithme.”



On peut dans beaucoup de pays dans le monde breveter un logiciel. C’est le cas en Europe et en France.





Eh non.

Bon courage pour essayer de breveter un logiciel, surtout un logiciel de compression ou un algorithme. Ça n’existe pas, et à supposer qu’un tel brevet ait été délivré, il ne vaut rien.

Typiquement, le MP3 a pu être breveté aux US, mais était libre ailleurs, d’où par exemple les 2 types de dépôts Debian : “US” et “non-US”, ce deuxième pouvant avoir tous les trucs brevetés aux US.

&nbsp;

En France et dans beaucoup de pays, le logiciel est protégé par le droit d’auteur.









misterB a écrit :



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Oui tu peux utiliser un VBR, mais c’est plus rapide de découper les vidéo que de laisser le soft analyser 2h de film et encoder <img data-src=" />





Rhaaa, compresser, convertir, coder, mais pas “encoder”, pliiiiz.



Mais le soft de toutes façons au départ analyse au moins 2 trames (ou plus) à la fois pour comprimer de façon efficace, il suffit de le configurer pour qu’il garantisse un débit constant sur une certaine durée, en bornant le degré de qualité (vers le bas et le haut) sur cette durée.









OlivierJ a écrit :



C’est vrai pour le profil “High”, c’est celui que je sélectionne pour Handbrake, je ne sais pas quelle contraintes il entraine sur les décompresseurs, je suppose que ça demande plus de puissance, ou peut-être des variantes algorithmiques que tout le monde n’implémente pas par défaut.&nbsp;&nbsp;





Oui, le décodage nécessite plus de ressources et le mode HIGH demande des prérequis qui ne sont peut-être pas implémentés partout. Ceci étant, si Netflix décide d’opter pour ce mode aujourd’hui, c’est que les soucis d’incompatibilités doivent être plutôt modestes. Téléphones, tablettes, GPU PC&nbsp;supportent le mode High depuis longtemps déjà. Ce n’est pas comme s’ils avaient été implémentés il y a deux ou trois ans à peine. D’où ma surprise.&nbsp;

J’imagine toutefois sans peine qu’une société qui veut se développer veut limiter au maximum les frustrations et permettre à tout le monde d’accéder à ses services. Du coup, du 360p en AVC Main permettait vraiment de brasser large le temps que la notoriété de la marque soit bien établie.



En même temps VP9 est le concurrent direct du HEVC.








OlivierJ a écrit :





Attention, ces royalties n’ont de sens et de validité qu’aux États-Unis (certes, la boîte est américaine), car dans le reste du monde on ne peut pas breveter de logiciel et d’algorithme.



Les brevets couverts par MPEG-LA ne sont pas seulement déposés aux US mais aussi dans l’UE, Chine, Japon, …&nbsp;

Ces brevets concernent des procédés de compression et pas leur implémentation logicielle.









brujita a écrit :



Les brevets couverts par MPEG-LA ne sont pas seulement déposés aux US mais aussi dans l’UE, Chine, Japon, …&nbsp;



Ces brevets concernent des procédés de compression et pas leur implémentation logicielle.








Ils ne sont pas valables hors US, ce sont des brevets logiciels, en d'autres termes ils concernent des algorithmes. On ne PEUT pas breveter d'algorithme en Europe, et ici c'est bien d'un algorithme qu'il s'agit.   



J’ai déjà rappelé pourquoi Debian a ou avait des miroirs “US” et “non-US”.









Ami-Kuns a écrit :



En H.265/HEVC il gagnerait plus, bon faut que le matos soit assez récent pour qu’il arrive à le lire.





J’ai encoder Kaamelott qui était en h.265 en h.264 pour ma Freebox et j’ai gagné quelques Mo pour chaque fichier.

Et tout en gardant tout le colis (format, ips, etc…)…



Bon après, S.U.P.E.R est bien foutu et permet un max de réglages. :)



Il y a une différence entre logiciel (serie d’instructions dans un langage informatique) et algorithme (méthode ou procédé pour résoudre un problème avec ou sans ordinateur). Les brevets FR/EU excluent le logiciel seulement. &nbsp;MPEG-LA fait valoir ses droits sur des brevets qui ne sont pas seulement déposés aux US.



Je suis preneuse si tu as un lien qui dit clairement que MPEG-LA ne peut exercer ses droits en dehors des US.&nbsp;








Aces a écrit :



J’ai –encoder– CONVERTI Kaamelott qui était en h.265 en h.264





<img data-src=" />

Merci.









brujita a écrit :



Il y a une différence entre logiciel (serie d’instructions dans un langage informatique) et algorithme (méthode ou procédé pour résoudre un problème avec ou sans ordinateur). Les brevets FR/EU excluent le logiciel seulement.





Oui, le logiciel est exclu aussi parce qu’on considère ici qu’on ne peut pas breveter un algorithme. Le logiciel ne fait qu’implémenter un algorithme. Si tu inventes un algorithme de compression, en Europe tu ne peux breveter ni l’algorithme, ni un logiciel qui l’implémente. Tout ce que tu peux faire c’est de commercialiser ton logiciel, qui sera protégé par le droit d’auteur, comme tous les logiciels.







brujita a écrit :



MPEG-LA fait valoir ses droits sur des brevets qui ne sont pas seulement déposés aux US.



Je suis preneuse si tu as un lien qui dit clairement que MPEG-LA ne peut exercer ses droits en dehors des US.&nbsp;







Le problème c’est que les sociétés sont le plus souvent basées aux US donc poursuivibles là-bas. Mais une société purement européenne ou asiatique par exemple, qui ne commercialiserait pas aux US, n’en aurait rien à faire de ces brevets. En fait le MPEG-LA attaque je crois les vendeurs de matériel qui gère le H264 (même si c’est géré en logiciel dans le matériel en question).

&nbsp;

D’ailleurs sous Linux tu peux compresser et décompresser du H264 sans souci, ça donne une idée.



Je n’ai pas de lien sous la main.



OlivierJ : il serait souhaitable que tu nous donnes des sources pour étayer tes affirmations. Je te renvoie pour ma part aux sources précédemment données&nbsp; sur les sites de l’INPI et de l’OEB.



Concernant le MP3 - soit disant non brevetable hors US - voici une liste de brevets un peu partout dans le monde :



http://mp3licensing.com/patents/index.html



je te laisse aussi faire quelques recherches sur Google Patent (ou Espacenet) avec les mots clefs “computer program”. Tu te rendras vite compte que le “brevet logiciel” n’est pas spécifique aux USA.

&nbsp;


A partir du moment où l’on utilise l’enc/dec provenant de MPEG-LA l’auteur de l’application doit payer des royalties. Cisco a réussi à negocier auprès de MPEG-LA l’utilisation de l’enc/dec H264 gratuitement si c’est l’utilisateur de l’application qui le télécharge explicitement.

http://www.openh264.org/BINARY_LICENSE.txt


Allez, hop, pour rire, un exemple de brevet octroyé en Europe en 2005 et portant sur un procédé (algorithme ?) de compression de code :



https://www.google.fr/patents/EP1378999B1



Cerise sur le gâteau, la revendication 26 de ce brevet porte sur un “computer program”.



On délivre donc bien des brevets dits “logiciels” en Europe.








Nikoap a écrit :



Concernant le MP3 - soit disant non brevetable hors US - voici une liste de brevets un peu partout dans le monde :



http://mp3licensing.com/patents/index.html




 je te laisse aussi faire quelques recherches sur Google Patent (ou Espacenet) avec les mots clefs "computer program". Tu te rendras vite compte que le "brevet logiciel" n'est pas spécifique aux USA.











Nikoap a écrit :



Allez, hop, pour rire, un exemple de brevet octroyé en Europe en 2005 et portant sur un procédé (algorithme ?) de compression de code :



https://www.google.fr/patents/EP1378999B1




 Cerise sur le gâteau, la revendication 26 de ce brevet porte sur un "computer program".       






 On délivre donc bien des brevets dits "logiciels" en Europe.








 Non, non et non, les brevets logiciels ne sont PAS valables en Europe !      

Ce n'est pas pour rien qu'il y a eu une bataille là-dessus il y a quelques années. Michel Rocard d'ailleurs a bien défendu la position anti-brevet.






Si certains ont été déposés, c'est abusif et ils ne valent rien et sont contestables en justice. Même aux US où ils sont légaux, il y a des brevets déposés (légalement) et contestables (et contestés).








bewar a écrit :



A partir du moment où l’on utilise le codec provenant de MPEG-LA l’auteur de l’application doit payer des royalties. Cisco a réussi à negocier auprès de MPEG-LA l’utilisation de l’enc/dec H264 gratuitement si c’est l’utilisateur de l’application qui le télécharge explicitement.

http://www.openh264.org/BINARY_LICENSE.txt





Là c’est déjà différent, car le codec produit par MPEG-LA n’est pas libre et peut être vendu comme n’importe quel logiciel (ou soumis à licence).

&nbsp;

Mais x264 (https://fr.wikipedia.org/wiki/X264 ) n’est pas soumis à ça.









durthu a écrit :



Comme tout le monde ici, je n’ai pas compris pourquoi ils ne sont pas passés en H265 ?



Problème de décodage hardware non présent sur une grande partie du parc ?



Pourquoi ne pas avoir fait une compression en H264,VP9 et une autre en H265 ? En fonction de ses capacités, le client aurait l’un ou l’autre format. CA prendrait plus de place mais permettrait de diminuer encore plus la bande passante.

Quand je vois la différence de taille des fichiers de certaines vidéos de vacances en H264 et H265, c’est parfois 2 fois moins gros pour une qualité identique.





je confirme tu a tout a fais raison



Je vois que tu es convaincu par ce que tu dis.



J’aimerais maintenant que tu arrives à me convaincre : tes sources ?



M. Rocard a effectivement “lutté” contre le brevet logiciel, et a été présenté comme ayant gagné cette lutte.



On peut dire effectivement qu’il a “gagné” dans le sens où un logiciel n’est pas brevetable “en tant que tel”.



Et ce “en tant que tel” est très important, c’est là toute la finesse de la chose. On ne protège pas un logiciel en soi, mais, par exemple, un logiciel comprenant un procédé brevetable.



Au final, des brevets “logiciels” sont aujourd’hui délivrés par l’OEB. Et l’INPI. Et dans d’autres pays européens.



Que tu estimes ces brevets non valides ou abusifs est ton droit. Mais il faudrait plus que ton simple avis pour qu’un brevet valablement délivré devienne d’un coup invalide.





&nbsp;


Qunad tu vois le viol de la redevance que demande la société qui gère les droits, tu comprends vite pourquoi le h265 n’est utilisé que pour les rips perso grace à libx265.



Inutile de vous poser des questions, chez netflix ils font des tests d’optimisation de malade sur tous les codecs même h265. Faites un tour sur leur blog.


Ils en sont où avec leur format AOMedia Video ? Me semble que Netflix fait parti de l’alliance qui doit bosser sur ce concurrent du format H265/HEVC qui ne demanderait pas de royalties.

Si à moyen terme ils prévoient de pousser le format AV1, ils veulent p-e pas perdre du temps et de l’argent avec l’HEVC.


À voir s’il y a plus récent

https://www.inpi.fr/sites/default/files/1_3_extrait_pi_et_transformation_economi…



Ce qui est applicable en France l’est en Europe et inversement sur ce point.



L’algorithme c’est un peu comme la recette d’un gâteau non protegeable.


Bien joué :



“Il n’en reste pas moins que comme pour le droit d’auteur, la brevetabilité indirecte de l’algorithme reste admise, notamment si celui-ci est intégré dans une invention elle-même brevetable il est à ce sujet utile de se référer à la jurisprudence de l’office européen des Brevets (OEB). Dès 1986, dans l’affaire T208/84, l’OEB fit une distinction entre la méthode mathématique en tant que telle, insusceptible de brevetabilité, et la revendication ayant pour objet un procédé technique dans lequel cette méthode est utilisée.&nbsp;On peut, en outre, prendre pour exemple la décision IBM aux termes de laquelle il a été décidé qu’un programme d’ordinateur inséré dans un ordinateur peut être breveté dès lors qu’il apporte «un effet technique supplémentaire » à cet appareil. On peut également citer les décisions Hitachi (T258/03) et Microsoft (T424/03) où l’OEB s’est attachée à démontrer en quoi un programme d’ordinateur pouvait améliorer techniquement l’ordinateur dans lequel il est intégré.&nbsp;Pour résumer la position de l’OEB, un algorithme ou un logiciel peut être brevetable indirectement à condition qu’il soit intégré à une invention et lui apporte une contribution technique”.

&nbsp;








Nikoap a écrit :



Bien joué :




"Il n’en reste pas moins que comme pour le droit d’auteur, la brevetabilité indirecte de l’algorithme reste admise, notamment si celui-ci est intégré dans une invention elle-même brevetable il est à ce sujet utile de se référer à la jurisprudence de l’office européen des Brevets (OEB). Dès 1986, dans l’affaire T208/84, l’OEB fit une distinction entre la méthode mathématique en tant que telle, insusceptible de brevetabilité, et la revendication ayant pour objet un procédé technique dans lequel cette méthode est utilisée.&nbsp;On peut, en outre, prendre pour exemple la décision IBM aux termes de laquelle il a été décidé qu’un programme d’ordinateur inséré dans un ordinateur peut être breveté dès lors qu’il apporte «un effet technique supplémentaire » à cet appareil. On peut également citer les décisions Hitachi (T258/03) et Microsoft (T424/03) où l’OEB s’est attachée à démontrer en quoi un programme d’ordinateur pouvait améliorer techniquement l’ordinateur dans lequel il est intégré.&nbsp;Pour résumer la position de l’OEB, un algorithme ou un logiciel peut être brevetable indirectement à condition qu’il soit intégré à une invention et lui apporte une contribution technique".     



&nbsp;





Le codec de la mpegla et les logiciels qui en découlent sont donc protégés. Par contre, la mise en place d’un codec libre et son utilisation ne serait pas illégal en tant que tel. Après ce serait le cas uniquement pour des entités purement européennes qui n’agissent pas sur les territoires ou les algos sont protégés (USA en gros).



&gt; Le codec de la mpegla et les logiciels qui en découlent sont donc protégés.



Un brevet couvre un pays ou une région (Europe, ARIPO, OAPI, …) (passons sous silence le brevet international - PCT - qui n’en est pas vraiment un). Il faut donc voir par quels brevets (i. e. sur quels territoires) le codec est protégé.



&gt; la mise en place d’un codec libre et son utilisation ne serait pas illégal en tant que tel.



Libre ou pas libre, ça ne change rien ici. Si le codec libre met en œuvre un procédé breveté, il est contrefaisant (only sur le territoire concerné par le brevet, of course).



&nbsp;Son utilisation, sa commercialisation ou sa diffusion, même gratuite, sur le territoire concerné est une contrefaçon (exception : les actes accomplis dans un cadre privé ET à des fins non commerciales).



Si le brevet porte sur un logiciel, caractérisé par les éléments A, B et C (des étapes d’un procédé par exemple), alors si le codec est un logiciel (libre ou pas) comprenant au moins ces éléments A, B et C, il y a contrefaçon.

&nbsp;