Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 10 sur 12 PremièrePremière ... 23456789101112 DernièreDernière
Affichage des résultats 271 à 300 sur 331
  1. #271
    Citation Envoyé par shlagevuk Voir le message
    Je viens de découvrir une feature bien cool des conteneurs MKV, le file linking (segment linking) qui permet basiquement d'ajouter une intro/outro présente dans un fichier externe à la liste des chapitres d'un conteneur mkv. Ainsi pas besoin de répéter une intro dans les X fichier ou elle est présente.

    Sauf que personne ne supporte la feature (VLC ok, mais plex ko et handbrake ko....)
    Oui tient, je m'en étais rendu compte par l’expérience, quasiment aucun lecteur ne supporte cette feature, sans vraiment de raison derrière. Alors que la plupart des autres features sont parfaitement gérée. J'ai jamais compris
    Je ne sais pas si ça a évolué sur mpc-hc mais à l'époque ça ne marchait pas du tout.

    - - - Mise à jour - - -

    Citation Envoyé par Sunseille Voir le message
    L'upscaling par traitement neuronal ouais est vraiment très intéressant au niveau de la qualité, je suis assez bluffé de ce qui en sort. T'as l'impression que ca a été fait par un pro pour un cout réduis et puis tu peux le faire de chez toi avec la carte graphique qui va bien.Mais je risque de me repeter, mais je n'ai pas tester le filtre nnedi3 avec avisynth qui a ce qu'il parrait a des resultats très proche pour un meilleur rendement.
    Pour le moment je reste sur les animes avec des lignes très nettes, c'est plus facile pour moi pour voir la différence et je pense que c'est ce qui mérite le mieux ce genre de traitements (Nichijou ).
    Mais je pense que ca devrait marcher un peu partout.

    Le gain au niveau du supersampling serait sur la qualité de l'upscale qui est beaucoup plus propre que les filtres habituels (mais rapide) que nous avons.


    Ca reste un traitement de foie gras ou ta carte graphique tourne a 100% pendant plusieurs heures consécutive. A voir si un rack de carte graphique pour miner du bitcoin pourrait être utiliser pour ce genre de trucs, mais bon après la conso pour mater des dessins animées....


    note a part, le thread c'est toujours topic [HEVC] pourquoi pas le rendre plus général au traitement vidéo, surtout avec l'arrivée prochaine de AV1 qui m'a l'air bien interessant tout pleins.
    En même temps l'upscale par réseau de neurone c'est ce qui se fait de mieux maintenant, même si ça a des limites sérieuse due à la base d'apprentissage et à la puissance nécessaire pour faire tourner le bouzin (un réseau de neurones performant d'upsclale tourne rarement en temps réel, trop de neurone pour nos machines, au labo sur un PC de compétition pro je suis obligé de faire tourner mes réseau de neurone en temps réel en me limitant à du format PAL pour les robots : au delà c'est l'explosion). Un réseau de neurone qui aura appris sur un set d'image très divers sera assez "mauvais" alors que si tu le spécialise, disons, dans l'animation, il sera très performant sur les images issu des animés en se spécialisant pour faire des hypothèse au vue du style de dessin etc...

    Problème : faire cet apprentissage est long et chiant, même en laboratoire, je bosse en labo et je trouve ça relou alors bon

    Mais un jour faudra peut-être que je ponde un truc spécialisé animation. Pour le fun.

    - - - Mise à jour - - -

    Citation Envoyé par shlagevuk Voir le message
    Comme le dit Foudge, je pense que tes deux animés "source" ont des bitrate très élevé de base, ces bitrates doivent en plus être fixe. Tu auras forcément un gros gain en les encodant en qualité constante 22RF en x265 étant normalement un encodage "imperceptible". De plus la plus part des animés sont très facilement compressible, il y a peu de détails dans l'image comparativement à une représentation réelle. Donc un épisode de 25min d'animé qui pèse 200mo ne me choque pas particulièrement, ça dépend du contenu (beaucoup d'action/mouvement, décors riche etc...). Le mieux étant toujours de comparer le résultat à la source pour voir si la qualité te suffis.
    Nan mais moi aussi ça m'a choqué le gain avec H265. Je sais pas comment ils ont fait évolué leurs algo mais le gain en taille sur l'animation est juste spectaculaire, et j'ai moi même beaucoup de mal à me faire à des épisodes 1080p de 200/300 mo qui représente une excellente qualité. La norme, encore aujourd'hui, c'est que 200/300 mo ça représente un épisode de mauvaise qualité en basse définition, le 1080p de bonnes qualité tapant plutôt dans les 1Go.
    Faudra que je bosse le sujet du H265 pour piger, mais note : si un canard connais le sujet et veut bien faire un résumé je prends.

  2. #272
    Bonjour,

    Je me permets de déterrer ce topic pour trouver de l'aide.

    Je suis nouveau dans l'encodage vidéo. Je m'y intéresse car je voudrais ripper mes bluray et les convertir en x265 pour avoir vidéothèque de qualité et optimisée niveau poids.

    Après avoir trouvé pas mal d'infos, notamment sur ce topic, j'ai fait plusieurs test avec handbrake et je suis très satisfait du résultat. Mais je me pose une question dont je n'ai trouvé de réponse.

    Après chaque encodage, lorsque j'ouvre le mkv avec mkvtoolnix, en plus de la vidéo, des pistes sons et des sous titres, je vois plusieurs balises de type "globale", une pour chaque élément du mkv. Apparemment ce serait des infos telles que des statistiques ou autre...

    J'imagine que ces balises ont été ajouté par handbrake. Le problème c'est que je n'en veux pas et que je ne trouve pas d'option dans handbrake pour ne pas les ajouter. Je suis donc obligé d'éditer chaque mkv avec mkvtoolnix pour les supprimer, ce qui fait de nombreuses manipulations fastidieuses et inutiles. La suppression de ces balises n'a aucun impacte sur le visionnage du mkv.

    Je ne parviens pas à trouver plus d'informations la dessus.

    Quelqu'un aurait une manip à me conseiller pour empêcher l'ajout de ces balises ?

  3. #273
    Les balise correspondent au chapitrage?
    WoW Classic - Amnennar – JcJ – EU / Français - Alliance - Maraghor 60 - Pupuce 60 - Mimighor 60 - Balbuldir 60 - Auberdine - JCE - EU - Horde - Yaghor 60 - Maraghor 22 - Smileys CPC

  4. #274
    Bonjour,

    Non ce n'est pas le chapitrage mais bien des "balises"
    Je vous joint une capture d'écran d'un mkv fraîchement encodé avec handbrake et édité avec mkvtoolnix :


  5. #275
    Bonjour, je me lance dans l'encodage avec handbrake.
    J'aurais une petite question car j'ai lue tout et son contraire.
    sa peut vous paraître bête mais bon...

    j'ai un fichier assez volumineux et j'aimerai donc le passer en hevc x265.
    si ma source es en 8 bits, est-ce utile de l'encoder en 10 bits ?
    merci.

  6. #276
    Bonsoir Magnazul,

    Voici ce que j'ai pu constater lors de différents tests que j'ai effectué avant de me lancer dans l'aventure:

    - Avec certaines sources 8bits je n'ai vu aucune différence entre un encodage x265 8bits et x265 10bits.
    - Avec d'autres sources 8bits j'ai remarqué une amélioration de l'image en x265 10bits par rapport au x265 8bits. Sur la version 8bits il y avait une légère pixelisation (artefacts) alors que sur la 10bits ils n'apparaissaient pas, comme si on avait appliqué un filtre avec un effet fondu, ce qui rendait l'image plus propre.
    - x265 8bits ou x265 10bits, le poids du fichier final est le même.
    - Le temps d'encodage est un peu plus long en x265 10bits. Par exemple, un encodage x265 8bits prenant 1h30 me demande 1h40.

    Du coup, personnellement je ne me prends pas la tête, je fais du x265 10bits à chaque fois.

    Tu peux te faire une idée grâce à la fonction "Preview" de Handbrake qui te permet de faire un test d'encodage avec les paramètres que tu as configuré. Tu peux ainsi faire des previews de 30s/60s/90s... et faire des comparaisons pour définir ta config optimale.

  7. #277
    Bonsoir Bolthorn merci pour ton explication, c'est plus claire pour moi, je vais faire mes tests pour le coup.

  8. #278
    Citation Envoyé par Magnazul Voir le message
    Bonsoir Bolthorn merci pour ton explication, c'est plus claire pour moi, je vais faire mes tests pour le coup.
    Attention, le décodage 10 bits demande également plus de ressources. En fonction de ce qui va le lire, ça peut compter. A titre d'exemple, un vieux PC avec une GT 1030 (sous mint et lecteur kodi) n'a aucune difficulté à lire un ficher vidéo de 16 Go 1080p (50 fps) en HEVC 8bit. Par contre, en 10 bits, un 1080p 25 fps/s de quelques Mo peut avoir des ralentissements notables avec décalage de son

    Sinon sur la page précédente du topic, j'ai fais quelques tests concernant le vitesse d'encodage en fonction des qualités appliquées (voir courbes).

  9. #279
    Citation Envoyé par Bolthorn Voir le message
    Bonjour,

    Je me permets de déterrer ce topic pour trouver de l'aide.

    Je suis nouveau dans l'encodage vidéo. Je m'y intéresse car je voudrais ripper mes bluray et les convertir en x265 pour avoir vidéothèque de qualité et optimisée niveau poids.

    Après avoir trouvé pas mal d'infos, notamment sur ce topic, j'ai fait plusieurs test avec handbrake et je suis très satisfait du résultat. Mais je me pose une question dont je n'ai trouvé de réponse.

    Après chaque encodage, lorsque j'ouvre le mkv avec mkvtoolnix, en plus de la vidéo, des pistes sons et des sous titres, je vois plusieurs balises de type "globale", une pour chaque élément du mkv. Apparemment ce serait des infos telles que des statistiques ou autre...

    J'imagine que ces balises ont été ajouté par handbrake. Le problème c'est que je n'en veux pas et que je ne trouve pas d'option dans handbrake pour ne pas les ajouter. Je suis donc obligé d'éditer chaque mkv avec mkvtoolnix pour les supprimer, ce qui fait de nombreuses manipulations fastidieuses et inutiles. La suppression de ces balises n'a aucun impacte sur le visionnage du mkv.

    Je ne parviens pas à trouver plus d'informations la dessus.

    Quelqu'un aurait une manip à me conseiller pour empêcher l'ajout de ces balises ?
    Citation Envoyé par Bolthorn Voir le message
    Bonjour,

    Non ce n'est pas le chapitrage mais bien des "balises"
    Je vous joint une capture d'écran d'un mkv fraîchement encodé avec handbrake et édité avec mkvtoolnix :

    https://i.ibb.co/F0fkh00/screenshot-mkvtoolnix.png

    Pas d'idées pour mon petit problème ?

  10. #280
    Ben la question, histoire de comprendre et pouvoir t'aider, c'est en quoi les balises sont un problème ? Tu as un souci lors de la lecture avec les balises?

  11. #281
    A vrai dire elles ne sont pas vraiment un souci mais ça m'intrigue.
    Comment sont elles créées, comment paramétrer ceci et que contiennent-elles exactement ? De plus ça prend un peu de place quand même, pas grand chose, mais sur des dizaines de fichiers (le cas pour une série par exemple) ça peut faire beaucoup à la fin. Un fichier d'1.50go passe à 1.47go sans ces balises

  12. #282
    Citation Envoyé par Nilsou Voir le message
    Faudra que je bosse le sujet du H265 pour piger, mais note : si un canard connais le sujet et veut bien faire un résumé je prends.
    Coucou Nilsou

    Il me semble que ze grande différence entre le H264 et le HEVC, niveau compression vidéo, est que ce dernier peut gérer des macroblocs à taille variable.
    En gros, là où le H264 est limité à une grille fixe pour déterminer quels zones ont changé d'une image sur l'autre, le HEVC est capable de définir des zones de tailles différentes.

    Comme une image vaut mieux que mille mots :


  13. #283
    Citation Envoyé par taronyu26 Voir le message
    Coucou Nilsou

    Il me semble que ze grande différence entre le H264 et le HEVC, niveau compression vidéo, est que ce dernier peut gérer des macroblocs à taille variable.
    En gros, là où le H264 est limité à une grille fixe pour déterminer quels zones ont changé d'une image sur l'autre, le HEVC est capable de définir des zones de tailles différentes.

    Comme une image vaut mieux que mille mots :

    https://tof.cx/images/2019/12/16/c76...0ef4979999.png

    Vous pourrez trouver un complément d'informations ici : https://createinmotion.fr/wiki-h265-...ment-du-futur/

  14. #284
    Ceux qui trainent sur ce topic devrait pouvoir aider sur ce problème

    J'imagine que la difficulté est d'encoder un flux en temps réel, mais on en parle là bas
    Grand maître du lien affilié

  15. #285
    Bonsoir, j'aurai besoin d'aide pour de la compréhension d'option dans handbrake, quelqu'un peut t'il m'aider ?
    j'ai encoder en x265 10bits pas mal de vidéo et je m'interroge maintenant si, la qualiter ne pourrais pas être mieux avec ceux la.

    j'aimerai savoir a quoi serve les option du bas dans "video"

    encoder tune : none
    encoder profile : auto
    encoder level : auto

    ils sont par défaut chez moi comme écrit ci dessus
    je ré encode principalement des vidéo d'animation 2d et je viens de m'apercevoir qu'il y a dans encoder tune "animation"
    mais ne sachant pas a quoi cela peut servir...

    merci.

  16. #286
    Citation Envoyé par Magnazul Voir le message
    Bonsoir, j'aurai besoin d'aide pour de la compréhension d'option dans handbrake, quelqu'un peut t'il m'aider ?
    j'ai encoder en x265 10bits pas mal de vidéo et je m'interroge maintenant si, la qualiter ne pourrais pas être mieux avec ceux la.

    j'aimerai savoir a quoi serve les option du bas dans "video"

    encoder tune : none
    encoder profile : auto
    encoder level : auto

    ils sont par défaut chez moi comme écrit ci dessus
    je ré encode principalement des vidéo d'animation 2d et je viens de m'apercevoir qu'il y a dans encoder tune "animation"
    mais ne sachant pas a quoi cela peut servir...

    merci.
    Remonte à la page 8 est tu auras les réglages de Megabilou pour ses dessins animés.

  17. #287
    Si j'ai bien compris, plus que de savoir quels réglages on utilise et/ou recommande, c'était de savoir en quoi consiste concrètement chaque option, bref, ce qu'il y a "sous le capot".
    Après j'ai peut-être juste déformé ma compréhension, car ça m'intéresserait (aussi) de savoir en quoi le comportement de l'encodeur est modifié.

    Je ne connais pas assez handbrake pour y répondre par moi-même

  18. #288
    Bonjour
    Quelqu'un aurait il un profil X265 avec des bons presets pour xmedia Recode?
    C'est pour réencoder quelques bluray en version plus light?

    Merci!
    Ingame: RiX

  19. #289
    Voilà le H266

    Quelqu'un saurait dire comment ça marche techniquement ?

    Accessoirement je cherchais un soft qui puisse encoder en masse des fichiers mp4 en M3U8 (je pense que handbrake + plug in ça marche mais y'a p'tet mieux)
    Grand maître du lien affilié

  20. #290
    30 à 50% de mieux que l'H265, c'est fort !

    Tu veux générer un fichier M3U8 à partir d'une liste (dossier ?) de fichiers MP4 ?

  21. #291
    non je veux générer le même nombre de fichiers (convertir chaque vidéo en une nouvelle vidéo)
    Grand maître du lien affilié

  22. #292
    Doit y avoir confusion : de ce que j’en sais le m3u8 est un format de playlist, pas un conteneur multimédia comme le mp4.

  23. #293
    Non en fait c'est lié au HLS, et ça permet de limiter les capacités d'une personne a télécharger une vidéo que tu lui laisse streamer.
    Grand maître du lien affilié

  24. #294
    Hello, Y aurait quoi comme logiciel pour faire de l'upscale via réseau neuronale et qui soit user friendly ? (payant, gratuit)
    J'ai trouvé Video Enhance AI de Topaz Labs. Je teste la version trial de 30 j. La version payante est assez cher mais peu valoir le coup, si on l'utilise souvent.
    Par contre, l'éditeur a changé leur politique sur les mise à jour, qui deviennent eux payant.

    C'est très user friendly, mais je trouve qu'il manque des options. Et les 4 presets d'IA ne sont pas forcément claire car le résultat n'est pas vraiment là et dépend de la source.
    Par contre, faut au moins un GPU nVidia de type GTX 1060 et ultérieur. Il y a bien une accélération CPU mais les perfs ne sont pas top.

    D'ailleurs, côté Upscale, le temps est affreusement long sur une vidéo avec une résolution supérieur à 500 pixel de haut/bas. En fait, plus la source est en haute résolution, plus ça prendra du temps et le résultat ne sera pas spécialement meilleurs.
    Par contre, si downsize la vidéo source par 2 et que je l'upscale, la durée de traitement est carrément divisé par 5/10 pour un résultat plutôt convaincant.

  25. #295
    Je peux pas t'éclairer sur les logiciels (je code mes propres algos quand j'en ai besoin). Mais pour avoir fait une thèse en IA, je peut éclaircir certains de ces points je pense :
    Citation Envoyé par MetalDestroyer
    - « les 4 presets d'IA ne sont pas forcément claire car le résultat n'est pas vraiment là et dépend de la source. » :
    Ça, ce sera toujours le cas. Par définition de l'apprentissage en IA, ça varie beaucoup en fonction de ce qui a été appris. Donc les résultats changeront énormément en fonction de la source. Peut-être que je peut t'éclairer sur les options si tu copie-colle leur nom ici.

    Citation Envoyé par MetalDestroyer
    Par contre, faut au moins un GPU nVidia de type GTX 1060 et ultérieur. Il y a bien une accélération CPU mais les perfs ne sont pas top.
    Normal ça, il faut des GPU dont certaines partie soient programmable aisément pour accélérer les multiplication matricielles utilisée en IA.

    Citation Envoyé par MetalDestroyer
    D'ailleurs, côté Upscale, le temps est affreusement long sur une vidéo avec une résolution supérieur à 500 pixel de haut/bas. En fait, plus la source est en haute résolution, plus ça prendra du temps et le résultat ne sera pas spécialement meilleurs.
    Ça c'est aussi parfaitement normal. Et quelque soit le logiciel, il n'y a pas grand chose à faire, le fonctionnement des réseaux de neurones implique des temps de traitement très long sur les upscale. Plus l'upscale sera de qualité (prenant en compte des apprentissages larges ou sur des séries temporelles etc.) Plus le calcul sera très long.

    Citation Envoyé par MetalDestroyer
    Par contre, si downsize la vidéo source par 2 et que je l'upscale, la durée de traitement est carrément divisé par 5/10 pour un résultat plutôt convaincant.
    Ça, a mon avis, c'est une très mauvaise idée
    Je te conseillerais plutôt d'avoir un bon GPU, de lancer le taf sur un supercalculateur si tu a des contacts dans le monde scientifiques ou autre ou encore de prendre ton mal en patience. Mais c'est vraiment une mauvaise idée de faire ça


    Tout ceci me fait penser que je voulais écrire un logiciel gratuit d'upscale pour les animés avec mes algos Ça me motive un peu à le faire si ça parait si utile.

  26. #296
    Citation Envoyé par Nilsou Voir le message
    Je peux pas t'éclairer sur les logiciels (je code mes propres algos quand j'en ai besoin). Mais pour avoir fait une thèse en IA, je peut éclaircir certains de ces points je pense :

    Ça, ce sera toujours le cas. Par définition de l'apprentissage en IA, ça varie beaucoup en fonction de ce qui a été appris. Donc les résultats changeront énormément en fonction de la source. Peut-être que je peut t'éclairer sur les options si tu copie-colle leur nom ici.
    Il y a bien une description qui est claire, mais qui ne correspond pas au rendu réel.
    Voilà les noms des différents modèles d'IA et leur description:
    * Gaia-HQ: P, HQ - Uscaling video
    * Gaia-CG: P,CG,HQ - Uscaling for computer-generated content
    * Artemis-HQ: P,HQ,MC - Enhance and upscale video
    * Artemis-LQ: P,LQ,MC - Enhance and upscale video

    Légendes des accronymes:
    P: for progressive video only
    CG: computer generated content
    HQ: for high-quality video
    MC: keep motion consistancy (less flickery)
    LQ: for low-quality video with strong noise/blockiness

    Sur la plupart des vidéos que j'ai testé, c'est le premier modèle Gaia-HQ qui marche le mieux.
    Le 4e modèle n'améliore pas le rendu sur les vidéos LQ.

    Citation Envoyé par Nilsou Voir le message
    Normal ça, il faut des GPU dont certaines partie soient programmable aisément pour accélérer les multiplication matricielles utilisée en IA.
    Ca ne me dérange pas. En faite, c'est juste une remarque pour ceux qui n'ont pas de GPU nVidia. J'ai une GTX 1080.

    Citation Envoyé par Nilsou Voir le message
    Ça c'est aussi parfaitement normal. Et quelque soit le logiciel, il n'y a pas grand chose à faire, le fonctionnement des réseaux de neurones implique des temps de traitement très long sur les upscale. Plus l'upscale sera de qualité (prenant en compte des apprentissages larges ou sur des séries temporelles etc.) Plus le calcul sera très long.


    Ça, a mon avis, c'est une très mauvaise idée
    Je te conseillerais plutôt d'avoir un bon GPU, de lancer le taf sur un supercalculateur si tu a des contacts dans le monde scientifiques ou autre ou encore de prendre ton mal en patience. Mais c'est vraiment une mauvaise idée de faire ça


    Tout ceci me fait penser que je voulais écrire un logiciel gratuit d'upscale pour les animés avec mes algos Ça me motive un peu à le faire si ça parait si utile.
    Bah, sur les nombreux tests, le fait de faire de l'upscale sur une vidéo en grosse résolution ne donne pas un résultat satisfaisant voir quasi-inexistant (surtout sur un anime, j'ai fait sur une seule vidéo, je ferai plusieurs tests).
    Alors que si je réduis la résolution d'origine par 2 et que j'upscale, le gain en upscale est là mais en contre partie, j'ai perdu pas mal d'info et du coup l'IA me génère des artefacts.

  27. #297
    Citation Envoyé par Nilsou Voir le message
    Normal ça, il faut des GPU dont certaines partie soient programmable aisément pour accélérer les multiplication matricielles utilisée en IA.
    Des GPUs programmables, on sait faire ça depuis très, très longtemps. Depuis qu'on fait du shader en fait, autant dire ça fait un bail.
    S'il y a une restriction sur la gamme de GPUs à utiliser, c'est certainement pour des raisons d'architecture, puisqu'il est plus facile d'optimiser ton code GPU quand tu te limites aux séries récentes. Tu compiles à destination de moins de GPUs, et tu peux bénéficer des améliorations du compilo et du runtime.

    De nombreux GPUs sortis avant les GTX 1060 sont plus performants en GPGPU, même s'ils sont antérieurs. C'est pas aussi simple que ça en a l'air.

    Vu qu'il s'agit d'IA les développeurs ont dû faire le choix d'utiliser les améliorations apportées par Nvidia en ce sens, que ce soit au niveau des GPUs et de la techno CUDA, et ça se comprend.
    Mais en soi on n'a pas attendu les GTX 10xx pour faire du GPGPU, IA comprise.

    Citation Envoyé par MetalDestroyer Voir le message
    Ca ne me dérange pas. En faite, c'est juste une remarque pour ceux qui n'ont pas de GPU nVidia. J'ai une GTX 1080.
    Pour le coup, si seule l'accélération CUDA est disponible, en effet, pour ceux qui n'ont pas de GPU Nvidia, c'est niet.
    S'il y a une accélération OpenCL de dispo, là par contre, c'est dispo pour tout le monde (les cartes Nvidia, les cartes AMD, mais aussi l'IGP si applicable, rigolez pas ça peut avoir ses avantages aussi).

  28. #298
    Citation Envoyé par MetalDestroyer Voir le message
    Il y a bien une description qui est claire, mais qui ne correspond pas au rendu réel.
    Voilà les noms des différents modèles d'IA et leur description:
    * Gaia-HQ: P, HQ - Uscaling video
    * Gaia-CG: P,CG,HQ - Uscaling for computer-generated content
    * Artemis-HQ: P,HQ,MC - Enhance and upscale video
    * Artemis-LQ: P,LQ,MC - Enhance and upscale video

    Légendes des accronymes:
    P: for progressive video only
    CG: computer generated content
    HQ: for high-quality video
    MC: keep motion consistancy (less flickery)
    LQ: for low-quality video with strong noise/blockiness
    Bah les deux premiers c'est parlant. Le premier c'est un upscaling généraliste, il a surement été appris sur une base de vidéo/image très générale allant des dessins animés au documentaire. Il donnera des résultats corrects mais ce sera toujours moins bon qu'un upscaling appris spécifiquement pour le type de vidéo que tu traite.

    Le second ça semble être pour de la 3D, du jeux-vidéo, des images rendu via des logiciels comme blender et autre, surement de l'animation aussi. Ça a du être appris sur une base d'image issue de moteur 3D divers. Du coups ça donnera un meilleur résultat, sur le papier, que le généraliste, mais uniquement si tu l'utilise sur une image de ce type.

    Les deux suivants ça semble être une combinaison d'algo. Il y a probablement l'upscaling des deux premiers, mais il semble aussi y avoir une réduction de bruit appliqué qui vient réduire le scintillement (flickering) ou le bruit sur les vidéos de basse qualité (pour le quatrième).
    Faut toujours être prudent avec les tambouilles d'algorithme amha.

    Sinon ils semblent également avoir intégré dans les deux derniers un apprentissage de logique de mouvement. Amha ils ont du faire un apprentissage sur des vidéos de très bonne qualité en fonction des images précédentes, du coups l'algo a en quelque sorte appris un modèle de prédiction du mouvement. Quand tu l'applique il vient donc corriger ton image en fonction de cette prédiction et forcement ça vient virer pas mal de soucis : scintillement, bruit etc...
    Amha c'est ça qui tourne en fond.

    Le défaut : ça ne marchera pas bien sur des vidéos aux mouvements incohérents (animés dessinés à la main par exemple) et ça apportera peu de choses sur des vidéo déjà irréprochables pour un cout calculatoire normalement plus important. Donc à fuir pour l'animation. Et à utiliser pour des films si la puissance de calcul le permet.


    Citation Envoyé par MetalDestroyer Voir le message
    Bah, sur les nombreux tests, le fait de faire de l'upscale sur une vidéo en grosse résolution ne donne pas un résultat satisfaisant voir quasi-inexistant (surtout sur un anime, j'ai fait sur une seule vidéo, je ferai plusieurs tests).
    Alors que si je réduis la résolution d'origine par 2 et que j'upscale, le gain en upscale est là mais en contre partie, j'ai perdu pas mal d'info et du coup l'IA me génère des artefacts.
    Que veut tu dire par « ne te donne pas un résultat satisfaisant ? » . Il est absolument impossible que ces algo appliquée à une opération d'upscale X*X -> Y*Y te donne un meilleur résultat sur une opération X/2*X/2->Y*Y. C'est impossible.

    - - - Mise à jour - - -

    Citation Envoyé par Taro Voir le message
    Des GPUs programmables, on sait faire ça depuis très, très longtemps. Depuis qu'on fait du shader en fait, autant dire ça fait un bail.
    S'il y a une restriction sur la gamme de GPUs à utiliser, c'est certainement pour des raisons d'architecture, puisqu'il est plus facile d'optimiser ton code GPU quand tu te limites aux séries récentes. Tu compiles à destination de moins de GPUs, et tu peux bénéficer des améliorations du compilo et du runtime.

    De nombreux GPUs sortis avant les GTX 1060 sont plus performants en GPGPU, même s'ils sont antérieurs. C'est pas aussi simple que ça en a l'air.

    Vu qu'il s'agit d'IA les développeurs ont dû faire le choix d'utiliser les améliorations apportées par Nvidia en ce sens, que ce soit au niveau des GPUs et de la techno CUDA, et ça se comprend.
    Mais en soi on n'a pas attendu les GTX 10xx pour faire du GPGPU, IA comprise.
    Il y a quand même pas mal de limite sur les opérations possibles dans le GPGPU sur les GPU anciens.
    Bon en vrai GTX 1060 c'est vrai que c'est un peu arbitraire. Depuis Fermi on a accès à pleins de chose facilement.


    Pour le coup, si seule l'accélération CUDA est disponible, en effet, pour ceux qui n'ont pas de GPU Nvidia, c'est niet.
    S'il y a une accélération OpenCL de dispo, là par contre, c'est dispo pour tout le monde (les cartes Nvidia, les cartes AMD, mais aussi l'IGP si applicable, rigolez pas ça peut avoir ses avantages aussi).[/QUOTE]

  29. #299
    Citation Envoyé par Nilsou Voir le message
    Il y a quand même pas mal de limite sur les opérations possibles dans le GPGPU sur les GPU anciens.
    Bon en vrai GTX 1060 c'est vrai que c'est un peu arbitraire. Depuis Fermi on a accès à pleins de chose facilement.
    Mouais. J'ai écrit une bonne quantité de code à destination de GPUs antérieurs aux GP10x, notamment du GM200 et du GM200-400, et je pouvais faire tourner à peu près n'importe quel calcul mathématique dessus, tant que ça peut s'écrire en C. J'ai dû mal à voir où se situe la limite en fait, la seule limite c'est celle des performances attendues que tu t'impose.

    C'est vrai que le choix "GTX 1060 et ultérieur" ça peut paraître arbitraire, mais il fallait bien trancher quelque part, et il me semble que les améliorations liées à l'IA ont commencé à se faire pour cette série.
    J'en suis pas certain, j'ai plus trop l'historique du toolkit en tête...

  30. #300
    Alors de mémoire, je suis pas expert en implémentation d'IA sur GPU parce que j'ai la flemme quand j'ai des super-calculateur avec moi et que de toute façon je bosse spécifiquement sur des IA pas cher calculatoirement. Mais en gros il y a des tonnes de recherches sur le sujet parce que, justement, c'est relou à implémenter sur du GPGPU standard. Notamment au niveau de l'apprentissage qui demande de faire des trucs qui sont relativement chiant sur le modèle standard du pipeline GPU, notamment des transferts constants entre CPU et GPU sur de grosses quantités de données et, surtout, le point le plus chiant de mémoire, des nœud d'étranglement. C'est à dire de très nombreux endroit ou tu es obligé d'attendre que toutes les unités aient finit de calculer pour mixer leur résultats (simple additions). Ce dernier point posait de gros problème sur les GPU standards, et continue d'ailleurs d'en poser d'après ce que j'en sais. Le modèle de calcul du GPU est basé sur une hyper-parralélisation : les shaders n'ont accès de façon performante qu'à un nombre d'entrée antérieur restreintes, mais pas à la totalité de chaque étape (c’est ce qui permet de calculer de nombreuses chaines parallèles).

    En gros : il va être ultra performant d'écrire un filtre local en GPGPU. Mais bien plus chiant d'écrire un simple algorithme qui fait la somme du résultat de tout les pixels au milieu du calcul des shaders, et cela, de façon performante. Hors, c'est pile cela que l'on désire en IA : que chaque étape d'après fasse la somme des étapes précédentes quand celles-ci sont toutes terminées... (ce qui est plutôt le taf d'un CPU en général)

    C'est la raison pour laquelle la parralélisation en IA est devenu un enjeux majeur de la recherche, sinon on se ferait pas chier . Google a bossé sur sa solution par exemple, en intégrant pleins de tricks, et c'est devenu certaines des bibliothèques les plus connu d'IA, mais c'est pas encore opti. Nvidia a quasiment modifié le matériel pour ça en intégrant ses fameux tensors core, et ils sont la conditions sinequanone pour que ses algos d'IA qui font tourner le raytracing soient fonctionnels à des performances acceptable. D'autres chercheurs pensent que les CG ne sont tout simplement pas adaptées et changent carrément le matos, de gros effort sont mis sur les FPGA et sur la recherche d'un composant capable de retranscrire les « poids modifiables » des réseaux de neurones (on cherche en gros un genre de mémoire résistive mais pas cher, et dont la valeur peut changer rapidement).

    Donc a priori, ce n'est pas si simple

    Et donc de mémoire toujours, Nvidia, avant de pondre les tensors cores, avaient débloqué pas mal de truc au fur et à mesure des versions pour qu'on puisse coder de façon efficace en minimisant les goulets d'étranglement (sans que ce soit ouf non plus). (certaines de ces fonctionnalités sont aussi nécessaire au support de Vulkan)

    De fait, peut-être que certaines de ces fonctionnalités sont utilisées par cet algos d'IA, d’où la limite arbitraire.

    En tout cas je vois ça comme ça. Et ça me parait pas déconnant au vu de cet historique.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •