Sur d’autres sites (12128)

• Evolution #3119 (Nouveau) : Développer le classement des objets de SPIP par Glissé/lâché

  13 décembre 2013, par realet RealET

  Possibilité de classer des articles par drag’n drop dans l’interface privée, par exemple avec sortable ( http://jqueryui.com/sortable/ ) ou mêmes les images et documents, selon ce même principe (une démo http://blog.arnaud-k.fr/demos/jquery-drag-n-drop/ )

  Analyse¶

  Il y a déjà une balise #RANG qui calcule le numéro de titre s’il y en a un (ça affiche la partie numéro de numéro point espace titre).
  Idéalement, et pour assurer une bonne transition, il faudrait sans doute :

  1. Créer un champ rang
  2. modifier la balise rang en conséquence
  3. Enregistrer le numéro du titre dans le champ rang
  4. Et que l’opération de drag’n’drop :
     • modifie les champs rang impactés
     • et enregistre aussi le numéro point espace dans les titres pour rétro compatibilité (pouvoir débrayer ça par un define dans mes_options)
  5. Et rajouter un bouton pour supprimer le classement

  Et prévoir que dans les boucles, par rang !par date puisse fonctionner correctement si rang à NULL.

  Discussion originale : http://thread.gmane.org/gmane.comp.web.spip.devel/64769

• FFmpeg streaming stuck few minutes after start [closed]

  19 février, par josue ramirez

  Sorry for my english ! :D

  


  I'm trying to make a live video stream from my webcam with ffmpeg using Node.

  


  I get the images or frames from ffmpeg via pipe1 on the stdout event and send them via a socket-io client to my angular app to play the stream.

  


  So far the stream starts fine and my angular app can play it fine, but after a certain time (8 minutes or so) ffmpeg stops sending data and the stream in my angular app stops and if I want to start the webcam again it's not possible anymore because it's apparently occupied by another process. I've been trying to figure out what's going on and what I've noticed is that the ffmpeg process just stops and the process is no longer visible with the top command (ubuntu), but the child process in node still shows a ffmpeg process as if it were a zombie process.

  


  I've tried running ffmpeg from the terminal to save an mp4 file with the stream and in that case there is no problem, the recording doesn't stop even using pipe1. Only when I run ffmpeg from my Node app, the error occurs.

  


  Does anyone have any idea what could be going on ?

  


  This command is the one that is executed to send the data through pipe1 both from node and from the terminal but it only stops in Node

  


  ffmpeg -f v4l2 -input_format mjpeg -video_size 800x600 -i /dev/video0 -q:v 4 -f image2pipe pipe1


  


  The same thing happens when saving an mp4 video only in Node it fails

  


  ffmpeg -f v4l2 -input_format mjpeg -video_size 800x600 -i /dev/video0 -q:v 4 video.mp4


  


  This is my function that starts the streaming

  


  export const startCamera = () => {
    logger.info('Starting camera ', cameraName);

    const inputFormat = process.platform === 'win32' ? 'dshow' : 'v4l2';

    const ffmpegArgs = [
        '-f', inputFormat, // Formato de entrada según la plataforma
    ];

    if (process.platform === 'linux') {
        ffmpegArgs.push(
            '-input_format', 'mjpeg',  // Especificar el formato antes de video_size
            '-video_size', '800x600',  // Tamaño de la imagen
        );
    }
    
    ffmpegArgs.push(
        '-i', cameraName,    // Dispositivo de entrada
        '-vf', 'fps=15',     // Fotogramas por segundo
        '-q:v', '10',        // Calidad de video
        '-f', 'image2pipe',  // Formato de salida
        'pipe:1'             // Salida por stdout
    );

    try {
        logger.info('FFmpeg command: ffmpeg', ffmpegArgs.join(' '));
        ffmpeg = spawn('ffmpeg', ffmpegArgs);
        let cameraOpen = false;
        // Enviar los datos del fotograma a través del WebSocket
        ffmpeg.stdout.on('data', (chunk) => {
            logger.debug(`Sending chunk of ${chunk.length} bytes`);
            if (!cameraOpen) {
                cameraOpen = true;
                serialConnection.connect();
                logger.info('Camera started!!');
            }

            if (streamWS.isActive()) {
                streamWS.send(chunk);
            }
        });
        // Manejo de errores
        ffmpeg.stderr.on('error', (data) => {
            logger.error('FFmpeg Error:', data.toString());
        });

        ffmpeg.on('close', async () => {
            logger.info('Camera closed....', cameraName);
            if (!cameraOpen) {
                await commandWS.send(
                    {
                        command: COMMANDS.START_STREAM,
                        isError: true,
                        response: `Error al intentar iniciar la camara ${cameraName}, verificar que la camara se encuentre bien conectada.`,
                    },
                    COMMANDS_EVENTS.ROBOT_RESPONSE
                );
            }
            cameraOpen = false;
            await serialConnection.close();
            stopCamera();
            await streamWS.disconnectWS();
        });
    } catch (e) {
        logger.error('Error tryng to start the camera...', e);
    }
};


  


• Anomalie #4049 (Nouveau) : Double authentification LDAP

  21 novembre 2017, par svpip -

  Version SPIP utilisée : 3.0.26 [23574]¶

  Lors d’une première authentification LDAP, l’utilisateur est amené à soumettre 2 fois son identité via le formulaire adhoc (#LOGIN_PUBLIC ou #LOGIN_PRIVE) pour valider son action, après un premier message indiquant "Erreur de mot de passe.".
  Lors d’une seconde authentification LDAP, ce même utilisateur, à présent référencé dans la table spip_auteurs, n’est soumis qu’à une seule demande de formulaire.
  Pour palier à cette anomalie "non bloquante" (la première), 2 solutions vérifiées :

  - soit peupler (si possible) en amont la base spip_auteurs
  - soit passer un parametre=valeur dans l’url lors de l’authentification qu’il convient de récupérer depuis config/ldap.php pour déclencher l’appel au LDAP.

  Problème de la "double identification" évoqué sur forum SPIP :
  voir https://forum.spip.net/fr_263478.html?debut_forums=%40266046#forum266046

  ---

  Tests non réalisés sur SPIP :
  3.1.7 [23768]
  3.2.0 [23778]

  Ces versions comportent des erreurs natives concernant la gestion LDAP, qu’il est néanmoins possible de contourner facilement.
  Voir tickets :

  https://core.spip.net/issues/3918
  https://core.spip.net/issues/3919