Recherche avancée

Sur d’autres sites (7124)

• Merge commit ’23f741f79327e31be7b2a75ebb2e02111e06e52f’

  28 mai 2014, par Michael Niedermayer

  Merge commit ’23f741f79327e31be7b2a75ebb2e02111e06e52f’
  * commit ’23f741f79327e31be7b2a75ebb2e02111e06e52f’ :
  
    matroskadec : parse the channel layout mask for FLAC
  Conflicts :
  
  	libavformat/oggparsevorbis.c
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/Makefile
  • [DH] libavformat/flacdec.c
  • [DH] libavformat/matroskadec.c
  • [DH] libavformat/oggdec.h
  • [DH] libavformat/oggparsecelt.c
  • [DH] libavformat/oggparseflac.c
  • [DH] libavformat/oggparseogm.c
  • [DH] libavformat/oggparseopus.c
  • [DH] libavformat/oggparsespeex.c
  • [DH] libavformat/oggparsetheora.c
  • [DH] libavformat/oggparsevorbis.c
  • [DH] libavformat/oggparsevp8.c

• FFMPEG HTTP protocol closing after first packet

  27 août 2019, par rusty

  I’m trying to send a live video stream from my webcam to FFMPEG via the HTTP protocol. However after the first packet is sent FFMPEG closes, but does indeed output a fully playable video. As my intention.

  After going over the documentation for the protocol I thought mulitiple_requests would stop this behavior which it did not. After searching online for a few hours I can not find an example specific to my scenario. i.e. receiving a network stream over HTTP.

  Code running on the client-side :

  var xhttp=new XMLHttpRequest;
  
  
  
  if (navigator.mediaDevices) {
  
  
  
      var constraints = { audio: true, video: true };
  
  
  
      navigator.mediaDevices.getUserMedia(constraints)
  
        .then(function(stream) {
  
          var mediaRecorder = new MediaRecorder(stream);
  
          m = mediaRecorder;
  
          m.start();
  
          m.ondataavailable=e=>{
  
            xhttp.open("POST","http://localhost:8080");
  
            xhttp.send(e.data);
  
          }
  
          setInterval(function(){
  
            m.requestData();
  
          },2000);
  
        }).catch(function(error) {
  
          console.log(error.message);
  
        });
  
  }

  The FFMPEG command I have tried thus far :

  ffmpeg -listen 1 -multiple_requests -i http://localhost:8080 file.webm

  Maybe this is not possible with FFMPEG ? If this is the case then it appears the only solution would be to put this command in a loop and keep appending to the output.

• 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 ;