Recherche avancée

Sur d’autres sites (11249)

• FFMPEG with dashjs

  14 avril 2017, par Dániel Kis

  I am going to create a live video & audio stream with ffmeg with libvpx-vp9 codec, and I want to view it from html5 browser with dashjs. But when the dashjs opens the video it seatches for chunks than not yet exits.

  Here is how I create the stream :

  VP9_LIVE_PARAMS="-speed 6 -tile-columns 4 -frame-parallel 1 -threads 8 -static-thresh 0 -max-intra-rate 300 -deadline realtime -lag-in-frames 0 -error-resilient 1"
  
  TARGET_PATH="/var/www/html/live/stream"
  
  
  
  ffmpeg \
  
    -thread_queue_size 8192 \
  
    -f v4l2 -input_format mjpeg -r 30 -s 640x360 -i /dev/video0 \
  
    -thread_queue_size 16384 \
  
    -f alsa -ar 44100 -ac 2 -i hw:1,0 \
  
    -map 0:0 \
  
    -pix_fmt yuv422p \
  
    -c:v libvpx-vp9 \
  
      -s 640x360 -keyint_min 60 -g 60 ${VP9_LIVE_PARAMS} \
  
      -b:v 300k \
  
    -f webm_chunk \
  
      -header "${TARGET_PATH}/glass_360.hdr" \
  
      -chunk_start_index 1 \
  
    "${TARGET_PATH}/glass_360_%d.chk" \
  
    -map 1:0 \
  
    -c:a libvorbis \
  
      -b:a 64k -ar 44100 \
  
    -f webm_chunk \
  
      -audio_chunk_duration 2000 \
  
      -header "${TARGET_PATH}/glass_171.hdr" \
  
      -chunk_start_index 1 \
  
    "${TARGET_PATH}/glass_171_%d.chk" \

  some seconds later I call the ffmpeg again to create manifest file :

  ffmpeg \
  
    -analyzeduration 1000\
  
    -f webm_dash_manifest -live 1 \
  
    -i "${TARGET_PATH}/glass_360.hdr" \
  
    -f webm_dash_manifest -live 1 \
  
    -i "${TARGET_PATH}/glass_171.hdr" \
  
    -c copy \
  
    -map 0 -map 1 \
  
    -f webm_dash_manifest -live 1 \
  
      -adaptation_sets "id=0,streams=0 id=1,streams=1" \
  
      -chunk_start_index 1 \
  
      -chunk_duration_ms 2000 \
  
      -time_shift_buffer_depth 7200 \
  
      -minimum_update_period 7200 \
  
    "${TARGET_PATH}/glass_live_manifest.mpd"

  My server’s clock is synced to "http://time.akamai.com/?iso"

  HTML5 player :

   
  
      
  
      
  
      
  
      
  
      
  
      <code class="echappe-js">&lt;script src=&quot;https://cdn.dashjs.org/latest/dash.all.min.js&quot;&gt;&lt;/script&gt;
  
  
    
  Live broadcast
    
  
     
  
         
     
     
  &lt;script&gt;<br />
  
                  var url = &quot;glass_live_manifest.mpd&quot;;<br />
  
                  var player = dashjs.MediaPlayer().create();<br />
  
                  player.initialize(document.querySelector(&quot;#videoPlayer&quot;), url, true);<br />
  
  <br />
  
     &lt;/script&gt;
     
    
   
  

• Writing multithreaded video and audio packets with FFmpeg

  27 février 2017, par Robert Jones

  I couldn’t find any information on the way av_interleaved_write_frame deals with video and audio packets.

  I have multiple audio and video packets coming from 2 threads. Each thread calls a write_video_frame or write_audio_frame, locks a mutex, initialize an AVPacket and writes data to an .avi file.

  Initialization of AVCodecContext and AVFOrmatContext is ok.

  — Edit 1 —

  Audio and video are coming from an external source (microphone and camera) and are captured as raw data without any compression (even for video).
  I use h264 to encode video and no compression for Audio (PCM).

  Audio captured is : 16bits, 44100khz, stereo

  Video captured is 25FPS

  Question :

  1) Is it a problem if I write multiple video packets at once (let’s say 25 packets/sec) and just one audio packet/sec.

  Answer : Apparently not, the function av_interleaved_write_frame should be able to manage that kind of data as soon as pts and dts is well managed

  This means I call av_interleaved_write_frame 25 times for video writing and just 1 for audio writing per second. Could this be a problem ? If it is how can I deal with this scenario ?

  2) How can I manage pts and dts in this case ? It seems to be a problem in my application since I cannot correctly render the .avi file. Can I use real time stamps for both video and audio ?

  Answer : The best thing to do here is to use the timestamp given when capturing audio / video as pts and dts for this kind of application. So these are not exactly real time stamps (from wall clock) but media capture timestamps.

  Thank you for your precious advices.

• x86util : import MOVHL macro

  11 février 2017, par James Darnley

  x86util : import MOVHL macro
  Originally committed to x264 in 1637239a by Henrik Gramner who has
  
  agreed to re-license it as LGPL.  Original commit message follows.
      x86 : Avoid some bypass delays and false dependencies
      A bypass delay of 1-3 clock cycles may occur on some CPUs when transitioning
  
      between int and float domains, so try to avoid that if possible.
  

  • [DH] libavutil/x86/x86util.asm