Recherche avancée

Médias (1)

Mot : - Tags -/Rennes

Autres articles (112)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Possibilité de déploiement en ferme

    12 avril 2011, par

    MediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
    Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)

Sur d’autres sites (12684)

  • avcodec/libsvtav1 : unbreak build with latest svtav1

    22 février, par Gyan Doshi
    avcodec/libsvtav1 : unbreak build with latest svtav1

    SVT-AV1 made a change in their public API in 988e930c but without a
    
version bump or any other accessible marker, thus breaking ffmpeg build
    
with current versions of SVT-AV1.
    

    They have finally bumped versions a month later, so check added.
    • [DH] libavcodec/libsvtav1.c

  • Random audio/video sync issue with libcamera-vid + ffmpeg on raspberry pi 3a+

    8 mai, par kepperi

    I have been working on camera software, which will stream live fullhd video to Cloudflare Stream via RTMPS protocol. Everything is mostly working nicely, but I have occasional A/V sync issues with the streams : Stream might start with correct A/V sync and it will stay correct until the end (1-2 h stream), but sometimes the A/V sync is misaligned like 1-2 sec so, that the audio is either behind or ahead of the video stream. And it will be like that until the end of the stream, then next stream might be just fine.

    


    I'm using libcamera-vid for the video and ffmpeg for the audio, muxing and sending all to Cloudflare. This is my command :

    


    libcamera-vid 
  --width 1920 --height 1080 --framerate 30 --timeout 0 
  --nopreview true --inline 1 --codec h264 --verbose 0 
  --intra 90 --bitrate 4000000 --output - | 
ffmpeg 
  -use_wallclock_as_timestamps 1 -loglevel error 
  -probesize 10M -analyzeduration 5M 
  -fflags +genpts -thread_queue_size 512 -f h264 -framerate 30 -i - 
  -thread_queue_size 8192 -itsoffset 0.7 
  -f alsa -channels 1 -ar 44100 -i hw:1,0 
  -c:v copy -c:a aac -b:a 96000 -fflags +genpts -async 1 -shortest -f flv - | 
( sleep 5; ffmpeg -re -i - -c copy -f flv "rtmps://live.cloudflare.com:443/live/..."


    


    So I can control initial A/V sync with -itsoffset and it is working, but still I encounter those random sync differences.

    


    I have also added the second ffmpeg command with 5 sec sleep to give the first ffmpeg process enough time to align with video and audio input before sending them to Cloudflare, but this seems not helping.

    


    I have also tried with Gstreamer, which fixed the AV issue completely, but it had weird glitches on video frames if the audio was enabled. Seemed like it tried to match the audio and video timestamps on fly and that caused warps/jumps and ghost frames on video. Audio was just fine.

    


    Here is my Gstreamer command (which will also have the same libcamera-vid piped in via fdsrc)

    


    GST_CLOCK_SYSTEM=1 gst-launch-1.0 -v
   fdsrc blocksize=524288 !
   h264parse config-interval=1 disable-passthrough=true !
   queue max-size-buffers=200 max-size-time=4000000000 max-size-bytes=0 !
   flvmux name=mux streamable=true latency=200 !
   queue max-size-buffers=200 max-size-time=4000000000 max-size-bytes=0 !
   rtmpsink sync=false location="rtmps://live.cloudflare.com:443/live/..."
   alsasrc device=hw:1,0 buffer-time=1000000 latency-time=200000 !
   audio/x-raw,rate=44100,channels=1,format=S16LE !
   queue leaky=downstream max-size-buffers=500 max-size-time=15000000000 max-size-bytes=0 !
   audioconvert ! audioresample ! avenc_aac bitrate=96000 ! aacparse !
   queue max-size-buffers=100 max-size-time=4000000000 max-size-bytes=0 ! mux.


    


    With Gstreamer, I have been experimenting different sizes of buffers, but no luck getting rid of the video glitches. If I remove audio from that gst-launch-1.0 command, video is just perfect.

    


    Hardware :

    


    


    I have also tried MUX instead of Cloudflare Stream, both acts identically so I guess the problem is not in receiving end encoding. This is also the reason I have not yet tried to "stream" into file.

    


    Currently I'm in a process of testing the libcamera-vid with raw yuv420 + ffmpeg but with ffmpeg encoding the video instead of just having encoded h264 from libcamera-vid. This is done with RPI4 since it has enough CPU for it.

    


    All help is appreciated !

    


  • Revision 31688 : anglais pour le plugin menus

    21 septembre 2009, par rastapopoulos@… — Log

    anglais pour le plugin menus

Navigation