Salut,
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?
=> Si c’est le cas, où est-ce que je peux commiter ce patch? Je ne pige pas la structure de _core_ sur zone.
ARNO*
Le 20/11/2019 à 10:53, Arnaud Martin a écrit :
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?
C'est peut être pas une mauvaise méthode...
mais sans toucher au core, on peut a priori ajouter dans le .htaccess une directive indiquant le bon comportement
Par exemple j'ai :
AddType image/vnd.microsoft.icon .ico
Si j'ai bien compris ce que tu veux, tu dois pouvoir ajouter :
AddType audio/mp4a-latm .aac
JL
Non, je viens d’essayer, et ça ne semble pas fonctionner.
Mon problème est que la fonction PHP de Gandi identifie le fichier «.acc» avec le mime_type «audio/x-hx-aac-adts». J’ai ajouté le AddType à mon htaccess, ça n’a pas l’air d’impacter la fonction PHP.
Du coup je convertis ce «mauvais» retour de PHP dans SPIP, là où on a les mime_alias (qui semblent bien servir à corriger les «mauvais» fichiers).
==========
Du coup je continue, le fichier audio fabriqué à partir d’un smartphone android expédie un fichier «.m4a», mais l’identifie avec le mime type video/3gpp. Et là je pense être complètement coincé.
Arnaud
Le 20 nov. 2019 à 11:35, JLuc <jluc@no-log.org> a écrit :
Le 20/11/2019 à 10:53, Arnaud Martin a écrit :
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?C'est peut être pas une mauvaise méthode...
mais sans toucher au core, on peut a priori ajouter dans le .htaccess une directive indiquant le bon comportement
Par exemple j'ai :
AddType image/vnd.microsoft.icon .icoSi j'ai bien compris ce que tu veux, tu dois pouvoir ajouter :
AddType audio/mp4a-latm .aacJL
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Hop,
Le 20/11/2019 à 10:53, Arnaud Martin a écrit :
Salut,
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?
Oui, ça semble légitime comme patch, cf :
https://github.com/symfony/symfony/pull/31565/files
=> Si c’est le cas, où est-ce que je peux commiter ce patch? Je ne pige pas la structure de _core_ sur zone.
Ici https://zone.spip.net/trac/spip-zone/browser/_core_/plugins/medias/ pour la version de dev (3.3). et là pour la 3.2 si on confirme qu'il faut reporter dans la branche stable https://github.com/symfony/symfony/pull/31565/files
++
b_b
OK.
Problème beaucoup plus chiant:
- j’ai deux fichiers .m4a. L’un est téléchargé du Web, et quand je l’ouvre dans un éditeur de texte, je vois qu’il commence par quelques caractères bizarres puis:
ftypM4A
- j’ai un second fichier .m4a. Celui-ci est fabriqué par l’application microphone d’un smartphone Android. Quand je regarde dans le fichier, ça commence avec:
ftyp3gp4
Du coup, le premier, quand je demande à PHP de me dire son MIME, il répond « audio/x-m4a».
Le second, catastrophe, ça me dit: «video/3gpp». Or, c’est bien de l’audio (puisque fichier .m4a, d’ailleurs).
Arg.
Arnaud
Le 20 nov. 2019 à 12:07, Bruno Bergot <bruno@eliaz.fr> a écrit :
Hop,
Le 20/11/2019 à 10:53, Arnaud Martin a écrit :
Salut,
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?Oui, ça semble légitime comme patch, cf :
https://github.com/symfony/symfony/pull/31565/files
=> Si c’est le cas, où est-ce que je peux commiter ce patch? Je ne pige pas la structure de _core_ sur zone.
Ici https://zone.spip.net/trac/spip-zone/browser/_core_/plugins/medias/ pour la version de dev (3.3). et là pour la 3.2 si on confirme qu'il faut reporter dans la branche stable https://github.com/symfony/symfony/pull/31565/files
++
b_b
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Le 20/11/2019 à 12:52, Arnaud Martin a écrit :
Du coup, le premier, quand je demande à PHP de me dire son MIME, il répond « audio/x-m4a».
Le second, catastrophe, ça me dit: «video/3gpp». Or, c’est bien de l’audio (puisque fichier .m4a, d’ailleurs).Arg.
Je ne suis pas spécialiste de ces formats, mais ffmpeg est une trousse à outils pour notamment convertir des formats, peut être une piste ?
--
nicod_
Hello 
Possible que je me trompe, mais un .m4a est un "conteneur", c’est-à-dire qu'il peut contenir aussi bien un fichier audio au format aac, que à un autre format (je ne sais plus trop les possibilités).
VLC (par exemple) ne te dit rien de plus concernant les codecs de ton fichier ?
Sinon concernant un commit, je vais faire un complément à super b_b qui à déjà répondu sur ce point
Pour la version "truck" (spip 3.3 actuellement), le plugin-dist de medias est là:
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_core_/plugins/medias/base/typedoc.php
Pour la version de spip 3.2, c'est ici:
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_core_/branches/spip-3.2/plugins/medias/base/typedoc.php
Sinon, tu as également l'option de git, et c'est ici que cela se trouve :
https://git.spip.net/SPIP/medias
Franck
-----Message d'origine-----
De : Arnaud Martin <arno@rezo.net>
Envoyé : mercredi 20 novembre 2019 12:53
À : Bruno Bergot <bruno@eliaz.fr>
Cc : Spip Liste <spip-zone@rezo.net>
Objet : Re: [SPIP Zone] (sans objet)
OK.
Problème beaucoup plus chiant:
- j’ai deux fichiers .m4a. L’un est téléchargé du Web, et quand je l’ouvre dans un éditeur de texte, je vois qu’il commence par quelques caractères bizarres puis:
ftypM4A
- j’ai un second fichier .m4a. Celui-ci est fabriqué par l’application microphone d’un smartphone Android. Quand je regarde dans le fichier, ça commence avec:
ftyp3gp4
Du coup, le premier, quand je demande à PHP de me dire son MIME, il répond « audio/x-m4a».
Le second, catastrophe, ça me dit: «video/3gpp». Or, c’est bien de l’audio (puisque fichier .m4a, d’ailleurs).
Arg.
Arnaud
Le 20 nov. 2019 à 12:07, Bruno Bergot <bruno@eliaz.fr> a écrit :
Hop,
Le 20/11/2019 à 10:53, Arnaud Martin a écrit :
Salut,
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?Oui, ça semble légitime comme patch, cf :
https://github.com/symfony/symfony/pull/31565/files
=> Si c’est le cas, où est-ce que je peux commiter ce patch? Je ne pige pas la structure de _core_ sur zone.
Ici https://zone.spip.net/trac/spip-zone/browser/_core_/plugins/medias/ pour la version de dev (3.3). et là pour la 3.2 si on confirme qu'il faut reporter dans la branche stable https://github.com/symfony/symfony/pull/31565/files
++
b_b
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
C’est un raisonnement purement microsoftien que de tirer une conclusion en se basant sur une extension de fichier. Le type MIME <https://fr.wikipedia.org/wiki/Type_de_médias> indique quel est réellement ce fichier en se basant sur sa signature (octets caractéristiques au début) ; et dans le cas présent ça dit bien que ce sont des formats différents ! .mpa n’est pas normalisé et est souvent utilisé pour indiquer de l’audio en AAC ou ALAC <https://fr.wikipedia.org/wiki/MPEG-4_Part_14> Pour l’autre c’est du 3GP <https://fr.wikipedia.org/wiki/3gp> souvent utilisé par les enregistreurs vocaux. L’extension peut être changé (ce qui n’équivaut pas à une conversion : remplacer .txt par .doc ne transforme pas le premier en le second) pour permettre à certaines applications d’ouvrir le document facilement (ça veut dire que le format est décodé en interne par ton lecteur, tout comme VLC saura le lire aussi, mais ton application ne gère pas la bonne extension ; ou alors c’est fait ainsi pour des raisons de compatibilité que nous ignorons)
Bref, PHP a bien raison et ça n’empêche pas que les deux soient de l’audio (ou de la vidéo), et l’extension ne peut faire foi…
Le mer. 20 nov. 2019 12:53, Arnaud Martin a écrit :
OK.
Problème beaucoup plus chiant:
j’ai deux fichiers .m4a. L’un est téléchargé du Web, et quand je l’ouvre dans un éditeur de texte, je vois qu’il commence par quelques caractères bizarres puis:
ftypM4Aj’ai un second fichier .m4a. Celui-ci est fabriqué par l’application microphone d’un smartphone Android. Quand je regarde dans le fichier, ça commence avec:
ftyp3gp4Du coup, le premier, quand je demande à PHP de me dire son MIME, il répond « audio/x-m4a».
Le second, catastrophe, ça me dit: «video/3gpp». Or, c’est bien de l’audio (puisque fichier .m4a, d’ailleurs).Arg.
Arnaud
Je pense comme Franck: le fichier qui me pose problème est bien un conteneur (format et terminaison .m4a), dont le contenu est en 3GP (d’ailleurs lui-même décrit dans la doc comme un… conteneur multimédia).
Le fait que PHP «identifie» le contenu du conteneur, c’est très bien, mais ce n’est pas vraiment la question: la question, c’est : qu’est-ce que je fais avec SPIP d’un côté, et ce format de fichier qui m’arrive, de manière standardisée, quand on enregistre le son sur un mobile Android? Je précise à nouveau: format fichier .m4a identifié comme video/3gpp par PHP, et donc bloqué par SPIP, il est plus où moins hors de contrôle de l’usager. C’est le fichier qui est fabriqué et expédié, directement, quand dans le formulaire très standard «Envoyer un fichier», sur un smartphone Android (Samsung A40), avec Chrome, je choisis l’option «Enregistrer un son» (les autres options seraient Choisir un fichier, et Enregistrer une vidéo…), ce ouvre l’enregistreur du smartphone. Une fois validé le son que je viens d’enregistrer, hop c’est associé au formulaire et c’est expédié directement sans contrôle supplémentaire de l'usager. Ultra-simple, et donc pour l’usager, c’est la situation typique «Ça marche pas votre truc».
Depuis hier j’ai contourné le problème. Mais c’est pas simple:
- dans Formidable, outre le format ACC et M4A, j’ai indiqué que j’acceptais aussi le format «vidéo» 3GP. C’est la première étape pour que le fichier *audio* au format .m4a passe le formulaire. (Mais en pratique: je ne veux pas de fichier vidéo 3GP, parce que je ne veux pas héberger de vidéos moi-même…)
- le hic, c’est que derrière je me retrouve avec un fichier zippé, parce que je suppose SPIP se méfie du fait que le type MIME ne correspond pas à l’extension (alors que, je répète: c’est bien un conteneur M4A avec une extension .m4a; dont le contenu multimédia est en 3GP et c’est ce qu’identifie PHP: mais l’extension d’origine n’est tout de même pas fautive)… Du coup, avec Formidable et CVT Upload, ce qui se retrouve dans /config/fichiers, c’est la version .m4a.zip du fichier uploadé. Donc je ne peux donc pas faire grand chose directement :-)à
- du coup, au moment de l’affichage des résultats, je balance une fonction maison qui prend le fichier .m4a.zip de /config/fichier, et le décompte dans /IMG/m4a. Et c’est ce fichier que je joue dans mon <audio src=*>
Autant dire que je trouve tout ça totalement farfelu, potentiellement dangereux, impossible à maintenir, et assez nettement hors de portée d’un développeur de site SPIP qui voudrait se reposer sur Formidable pour fabriquer son formulaire…
C’est pour ça que je signale le problème: c’est un cas d’usage relativement simple (un formulaire sur un smartphone, je clique «Envoyer un fichier», ça déclenche l’enregistreur de mon smartphone, je valider, et là ça ne marche pas… sauf bidouille bizarre décrite ci-dessus), et je ne vois pas trop si on peut y répondre côté SPIP (sauf à assouplir les règles d’upload de fichiers multimédia, où PHP identifie le contenu plutôt que le conteneur).
Une option serait de «corriger» volontairement l’extension à partir du MIME détecté par PHP (ici: renommer le fichier .m4a en .3gp, parce que c’est ce qu’a identifié PHP), au lieu de zipper le fichier suspect, mais:
- je ne sais pas si ça fonctionne correctement ensuite de simplement changer la terminaison d’un conteneur;
- c’est chiant parce que M4A c’est identifié comme un conteneur audio, alors que 3GP c’est audio et vidéo (donc pas le même player).
ARNO*
Le 20 nov. 2019 à 21:00, Franck <spip.franck@lien-d-amis.net> a écrit :
Hello
Possible que je me trompe, mais un .m4a est un "conteneur", c’est-à-dire qu'il peut contenir aussi bien un fichier audio au format aac, que à un autre format (je ne sais plus trop les possibilités).
VLC (par exemple) ne te dit rien de plus concernant les codecs de ton fichier ?Sinon concernant un commit, je vais faire un complément à super b_b qui à déjà répondu sur ce point
Pour la version "truck" (spip 3.3 actuellement), le plugin-dist de medias est là:
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_core_/plugins/medias/base/typedoc.phpPour la version de spip 3.2, c'est ici:
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_core_/branches/spip-3.2/plugins/medias/base/typedoc.phpSinon, tu as également l'option de git, et c'est ici que cela se trouve :
https://git.spip.net/SPIP/mediasFranck
-----Message d'origine-----
De : Arnaud Martin <arno@rezo.net>
Envoyé : mercredi 20 novembre 2019 12:53
À : Bruno Bergot <bruno@eliaz.fr>
Cc : Spip Liste <spip-zone@rezo.net>
Objet : Re: [SPIP Zone] (sans objet)OK.
Problème beaucoup plus chiant:
- j’ai deux fichiers .m4a. L’un est téléchargé du Web, et quand je l’ouvre dans un éditeur de texte, je vois qu’il commence par quelques caractères bizarres puis:
ftypM4A- j’ai un second fichier .m4a. Celui-ci est fabriqué par l’application microphone d’un smartphone Android. Quand je regarde dans le fichier, ça commence avec:
ftyp3gp4Du coup, le premier, quand je demande à PHP de me dire son MIME, il répond « audio/x-m4a».
Le second, catastrophe, ça me dit: «video/3gpp». Or, c’est bien de l’audio (puisque fichier .m4a, d’ailleurs).Arg.
Arnaud
Le 20 nov. 2019 à 12:07, Bruno Bergot <bruno@eliaz.fr> a écrit :
Hop,
Le 20/11/2019 à 10:53, Arnaud Martin a écrit :
Salut,
Impossible d’uploader un fichier AAC sur un hébergement Gandi. J’ai trouvé que Gandi identifiait les fichiers .aac avec le MIME "audio/x-hx-aac-adts ».
Du coup ça fonctionne en ajoutant le $mime_alias suivant dans medias/base/typedoc.php:
'audio/x-hx-aac-adts' => 'audio/mp4a-latm'
=> Est-ce la bonne méthode pour corriger ce comportement de Gandi?Oui, ça semble légitime comme patch, cf :
https://github.com/symfony/symfony/pull/31565/files
=> Si c’est le cas, où est-ce que je peux commiter ce patch? Je ne pige pas la structure de _core_ sur zone.
Ici https://zone.spip.net/trac/spip-zone/browser/_core_/plugins/medias/ pour la version de dev (3.3). et là pour la 3.2 si on confirme qu'il faut reporter dans la branche stable https://github.com/symfony/symfony/pull/31565/files
++
b_b
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone