Recherche avancée

Médias (1)

Mot : - Tags -/framasoft

Autres articles (38)

  • Pas question de marché, de cloud etc...

    10 avril 2011

    Le vocabulaire utilisé sur ce site essaie d’éviter toute référence à la mode qui fleurit allègrement
    sur le web 2.0 et dans les entreprises qui en vivent.
    Vous êtes donc invité à bannir l’utilisation des termes "Brand", "Cloud", "Marché" etc...
    Notre motivation est avant tout de créer un outil simple, accessible à pour tout le monde, favorisant
    le partage de créations sur Internet et permettant aux auteurs de garder une autonomie optimale.
    Aucun "contrat Gold ou Premium" n’est donc prévu, aucun (...)

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

Sur d’autres sites (5320)

  • avcodec/osq : avoid undefined negation

    4 février, par Michael Niedermayer
    avcodec/osq : avoid undefined negation

    Fixes : negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int') ; cast to an unsigned type to negate this value to itself
    
Fixes : 390646659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-5040277374435328
    

    Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/osq.c

  • avutil/aes : Don't use out-of-bounds index

    21 octobre 2022, par Andreas Rheinhardt
    avutil/aes : Don't use out-of-bounds index

    Up until now, av_aes_init() uses a->round_key[0].u8 + t
    
as dst of memcpy where it is intended for t to greater
    
than 16 (u8 is an uint8_t[16]) ; given that round_key itself
    
is an array, it is actually intended for the dst to be
    
in a latter round_key member. To do this properly,
    
just cast a->round_key to unsigned char*.
    

    This fixes the srtp, aes, aes_ctr, mov-3elist-encrypted,
    
mov-frag-encrypted and mov-tenc-only-encrypted
    
FATE-tests with (Clang-)UBSan.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavutil/aes.c

  • NodeJS piping with ffmpeg

    8 février 2014, par Gnap

    I wanted to do a HTTP live stream on a screen cast with using ffmpeg, nodejs and html5 . I wanted it to be as real time as possible. However, I find that my video received by the client was behind by 1 2 seconds (On Chrome/Chromium). I am using vp8/webm as my codec.

    I have eliminated the following factors as such :
    1) Network : I have tried serving and receiving the video file locally by stating the video source to be 127.0.0.1:PORT or localhost:PORT
    2) ffmpeg encoding speed:I have tried outputting the file locally, it the "delay" seems to be negligible.
    3) Chrome internal buffer. The buffer was accounted to be 0.07s 0.08s.

    On the nodeJS side, I have a child process that runs the ffmpeg command, and did a ffmpeg.stdout.pipe(res) ; <— ffmpeg is child_process.spawn(...)

    So it seems that the ffmpeg.std.pipe(res) of nodejs seems to be the one delaying the video stream. Am I correct in assuming so ? Is there anyway that I may reduce the delay ?

Navigation