Recherche avancée

Médias (3)

Mot : - Tags -/collection

Autres articles (53)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

Sur d’autres sites (6377)

  • Flush & Latency Issue with Fragmented MP4 Creation in FFMPEG

    30 septembre 2015, par galbarm

    I’m creating a fragmented mp4 for html5 streaming, using the following command :

    -i rtsp://172.20.28.52:554/h264 -vcodec copy -an -f mp4 -reset_timestamps 1 -movflags empty_moov+default_base_moof+frag_keyframe -loglevel quiet -
    1. "-i rtsp ://172.20.28.52:554/h264" because the source is h264 in rtp packets stream from an ip camera.
      For the sake of testing, the camera is set with GOP of 1 (i.e. all frames are key frames)
    2. "-vcodec copy" because I don’t need transcoding, only remuxing to mp4.
    3. "-movflags empty_moov+default_base_moof+frag_keyframe" to create a fragmented mp4 according to the media source extensions spec.
    4. "-" at the end in order to output the mp4 to stdout. I’m grabbing the ouput and sending it to the webclient through web sockets.

    Everything is working well, expect for a latency issue which I’m trying to solve.
    If I’m logging every time a data is coming in from stdout, with the timestamp of arrival, I get this output :

    16/06/2015 15:40:45.239 got data size = 24

    16/06/2015 15:40:45.240 got data size = 7197

    16/06/2015 15:40:45.241 got data size = 32768

    16/06/2015 15:40:45.241 got data size = 4941

    16/06/2015 15:40:45.241 got data size = 12606

    16/06/2015 15:40:45.241 got data size = 6345

    16/06/2015 15:40:45.241 got data size = 6339

    16/06/2015 15:40:45.242 got data size = 6336

    16/06/2015 15:40:45.242 got data size = 6361

    16/06/2015 15:40:45.242 got data size = 6337

    16/06/2015 15:40:45.242 got data size = 6331

    16/06/2015 15:40:45.242 got data size = 6359

    16/06/2015 15:40:45.243 got data size = 6346

    16/06/2015 15:40:45.243 got data size = 6336

    16/06/2015 15:40:45.243 got data size = 6338

    16/06/2015 15:40:45.243 got data size = 6357

    16/06/2015 15:40:45.243 got data size = 6357

    16/06/2015 15:40:45.243 got data size = 6322

    16/06/2015 15:40:45.243 got data size = 6359

    16/06/2015 15:40:45.244 got data size = 6349

    16/06/2015 15:40:45.244 got data size = 6353

    16/06/2015 15:40:45.244 got data size = 6382

    16/06/2015 15:40:45.244 got data size = 6403

    16/06/2015 15:40:45.304 got data size = 6393

    16/06/2015 15:40:45.371 got data size = 6372

    16/06/2015 15:40:45.437 got data size = 6345

    16/06/2015 15:40:45.504 got data size = 6352

    16/06/2015 15:40:45.571 got data size = 6340

    16/06/2015 15:40:45.637 got data size = 6331

    16/06/2015 15:40:45.704 got data size = 6326

    16/06/2015 15:40:45.771 got data size = 6360

    16/06/2015 15:40:45.838 got data size = 6294

    16/06/2015 15:40:45.904 got data size = 6328

    16/06/2015 15:40:45.971 got data size = 6326

    16/06/2015 15:40:46.038 got data size = 6326

    16/06/2015 15:40:46.105 got data size = 6340

    16/06/2015 15:40:46.171 got data size = 6341

    16/06/2015 15:40:46.238 got data size = 6332

    As you can see, the first 23 lines (which contain data of about 1.5 secs of video) are arriving almost instantly, and then the delay between each 2 consecutive lines is 70ms which makes sense because the video is 15 frames per sec.
    This behavior introduces a latency of about 1.5 sec.

    It looks like a flushing issue because I don’t see any reason why would ffmpeg need to hold the first 23 frames in memory, especially since each frame is a fragment of it’s own inside the mp4.
    I couldn’t however, find any method that would cause ffmpeg to flush this data faster.

    Has anyone got a suggestion ?

    I’d like to note that this is a follow up question to this one :
    Live streaming dash content using mp4box

  • How to feed fragmented mp4 as input to ffmpeg ?

    5 juin 2021, par hd312

    I have scenario where I need to process fragmented mp4 as input to ffmpeg. Is this supported ? If so, are there any options flags I need to use to achieve this.

    


  • Anomalie #3536 : Incompatibilité avec le navigateur Lynx si forcer_lang=true

    31 août 2015, par Raphaël MELIOR

    b b a écrit :

    Pour info, je viens de tester avec Lynx 2.8.8pre4-1 sur un SPIP 3.0.20 qui utilise forcer_lang et je ne reproduis pas le bug.

    Bonjour,

    Pour ma part j’utilises SPIP 2.1.17-1+deb7u4 (Debian), Lynx Version 2.8.8pre.4
    Le problème existe aussi avec une install de tests SPIP 3.0.14-1 (Debian)

    J’ai effectué un test avec la version trouvée sur le site de spip :

    SPIP 3.0.20 + écran de sécurité 1.2.2
    Niveau options j’ai mis par défaut (sqlite notamment)

    Les plugins ci-dessous sont chargés et activés dans le répertoire plugins-dist/.
    Brèves 1.3.6 - stable
    Compagnon 1.4.1 - stable
    Compresseur 1.8.11 - stable
    Dump 1.6.9 - stable
    Forum 1.8.40 - stable
    Images 1.1.10 - stable
    jQuery UI 1.8.21 - stable
    MediaBox 0.8.11 - stable
    Medias 2.7.66 - stable
    Mots 2.4.13 - stable
    Organiseur 0.8.12 - stable
    Pétitions 1.4.6 - stable
    Porte plume 1.12.4 - stable
    Révisions 1.7.9 - stable
    SafeHTML 1.4.1 - stable
    Sites 1.7.13 - stable
    Squelettes par Rubrique 1.1.1 - stable
    Statistiques 0.4.28 - stable
    Support vieux navigateurs 1.2.0 - stable
    SVP 0.80.26 - stable
    TextWheel pour SPIP 0.8.30 - stable
    Urls Etendues 1.4.26 - stable
    Vertèbres 1.2.2 - stable

    Je crée le fichier config/mes_options.php avec "< ?php $GLOBALS[’forcer_lang’]=true ; ?>" écrit dedans.
    Pour le moment pas de problème, Lynx sur l’adresse de l’installation ( http://127.0.0.1/spip3/ ) fonctionne malgré le forcer_lang.

    Je crée un VirtualHost (Apache2) comme ceci :
    <virtualhost><br />        ServerName test-spip3.local<br />        DocumentRoot /var/www/spip3<br /></virtualhost>

    Je rajoute test-spip3.local dans /etc/hosts pour qu’il soit résolu en 127.0.0.1
    Je retouche aussi le paramètre "Adresse (URL) du site public" dans "Identité du site" pour "http://test-spip3.local" (lorsque j’ajoute un "/" à la fin il est automatiquement retiré à la validation).

    Lorsque je tente d’accéder à "http://test-spip3.local/" avec lynx cela redirige vers la fameuse adresse "http://test-spip3.local/./?lang=fr". Sans forcer_lang, pas de soucis.
    Lorsque j’éssaye à nouveau vers "http://127.0.0.1/spip3/" cela redirige vers "http://127.0.0.1/spip3/?lang=fr" qui fonctionne.

    Merci

Navigation