[HFR] Focus : Encodage H.264 : Retour sur NVENC et QuickSync

Focus : Encodage H.264 : Retour sur NVENC et QuickSync [HFR] - HFR - Hardware

Marsh Posté le 25-05-2012 à 21:50:01   0  

Dans notre test de la GeForce GTX 680 de Nvidia, nous avions mentionné l'arrivée d'une nouvelle fonctionnalité baptisée NVENC, un encodeur H.264 placé dans une unité fixe.
Lire la suite ...

Reply

Marsh Posté le 25-05-2012 à 21:50:01   

Reply

Marsh Posté le 25-05-2012 à 22:27:16   0  

Moi ce qui m'intéresserait comme article c'est un état des lieux sur le montage vidéo à partir de diverses sources genre reflex ou autres device 1080p en H264 MainConcept
 
Parce que le X264... à part copier des films, est-ce qu'il y a un grand intérêt ?
 
Travaillant sous adobe première, et ayant deux sources 1080p h264, je n'ai pas trouvé de format d'export en x264 sous première...

Reply

Marsh Posté le 25-05-2012 à 22:43:02   0  

Arf déçu par la qualité, pourtant ce genre d'unité hardware c'est vraiment le top :/.
Mais une question, ce problème de qualité (dans le cas d'Intel), c'est un problème matériel, ou est-ce purement logiciel (l'SDK donc)?
 
En d'autre terme peut-on espérer dans le future des soft d'encodage utiliser une version du SDK mise à jour et proposant une meilleure qualité, le tout étant toujours compatible avec l'unité hardware des cpu existants?


Message édité par le 26-05-2012 à 12:03:09
Reply

Marsh Posté le 25-05-2012 à 23:22:02   0  

Merlin_L_Enchanteur a écrit :

Travaillant sous adobe première, et ayant deux sources 1080p h264, je n'ai pas trouvé de format d'export en x264 sous première...


Si je ne m'abuse x264 produit des fichiers au format h.264... C'est juste que adobe doivent utiliser des algorithmes à eux plutôt que d'utiliser x264 non ? Sinon au besoin tu dois pouvoir exporter en trames non compressées et compresser ensuite avec x264.

Message cité 1 fois
Message édité par BlueScreenJunky le 25-05-2012 à 23:22:26
Reply

Marsh Posté le 25-05-2012 à 23:28:54   0  

merci pour l'article  :jap:


Message édité par Marc le 25-05-2012 à 23:35:34

---------------
Mon Feedback  --  Topic achats / Ventes
Reply

Marsh Posté le 25-05-2012 à 23:37:32   0  

BlueScreenJunky a écrit :


Si je ne m'abuse x264 produit des fichiers au format h.264... C'est juste que adobe doivent utiliser des algorithmes à eux plutôt que d'utiliser x264 non ? Sinon au besoin tu dois pouvoir exporter en trames non compressées et compresser ensuite avec x264.


Ils utilisent MainConcept H264 en version CPU, dommage il y a une version CUDA pour NV et OpenCL pour AMD mais pas intégrée (elles doivent couter bonbon).

 

x264 n'est pas utilisable directement dans première et c'est dommage car il est supérieur. Il faut passer par un format intermédiaire oui.

 

On peut par contre utiliser QuickSync dans Première pour le H.264 avec un plug-in permettant d'utiliser le MediaSDK Intel

Message cité 1 fois
Message édité par Marc le 25-05-2012 à 23:42:19
Reply

Marsh Posté le 25-05-2012 à 23:54:37   0  

Bon il y a une phrase de l'article qui ne passe pas, dsl :)
 
Si on veut de la qualité, NON ON NE FAIT EN 2 PASSES.
 
On encode en mode CRF (donc par définition 1 passe).
 
Ca a en plus l'avantage d'être plus rapide (puisqu'une seule passe). Par contre, effectivement, la taille exacte finale n'est pas prévisible, contrairement au mode rate control.
 
Cela étant dit, je me doute bien que si vous voulez comparer les qualités, il vous faut bien passer les mêmes réglages / restrictions à tous les compétiteurs, d'où l'utilisation d'un mode rate control.
 
Mais en général (et sauf cas particulier où il y a une taille particulière et bien précise à fixer), le mode RC n'est pas approprié au regard du CRF (qui plus est plus rapide).

Reply

Marsh Posté le 26-05-2012 à 00:04:03   0  

ParkerLewis a écrit :

Cela étant dit, je me doute bien que si vous voulez comparer les qualités, il vous faut bien passer les mêmes réglages / restrictions à tous les compétiteurs, d'où l'utilisation d'un mode rate control.


 
Tout à fait.
 
http://forum.hardware.fr/hfr/Hardw [...] m#t8028910

Reply

Marsh Posté le 26-05-2012 à 00:20:11   0  

Marc a écrit :


Ils utilisent MainConcept H264 en version CPU, dommage il y a une version CUDA pour NV et OpenCL pour AMD mais pas intégrée (elles doivent couter bonbon).
 
x264 n'est pas utilisable directement dans première et c'est dommage car il est supérieur. Il faut passer par un format intermédiaire oui.
 
On peut par contre utiliser QuickSync dans Première pour le H.264 avec un plug-in permettant d'utiliser le MediaSDK Intel


 
Ah voila... ils ne sont pas clairs sur leur site :( chez Adobe ! Ils parlent de versions Cuda et Opencl de leur premiere, mais pas d'infos sur comment l'activer... D'où ma tentative de sujet sur OPENCL justement, parce que l'opencl marche chez moi, mais impossible de l'activer sous premier elements 10
 
sinon, deux solutions, soit passer par un format intermédiaire, soit utiliser un frame server genre Debugmode  
 
Et sinon, d'où mon sujet aussi pour m'aider à choisir un PC pour du montage sous première... à moins de revendre première et de passer sur un soft plus adapté au montage x264 en 1080p 4.2

Reply

Marsh Posté le 26-05-2012 à 00:29:08   0  

C'est le moteur de rendu de Premiere qui est accéléré CUDA pour les NVIDIA (pour appliquer les effets) et OpenCL pour les Radeon (uniquement sur Mac pour OpenCL). Pas l'encodage en lui-même. Après MainConcept reste un bon encodeur même si x264 est un peu supérieur ;)

Message cité 1 fois
Message édité par Marc le 26-05-2012 à 00:30:43
Reply

Marsh Posté le 26-05-2012 à 00:29:08   

Reply

Marsh Posté le 26-05-2012 à 00:35:58   0  

Marc a écrit :

C'est le moteur de rendu de Premiere qui est accéléré CUDA pour les NVIDIA (pour appliquer les effets) et OpenCL pour les Radeon (uniquement sur Mac pour OpenCL). Pas l'encodage en lui-même. Après MainConcept reste un bon encodeur même si x264 est un peu supérieur ;)

 


tout à fait :)

 

opencl uniquement sur mac aussi :)

 

mais en fouillant un peu plus j'ai vu que certains filtres d'export utilisaient cuda ou étaient sensé le faire et les prévisions pour opencl

 

de toutes les façons, sous première, même en faisant la phase de rendu avant l'export, j'ai pas vu d'accélération :( (je ne parle pas de gpu)

 

je veux juste de la rapidité :cry: parce que traiter à 1/2 fps, c'est pas possible :cry:

 

;)


Message édité par Marc le 26-05-2012 à 00:39:56
Reply

Marsh Posté le 26-05-2012 à 00:51:14   0  

immonde la qualité et surtout avec l'encodage NVIDIA, on ne distingue même pas les personnes sur le screen !

Reply

Marsh Posté le 26-05-2012 à 05:44:19   0  

Ce serais possible avec votre config (l'i5 ivy bridge) de faire un encodage de votre scene de test en mode CRF sur handbrake si vous avez le temps ?
Je serais curieux de comparer le temps d'encodage et la qualité finale, pour voir les solution hardware par rapport à la grosse qualité qu'est capable de fournir le x264, et qui est utilisé quotidiennement par toute les team de rip.
Juste histoire de voir le retard qu'on intel, amd et nvidia ^^
 
(enfin c'est si vraiment vous vous ennuyez dans les jour à venir, je suppose que vous n'avez pas que ça à faire ^^)

Reply

Marsh Posté le 26-05-2012 à 09:30:27   0  

En même temps si on veux vraiment de la qualité il faut utiliser le 10-bit dont les avantages sur l'efficacité sur l'encodage ne sont plus à démontrer. Une réduction de la taille de fichier jusqu'à 20% avec une qualité équivalente voire supérieure (surtout sur le dégradés dans les films d'animation).
Le problème étant que seul x264 propose l'encodage en 10-bit et niveau decodeur aucun constructeur de carte vidéo a trouvé bon de développer l'accélération matérielle pour ce format (tout comme d'ailleurs aussi le h264 classique avec plus de 10 reframes) et il y a juste quelques logiciels qui le décodent.

Reply

Marsh Posté le 26-05-2012 à 10:57:43   0  

ParkerLewis a écrit :

On encode en mode CRF (donc par définition 1 passe).
 
Ca a en plus l'avantage d'être plus rapide (puisqu'une seule passe). Par contre, effectivement, la taille exacte finale n'est pas prévisible, contrairement au mode rate control.

Tous les encodeurs ne supportent pas CRF ce qui nous limite. Il me semble délicat de mettre face à face des encodages CRF face à des encodages RC 1 passe. Sur quel critère peut on choisir un CRF, en essayant de s'aligner sur le temps ? sur la qualité ? sur le bitrate ? Très difficile a comparer proprement avec des encodages RC qui sont les seuls supportés par le hardware.

Reply

Marsh Posté le 26-05-2012 à 12:05:10   0  

Reply

Marsh Posté le 26-05-2012 à 15:46:41   0  


http://www.anandtech.com/show/5835 [...] rinity-apu[/quotemsg]Uniquement au niveau des filtres de resize en fait pour handbrake.
 
Le déCodage DXVA c'est au cas par cas, sur beaucoup de cartes les blocs ne sont pas optimisés pour aller très vite, un filtre CPU multithreadé fait souvent largement mieux cf notre test précédent.
 
Le plus intéressant n'est pas lié a handbrake, c'est x264 openCL, mais apparemment ça n'est pas encore prêt, cf le dev ici : http://forum.doom9.org/showthread. [...] ost1574692
 
C'est a suivre de prêt parce que c'est ambitieux, mais encore trop tôt pour qu'on puisse mesurer quelque chose.


Message édité par C_Wiz le 27-05-2012 à 00:06:05
Reply

Marsh Posté le 26-05-2012 à 17:28:05   0  

"dédodage" ?
 
Au fur et à mesure, de plus en plus de 'fonctions' c'est à dire des bouts de programme vont prendre en charge certaines parties des cartes graphiques, je pense qu'à moyen terme on verra même apparaitre des cartes à base de DSP dédiés et reprenant les parties utiles du gpu computing (un peu comme les cartes TESLA/FERMI dépourvues de sortie graphique).
 
Perso, ça fait des années que je demande à DXO de mettre en place ce type de cartes, parce qu'il n'y a pas de raison que dans le monde de la photo, un reflex comme le 7d par exemple, soit capable de derawtiser et d'appliquer quelques filtres sur 8 images par secondes avec simplement deux digic4, alors que nos pc surpuissant mettent 20 secondes par image... Il y a quelque chose d'incohérent.
 
Et c'est pareil pour la vidéo. Là je suis en train d'exporter un film de 1H25 en 1080p et j'en ai pour 3h30 après avoir effectué le rendu sous première... j'ai pourtant un X6 @ 4Ghz...
 
Pour l'instant la seule compression vidéo supportée par le GPU... c'est l'utilisation de la partie HD de la carte :heink: C'est pas du tout ce qu'on attend ! Le décodage HD, indépendant de sa qualité pas forcément tip-top ne représente que 4/7 % de l'utilisation du GPU... C'est un peu n'importe quoi.
 
Mais c'est l'informatique qui a évolué comme ça : logiciels tout pourris, monstrueux et lourds exploitant toujours moins bien le matériel qui lui ne cesse d'évoluer de manière incohérente.
 
Etant un informaticien de la première heure, je me souviens que sur Amiga (dont l'OS avec celui de NEXT reste pour moi une référence absolue) on utilisait déjà des puces dédiés à chaque usage. Le PC ne sait toujours pas faire certaines choses qui étaient courantes sur Amiga en 1992.... Avec des processeur à 50 MHz...
 
PS : C'est moi ou le lien vers la news ne marche pas ?

Reply

Marsh Posté le 26-05-2012 à 20:19:01   0  

On transcode, cf ici :http://www.hardware.fr/articles/828-2/conteneur-codec-transcodage.html
 
 

Merlin_L_Enchanteur a écrit :

PS : C'est moi ou le lien vers la news ne marche pas ?

C'est d'avoir cité Amiga, Atari vaincra.
 
(ou alors un petit souci technique corrigé depuis, désolé ;))

Reply

Marsh Posté le 26-05-2012 à 21:04:10   0  

:lol: ;) ps dédodage, je vois toujours pas :o

Reply

Marsh Posté le 27-05-2012 à 00:06:27   0  

Merlin_L_Enchanteur a écrit :

:lol: ;) ps dédodage, je vois toujours pas :o

Moi non plus ;)

Reply

Marsh Posté le 27-05-2012 à 15:16:46   0  

excellent tests!
idéalement, j'aimerais y voir figurer une carte SPURSENGINE (avec Adobe Premiere) et le tandem SPURSENGINE + CUDA avec la dernière mouture de TMPENC (où cuda sert aux filtres & effets)
ce serait le top !!
et peut être de quoi voir un beau -et utile- bras de fer contre x264 (que j'aime beaucoup)

Reply

Marsh Posté le 27-05-2012 à 15:30:52   0  

:) bien bien bien :) Marc... S'il te plait :love:

Reply

Marsh Posté le 30-05-2012 à 23:06:18   0  

L'article a été mis à jour avec les chiffres corrects pour NVENC.

Reply

Marsh Posté le 31-05-2012 à 06:40:45   0  

Bravo pour la réactivité!!!

Reply

Marsh Posté le 17-08-2012 à 14:47:27   0  

Bon je viens de lire ce très intéressant test sur le fond et excellent sur la forme aussi (votre comparatif screenshoot est impeccable et implacable aussi).
 
Il se trouve que je connais très bien l'encodage video pour avoir fait des encodages BluRay commerciaux dans une autre vie (compressionist inside). Voici donc quelques remarques utiles j'espère.
 
Je me m'y connais pas beaucoup en encodage hardware (compressionist inside) mais il me semble que le mode 1 passe à bitrate constant (CBR) ne doit être utilisé que pour du contenu en streaming (par définition sans possibilité d'évaluation de la complexité du contenu).
 
Le mode constante qualité en 1 passe (CRF mode pour x264) donnera de bien meilleurs résultats avec une prédictibilité sur la qualité finale. Le mode 2 passes ne donnera pas une qualité finale plus grande mais donnera une prédictibilité sur la taille du fichier final. C'est le seul avantage du mode 2 passes. L'utilisation du mode 2 passes était absolument nécessaire lorsqu'il fallait tenir son encodage sur un volume déterminé (700 Mo soit 1CD pour les divx par exemple) mais ce n'est plus trop le cas aujourd'hui avec l'explosion de la BP de l'ADSL (oui je sais le piratage c'est mal). Aujourd'hui le mode le plus populaire pour l'encodage c'est le mode crf du x264.
 
Enfin bref faire de l'encodage CBR 1 passe avec des encodeurs hardwares est une bien mauvaise idée car la qualité finales sera très inconstante (avec les encodeurs softwares aussi en passant). Je ne sais pas si c'est possible avec mediaespresso mais l'encodage à qualité constante doit être privilégié (mode à quantizer fixé pour les I,P et BFrame). Si ce n'est pas possible avec mediaespresso je sais que Mainconcept Reference (excellent encodeur MPEG2, VC1 et H264) permet de faire de l'encodage CUDA H264 avec quantizer constant. A mon avis la qualité sera tout autre et cela permettra de comparer avec un autre encodeur CUDA (H264 High Profil me semble-t-il).


Message édité par sagittaire le 17-08-2012 à 14:52:28
Reply

Marsh Posté le 29-08-2012 à 12:12:28   0  

sagittaire a écrit :

Enfin bref faire de l'encodage CBR 1 passe avec des encodeurs hardwares est une bien mauvaise idée

Oui là dessus on est parfaitement d'accord, le problème est que l'on a pas le choix, les API fournies par les constructeurs ne permettent que cela !
 
Cf notre article plus long ici : http://www.hardware.fr/articles/82 [...] mique.html

Reply

Marsh Posté le 29-08-2012 à 12:20:16   0  


Dommage, toujours rien du coté des GPU AMD.


---------------
> Mon FEEDBACK <
Reply

Marsh Posté le 05-02-2013 à 22:35:00   0  

Désolé pour le up du topic mais j ai une question le project shield de NVIDIA se servira de la technologie nvenc et je voulais savoir si la 670 gainward (référence) était compatible avec cette technologie :)


Message édité par Nico55 le 05-02-2013 à 22:35:27
Reply

Marsh Posté le 08-10-2014 à 14:51:23   0  

Hello
oui, je déterre le sujet !!
je viens de me rendre compte que le nouveau (juillet 2014) SDK de Nvidia inclut maintenant la gestion double passe et le GOP ajustable.
issue de leur doc:
 
Pass Rate Control
For better quality, it is recommended to use
two-pass rate control (e.g. NV_ENC_PARAMS_RC_TWOPASS_CBR)
,
which allows better quality encoding compared to
single pass rate control (e.g.NV_ENC_PARAMS_RC_CBR)
with a drop in performance.
If client sets NV_ENC_PARAMS_RC_2_PASS_QUALITY, encoder might violate the VBV settings to improve the quality of I frames.
Applications using strict single frame VBV and single pass rate control will result in poor quality scene cuts and lower quality for frames with high complexity. Using two pass rate control helps to mitigate these issues.
It should be set as follows:
NV_ENC_RC_PARAMS
::
rateControlMode
=
NV_ENC_RC_2_PASS_FRAMESIZE_CAP
;  

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed