Connexion
Abonnez-vous

OBS Studio 28.0 : codages HDR et 10 bits, support d’Apple Silicon

OBS Studio 28.0 : codages HDR et 10 bits, support d’Apple Silicon

Le 06 septembre 2022 à 05h01

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.

Le 06 septembre 2022 à 05h01

Commentaires (30)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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

votre avatar

(reply:2091479:vivienfr) Le problème de l’AV1, c’est qu’il restera cantonné à une niche tant qu’il sera uniquement compatible à partir des RTX 3000 / RX 6000.


votre avatar

vivienfr a dit:


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).


:cap:



(pour mémoire, codec = codeur/décodeur ou coder/decoder in English)

votre avatar

QTrEIX a dit:


tant qu’il sera uniquement compatible à partir des RTX 3000 / RX 6000


Comment ça, compatible ?
On peut faire du AV1 sans carte graphique.

votre avatar

(reply:2091511:OlivierJ) Donc tu passes par le CPU ? J’avais lu qu’il fallait une RTX 3000 ou un RX 6000 pour encoder, j’ai un R7 3700X + RX 5700, durant l’encodage en AV1 via SVT-AV1, j’ai un message d’erreur qui m’indique que l’encodeur met trop de temps à encoder, selon un topic du forum de OBS sur le même sujet, cela vient d’un problème de performance, donc ma config ne serait pas assez puissante.


votre avatar

QTrEIX a dit:


Donc tu passes par le CPU ?


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).




J’avais lu qu’il fallait une RTX 3000 ou un RX 6000 pour encoder coder (ou plutôt compresser ou convertir, pliiiiz), j’ai un R7 3700X + RX 5700, durant l’encodage la conversion en AV1 via SVT-AV1,


:pleure: Mes yeux… Anglicisme overload… (en bon français on parle de codage, pas “encodage”, c’est un matheux qui parle, et un geek aussi)
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.




j’ai un message d’erreur qui m’indique que l’encodeur le codeur met trop de temps


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.




selon un topic du forum de OBS sur le même sujet, cela vient d’un problème de performance, donc ma config ne serait pas assez puissante.


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.

votre avatar

OlivierJ a dit:


pliiiiz
Anglicisme overload


:brice:

votre avatar

OlivierJ a dit:


:pleure: Mes yeux… Anglicisme overload… (en bon français on parle de codage, pas “encodage”, c’est un matheux qui parle, et un geek aussi)


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…




On dit qu’on convertit ou qu’on sauve


Là si on reste au 19è siècle, ça prend une tournure coloniale assez inquiétante :)

votre avatar

deux nouveaux trucs qui vont simplifier la vie:




  1. CTRL+Z pour annuler une opération !! Bordel… on est en 2022 !!

  2. une source sonore distincte pour chaque application capturée (fini Voicemeeter Banana)



\o/

votre avatar

vivienfr a dit:


Je suis étonné que OBS ait fait l’impasse sur VP9.


Peut-être un problème de propriété ?

votre avatar

Non : VP9 est un codec vidéo ouvert et sans redevance développé par Google.

votre avatar

ragoutoutou a dit:


Le mot est utilisé en langue française depuis les années 60 et figure dans les dictionnaires. Il y a prescription.


Ç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)




Berbe a dit:


Peut-être un problème de propriété ?


Ç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)

votre avatar

OlivierJ a dit:


une compression avec perte n’est pas un codage, puisqu’on ne retrouve pas l’original)


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.

votre avatar

(quote:2091675:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Dans ce cas, rien en informatique n’est un codage de l’original.


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.




Toute transcription analogique vers numérique implique un certain degré de quantification, qui occasionne une perte.


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).




FLAC par exemple est régulièrement appelé un codage sans perte mais c’est techniquement faux


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.

votre avatar

(reply:2091685:Zone démilitarisée)


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.

votre avatar

(quote:2091675:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
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.


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.

votre avatar

(quote:2091779:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Ce que je veux dire c’est que la chose importante est la qualité de la restitution.


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.




des données qui ne sont elles-mêmes que des approximations de la réalité.


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).




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…


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).




Cette définition informelle ne fait pas mention de la qualité de restitution.


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.




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…


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.




Bref “codage” est polysémique et aucune des deux définitions ne convient à ce qu’on tente d’exprimer ici.


??
Reviens sur terre :-) .

votre avatar

OlivierJ a dit:


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.


Merci de m’expliquer l’informatique, ça me manquait…




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.


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.

votre avatar

(quote:2092176:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
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.


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).

votre avatar

OlivierJ a dit:


Tes phrases ne veulent rien dire.


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…

votre avatar

(quote:2092284:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
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.


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.




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.


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 : fr.wikipedia.org Wikipedia.
À 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.

votre avatar

OlivierJ a dit:


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.


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, très astucieux, il n’y a pas de transmission de table explicitement.


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é.




PS : gzip utilise une combinaison des algorithmes LZ77 et Huffman.


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.

votre avatar

(quote:2092432:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
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.


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.




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 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 pas un codage… Et merci de confirmer ce que je dis : huffmann n’est qu’un élément de l’algorithme global de compression.


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.

votre avatar

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.

votre avatar

(reply:2092477:33A20158-2813-4F0D-9D4A-FD05E2C42E48)


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 :chant:

votre avatar

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 : en.wikipedia.org Wikipedia



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.

votre avatar

(reply:2092523:33A20158-2813-4F0D-9D4A-FD05E2C42E48)


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).

votre avatar

OlivierJ a dit:


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).


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.

votre avatar

(quote:2092707:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
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.


N’importe quoi. Un algorithme qui ne voit pas les données qu’il traite, et qui ne génère rien. :reflechis:
Fin de la discussion pour moi.

votre avatar

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.

OBS Studio 28.0 : codages HDR et 10 bits, support d’Apple Silicon

Fermer