Recherche avancée

Médias (0)

Mot : - Tags -/flash

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (42)

  • Déploiements possibles

    31 janvier 2010, par

    Deux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
    L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
    Version mono serveur
    La version mono serveur consiste à n’utiliser qu’une (...)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 is the first MediaSPIP stable release.
    Its official release date is June 21, 2013 and is announced here.
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

Sur d’autres sites (4506)

  • Anomalie #3686 : formulaire_editer_article_verifier : vérification incomplète

    21 février 2016, par Peet du

    La ligne https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157, vient de
    https://core.spip.net/issues/2508.

    L’avantage (?) de https://core.spip.net/projects/spip/repository/revisions/19075, c’est que ça gère aussi bien les cas de création et de modification d’un article dans une rubrique interdite.

    J’ai donc testé mon patch avec le cas d’un admin restreint et il n’y a pas d’effet de bord : ceci grâce à autoriser_article_modifier().

    Il est donc question ici de compléter/corriger cette demande : il doit être possible de voir et de modifier, même si il est interdit de créer.

    Le bug que j’ai trouvé :

    C’est le cas qui se présente avec le plugin LIM

    1- un article ou des articles ont été créés dans une rubrique ;
    2- puis le webmestre décide plus tard d’interdire la création de nouveaux articles dans cette même rubrique, ceci grâce à une fonction du plugin LIM ;
    3- Mais si il n’est plus possible de créer un article dans cette rubrique, LIM gère le cas où l’auteur veut les modifier ses articles présents dans cette rubrique.

    Donc le bug soulevé vient du fait que le plugin LIM surcharge l’autorisation autoriser_rubrique_publierdans(). Plus exactement, il ajoute une condition.
    voir http://zone.spip.org/trac/spip-zone/changeset/95014/_plugins_/lim/trunk/lim_autorisations.php.

    Je précise que cette fonctionnalité du plugin LIM pose un problème seulement avec l’objet Article. Pas avec les autres objets éditoriaux.

    Voilà. J’espère n’avoir rien oublié.

  • Anomalie #4308 (Nouveau) : Objet sans statut : problème avec objet_instituer()

    7 mars 2019, par tcharlss (*´_ゝ`)

    Le contexte

    J’ai un objet éditorial sans statut, et avec une date.
    La date est bien déclarée dans declarer_tables_objets_sql : 'date' => 'date'
    Le formulaire d’édition permet de modifier directement la date, sans avoir à passer par #FORMULAIRE_DATER.

    Problème

    La date saisies par l’utilisateur n’est pas enregistrée, ça remet systématiquement la date actuelle.
    À la toute fin des traitements, dans la fonction objet_editer_heritage(), on retrouve bien la date correcte dans le tableau des champs à modifier qui est transmis à sql_updateq().
    Par contre il y également le champ ’statut’, hors il n’a rien à faire là : ça provoque une erreur SQL.

    Voici ce que renvoie var_dump($champs) :

    array (size=2)
      ’statut’ => string ’’ (length=0)
      ’date’ => string ’2019-01-22 00:00:00’ (length=19)
    

    C’est en amont dans objet_instituer() que le tabeau des champs à modifier est contruit.
    Il semble qu’il y a des tests effectués pour vérifier la présence du champ de statut dans la table, pourtant même en son absence il se retrouve dans la liste.
    Je n’arrive pas à mettre le doigt sur l’endroit exact où ça coince, RastaPopoulos me dit que ça doit se jouer vers la ligne 333

    Solution

    Pas vraiment une solution, mais ça montre bien que c’est l’absence de statut qui fait tout planter : quand je retire la clé ’statut’ dans au moyen du pipeline pre_edition, ça marche.

  • RTSP to HLS conversion with error on some devices

    2 septembre 2024, par Wallace Ketler

    I'm trying to convert, on a node server, RTSP IP camera devices to HLS to run livestreams on the web. The following code works well for some RTSP devices, but for others I encounter problems.

    


       function startLive(rtspUrl, outputDir, id_local, id_camera) {
        return new Promise((resolve, reject) => {
            const processKey = `${id_local}_${id_camera}`;
            if (ffmpegProcesses[processKey]) {
                return reject(new Error('Conversão já está em andamento para esta câmera'));
            }
        
            const process = ffmpeg(rtspUrl)
                .inputOptions([
                    '-rtsp_transport', 'tcp',
                    '-fflags', 'nobuffer',
                    '-max_delay', '1000000',
                    '-analyzeduration', '1000000',
                    '-probesize', '1000000',
                    '-flush_packets', '1',
                    '-avioflags', 'direct'
                ])
                .outputOptions([
                    '-c:v', 'libx264',
                    '-preset', 'ultrafast',
                    '-tune', 'zerolatency',
                    '-c:a', 'aac',
                    '-hls_time', '10',
                    '-hls_flags', 'delete_segments',
                    '-hls_list_size', '5',
                    '-hls_wrap', '5',
                    '-strict', '-2'
                ])
                .output(path.join(outputDir, 'stream.m3u8'))
                .on('start', (commandLine) => {
                    console.log('Spawned FFmpeg with command: ' + commandLine);
                })
                .on('stderr', (stderrLine) => {
                    console.log('FFmpeg stderr: ' + stderrLine);
                })
                .on('end', () => {
                    console.log('Conversão concluída');
                    delete ffmpegProcesses[processKey]; 
                    resolve();
                })
                .on('error', (err, stdout, stderr) => {
                    console.error('Erro na conversão', err);
                    console.error('FFmpeg stdout:', stdout);
                    console.error('FFmpeg stderr:', stderr);
                    delete ffmpegProcesses[processKey]; 
                    reject(err);
                })
                .run();
    
            ffmpegProcesses[processKey] = process; 
        });
    }


    


    When the conversion succeeds, it continues indefinitely with the logs :

    


    FFmpeg stderr: frame=   61 fps= 48 q=13.0 size=N/A time=00:00:02.03 bitrate=N/A dup=60 drop=0 speed= 1.6x    
FFmpeg stderr: frame=   75 fps= 42 q=17.0 size=N/A time=00:00:02.52 bitrate=N/A dup=62 drop=0 speed=1.41x    
FFmpeg stderr: frame=   91 fps= 39 q=16.0 size=N/A time=00:00:03.04 bitrate=N/A dup=65 drop=0 speed=1.31x    
FFmpeg stderr: frame=  108 fps= 38 q=15.0 size=N/A time=00:00:03.60 bitrate=N/A dup=68 drop=0 speed=1.27x    
FFmpeg stderr: frame=  121 fps= 36 q=24.0 size=N/A time=00:00:04.03 bitrate=N/A dup=70 drop=0 speed=1.21x    
FFmpeg stderr: frame=  138 fps= 36 q=16.0 size=N/A time=00:00:04.60 bitrate=N/A dup=73 drop=0 speed= 1.2x    
FFmpeg stderr: frame=  152 fps= 35 q=17.0 size=N/A time=00:00:05.08 bitrate=N/A dup=75 drop=0 speed=1.17x    
FFmpeg stderr: frame=  168 fps= 35 q=16.0 size=N/A time=00:00:05.60 bitrate=N/A dup=78 drop=0 speed=1.15x    
FFmpeg stderr: frame=  183 fps= 34 q=21.0 size=N/A time=00:00:06.11 bitrate=N/A dup=80 drop=0 speed=1.13x    
FFmpeg stderr: frame=  198 fps= 34 q=16.0 size=N/A time=00:00:06.60 bitrate=N/A dup=83 drop=0 speed=1.12x    
FFmpeg stderr: frame=  215 fps= 33 q=16.0 size=N/A time=00:00:07.16 bitrate=N/A dup=86 drop=0 speed=1.11x    
FFmpeg stderr: frame=  230 fps= 33 q=16.0 size=N/A time=00:00:07.66 bitrate=N/A dup=88 drop=0 speed= 1.1x    
FFmpeg stderr: frame=  246 fps= 33 q=19.0 size=N/A time=00:00:08.20 bitrate=N/A dup=91 drop=0 speed= 1.1x    


    


    And with the segments saved in the folder configured as output. But for certain devices, after creating the stream.m3u8 file and saving the first segment, the conversion is considered finished and falls into .on('end') . The error log is as follows :

    


    FFmpeg stderr: frame=    0 fps=0.0 q=0.0 size=N/A time=00:00:01.12 bitrate=N/A speed=2.08x    
FFmpeg stderr: [hls @ 0x55e00dfc4380] Opening 'my_path/stream0.ts' for writing
FFmpeg stderr: [hls @ 0x55e00dfc4380] Opening 'my_path/stream.m3u8.tmp' for writing
FFmpeg stderr: frame=    0 fps=0.0 q=0.0 Lsize=N/A time=00:00:01.37 bitrate=N/A speed= 2.5x    
FFmpeg stderr: video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
FFmpeg stderr: [aac @ 0x55e00dfff840] Qavg: 65536.000
FFmpeg stderr: 
Conversão concluída


    


    The muxing overhead: unknown only appears when the error occurs and the conversion is complete.

    


    I've already tried changing the video and audio encoders, as well as the various input and output parameters of the conversion. I also tried updating ffmpeg (it's already on the latest version, using fluent-ffmpeg, "fluent-ffmpeg": "^2.1.3",)

    


    I would like to understand why this happens on some devices and how to fix it. Thanks.