Nouvelle version majeure pour cette solution open source de diffusion vidéo, avec à son bord d’importantes améliorations, dont les principales sont les codages 10 bits et HDR pour augmenter la qualité du rendu des couleurs.
https://github.com/obsproject/obs-studio/releases/tag/28.0.1, ce support permet la prise en charge d’équipements tels que les EVGA XR1 Pro, Elgato 4K60 Pro Mk.2, et AverMedia Live Gamer 4K, et d’en diffuser directement l’image sur le service HLS de YouTube. Elle a d’ailleurs publié une liste des matériels supportés.
L’autre gros apport, c’est la disponibilité d’une version pour Apple Silicon. Non seulement les performances générales sont à la hausse, mais la version Mac supporte en plus ScreenCaptureKit d’Apple, une API introduite dans Monterey. Ce changement permet lui aussi d’accélérer, et dans de vastes proportions cette fois, comme MacG s’en faisait l’écho déjà il y a quelques mois.
Malheureusement, de nombreux plugins ne sont pas compatibles avec cette version. OBS Project avertit clairement de ce point dans son annonce.
D’autres changements sont présents, comme un passage à Qt6 et une modernisation de l’interface, via notamment un nouveau thème Yari. On trouve également un nouveau codeur AMD, la possibilité d’une capture audio spécifique à une application sous Windows, le support du Background Removal de NVIDIA sous Windows, ou encore le support des messages directs vers YouTube depuis OBS.
Commentaires (30)
#1
L’autre grande nouveauté d’OBS 28, c’est le support de l’enregistrement directement en AV1.
OBS version 28 et propose, dans l’onglet avancé, un enregistrement AV1 via SVT-AV1 (encodeur performant crée par Intel et Netflix) et AOM AV1 (encodeur de référence, qui demande beaucoup de CPU).
Je suis étonné que OBS ait fait l’impasse sur VP9.
=> https://lafibre.info/tv-numerique-hd-3d/av1-ou-hevc/msg970767/#msg970767
#2
#3
(pour mémoire, codec = codeur/décodeur ou coder/decoder in English)
#4
Comment ça, compatible ?
On peut faire du AV1 sans carte graphique.
#5
#6
On peut toujours utiliser un CPU (surtout qu’au départ quand on crée un codec il n’y a pas de version matérielle), c’est ce dont a parlé vivienfr dans son commentaire, et on a des dépêches régulièrement sur la progression des codecs AV1 (et autres VP9).
On dit qu’on convertit ou qu’on sauve en JPG, on ne code pas en JPG, je ne comprendrai jamais pourquoi on parle de codage (c’est pas un codage au sens strict vu qu’il y a perte), même si on parle de codec un peu abusivement aussi pour la même raison.
Drôle d’erreur à vrai dire, jamais vu ça avec un codec. Et jusqu’à présent, la plupart des codecs qui sortent ne compressent pas en temps réel.
Bizarre, on peut convertir en n’importe quel format même avec un Raspberry, c’est juste une question de temps. Quand j’ai commencé la conversion en H264 c’était quelques images par seconde sur mon ordi de l’époque.
#7
#8
Le mot est utilisé en langue française depuis les années 60 et figure dans les dictionnaires. Il y a prescription.
Il était inconnu par exemple au 19è siècle, mais ça pose la question: à quelle date le “bon Français” est-il mort…
Là si on reste au 19è siècle, ça prend une tournure coloniale assez inquiétante :)
#9
deux nouveaux trucs qui vont simplifier la vie:
\o/
#10
Peut-être un problème de propriété ?
#10.1
Non : VP9 est un codec vidéo ouvert et sans redevance développé par Google.
#11
Ça reste très moche.
Et en plus c’est plus rapide d’éviter le “en”, qui est inutile.
(sans parler du fond qui est qu’une compression avec perte n’est pas un codage, puisqu’on ne retrouve pas l’original)
Ça m’étonnerait : « VP9 est un codec vidéo ouvert et sans redevance développé par Google ».
(PS : arf Fred42 m’a précédé de peu)
#12
Dans ce cas, rien en informatique n’est un codage de l’original. Toute transcription analogique vers numérique implique un certain degré de quantification, qui occasionne une perte. FLAC par exemple est régulièrement appelé un codage sans perte mais c’est techniquement faux, puisqu’il s’appuie sur le format CD qui a déjà perdu une partie du signal.
Il faut juste ensuite définir le niveau acceptable de perte.
#13
Ben si. On dispose de données en entrée et en sortie d’un codec/algo. C’est facile de voir s’il y a des pertes ou pas, c’est bien pour ça qu’on parle de compression sans perte ou avec pertes.
La quantification est indépendante du codage, c’est une autre question. Et en effet, la quantification introduit une forme de bruit, qu’on sait assez bien rendre très faible (en particulier en ajoutant un très faible bruit de type triangulaire).
Le FLAC est un codage sans perte, contrairement au MP3, AAC, Ogg et compagnie. De même que les compressions Zip, Gzip, LZMA, Zstd, LZ4, etc qui sont sans perte, on retrouve exactement les données d’avant la compression.
#13.1
Je me suis manifestement, et comme à mon habitude, exprimé trop succinctement…
Ce que je veux dire c’est que la chose importante est la qualité de la restitution. Qu’une compression soit avec ou sans perte n’est pas un gage de qualité de restitution dès l’ors qu’elle est appliquée sur des données qui ne sont elles-mêmes que des approximations de la réalité.
Mon exemple FLAC est que malgré qu’il soit désigné comme “sans perte”, rien ne prouve qu’il donne un meilleur rendu qu’une compression d’un signal 192K/24 bits compressé avec perte pour atteindre le même bitrate…
Or donc, mon Petit Larousse Grand Format (sic) 2005 - 100e édition définit le codage comme l’action d’appliquer un code pour transformer un message ou des donnée cen vue de leur transmission ou de leur traitement. Synonyme: encodage. Cette définition informelle ne fait pas mention de la qualité de restitution.
SI par contre on utilise la définition de codage telle que retenue par la théorie de l’information, bien GZIP n’est pas un codage non plus…
Bref “codage” est polysémique et aucune des deux définitions ne convient à ce qu’on tente d’exprimer ici.
#14
Je pense qu’il est appelé comme ça parce qu’il n’y a pas de perte par rapport au CD, pas par rapport au signal dont est issu le CD.
#15
Mais ça n’a rien à voir avec la compression. La compression sans perte restitue les données à l’identique. La production du son ensuite c’est une autre histoire, la compression ça ne concerne pas que des données audio.
Dans le cas du CD, l’approximation est indistinguable du signal d’origine (au dB près si pas moins côté électronique, et pour l’oreille humaine avec une bonne électronique).
Heu, si.
En plus du fait que dépasser le 44 KHz / 16 bits ne sert absolument à rien pour la reproduction (c’est répété et réexpliqué à chaque nouvelle sur le sujet).
Informelle ?
C’est la définition du codage.
Et en effet quel rapport avec la restitution ? La notion de codage ne concerne pas que des échantillons sonores.
Heu, hein ??
(tu racontes des bêtises)
Ça me fait penser qu’une des premières techniques de compression de données s’appelle le codage de Huffman.
??
Reviens sur terre :-) .
#16
Merci de m’expliquer l’informatique, ça me manquait…
Le codage de Huffman est un codage au sens strict tant qu’il n’est pas adaptatif… Il n’est donc qu’une partie du processus de compression. Mais bon, on va dire que c’est moi qui n’ai pas compris ce que tu entends par codage.
#17
Tes phrases ne veulent rien dire.
Le codage de Huffman est un algorithme réversible (ou bijectif si on est matheux), et c’est un codage au sens mathématique. Il se trouve que ce codage permet également de compresser les données, selon leur entropie (les lettres les plus fréquentes sont codées sur moins de bits, et il s’agit d’un codage préfixe - je parle de lettres mais ça vaut pour n’importe quel type de données non aléatoires).
#18
Non, c’est toi qui as décidé que j’étais un imbécile qui ne sait pas de quoi il parle. Le codage de Huffman, comme tu le dis si bien, ne peut servir à compresser des données que si les données en entrée suivent raisonnablement une répartition donnée. Un codage de Huffmann qui compresse le français ne compressera pas le russe. Le codage de Huffmann à lui seul n’est donc PAS un algorithme de compression.
Donc, par conséquent, pour réaliser un logiciel de compression digne de ce nom, il faut préalablement déterminer la répartition des symboles et en déduire le codage optimal, puis le transmettre au destinataire comme table annexe. Si la résultante du codage proprement dit est bien un code préfixe, il n’en est pas du tout de même pour la table de fréquences (qui rend le codage adaptatif). Cette résultante n’est pas un codage de Huffmann…
#19
Manifestement tu ne connais pas le codage de Huffman ni comment on s’en sert. Il a été inventé spécifiquement pour de la compression de données. Et comme tout algorithme de compression, il ne peut pas tout compresser bien évidemment. Quoiqu’il en soit, il compresse aussi bien du russe que du français.
Pas forcément, cf l’algorithme LZW, très astucieux, il n’y a pas de transmission de table explicitement.
Concernant la mise en oeuvre du codage de Huffman (on parle également d’un codage entropique), il y a plusieurs façons, tout est expliqué ici : https://fr.wikipedia.org/wiki/Codage_de_Huffman .
À noter que Huffman est utilisé dans la compression JPEG, à un des stades de l’algorithme.
PS : gzip utilise une combinaison des algorithmes LZ77 et Huffman.
#20
Ben, non, puisque la répartition des lettres du russe est totalement différente de celle du français. Il existe UN codage de Huffmann qui compresse bien le français et UN AUTRE codage de Huffmann qui compresse bien le russe, mais ce sont deux codages différents. Le codage du français qu, par exemple ne prendrait que 3 bits pour E n’a absolument aucun intérêt pour compresser du russe qui n’a pas cette lettre…
LZW n’est pas un codage au sens de la théorie de l’information puisqu’il dépend de l’historique des symboles précédents et devient de ce fait non concaténable. C’est une compression, mais pas un codage. Un simple Huffmann peut aussi se passer de table explicite, en recalculant les distributions tous les X symboles. Mais ce faisant, encore une fois, il cesse d’être un codage puisqu’il dépend du passé.
Toujours pas un codage… Et merci de confirmer ce que je dis : huffmann n’est qu’un élément de l’algorithme global de compression.
#21
Ben évidemment, vu comment fonctionne le codage de Huffman…
Les arbres binaires ne sont pas les mêmes en fonction des données, mais c’est la base de l’algorithme.
C’est un codage du message entier et même du message partiel, puisque si on dispose des données depuis le début du fichier, on peut décoder ce qu’on a reçu.
Toujours un codage (on parle de Huffman). Et le codage de Huffman est un des algorithmes utilisés dans des algorithmes plus complexes, comme gzip et JPEG.
Je ne vois pas où va cette discussion.
#21.1
Non, ce ne sont pas des codages. Puisque tu aimes Wikipedia :
Codage
Soit L et M deux langages.
Un codage c de L dans M est un morphisme (pour l’opération { . ) injectif. En d’autres termes, c’est une correspondance entre les mots de L et ceux de M, où à tout mot de L est associé un unique mot de M et tel que le codage de la concaténée soit égale à la concaténée des codages.
Cette propriété n’est pas vraie pour LZW. Elle est vraie pour huffmann, MFM, NRZI et consorts, mais pas pour zip ou png ou FLAC.
Pour dire simple, si je compresse ABCD, la résultante n’est pas AB compressé suivi de CD compressé.
Bref, non, toutes ces méthodes de compression sans perte sont bel et bien des applications bijectives, mais pas des codages.
#22
En fin de compte vu ce que tu as écrit, on est en accord sur un point, le fait que l’algorithme de Huffman est un codage.
Champagne c’est la fête
#22.1
Héééé non, non, toujours pas. L’algorithme de Huffmann n’est pas un codage. C’est, comme tu le dis si bien un algorithme, qui à partir d’une distribution de fréquences d’une source (vue comme une variable aléatoire discrète) construit un codage entropique optimal pour cette source.
Wikipedia : https://en.wikipedia.org/wiki/Huffman_coding
The output from Huffman’s algorithm can be viewed as a variable-length code table for encoding a source symbol (such as a character in a file).
Tu te vantes de vouloir utiliser les définitions précises des choses, mais finalement tu te contentes d’approximations.
Allez, je t’offre le Champomy pour la peine.
#23
Eh si c’est un codage, même dans le sens où tu le restreins.
Tu l’as même écrit précédemment : « Elle est vraie pour huffmann, MFM, NRZI et consorts ». Chaque lettre ou symbole est toujours codé pareil (ce qui n’est pas le cas pour LZW effectivement).
#24
Est-ce que tu peux au moins essayer de lire ce que j’écris ? L’algorithme de Huffmann prend en entrée une (estimation de) probabilité de chaque symbole et contruit un codage optimal pour cette répartition. Évidemment que le résultat de l’algorithme est un codage ! Mais l’algorithme lui-même n’est pas un codage.
Une fois que l’algorithme a pondu le codage, ce codage peut être appliqué à une ou plusieurs sources (y compris à des sources qui ne suivent pas la répartition - auquel cas l’application du codage ne donnera pas un résultat optimal). Mais l’algorithme lui-même ne voit jamais la suite de symboles à coder, pas plus qu’il ne génère une suite de symboles codés.
#25
N’importe quoi. Un algorithme qui ne voit pas les données qu’il traite, et qui ne génère rien.
Fin de la discussion pour moi.
#25.1
Je confirme que tu es incapable de comprendre une phrase simple :
J’écris : L’algorithme prend en input la répartition et donne en output un codage.
OlivierJ comprend : *Un algorithme qui ne voit pas les données qu’il traite et ne génère rien.
*
Oui, de fait, il ne sert à rien de discuter avec toi. Tu es convaincu d’avoir raison quitte à déformer tout ce que je dis.