/* Topic des codeurs [8] */

Rolinh · Le 27/04/2013, à 19:03

Pour ce qui est du multiplexage, ce n'est pas moi qui m'en occupera mais la manière dont l'utilisateur de la lib l'utilise.
En fait, la lib propose les fonctions suivantes:

struct gwavi_t *gwavi_open(char *filename, int width, int height, char *fourcc,
			   int fps, struct gwavi_audio_t *audio);
int gwavi_add_frame(struct gwavi_t *gwavi, unsigned char *buffer, size_t len);
int gwavi_add_audio(struct gwavi_t *gwavi, unsigned char *buffer, size_t len);
int gwavi_close(struct gwavi_t *gwavi);

Je pense que les noms sont parlant d'eux-mêmes.
Pour les détails, faudra juste attendre que je publie le code (ce qui ne devrait pas trop tarder).

The Uploader · Le 27/04/2013, à 19:14

L'utilisateur ne peux pas choisir la version du conteneur ? (AVI 1.0 ou AVI 2.0)

Remarque, je vois pas trop l'intérêt de préférer AVI 1.0, sauf pour la nostalgie.

(edit : ah oui, H.264 dans .AVI ça se trouve, mais c'est broken(*) - quant à mettre du Vorbis dans un .AVI ça ne marche pas du tout on dirait -, et bien sûr le VFR (Variable Framerate) n'est pas supporté))

Bref, y'a des formats pas compatibles, mais je n'ai pas de liste exacte.

(*) par exemple, les IDR-frames du format H.264, posent problème, mais pas que :

qyot27 a écrit :

The thing about applying the same hacks as was used in ASP is that ASP is bad enough to do that to, but H.264's featureset is much more expansive in regard to B-frames, the B-pyramid, etc. Using said hacks to put H.264 in AVI often isn't sufficient enough to ensure that the audio remains synced, in the case of numerous B-frames and especially the B-pyramid. The only way around it is to disable those features, but that results in benefit being lost. It'll still perform well, but not as well as it could have.
I've never found an in-depth answer concerning how YAMB/MP4Box corrects H.264 VFW streams before putting them in MP4, although I can only assume that it does perform some sort of fix, since afterward they seem to be fine. I switched my encoding to MeGUI and then ultimately CLI a couple years ago, so having to work around H.264-in-AVI is a very rare occurrence for me.

http://forum.doom9.org/archive/index.php/t-143613.html

Dernière modification par The Uploader (Le 27/04/2013, à 19:36)

Rolinh · Le 27/04/2013, à 20:06

The Uploader a écrit :

L'utilisateur ne peux pas choisir la version du conteneur ? (AVI 1.0 ou AVI 2.0)

Non, ça n'est pas prévu et je ne pense pas que ça le sera.

J'ai déjà mis du H264 dans un AVI avec cette lib et ça marche sans problèmes (pour ce que je l'ai testé). En fait, l'application de vidéo en embarqué que j'écris génère un flux vidéo (720p et 1080p pour le moment) compressé en H264 et le met dans un fichier AVI via cette lib (il est possible de mettre le flux dans d'autres conteneurs aussi, évidemment).

The Uploader · Le 27/04/2013, à 20:11

Ah ce n'est pas impossible à faire, mais outre les hacks (dont celui pour les b-frames), ça limite fortement les options du format H.264 que tu peux utiliser (comme b-pyramid est une des options qui rend la compression nettement plus efficace, et aussi --open-gop qui utilise des IDR-frames). ^^

Tu peux regarder du côté de x264vfw pour voir en détail ce qui peut poser problème avec le H.264 pour le conteneur .AVI (bon il risque d'y avoir des hacks pour la compatibilité avec VfW, dans le tas).

Dernière modification par The Uploader (Le 27/04/2013, à 20:19)

Rolinh · Le 27/04/2013, à 20:26

Ouep et c'est bien dommage d'ailleurs. C'est juste qu'un client potentiel souhaite absolument de l'AVI donc voilà. Pour le coup, j'ai cherché une lib pour me simplifier la vie, je suis tombé sur libkohn-avi et vu que j'y apporte des changements, je les publie sous une nouvelle lib pour la création d'AVI.
J'ai prévu mon appli pour facilement envoyer le flux compressé H264 dans d'autres types de conteneurs voir dans plusieurs conteneurs différents à la volée ce qui fait que je vais aussi me pencher sur d'autres formats.

Dernière modification par Rolinh (Le 27/04/2013, à 20:27)

grim7reaper · Le 27/04/2013, à 20:42

Rolinh a écrit :

Je ne suis pas trop sûr de quelle façon je suis censé répartir mes fichiers sources dans mon dépôt. Concrètement, j'ai pour le moment 6 fichiers sources (3 C et 3 header). Seul une paire de fichiers contient les fonctions qui sont censées être utilisées lorsque l'on utilise la lib dans un programme. Une paire contient des fonctions utilitaires générales et la dernière paires des fonctions utilitaire pour la création du fichier AVI.
Je pensais à quelque chose dans le genre (avec éventuellement un dossier pour des tests):
├── LICENSE
├── Makefile
├── README.md
├── demo
│   ├── demo.c
│   └── demo.h
├── doc
│   └── Doxyfile
└── src
├── gwavi.c
├── gwavi.h
└── utils
├── avi-utils.c
├── avi-utils.h
├── fileio.c
└── fileio.h
Avec génération de libgwavi.so à la racine du dossier. Ça vous parait correct?
Ah, une fois publiée, une revue de code sera toujours bienvenue, surtout pour une lib.

Le layout me paraît correcte.
Perso, soit je fais comme ça, soit j’ai un src et un inc, ça dépend de l’humeur du moment (l’avantage du répertoire inc c’est qu’il peut servir à mettre les headers publics, les autres pouvant rester dans le répertoire src).
Je ne sais pas si le sous-répertoire utils est très pertinent ici.
Sinon, pour le .so je le mettrai bien dans un répertoire lib.

Rolinh · Le 27/04/2013, à 20:52

C'est vrai que "utils" n'est peut-être pas pertinent. Le truc, c'est que le seul "header public" est gwavi.h.
Du coup, si je te suis bien, je devrais plutôt faire le layout suivant?

├── AUTHORS.md
├── LICENSE
├── Makefile
├── README.md
├── doc
│   └── Doxyfile
├── examples
│   ├── Makefile
│   ├── demo.c
│   └── demo.h
├── inc
│   └── gwavi.h
├── lib
└── src
    ├── avi-utils.c
    ├── avi-utils.h
    ├── fileio.c
    ├── fileio.h
    └── gwavi.c

grim7reaper · Le 27/04/2013, à 21:12

Rolinh a écrit :

Du coup, si je te suis bien, je devrais plutôt faire le layout suivant?

Yep.
Enfin, pour le inc tu fais comme tu le sens.
Moi même, ça varie d’un projet à l’autre.

Dernière modification par grim7reaper (Le 27/04/2013, à 21:13)

Rolinh · Le 27/04/2013, à 21:24

Ouep mais ça me va bien le inc pour le coup vu que pour utiliser la lib, il y a juste besoin d'include gwavi.h.
Bon, je vais écrire le Makefile en conséquence et je publierais tout ça.

The Uploader · Le 27/04/2013, à 21:39

@Rolinh :
Ta lib prévient l'utilisateur si elle détecte des options incompatibles avec le .AVI (open-gop introduira des IDR frames, b-pyramid introduira des références à des images bidirectionnelles, ...) dans un bitstream H.264 en entrée ?

(je sais pas trop comment en fait, ce sera plutôt à faire dans une couche plus haut niveau, genre un programme de muxing qui utilise la lib >_< )

Ça peut être difficile à implémenter pour pas grand chose (tu peux à la place mettre un gros warning générique qui documente les options non supportées dans la doc'). C'était juste un truc comme ça. ^^

(bon sinon tu peux hacker autour de ces limitations, mais vu que ces hacks ne sont pas pris en charge par les démultiplexeurs .AVI... )

Dernière modification par The Uploader (Le 27/04/2013, à 21:49)

Rolinh · Le 27/04/2013, à 22:31

Non, elle prévient rien du tout.

Comme tu dis, je pourrais mettre une note à ce propos, genre dans le readme. Enfin bon, dans un autre sens, ça veut dire qu'il faudrait que je liste tous les fourcc et que je dise en détail lesquels sont supportés et lesquels ne le sont pas. Je ne sais pas si j'ai vraiment envie de m'amuser à ça.

Bon, je finirais demain. Il ne me reste plus qu'à configurer doxygen et écrire une application de démo. Bon, l'application de démo attendra je pense. Je mettrais un disclaimer pour prévenir que la lib n'est pas encore en version finale.

Rolinh · Le 28/04/2013, à 11:40

Bon, voilà, c'est publié.
Il me reste encore à documenter les fonctions de la lib. J'ai aussi quelques warnings qu'il faut que je corrige. Enfin bon, j'ai mis un petit disclaimer comme quoi il y a encore un petit peu de travail à faire dessus.

EDIT: à propos, je viens d'apprendre que les dernières versions de Doxygen parsent correctement le markdown. Par ailleurs, c'est aussi facile d'indiquer le README.md comme fichier principal qui doit être parsé et affiché sur index.html. Ça rend vraiment bien! Un make doc si vous voulez voir. Ah, l'url de clone n'est pas spécifiée donc pour cloner:

git clone git://gw-computing.net/libgwavi.git

Dernière modification par Rolinh (Le 28/04/2013, à 11:44)

The Uploader · Le 03/05/2013, à 09:50

Linux/Cdorked.A : nouvelle porte dérobée Apache discrète

Dr Le Rouge · Le 03/05/2013, à 13:14

Un monsieur (ou une madame) sur github, à propos de meuporg a écrit :

Add Android App with Sync function

Mais encore ?

Pour ceux que ça intéresserait, je m'y suis remis : code simplifié et nouvelles fonctionnalités au programme o/

Rolinh · Le 03/05/2013, à 17:22

Si un jour vous avez besoin de couper les N premières frames d'une vidéo RAW en YUV, pas la peine d'écrire un outil pour le faire, je viens d'en publier un: yuvcutter.

The Uploader · Le 03/05/2013, à 17:49

@Rolinh :
Merci cela me sera très certainement utile.

grim7reaper · Le 03/05/2013, à 18:04

Rolinh a écrit :

Bon, voilà, c'est publié.

Ça fait un moment que je voulais faire une remarque (mais avant je voulais faire des tests, voire faire un patch mais en fait j’ai pas trop de temps en ce moment )
Dans fileio.c, les écritures octet par octet ça doit être plutôt moche niveau perf’.
Ça serait pas équivalent de passer par un bon vieux fwrite ? Où j’ai raté un truc ?

Rolinh a écrit :

Si un jour vous avez besoin de couper les N premières frames d'une vidéo RAW en YUV, pas la peine d'écrire un outil pour le faire, je viens d'en publier un: yuvcutter.

Ça me rappelle quand j’avais du jouer avec du YUV 422 lors de mon dernier projet scolaire (bon j’avais pas eu besoin de le découper par contre).

Bon, dans Rosalind je suis finalement venu à bout de REAR. Et comme je le pensais, la piste sur laquelle je partais avant de faire un long break sur Rosalind était la bonne. C’était pas si sorcier, quand on sait quoi chercher.

Rolinh · Le 03/05/2013, à 18:25

@The Uploader: ce n'est pas grand chose mais je suis content si ça peut servir à d'autres personnes

grim7reaper a écrit :

Ça fait un moment que je voulais faire une remarque (mais avant je voulais faire des tests, voire faire un patch mais en fait j’ai pas trop de temps en ce moment )
Dans fileio.c, les écritures octet par octet ça doit être plutôt moche niveau perf’.
Ça serait pas équivalent de passer par un bon vieux fwrite ? Où j’ai raté un truc ?

Oui, très certainement. Pour être honnête, je n'ai pas non plus énormément de temps non plus et j'avais besoin de la lib assez vite pour mon projet video. Du coup, je me suis contenté d'ajouter des vérifications d'erreurs et de la doc à la lib originale en me disant que je reviendrais dessus plus tard si je trouve le temps. D'autant plus que gcc me warn de conversion implicite de signe sur write_int(). Quand je cross-compile la lib pour ARM (via codesourcery), je me tape carrément une pile de warnings de ce genre.

grim7reaper a écrit :

Ça me rappelle quand j’avais du jouer avec du YUV 422 lors de mon dernier projet scolaire (bon j’avais pas eu besoin de le découper par contre).

Mon use-case est en fait exactement celui que j'ai mis dans le README. En fait, je suis en train de faire des mesures de PSNR via le logiciel de référence H264/AVC et pour que le calcul soit corrects, il faut que j'aligne la première frame de ma vidéo compressée en H264 via mon appli avec la vidéo de référence en YUV. Parce que s'il y a un décalage ne serait que d'une frame, le résultat du PSNR ne vaut évidemment plus rien...

Pour ma part, Rosalind attendra que je sois moins chargé...

EDIT: @The Uploader: au fait, il a rejoint la liste des paquets que je maintiens sur AUR.

Dernière modification par Rolinh (Le 03/05/2013, à 18:29)

The Uploader · Le 03/05/2013, à 19:30

Le SSIM est beaucoup plus fiable que le PSNR, mais les deux n'aiment pas du tout les améliorations psycho-visuelles qui plaisent tellement à l'oeil humain (telles que la Variance-based Adaptive Quantization, ou les options de psy-rd).

le x264 peut te calculer les deux :

--enable-ssim --enable-psnr

Bref, les scores SSIM/PSNR sont toujours à prendre avec méfiance (le x264 a même un preset qui maximise le score PSNR en désactivant toutes les améliorations psycho-visuelles. Bref, l'aspect de l'image plaira à la machine, mais pas à l'humain).

Rolinh a écrit :

EDIT: @The Uploader: au fait, il a rejoint la liste des paquets que je maintiens sur AUR.

Cool.

Dernière modification par The Uploader (Le 03/05/2013, à 19:52)

Rolinh · Le 03/05/2013, à 20:22

The Uploader a écrit :

Le SSIM est beaucoup plus fiable que le PSNR

Oui, je suis au courant. Seulement, pour autant que je sache, le décodeur de référence H264 ne permet que le calcul du PSNR.
Ceci dit, ça pourrait être intéressant que je fasse aussi le calcul du SSIM. Mais bref, comme tu dis, dans tous les cas ce ne sont pas des métriques à prendre pour argent comptant, seulement un indicateur.
Donc évidemment, je ne tiens pas compte uniquement de ça. Il faut d'ailleurs aussi que je fasse des tests de random access. Le but de tout ça, c'est de jouer avec les paramètres de l'H264 pour trouver un bon compromis qualité/taille de fichier.

The Uploader · Le 03/05/2013, à 20:49

Rolinh a écrit :

Le but de tout ça, c'est de jouer avec les paramètres de l'H264 pour trouver un bon compromis qualité/taille de fichier.

T'as toujours le même type de sources ?

Si non, ça risque d'être complexe d'avoir une qualité vraiment constante.

Dernière modification par The Uploader (Le 03/05/2013, à 20:51)

Rolinh · Le 04/05/2013, à 15:28

Non, je n'ai pas forcément toujours le même type de source. En fait, mon appli est capable de prendre des presets en fonction de ce qui est souhaité et du type d'input. Le but est de chercher plusieurs réglages pour offrir des presets en fonction.

The Uploader · Le 04/05/2013, à 15:33

Le x264 a déjà des presets selon les sources (--preset et --tune), tu peux sûrement t'en inspirer.
Ce qu'ils changent est décrit dans x264 --fullhelp

The Uploader · Le 04/05/2013, à 16:26

Comment endiguer les contrefaçons de jeux vidéos (DRM free)...

Rolinh · Le 04/05/2013, à 20:09

The Uploader a écrit :

Le x264 a déjà des presets selon les sources (--preset et --tune), tu peux sûrement t'en inspirer.

Peut-être. J'y jetterais un œil.

Tu bosses sur des projets video?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1126 Le 27/04/2013, à 19:03

Re : /* Topic des codeurs [8] */

#1127 Le 27/04/2013, à 19:14

Re : /* Topic des codeurs [8] */

#1128 Le 27/04/2013, à 20:06

Re : /* Topic des codeurs [8] */

#1129 Le 27/04/2013, à 20:11

Re : /* Topic des codeurs [8] */

#1130 Le 27/04/2013, à 20:26

Re : /* Topic des codeurs [8] */

#1131 Le 27/04/2013, à 20:42

Re : /* Topic des codeurs [8] */

#1132 Le 27/04/2013, à 20:52

Re : /* Topic des codeurs [8] */

#1133 Le 27/04/2013, à 21:12

Re : /* Topic des codeurs [8] */

#1134 Le 27/04/2013, à 21:24

Re : /* Topic des codeurs [8] */

#1135 Le 27/04/2013, à 21:39

Re : /* Topic des codeurs [8] */

#1136 Le 27/04/2013, à 22:31

Re : /* Topic des codeurs [8] */

#1137 Le 28/04/2013, à 11:40

Re : /* Topic des codeurs [8] */

#1138 Le 03/05/2013, à 09:50

Re : /* Topic des codeurs [8] */

#1139 Le 03/05/2013, à 13:14

Re : /* Topic des codeurs [8] */

#1140 Le 03/05/2013, à 17:22

Re : /* Topic des codeurs [8] */

#1141 Le 03/05/2013, à 17:49

Re : /* Topic des codeurs [8] */

#1142 Le 03/05/2013, à 18:04

Re : /* Topic des codeurs [8] */

#1143 Le 03/05/2013, à 18:25

Re : /* Topic des codeurs [8] */

#1144 Le 03/05/2013, à 19:30

Re : /* Topic des codeurs [8] */

#1145 Le 03/05/2013, à 20:22

Re : /* Topic des codeurs [8] */

#1146 Le 03/05/2013, à 20:49

Re : /* Topic des codeurs [8] */

#1147 Le 04/05/2013, à 15:28

Re : /* Topic des codeurs [8] */

#1148 Le 04/05/2013, à 15:33

Re : /* Topic des codeurs [8] */

#1149 Le 04/05/2013, à 16:26

Re : /* Topic des codeurs [8] */

#1150 Le 04/05/2013, à 20:09

Re : /* Topic des codeurs [8] */

Pied de page des forums