Encore une question : Pensez-vous qu'il faille rajouter une section prévention, du genre pour évitez les desynchronisations et autre ?
Ca pourrait être sympa, un titre/une idée du genre "prenez soin de votre TAS, évitez de perdre des heures de boulot".
Dedans on pourrait trouver en vrac:
-les désynchro, et les moyens de les éviter s'il y en a des évidents, ou alors au moins penser à vérifier souvent
-backup des fichiers movie, automatique et manuel
-bien gérer ses savestates pour ne pas faire une erreur et effacer un bout de TAS d'une simple pression de touche. Là on peut causer du bulletproof rerecording par exemple, une fonction géniale quand l'émulateur l'a. Aussi bien savoir gérer les modes read only et read + write par exemple.
-en résumé, être bien organisé c'est plus sûr, quoi
N'ayant jamais vraiment TASé que sur un émulateur, je vois vraiment pas ce qu'est la fonction bulletproof, les fonctions backup automatique et autre x) Va falloir de l'aide :p
coconou wrote:
C'est vrai, tout d'abord comme le dis coconou, merci pour ce suberbe tutoriel que je parcoure à chaque mise à jour. Suite à ta vidéo, je me permets de poster ceci sur la règle des 21 frames que tu dis ne pas comprendre.
Dans SMB1 et SMB2 (version jap bien entendu), chaque fois qu'il y a l'écran noir pour un début ou une fin de niveau, les retards de jeu pour une quantité variable de temps sont compensés (par manque de mémoire de la console il me semble, ou du moins pour alléger lesdits calculs).
Le retard est en fait calculé de sorte que les progrès en cours de lecture seront arrondis aux 21 frames suivantes.
A titre d'exemple, ça veux dire que si tu termines un niveau avec un compteur d'
1 frames, la longueur du niveau sera N+21 frames
15 frames, la longueur du niveau sera N+21 frames
20 frames, la longueur du niveau sera N+21 frames
21 frames, la longueur du niveau sera N+21 frames
22 frames, la longueur du niveau sera N+42 frames
30 frames, la longueur du niveau sera N+42 frames
42 frames, la longueur du niveau sera N+42 frames
43 frames, la longueur du niveau sera N+63 frames
Et ainsi de suite, où N est une longueur minimale constante de l'écran noir.
Par conséquent, la seule partie du jeu qui peut être améliorée en dehors de ce temps de moins de 21 frames est le niveau en lui-même dans sa qualité optimale d'optimisation.
En fait c'est assez proche des subpixels pour le temps si on veux, la différence ici est que ceux-ci sont arrondis au début et en fin de niveau...
J'espère avoir pu t'aider et être assez clair pour que tu puisse un peu mieux comprendre le principe.
Merci encore pour le temps passé sur ce tuto et pour tes vidéos de grande qualité et très instructives!
PS: si t'as besoin d'un tuto pour un encodage simple et en HD 720 ou 1080 à partir d'un rendu "simple" depuis un émulateur sans Lua je peux t'aider.
En plus j'aurai plus de temps depuis la semaine prochaine, j'aurai plus mes 6h de déplacements par jour mais plus qu'une heure ^^
En fait c'est assez proche des subpixels pour le temps si on veux, la différence ici est que ceux-ci sont arrondis au début et en fin de niveau...
Ah la j'ai compris ! :D Non sans rire c'est assez claire ton explication, donc en gros pour améliorer un niveau faudra l'amélioré de 21 frames... Ce qui explique pourquoi j'ai lu recemment que HappyLee avait amelioré le 1-1 et qui lui manqué qu'une seule frame pour battre son TAS... et que ca l'énervé :o
Sinon, toute aide est bienvenu :)
N'ayant jamais vraiment TASé que sur un émulateur, je vois vraiment pas ce qu'est la fonction bulletproof, les fonctions backup automatique et autre x) Va falloir de l'aide :p
Alors, les backup c'est tout simple. Y'a des émulateurs qui proposent de faire des sauvegardes de secours des fichiers movie, automatiquement. Des backup, quoi ^^.
D'un autre côté, qu'on ait activé ça sur l'émulateur ou pas n'interdit pas de le faire manuellement: on peut simplement copier le fichier movie de notre TAS de temps en temps.
Le bulletproof rerecording c'est un truc qui facilite vraiment la vie, j'ai jamais TASé sans (FCEUX et BizHawk l'ont). Je copie l'explication de l'aide sur FCEUX directement:
All savestates made during movie recording contain the movie information up to the frame of the savestate. When a savestate is loaded, the movie file in the savestate is also loaded. This is referred to as "Bullet Proof Rerecording" because it prevents possible desyncs and lost data from improper/out of order savestate loading.
Exemple: tu fais une save 1 dans SMB un peu avant d'entrer dans la tuyau du stage 1-1. Ensuite tu passes un moment à essayer d'optimiser les mouvements dans la zone bonus à l'aide d'autres saves (2, 3, 4, 5, 6, 7, 8), puis arrivé au tuyau de sortie et satisfait, tu fais une save 9.
Là t'as un doute et tu te demandes si t'as pas moyen d'entrer dans le premier tuyau plus vite, tu peux recharger la save 1 et faire des tests en utilisant les saves 2, 3, 4, etc... (sauf 9). Finalement ça va, le premier essai était optimisé à fond, pas besoin de le changer, tu peux recharger la save 9 qui est à la fin de la zone souterraine bonus et continuer sans souci.
Ca peut servir aussi à tester plusieurs façons de passer un endroit sans avoir à terminer par la meilleure, si tu vois ce que je veux dire.
Exemple2: là je passe en haut ou en bas? Hop, on tente en bas d'abord. Tu te sers de plusieurs saves pour arriver où tu veux en passant par en bas, puis tu sauvegardes sur le slot 4 pour garder cet itinéraire en mémoire. Après tu recharges une save d'avant le choix haut/bas, puis tu passes par en haut. Là tu te sers des mêmes slots de sauvegarde "temporaires" qu'à l'essai par le bas (sauf donc le 4) jusqu'à arriver au même point mais en passant par en haut. Tu vois que par le bas c'était plus rapide, donc tu peux directement recharger ta save 4 pour continuer, sans avoir à refaire cette version plus rapide par le bas.
Oh ! Je vois ! Dolphin a le backup auto depuis les r'ecentes versions, et il avait le bulletproof rerecording... Mais ca bouffait beaucoup trop de ram, ils l'ont enleve recemment aussi :p
Mais ca me dit quelque chose tout ca ok merci :)
J’ai ajouté du texte à la fin de I-C/ afin de parler vite fait des objectifs arbitraires et des runs de jeu moyennement TASable sur youtube... J'sais pas si c'est nécessaire ou bien placé par contre :p
Je plancherai sur les mesures contre le desynch ce week-end, ce serait cool si quelqu'un qui s'y connait pouvait faire le truc sur l'encodage, et j'aimerai egalement des conseils sur la partie submission :
1- est-elle necessaire ?
2- que y dire ?
Je pensais a rappelé de faire un effort, les submissions jolies et bien explique attire toujours plus le regards qu'une submission vierge (comme les.... non rien), et que les gens ont plus de facilité a comprendre la run quoi... :/ :p
merci, ça aidera ceux qui comme moi préparent un TAS et souhaitent le soumettre proprement pour que ce soit agréable :)
"Si le mal existe en ce monde, il se cache dans le cœur des hommes."
"If there is evil in this world, it lurks in the hearts of man."
Edward D. Morrison - Tales of Phantasia
J’ai ajouté du texte à la fin de I-C/ afin de parler vite fait des objectifs arbitraires et des runs de jeu moyennement TASable sur youtube... J'sais pas si c'est nécessaire ou bien placé par contre :p
Je plancherai sur les mesures contre le desynch ce week-end, ce serait cool si quelqu'un qui s'y connait pouvait faire le truc sur l'encodage, et j'aimerai egalement des conseils sur la partie submission :
1- est-elle necessaire ?
2- que y dire ?
Je pensais a rappelé de faire un effort, les submissions jolies et bien explique attire toujours plus le regards qu'une submission vierge (comme les.... non rien), et que les gens ont plus de facilité a comprendre la run quoi... :/ :p
La partie sur les objectifs me semble bien. Et je pense pas que ça pose de problème de dire par exemple qu'on peut toujours faire un TAS même s'il n'est pas publiable ici; après tout c'est un guide sur les TAS en général, pas uniquement sur TASvideos.
D'ailleurs j'ai la flemme de tout relire pour confirmer, mais je sais plus si t'as précisé que c'était préférable de montrer un peu ses WIP sur le forum avant de soumettre une run direct sans aucun feedback (en gros ne pas spammer le workbench avec des trucs qui seront rejetés très vite, s'assurer d'avoir bien fait le boulot et de savoir ce que les gens attendent au minimum d'une run présentée "officiellement").
Si tu fais une partie "submission", y'a sûrement plusieurs trucs à dire.
Déjà la partie "technique" si on veut entrer dans le détail et tout bien expliquer. Ce passage expliquerait simplement comment remplir la "fiche", ce qu'on doit mettre dans chaque case avec des explications et des conseils, par exemple...
Puis y'aurait des conseils plus généraux, un peu comme dit plus haut. Du genre qu'il ne faut pas soumettre n'importe quoi (gros résumé).
Je pense que c'est bien de causer surtout du texte de description de la run.
Déjà qu'il faut quand même prendre le temps de le soigner, malgré le fait qu'on puisse être pressé de montrer notre super TAS qui a demandé beaucoup de temps. J'avais un peu fait cette erreur pour ma première publication, le texte était assez court; enfin c'était un jeu très connu (Castlevania) et qui avait été bien retourné dans tous les sens par des précédents TAS... Mais il y a toujours des gens qui ne connaissent pas les astuces, même bien connues, utilisées dans les runs de jeux populaires.
Donc bref, le but c'est de bien savoir expliquer ce qu'il se passe dans le TAS, d'expliquer les petites astuces, les bugs utilisés, et d'expliquer ce qui a demandé du travail ou de la réflexion (car souvent ce sont des petits détails qui sont les plus compliqués ^^).
Pour le reste... Commencer par une description du jeu/de la run, noter les buts visés, l'émulateur utilisé, ajouter une partie pour remercier des gens si on est redevable à quelqu'un, etc...
En fait ça devrait être facilement explicable en montrant des exemples.
La partie sur les objectifs me semble bien. Et je pense pas que ça pose de problème de dire par exemple qu'on peut toujours faire un TAS même s'il n'est pas publiable ici; après tout c'est un guide sur les TAS en général, pas uniquement sur TASvideos.
D'ailleurs j'ai la flemme de tout relire pour confirmer, mais je sais plus si t'as précisé que c'était préférable de montrer un peu ses WIP sur le forum avant de soumettre une run direct sans aucun feedback (en gros ne pas spammer le workbench avec des trucs qui seront rejetés très vite, s'assurer d'avoir bien fait le boulot et de savoir ce que les gens attendent au minimum d'une run présentée "officiellement").
Deuxième paragraphe du III- :p
Si tu fais une partie "submission", y'a sûrement plusieurs trucs à dire.
Déjà la partie "technique" si on veut entrer dans le détail et tout bien expliquer. Ce passage expliquerait simplement comment remplir la "fiche", ce qu'on doit mettre dans chaque case avec des explications et des conseils, par exemple...
Puis y'aurait des conseils plus généraux, un peu comme dit plus haut. Du genre qu'il ne faut pas soumettre n'importe quoi (gros résumé).
J'y avais carrément pas pensé mais oui c'est vrai que ça peut aider !
Je pense que c'est bien de causer surtout du texte de description de la run.
Déjà qu'il faut quand même prendre le temps de le soigner, malgré le fait qu'on puisse être pressé de montrer notre super TAS qui a demandé beaucoup de temps. J'avais un peu fait cette erreur pour ma première publication, le texte était assez court; enfin c'était un jeu très connu (Castlevania) et qui avait été bien retourné dans tous les sens par des précédents TAS... Mais il y a toujours des gens qui ne connaissent pas les astuces, même bien connues, utilisées dans les runs de jeux populaires.
Donc bref, le but c'est de bien savoir expliquer ce qu'il se passe dans le TAS, d'expliquer les petites astuces, les bugs utilisés, et d'expliquer ce qui a demandé du travail ou de la réflexion (car souvent ce sont des petits détails qui sont les plus compliqués ^^).
Pour le reste... Commencer par une description du jeu/de la run, noter les buts visés, l'émulateur utilisé, ajouter une partie pour remercier des gens si on est redevable à quelqu'un, etc...
En fait ça devrait être facilement explicable en montrant des exemples.
Ça fait une belle liste de chose à dire, puis c'est pour aider ceux qui regardent sans trop connaître les glitchs du jeu (Oh
Ocarina Of Time, le jeu de mon enfance ! Et si je regardais le TA... Euh... J'me rappelle pas qu'il aille aussi vite le Link... Et il me semble qu'il y avait des donjons dans ce jeu...).
Ok, ce sera définitivement dans le guide final (qui est proche d'être accompli... V1.0 :p)
Faudra juste que je refasse la vidéo sur l'hex editing, puisque j'ai oublié une partie majeur de ce truc : l'édition de fichier hexadécimaux x)
C'était très bien je trouve. En tout cas pour expliquer la façon de faire.
Bonnes musiques relaxantes encore une fois, et bien choisies.
Mais comme il faut toujours trouver à redire quand on est un peu perfectionniste, je me lance ^^
Tout ça pourra bien sûr être ajouté en texte sous la vidéo pour entrer dans le détail, remarque, pas besoin de la refaire si tu veux inclure ces trucs:
Je pense qu'il faudrait aussi dire que l'hex editing ne sert pas qu'à reprendre des bouts de run de quelqu'un d'autre; on peut très bien avoir envie de refaire certains passages soi-même avant de les recopier dans la run. Ou alors ça peut être utilisé pour regrouper le boulot de plusieurs personnes si on bosse en équipe.
Autrement, tu parles bien du déterminisme au début, mais pas assez, je trouve, à la fin, une fois que le spectateur sait comment faire l'hex editing. Je pense que c'est à ce moment là qu'il est le plus "prêt" à comprendre ce que ça implique de changer des choses. Par exemple il y a le coup des subpixels (ou subsub, enfin la décimale de la vitesse) dans SMB. Si on ne finit pas le 1-1 avec les mêmes valeurs, on court facilement au devant de désync plus loin :P (c'est pour ça que tu t'es contenté de courir vite fait sur l'ennemi en 1-2, hein? ^^)
Il y a aussi des jeux qui ont des évènements dépendant d'une sorte de timer général, donc perdre ou gagner des frames change tout ça plus tard aussi.
Puis il y a des RNG qui peuvent partir en vrille, et tout et tout...
Enfin voilà, je verrais bien une explication un peu plus détaillée en bonus pour expliquer les choses qui peuvent mal tourner après un hex editing. Ou au pire, juste citer ça comme une liste, que le lecteur/spectateur soit prévenu ^^
C'était très bien je trouve. En tout cas pour expliquer la façon de faire.
Bonnes musiques relaxantes encore une fois, et bien choisies.
Mais comme il faut toujours trouver à redire quand on est un peu perfectionniste, je me lance ^^
Tout ça pourra bien sûr être ajouté en texte sous la vidéo pour entrer dans le détail, remarque, pas besoin de la refaire si tu veux inclure ces trucs:
Je pense qu'il faudrait aussi dire que l'hex editing ne sert pas qu'à reprendre des bouts de run de quelqu'un d'autre; on peut très bien avoir envie de refaire certains passages soi-même avant de les recopier dans la run. Ou alors ça peut être utilisé pour regrouper le boulot de plusieurs personnes si on bosse en équipe.
Autrement, tu parles bien du déterminisme au début, mais pas assez, je trouve, à la fin, une fois que le spectateur sait comment faire l'hex editing. Je pense que c'est à ce moment là qu'il est le plus "prêt" à comprendre ce que ça implique de changer des choses. Par exemple il y a le coup des subpixels (ou subsub, enfin la décimale de la vitesse) dans SMB. Si on ne finit pas le 1-1 avec les mêmes valeurs, on court facilement au devant de désync plus loin :P (c'est pour ça que tu t'es contenté de courir vite fait sur l'ennemi en 1-2, hein? ^^)
Il y a aussi des jeux qui ont des évènements dépendant d'une sorte de timer général, donc perdre ou gagner des frames change tout ça plus tard aussi.
Puis il y a des RNG qui peuvent partir en vrille, et tout et tout...
Enfin voilà, je verrais bien une explication un peu plus détaillée en bonus pour expliquer les choses qui peuvent mal tourner après un hex editing. Ou au pire, juste citer ça comme une liste, que le lecteur/spectateur soit prévenu ^^
C'est vrai que je me suis pas mal concentré sur la chance, peut-être une révision (beaucoup) plus tard :p)
Une révision de la vidéo? Nan faut pas aller jusque là je pense (et ça fait du boulot). Mais si tu veux ajouter des détails sur les dangers de l'hex editing, je suis sûr qu'un petit ajout version texte dans le guide serait plus pratique. C'est surtout des infos qui n'ont pas vraiment besoin d'exemples en images.
Est-ce qu'il y aura un point TAS multi-joueur?
Genre TAS 2joueurs et plus?
J'ai ma petite idée de comment le faire, mais si tu pouvais faire un chapitre là-dessus, ça serait excellent!
Franchement chapeau, c'est bien fait et ultra complet !
Niveau encoding, je partage ce que j'ai testé / utilisé:
Pour un encodage rapide et pas trop dégeu, on peut utiliser le "Record AVI"de l'émulateur quand il a de bons codecs (et ça malheureusement, il faut faire des essais pour ce qui vous convient).
Pour Bizhawk par exemple, je mets ces paramètres
pour avoir ce résultat:
Link to video
Je rescale l'image parce que la SNES, c'est petit d'origine :p; du mkv pour le format de sortie. Pourquoi mkv? Parce que ça prends moins de place qu'un mp4 à qualité égale :)
On voit que le codec utilisé est x264 (le meilleur) pour la vidéo et vorbis (de l'ogg) pour l'audio.
Notez 2 choses importantes:
Aucun souci si l'émulateur n'est pas à 50/60 fps, la vidéo le sera elle.
Bizhawk offre la possibilité de capturer l'OSD ce qui n'est pas le cas de tous. Par OSD, j'entend les fps, le nombre de rerecord, les éventuelles infos supplémentaires affichées par scripts,...
Maintenant, si je prends le cas de PSXjin qui est beaucoup plus rustique et ne propose pas de vrai bons codecs. A nouveau pour quelque chose de rapide et simple, je mets l'émulateur dans la résolution que je souhaite et je capture l'appli avec OBS. C'est plié :p.
Et si on veut une vrai vidéo HD tout propre?
Là, ça se complique. Premièrement, il faut se renseigner sur les options graphiques de l'émulateur et faire des essais. On a parfois des options de lissage des textures qui donnent de beaux résultats! (et parfois de la merde aussi, soyons franc).
Récapitulatif des résolutions format 4/3, chère à nos vieilles consoles:
640 x 480 => 480p
960 x 720 => 720p
1440 x 1080 => 1080p
Quand on a un image satisfaisante, on peut capturer. Là, on va choisir les options "non compressées" et un .avi comme conteneur. Attention /!\ ça prend beaucoup de place, c'est comme si on prenait un screenshot à chaque frame, comptez 2Go les 10secondes en 720p (+/-).
Si ffmpeg existe en tant que "encoder" possible, utilisez-le ! Il est performant et présente l'avantage de ne pas splitter sur la durée mais seulement en cas de changement de résolution.
Moi pour l'exemple, je vais prendre un cas assez extrême, des fichiers splités. Dernière précision, choisissez un nom sans espace ou autre caratère bizarre.
Très franchement, je trouve que c'est une manoeuvre plus simple sous Linux donc je ne parlerai pas de ce qui est possible sous Windows vu que j'en sais trop rien.
J'ai capturé le start screen de mario world en 1440 x 1080 et j'ai obtenu 4 fichiers pour un total de 5.8Go. C'est énorme! On va compresser ça. Pour se faire, j'utilise un utilitaire en ligne de commande qui se nomme "mencoder".
Lui et son pendant mplayer sont des outils géniaux qui peuvent tout faire. Dumper de l'audio, extraire des sous-titres,etc... On se place dans le dossier où sont nos fichiers vidéos qu'on aura pris soin d'isoler de tout les reste.
Traduit, ça donne: Je lance mencoder avec les paramètres -oac (pour output audio codec) copy (on ne change rien au format original); -ovc (pareil mais pour video); -forceidx (on force la reconstruction de l'index de l'avi, c'est plus sûr); -o pour donner un nom à nontre fichier final et enfin le truc tordu `ls *.avi` (les espèces d'apostrophes qui n'en sont pas! -backticks `- font en sorte que ce qui est dedans soit interprété comme une commande; ici je liste les fichier *.avi et cette liste sera utilisé comme paramètre par mencoder; en gros ça évite de taper le nom de tout les fichiers un par un). Et voilà ce qui apparait
Un joli fichier qui fait exactement la taille de tout les autres! Compressons maintenant. Retour à ffmpeg avec la commande suivante:
Relativement simple à comprendre: tout ce qui est entre -vcodec et -acodec concerne la vidéo, entre -acodec et -threads concerne l'audio. L'option -threads 0 fait en sorte que le boulot soit équitablement répartit entre les différents coeurs/cpu.
Si vous souhaitez plus d'infos sur les paramètres d'x264 et de libvorbis, il faut farfouiller le net. Ce sont des codecs très complexes mais qui offrent les meilleurs résultats! (Notez que pour le son, le meilleur codec est AAC, réservez-le pour des films par exemples vu qu'il supporte le 5.1; l'ogg est largement suffisant pour nous même sur une console newgen)
Il y a juste un avertissement qui nous conseille d'utiliser la commande avconv au lieu de ffmpeg; la syntaxe et le résultat sont identiques. On notera l'option -movflags +faststart qui optimise la vidéo pour une lecture sur le web. Absolument pas obligatoire si vous l'uploadez sur youtube, ils le font pour vous.
Le résultat de cet encodage:
Link to video
Mon fichier pèse 3.1Mo, une broutille contre les 5.8Go de tout à l'heure. Et le résultar est très correcte.
Et si vous êtes maso et obstiné par la qualité? Vous pouvez opter pour du multi-pass. C'est à dire qu'on va faire un premier encodage rapide qui sert juste à évaluer et le second qui fait l'encodage proprement dit.
On voit que la commande divise en 2 (par le &&) la première pass est jetée (/dev/null en sortie) et la seoncde fois, on obtient le fichier final_2.mkv. Remarquez aussi qu'on encode le son uniquement lors de la 2ème pass, d'où le -na (no audio) dans la première commande.
Le fichier obtenu pèse 7,3Mo dans mon cas, on ne verra pour ainsi dire pas de différence mais dans le cas d'un shmup, ça peut être flagrant.
Link to video
Vous pouvez bien évidemment jouer sur les paramètres pour faire varier le poids du fichier, la qualité,... Il y a des tonnes d'options possibles, je me suis contenté de l'essentiel afin de rester simple et compréhensible (enfin j'espère :D)
Voilà, c'est tout ce que je sais. Je précise que je n'ai pas la science infuse mais je pense que c'est un bon début et j'espère avoir un peu éclaircit vos lanternes :).
Happy encoding.
PS: Youtube réencodant, il est possible que le résultat soit différent de ce que j'ai obtenu réellement.
EDIT: Quelques infos en plus sur la commande d'encodage single-pass.
Wow. Je lirais ça quand j'aurais le temps (dans une dizaine d'heure à priori), mais ça semble être du beau concret ! Oo
- J'apprendrais sans doute plein de truc moi aussi :o)
Merci beaucoup !
On voit que c'est pas pour rien qu'on a des personnes spécialisées dans l'encodage sur le site, ça peut devenir vraiment coton avec certains émulateurs ^^ (PSX, 64, Dolphin...)
Mes seules expériences viennent de FCEUX et Bizhawk. J'encodais à la brute avec le codec Camstudio lossless pour avoir d'abord une vidéo "parfaite" (mais grosse).
Le truc c'est qu'ensuite vaut mieux passer par un prog spécialisé (virtualdub par exemple) pour réduire la taille par compression, surtout pour les longues vidéos, et appliquer des petites bidouilles, par exemple pour le "deblink" si on veut poster le résultat sur youtube qui réduit les FPS (le deblink évite qu'un sprite devienne invisible ou toujours visible quand il clignote, comme quand un perso se prend des dégâts, mais perso je sais pas comment on le fait ^^).
Je comprends toujours pas comment encodé proprement sur Dolphin. Mais j'ai appris à faire les modifs pour me faire des versions a/v hack x)
J'utilise lagarith d'habitude :p
J'ai jamais vraiemnt travaillé avec Dolphin, mais je regarderai si ça peut t'aider.
Je ne connaissais pas lagarith. Je parle de x264 (qui est en fait le pendant libre de h264) parce que c'est LE codec le plus utilisé de par ses multiples atouts (compatibilité, performance, qualité), ça n'exclu bien évidemment pas d'utiliser vos codecs préférés !
Petite astuce que tu parles d' a/v hack. Le mkv a le très gros avantage de pouvoir contenir plusieurs flux audios et/ou vidéos dans un même fichier. Les sous-titres sont également un flux à part.
En d'autres termes, il est possible d'avoir un film multilingue avec sous-titres désactivables dans un seul mkv (ce qui n'est pas le cas du mp4).
Ok je pense prendre pas mal de ton boulot Hâthor (en te rendant crédit évidemment), et en plus ajouté un tutoriel sur l’installation de ffmpeg du coup tant qu'à faire :p
Lagaryth est en gros le main concurrent du x264, ils sont très proches d'ailleurs niveau codec :o
Ok, sers-toi, j'ai écris pour ça! :)
En ce qui concerne Dolphin, qui n'a pas de moyen interne de capturer (et ça, c'est très moche); en tout cas, je n'en ai pas trouvé. Je ne vois qu'une solution:
Pareil, on bidouille les options graphiques pour avoir un résultat satisfaisant. J'opterais pour passer le jeu en fullscreen et ensuite => FRAPS.
Grosse config inside. Je peux vraiment pas tester, Dolphin rame à mort sur mon PC :(
(Ok pour lagaryth, j'ignorais son existence. je dormirai moins bête :D)
Il y a une option pour capturer :
Elle est caché ! (...)
Graphics -> Advanced -> Dump Frames
DSP -> Dump Audio (en vérifiant que t'es en DSound)
Je vais essayer de faire un premier jet sur tout ça, pour voir :)
Pourquoi faire simple quand on peut faire compliqué.... -_-'
Je vais faire quelques tests de mon côté aussi.
EDIT Bon, il nous fait la totale, audio séparé ET fichier splitté :D. ffmpeg est capable d'utiliser un fichier audio spécifique mais il y a plus simple pour moi, les détails arrivent bientôt.
pour avoir ce résultat:
Link to video
Je rescale l'image parce que la SNES, c'est petit d'origine :p; du mkv pour le format de sortie. Pourquoi mkv? Parce que ça prends moins de place qu'un mp4 à qualité égale :)
On voit que le codec utilisé est x264 (le meilleur) pour la vidéo et vorbis (de l'ogg) pour l'audio.
Notez 2 choses importantes:
J'ai capturé le start screen de mario world en 1440 x 1080 et j'ai obtenu 4 fichiers pour un total de 5.8Go. C'est énorme! On va compresser ça. Pour se faire, j'utilise un utilitaire en ligne de commande qui se nomme "mencoder".
Lui et son pendant mplayer sont des outils géniaux qui peuvent tout faire. Dumper de l'audio, extraire des sous-titres,etc... On se place dans le dossier où sont nos fichiers vidéos qu'on aura pris soin d'isoler de tout les reste.
Un joli fichier qui fait exactement la taille de tout les autres! Compressons maintenant. Retour à ffmpeg avec la commande suivante:
Il y a juste un avertissement qui nous conseille d'utiliser la commande avconv au lieu de ffmpeg; la syntaxe et le résultat sont identiques. On notera l'option -movflags +faststart qui optimise la vidéo pour une lecture sur le web. Absolument pas obligatoire si vous l'uploadez sur youtube, ils le font pour vous.
Le résultat de cet encodage:
Link to video
Mon fichier pèse 3.1Mo, une broutille contre les 5.8Go de tout à l'heure. Et le résultar est très correcte.
Et si vous êtes maso et obstiné par la qualité? Vous pouvez opter pour du multi-pass. C'est à dire qu'on va faire un premier encodage rapide qui sert juste à évaluer et le second qui fait l'encodage proprement dit.