Recherche avancée

Sur d’autres sites (11129)

• ffmpeg from chrome native messaging host app not working

  9 juin 2014, par Moisés Olmedo

  OK, this is what I got, I’m using native messaging to fire a c++ program from a chrome extension in Windows.
  This c++ program (ehost.exe) creates a ffmpeg process for recording the input audio and saving it to mp3.
  I do this with the CreateProcess() function
  This works perfect when I open ehost.exe myself (double clicking it)
  but when I open it from my chrome extension (chrome.runtime.connectNative() ), the ffmpeg process opens but ffmpeg writes no output file, as if it didn’t have permissions...

  Anybody knows why ?
  This is the ehost.exe code for starting ffmpeg.exe

  static HANDLE startFFmpeg()
   {
       char cmd[] = "C:\Users\moizilla\Desktop\native\ffmpeg\bin\ffmpeg.exe -y -f dshow -i audio=\"Microphone (High Definition Aud\" -acodec libmp3lame C:\Users\moizilla\Desktop\native\kasdkddfodkadd.mp3";
       PROCESS_INFORMATION pi = {0};
       STARTUPINFO si={0};
       si.cb = sizeof(STARTUPINFO);
       if(CreateProcess(NULL, cmd, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi)){
           CloseHandle(pi.hThread);
           return pi.hProcess;
       }
       return NULL;
}

• Evolution #4115 (En cours) : export des metas du plugin MOTS

  20 mars 2018, par Arnaud Bérard

  Bonjour,
  Le plugin MOTS permet l’export de ses metas via le plugin ieconfig et la pipeline ieconfig_metas.

  La valeur de la meta exporté est actuellement ’mots’.

  Si pour un plugin squelette on souhaite ajouter un export (par exemple une structure de groupes/mots) en passant par la pipeline ieconfig, la clef du tableau doit OBLIGATOIREMENT être un prefixe de plugin (dans le cas présent ’mots’), les deux valeurs s’écrase dans le yaml généré.

  Je suggèrerais donc de faire comme dans le plugin menu et utiliser pour la description des metas exportables [’mots_meta’], ceci contourne le problème, permet d’avoir des exports et les metas.

  ceci ne devrait impacter que les concepteurs de squelettes qui utilise un fichier yaml ieconfig déjà généré antérieurement à cette évolution pour initialiser/installer leur squelette, il/elles devront le mettre à jour, avec la nouvelle definition…

• Revision 31381 : il y avait une GROSSE erreur : comme on fermait les élément dans la ...

  7 septembre 2009, par rastapopoulos@… — Log

  il y avait une GROSSE erreur : comme on fermait les élément

• dans la définition de l’entrée, on ne pouvait pas insérer le sous-menu éventuel DANS le
•  !!
  Il y a donc un gros changement pour ceux qui ont créé leur propre type d’entrée : les types qui ACCEPTE les sous-menus ne doivent pas fermer l’élément
• , c’est le plugin qui s’en occupera après avoir éventuellement insérer un sous-menu dedans.
  Pour les types qui refusent les sous-menus, la question ne se pose pas et il n’y a rien à changer.
  Cette modification est reportée dans la documentation :  http://www.spip-contrib.net/Ajouter-des-types-d-entrees-pour
  (cf. "Pourquoi la balise LI n’est pas fermée ?")