Recherche avancée

Médias (91)

Autres articles (79)

  • D’autres logiciels intéressants

    12 avril 2011, par

    On ne revendique pas d’être les seuls à faire ce que l’on fait ... et on ne revendique surtout pas d’être les meilleurs non plus ... Ce que l’on fait, on essaie juste de le faire bien, et de mieux en mieux...
    La liste suivante correspond à des logiciels qui tendent peu ou prou à faire comme MediaSPIP ou que MediaSPIP tente peu ou prou à faire pareil, peu importe ...
    On ne les connais pas, on ne les a pas essayé, mais vous pouvez peut être y jeter un coup d’oeil.
    Videopress
    Site Internet : (...)

  • MediaSPIP Player : problèmes potentiels

    22 février 2011, par

    Le lecteur ne fonctionne pas sur Internet Explorer
    Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
    Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...)

  • L’agrémenter visuellement

    10 avril 2011

    MediaSPIP est basé sur un système de thèmes et de squelettes. Les squelettes définissent le placement des informations dans la page, définissant un usage spécifique de la plateforme, et les thèmes l’habillage graphique général.
    Chacun peut proposer un nouveau thème graphique ou un squelette et le mettre à disposition de la communauté.

Sur d’autres sites (5028)

  • VLC - Transcoding a 4k Picture to a Transport Stream

    20 janvier 2020, par gdogg371

    After a lot of crying, stamping my feet and pulling my hair out, I have now managed to transcode my 4k capture card into an RTP MPEG2 transport stream using VLC, as per the below :

    vlc dshow:// :dshow-vdev="Video (00 Pro Capture HDMI 4K+)" :dshow-adev="Audio (2- 00 Pro Capture HDMI 4K+)" :dshow-threads=8 :dshow-aspect-ratio=16\:9 :dshow-size="2160x1080" :dshow-pixel_format=NV12 :dshow-tune=film :dshow-preset=veryslow :dshow-vcodec=hevc_nvenc :dshow-fps=50 :dshow-crf=0 :dshow-acodec=mp4a :dshow-stereo-mode=5 :dshow-force-surround-sound=0 :dshow-ab=128 :dshow-samplerate=44100 :no-dshow-config :live-caching=100 :sout=#transcode{venc=ffmpeg,vcodec=mp2v,threads=8,aspect=16:9,width=2160,height=1080,fps=50,aenc=ffmpeg,acodec=a52,ab=1500,channels=6,samplerate=48000,soverlay}:rtp{dst=192.168.1.15,port=8554,mux=ts}

    My remaining issue though is, that I cannot get a 4k picture to transcode cleanly. I get horrendous stutter of the picture if I try and 2160x1080 at 50 fps is the best I have been able to achieve.

    The Magewell 4k card I have been using runs natively at 3840x2160 at 50fps, outputting a raw video signal. Is there some kind of built in limitation of MPEG2 where it cannot handle a 4k signal that I am not aware of ?

    Can anyone suggests some amendments to the above, so as to process a 4k signal properly ?

    Thanks

  • Color shift when encoding DNxHD QuickTime Video [closed]

    13 mai 2013, par Yani

    I have been tasked with developing the Editorial submission pipeline for an animated feature film project. Our studio is based on Windows 7 and the Editing team is using Avid Media Composer. We have decided to go with the "fast import" approach for bringing media into Avid. My tools take some frames and encode DNxHD QuickTime videos from them, then we write out an ALE document to assist with the batch importing of the delivery content. We call it the "fast import" approach because Avid only has to change the video container from MOV to MXF and it doesn't have to do any real encoding which is usually the time consuming part.

    I have tried comparing DNxHD QuickTime videos encoded using FFmpeg, RVIO and Nuke. The color in each video is different but the only one that matches the video created by importing frames directly into the Avid is the video generated by Nuke. I have heard the color shift may be caused by the way the Apple QuickTime libraries manage color on the Windows platform, is this true ? If so, how is Nuke able to produce the correct output ? Also, is there any way I can produce the correct output using FFmpeg or RVIO ?

  • feed raw yuv frame to ffmpeg with timestamp

    30 août 2014, par hawk_with_wind

    I’ve trying pipe audio and video raw data to ffmpeg and push realtime stream through RTSP protocol on android.
    the command-line is look like this

    "ffmpeg -re -f image2pipe -vcodec mjpeg -i "+vpipepath
    + " -f s16le -acodec pcm_s16le -ar 8000 -ac 1 -i - "
    + " -vcodec libx264 "
    + " -preset slow -pix_fmt yuv420p -crf 30 -s 160x120 -r 6 -tune film "
    + " -g 6 -keyint_min 6 -bf 16 -b_strategy 1 "
    + " -acodec libopus -ac 1 -ar 48000 -b:a 80k -vbr on -frame_duration 20 "
    + " -compression_level 10 -application voip -packet_loss 20 "
    + " -f rtsp rtsp://remote-rtsp-server/live.sdp";

    I’m using libx264 for video codec and libopus for audio codec.
    the yuv frames are feed through a named pipe created by mkfifo, the pcm frames are feed through stdin.

    It works, and I can fetch and play the stream by ffplay. But there is serverely audio/video sync issue. Audio is 5 10 seconds later than video.
    I guess the problem is both yuv frame and pcm frame doesn’t have any timestamp on them. FFmpeg add timestamp when it feed with the data. but audio/video capture thread is impossible to run at the same rate.
    Is there a way to add timestamp to each raw data frame ? (something like PST/DST ?)

    the way I used was from this thread :
    Android Camera Capture using FFmpeg