Bonjour,
j'ai lu un peu de documentation sur le sujet, mais je ne connais pas grand chose en matière d'encodage vidéo. J'aimerais avoir vos avis pour choisir un format adéquat, compte tenu de ce que je souhaite faire.
A l'aide de ffmpeg, je réalise une capture vidéo d'un écran.
Sur cette écran, un programme se charge d'ouvrir différents lecteurs de contenus (documents, vidéos, diaporamas,...).
ffserver se charge de diffuser un flux correspondant à la vidéo capturée.
Des écrans lisent ce flux et l'affichent, grâce à un ordinateur embarqué dans l'écran.
Quel codec me conseillez-vous, sachant que :
- je veux faire de l'encodage en temps réel (avec un décalage de quelque secondes possible)
- mon contenu est principalement statique, à l'exception de diaporamas animés et occasionnellement un peu de vidéo (mais pas de la HD)
- le but de la compression est simplement d'économiser de la bande passante sur le réseau (entre l'encodeur et les afficheurs)
- j'ai le contrôle des ordinateurs des afficheurs, donc je peux y installer des décodeurs exotiques si besoin
Je pensais utiliser ffmpeg, vu que je l'utilise déjà pour la capture vidéo, mais je peux utiliser mencoder si besoin, pour la partie compression vidéo.
Merci d'avance !
Forum Linux.débutant Compression vidéo : quel codec utiliser ?
30
oct.
2008
# Ce que j'ai déjà compris
Posté par santos . Évalué à 4.
- celles qui ne valent rien (avi C null télechargr pluto divx pro C trop puissan)
- les comparatifs poussés mais appliqués à l'encodage de films.
J'ai au moins compris qu'il y a deux choses à choisir :
- un conteneur (AVI ou MPG), qui n'influe ni sur le poids ni sur la qualité de la vidéo finale)
- un codec audio et un codec vidéo.
L'audio pour le moment ça ne m'intéresse pas.
Pour la vidéo, priori les deux codecs en vogue sont x264 et xvid, tous deux des implémentations partielles et libres des spécifications MPEG4.
J'ai cru comprendre que x264 a un rapport qualité/poids légèrement supérieur à xvid.
[^] # theora et dirac
Posté par Adrien . Évalué à 5.
Il y a également le codec theora aussi, qui est moins bon que x264 et xvid apparemment mais plus rapide à l'encodage. Si tu veux encoder en temps réel c'est peut-être intéressant.
J'ai aussi entendu parler de dirac aussi… mais je sais pas si on peut trouver des encodeurs facilement. Apparemment le dirac tue pour les vidéos de bonne qualité, mais il est assez gourmand en cpu…
— pour les conteneurs :
Matroska est aussi très intéressant et libre : on peut y mettre un grande quantité de format apparemment.
ça peut être intéressant si tu veux mettre des pistes audio en vorbis par exemple.
[^] # Re: theora et dirac
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pour le logiciel regarde VLC !
"La première sécurité est la liberté"
# Plus d'informations ?
Posté par briaeros007 . Évalué à 4.
-peu consommateur et en codage, et en décodage
-compression suffisante pour envoyer sur 10 Mbps
-codec "historique" => beaucoup de matériel/savent savent le lire
2°) la puissance nécessaire
- si tu as des machines de guerre, alors tu peux essayer des codecs plus efficaces comme le mpeg4 ou le mpeg4-avc (h.264). La consommation nécessaire est grosso modo la suivante
MPEG4=2-4x MPEG-2
MPEG4-AV=2-4x MPEG4
3°) Les pertes
Si ton réseau est soumis à perte ou modification , tu peux voir à
- augmenter la compression : on diminue le nombre de paquet a transmettre (un paquet modifié => un paquet perdu) , donc le nombre de paquet perdu diminue.... Mais le nombre d'information transmise par paquet est plus important. Par conséquent, une perte a(peut avoir) plus d'impact visuel.
- diminuer la compression , pour qu'une perte ait moins d'impact visuel.
tout dépend si les pertes sont dus à une congestion (trop de débit) , au médium, a ...
4°) La transmission
Il existe plusieurs moyen pour la transmission
- Tu peux essayer d'utiliser du multicast puisque c'est un producteur, de multiples consommateurs.
- Tu peux utiliser aussi du RTP/... en unicast
- Tu peux en outre essayer d'utiliser des mécanismes d'ARQ (récupérer des paquets perdu), mais la on commence a rentrer dans le lourd
[^] # Re: Plus d'informations ?
Posté par santos . Évalué à 2.
merci pour ces nombreuses remarques.
Concernant MPEG-2, peut importe qu'il soit répandu ou non, puisque je suis libre d'installer ce que je veux, tant côté serveur que côté clients.
En revanche, son bon ratio consommation/compression m'intéresse bien.
As-tu une idée d'un ordre de grandeur de consommation de ressources de Theora comparé à MPEG* ?
J'essaye de concevoir mon application en faisant abstraction des contraintes réseau, mais en pratique il est possible qu'elle soit déployée sur des réseaux "pourris" (10Mbps, équipements de piètre qualité, encombrement, etc...). Donc mieux vaut choisir une solution qui dans un premier temps ne consommera pas trop de bande passante.
D'autant plus que si dans un premier temps un réseau de qualité moyenne suffit pour connecter 4 écrans, les contraintes seront différentes si je veux mettre 40 écrans...
Concernant la puissance de mes clients, voici leur configuration matérielle :
Carte COMMEL LS-372
Processeur Intel Core Solo ou Duo
Chipset Intel 965
1 GO de RAM minimum
Carte graphique intégrée Intel X3100
Connectique HDMI
SSD de 1 à 4GO ou disque dur
Gigabit Ethernet
Cependant, le réseau derrière n'est pas forcément Gigabit, toussa...
Donc à mon avis, il vaut mieux que je mise sur la puissance de décodage de mes clients, et que j'économise un maximum de bande passante.
Concernant les pertes, la mise en place d'un tunnel SSH ou d'un VPN résoudrait le problème, non ? Il est possible que cela me soit imposé pour des raisons de sécurité.
En termes de qualité, pour le moment je ne cherche pas à faire de la vidéo HD... Les écrans sont toutefois HD-ready (1366*768).
A titre d'exemple, je souhaite qu'une présentation PowerPoint ou OpenOffice soit capturée en vidéo, puis affichée sur mes écrans, sans pertes visibles (genre que ça ne fasse pas des vieux petits carrés ou des saccades pendant les transitions). Par contre les contenus sont essentiellement statiques, à l'exception des transitions dans les diaporamas, et quelques vidéos occasionnelles, mais de type publicité, donc pas nécessairement de grande qualité.
La transmission multicast, je ne pense pas. A terme, chaque afficheur recevra un flux différent (donc capturé et encodé séparément).
[^] # Re: Plus d'informations ?
Posté par briaeros007 . Évalué à 3.
Je voulais surtout dire que tu as un (plus) grand nombre de solution (encoding/transmission/...) et que donc tu as un plus grand choix ;)
As-tu une idée d'un ordre de grandeur de consommation de ressources de Theora comparé à MPEG* ?
La dernière fois que j'ai essayé (une des premières beta), cela demandait plus de puissance que du xvid(mpeg4).
Il est possible que ça ait changé depuis le temps aussi.
pour tes clients, à vue de nez ils supportent le xvid 720p sans problème, je serais moins catégorique pour du h.264 (mais ils supporte du h.264 480p sans problème).
Pour l'encodeur, ben tout dépend de la machine, en sachant qu'a moins d'avoir des betes de guerre, encoder en temps réel le h.264 est relativement dure à atteindre.
En ce qui concerne les pertes, si tu adopte une stratégie de streaming (ce qui semble être le cas vu que tu essaie de faire d'après ce que j'ai compris un "live feed", cad affiché en presque temps réel une vidéo qui est capturée en live), alors tu ne peux pas utiliser TCP, cela entraine trop de délai et trop de traffic réseau.
De plus le vpn ne _doit pas_ être en tcp (tcp sur tcp c'est mal) , donc en udp.
Si tu ne cherche pas à faire du "live feed" (stockage des vidéos et acessibilité après), alors le plus simple c'est de mettre en place un répertoire partagée (nfs par exemple) ou chaque client ira récupérer la vidéo. La effectivement il n'y aura pas de problème de perte, mais dans ce cas je comprend pas très bien la contrainte d'encodage temps réel.
Si tu souhaite utiliser un système de stockage, alors n'importe quel conteneur peut faire l'affaire (le surpoids de chacun n'est pas ce qu'il y'a de plus important dans une simple vidéo).
Tu as le choix principalement entre trois conteneur
- avi (l'historique, peu de possibilité, mais suffisant pour une simple vidéo. Ne supporte pas tous les codecs).
- mp4 (le conteneur "officiel" du h.264. Plus évolué , plus adapté à l'envoi sur le réseau, mais pas parfait.
- mkv : conteneur libre, qui est le plus "performant" à l'heure actuel (support de presques tous les codecs, des st, possibilité de chapitrage, etc...).
Je te conseillerais le mkv, mais je ne connais pas d'outils qui permettent de créer un mkv avec "un pipe".
en ce qui concerne le fait que le contenu soit statique : c'est tout benef pour toi : un système de compression video se base sur le fait que deux images qui se suivent sont semblables.
Donc je te conseillerais d'augmenter au maximum le temps entre deux frames I (cad une frame qui contient une image au grand complet).
Pour résumer :
Si tous les clients doivent afficher la même vidéo en même temps
-> streaming (multicast si possible)
Si les vidéos proviennent d'une source qui capture en même temps (live feed,...)
-> streaming (multicast ou unicast)+ codec permettant d'encoder à la volée sur la machine d'enco.
Si les vidéos sont "offline"
-> streaming si archi déjà en place, réseau "correct"
-> répertoire nfs, vidéo préencoder.
Ps : en ce qui concerne théora : la qualité des MPEG est quand même très bien. Un Xvid/ lavc-mpeg4 bien encodé a une très bonne qualité, même a des bitrates "faibles".
faut voir si MSU (http://compression.ru/video/codec_comparison/mpeg-4_avc_h264(...) ou doom9 (http://www.doom9.org/index.html?/codecs-quali-105-3.htm, http://forum.doom9.org/showthread.php?t=140336, ...) a des comparaisons des codecs. Ils ont une bien meilleur opinion que moi des codecs ;)
[^] # Re: Plus d'informations ?
Posté par santos . Évalué à 2.
Alors, pour préciser ce que je souhaite faire :
en amont, des utilisateurs planifient des contenus (par exemple, un powerpoint de 12h34 à 12h37, suivi d'un PDF pendant 10 secondes, suivi d'une vidéo flash de 30 secondes, etc...
La planification se fait suffisamment de temps avant l'instant de passage pour qu'il n'y ait pas de conflits, et qu'elle soit éditable.
Parallèlement, un script analyse en permanence le planning, et en fonction, ouvre et affiche sur l'écran du serveur de streaming le bon contenu dans le bon player. Pendant ce temps, FFMPEG capture tout ce qui passe à l'écran, sans interruption. C'est ce flux produit que je veux encoder et envoyer aux afficheurs.
Il peut y'avoir 10 secondes, 30 secondes, 1 minute de décalage, ce n'est pas gênant, mais il faut quand-même que le flux soit généré à la volée. Donc il s'agit bien de produire un *flux* vidéo, et non des fichiers.
Un peu comme la TV, en quelque sorte. Chez TF1, ils font passer successivement des émissions en direct, des films préparés à l'avance, etc... mais côté client, on reçoit un flux continu, en temps réel (moyennant quelques secondes ou minutes de décalage).
Est-ce que c'est plus clair comme ça ?
Mon client, à priori ça sera un lecteur type VLC en plein écran, qui lit un flux du genre http://monserveur.local:XX?afficheur=4 par exemple.
La question de la sécurité et de la fiabilité du flux, je dirais que pour le moment c'est secondaire.
Vu la puissance de mes machines clientes, et le fait que je veux faire de l'encodage en live, d'après ce que tu me dis le codec xVid semble le mieux adapté.
[^] # Re: Plus d'informations ?
Posté par briaeros007 . Évalué à 2.
ffmpeg a sa propre implémentation (que tu peux accéder avec mencoder en encodant -ovc lavc -lavcopts vcodec=mpeg4:...)
Sinon effectivement c'est plus clair ;)
Vlc peut essayer de faire de l'enco à la volée (mais moins performant que les routines optimisées de ffmpeg).
ffmpeg (ffserver) est censé pouvoir effectuer aussi ce streaming avec enco à la volée, mais la dernière fois que j'ai testé ffmpeg comme serveur de streaming , il aimait bien les segfault /o\
(un exemple de conf ffserver :
http://ffmpeg.mplayerhq.hu/sample.html ,dans notre cas ça sera "format avi", et si tu es sur de ne pas avoir de vidéo, alors active le VideoIntraOnly )
il y a aussi lscube (live.polito.it) qui semblait proposer ce genre de service (ils sont en dvp), mais leur site semble down /o\
[^] # Re: Plus d'informations ?
Posté par Nonor . Évalué à 4.
J'ai utilisé cette implémentation pendant un moment à l'époque, et ça marchait très très bien.
Grosso modo ça produit du standard mpeg4 similaire au divx / xvid, en qualité moins belle que le xvid mais pas énormément non plus, et avec un encodage _beaucoup_ plus rapide.
Je te conseille d'essayer ça personnellement. De toutes façons, FFmpeg, globalement, c'est du béton armé.
# l'architecture est elle bonne ?
Posté par Psychofox (Mastodon) . Évalué à 3.
J'ai l'impression que la solution "vidéo" n'est pas la meilleure et que tu devrais chercher plus tôt à diffuser le flux de ta présentation et que chaque client s'occupe lui même de l'affichage de celle-ci.
[^] # Re: l'architecture est elle bonne ?
Posté par briaeros007 . Évalué à 2.
La vidéo ne me semble pas si "im pertinente" que ça ;)
[^] # Re: l'architecture est elle bonne ?
Posté par Psychofox (Mastodon) . Évalué à 3.
[^] # Re: l'architecture est elle bonne ?
Posté par santos . Évalué à 2.
[^] # Re: l'architecture est elle bonne ?
Posté par santos . Évalué à 3.
[^] # Re: l'architecture est elle bonne ?
Posté par santos . Évalué à 2.
mon but est de développer une nouvelle solution, différente de la solution actuelle ;
la solution actuelle est basée sur des pages web, qui permettent de disposer les différents contenus sur l'écran, et sur chaque client il y a un navigateur en plein écran, bardé de plugins (vidéo, flash, pdf, office,...) pour interpréter les différents contenus.
Moi je veux précisément abandonner ce principe, en concentrant le travail de génération des vues sur un serveur d'affichage, plutôt que de le déléguer aux terminaux.
Cela en particulier dans le but de rentre les afficheurs indépendants de la nature des contenus qu'ils affichent. La solution de la capture vidéo est la seule qui me permet d'atteindre cet objectif.
Les conséquences de cette solution sont une réduction de la qualité d'affichage des contenus, et une grosse consommation de bande passante, mais pour moi tout cela est envisageable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.