Recherche avancée

Sur d’autres sites (6544)

• Displaying YUV420 data using Opengles shader is too slow

  28 novembre 2012, par user1278982

  I have a child thread called A to decode video using ffmpeg on iPhone 3GS, another thread called B to display yuv data, in thread B, I used glSubTexImage2D to upload Y U V textures, and then convert yuv data to RGB in shader, but the frame rate in the decode thread is only 15fps.Why ?

  Update :
  The frame size is 720 * 576.
  I also found something interesting that if I didn't start the thread displaying the YUV data, the frame rate calculated in the decode thread is 22 fps,otherwise 15 fps.So I think that my displaying method must be inefficient.the code as below.

  I have a callback in the decode thread :

  typedef struct _DVDVideoPicture
  
  {
  
     char *plane[4];
  
     int iLineSize[4];
  
  }DVDVideoPicture;
  
  
  
  void YUVCallBack(void *pYUVData, void *pContext)
  
  {
  
     VideoView *view = (VideoView *)pContext;
  
     [view.glView copyYUVData:(DVDVideoPicture *)pData];
  
     [view calculateFrameRate];
  
  }

  The copyYUVData method extract the y u v planes separately. The following is displaying thread method.

• "Moov Atom not Found " while converting .m4a into .mp3 audio file ?

  22 juillet 2021, par Comrade Shiva

  when i was converting iphone Audio recording .m4a file into .mp3 format at that time i got error "Moov Atom not found" showing on the screen,,,,
so i tried to check this error on internet ,found that some ffmpeg commands and recover_mp4's commands but same error showing on the screen ,,,,
it may be my Audio file was damaged so any solution to recover the audio file ,,,,,
recover_mp4.exe showing some commands and claiming to recover file but in my lappy its not workable When ffmpeg is used
when recover_mp4 is used

  


• Evolution #4105 : Constante ou config ?

  28 février 2018, par RastaPopoulos ♥

  Du coup maintenant on a trois discussions ouvertes sur les config, le ticket de Placido, le fil sur la liste emails, et ce ticket…

  b_b attention, dans l’idée de Maieul la constante est inversement prioritaire, et non pas à chercher en dernier recours.

  Mais mon avis c’est que les deux sont un peu de la merde. :D

  Déjà il ne faut pas comparer constantes et form de config, mais constante et meta (= une config gardée en mémoire en base). On a une API lire_config() et ecrire_config(), ça ne vient pas forcément que d’un formulaire avec interface humaine.

  L’avantage des constantes, c’est le déploiement, c’est défini et activé à chaque hit et donc pour l’exécution complète de tout ce qui suit. Ce qui est un énorme avantage pour vraiment activer des choses depuis un plugin (ou le mes_options général).
  L’inconvénient c’est que c’est un peu de la merde, vu que ça ne peut se surcharger qu’une seule fois et c’est super compliqué si plusieurs plugins chercher à faire des choix.

  L’avantage des config en base, c’est que c’est une API à nous, et qui peut être réécrite à tout moment. C’est beaucoup plus souple, et ça permet aussi des valeurs plus complexes.
  L’inconvénient c’est que c’est un peu de la merde : ça ne concerne qu’un enregistrement fixé en base. Et donc pas à chaque hit ! Du coup si un plugin personnalise une valeur lors de son installation, bah un form de config peut l’avoir réenregistré autrement ensuite, ou n’importe quel autre plugin en PHP avec ecrire_config(). Du coup c’est vraiment de la merde pour le déploiement contrôlé de variables de config !

  Mon idée est donc qu’il manque clairement quelque chose pour avoir une API complète de gestion des configurations.
  1) on doit pouvoir le garder en mémoire (chez nous en BDD)
  2) mais on doit AUSSI pouvoir le définir à chaque hit !

  Or il se trouve que le tableau des metas (donc des configs !) est de toute façon déjà chargé au démarrage de SPIP et trimballé entier durant tout le hit PHP !

  Du coup pour moi la solution la plus propre c’est qu’il y ait un nouveau pipeline "lire_config" qui permettent de modifier le tableau des configs après qu’il ait été initialisé depuis la base. Du coup on aurait bien les valeurs venant de la base (form de config ou autre), MAIS AUSSI n’importe qui pourrait forcer la valeur d’une config à chaque hit, exactement comme on le fait pour les constantes. Et du coup vu que pipeline, bah on pourrait le surcharger plusieurs fois, suivant le path, etc, easy et simple à comprendre pour tout le monde.

  monplugin_lire_config($metas) 
      // Je force une config
      $metas[’albums’][’activer_trucmuche’] = true ;
      return $metas ;