Recherche avancée

Sur d’autres sites (5944)

• lavfi/hqdn3d : add slice thread optimization

  2 octobre 2019, par Jun Zhao

  lavfi/hqdn3d : add slice thread optimization
  Enabled one thread per plane, used the test command for 1080P video
  
  (YUV420P format) as follow :
  ffmpeg -i 1080p.mp4 -an -vf hqdn3d -f null /dev/nul
  This optimization improved the performance about 30% in 1080P YUV420P
  
  case (from 110fps to 143fps), also pass the framemd5 check and FATE.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Reviewed-by : Moritz Barsnick <barsnick@gmx.net>
  
  Signed-off-by : Jun Zhao <barryjzhao@tencent.com>
  

  • [DH] libavfilter/vf_hqdn3d.c
  • [DH] libavfilter/vf_hqdn3d.h

• ffmpeg stream rejected by youtube because it's too slow

  15 septembre 2019, par DeadlyBacon

  I have an app that sends WebM video to a socket in my server, the socket then executes ffmpeg to transform the video to flv and send it to a youtube rtmp ingester.

  Thing is, youtube rejects the stream, saying that the broadcast status is incorrect, no matter what I do.

  In my naivette I initially tried to stream 1080p and 720p, that failed, so I went down, assuming that that might help me with the bitrate issue... It did not.

  The error that Youtube gives me is in spanish but it basically says that the stream is too slow and I should lower resolution or bitrate(I’m already @ 240p and it’s not working).

  Edit : Here’s the error, translated :

  Main broadcast :
  YouTube is not receiving enough video to guarantee a fluid broadcast. Buffering will occur.

  Main Broadcast : We are not receiving video data at a fast enough speed. Your audience may experience buffering. Make sure that your connection is fast enough o consider using a lower bitrate.

  Here is my call to ffmpeg thus far (language is node.js if that matters.) :

  const ffmpeg = child_process.spawn('ffmpeg', [
  
  
  
      '-f', 'lavfi', '-i', 'anullsrc',
  
  
  
      //    '-re', // I was told i shouldnt use this parameter. i dont know, honestly.
  
  
  
  
  
  
  
      // FFmpeg will read input video from STDIN
  
      '-i', '-',
  
  
  
      // Because we're using a generated audio source which never ends,
  
      // specify that we'll stop at end of other input.  Remove this line if you
  
      // send audio from the browser.
  
      '-shortest',
  
  
  
      '-vcodec', 'libx264',
  
  
  
      '-acodec', 'aac',
  
  
  
      //ffmpeg
  
      //-re -loop 1
  
      //-framerate 2 -i test1.jpg -i https://xxxxxxxxxxx:8443/live.ogg
  
      //-c:a aac
  
      //-s 2560x1440
  
      //-ab 128k -vcodec libx264 -pix_fmt yuv420p -maxrate 2048k -bufsize 2048k
  
      //'-framerate', '30',
  
      '-r', '24',
  
      //'-s', '2560x1440',
  
  
  
  
  
      '-force_key_frames','expr:gte(t\,n_forced/2)',
  
  
  
      '-preset', 'ultrafast',
  
      '-pix_fmt', 'yuv420p',
  
      '-s', '426x240',
  
      '-crf', '23',
  
      '-bf', '2',
  
      '-q:a', '1',
  
      '-ac', '2',
  
      '-ar','48000',
  
      '-use_editlist','0',
  
      '-movflags','+faststart',
  
      //  '-ab', '128k',
  
      '-g', '48',
  
  
  
      //'-minrate', '1500k',
  
      '-minrate', '1000k',
  
      '-maxrate', '2000k',
  
  
  
      '-bufsize', '2000k',/*
  
      '-g', '30',*/
  
      //'-keyint_min', '30',
  
      //'-t', '30',
  
  
  
      ////
  
      '-deadline', 'realtime',
  
      '-cpu-used','-16',
  
  
  
      '-tune', 'zerolatency',
  
  
  
      '-threads', '4',
  
  
  
      //-g 2 -strict experimental -f flv rtmp://a.rtmp.youtube.com/live2/xxxxxxxxxxxxx
  
  
  
  
  
      // FLV is the container format used in conjunction with RTMP
  
      '-f', 'flv',
  
  
  
  
  
  
  
      // The output RTMP URL.
  
      // For debugging, you could set this to a filename like 'test.flv', and play
  
      // the resulting file with VLC.  Please also read the security considerations
  
      // later on in this tutorial.
  
      rtmpUrl
  
  ]);

  Edit : input is fed via stdin whenever the socket receives data.

  In my completely uneducated opinion, the "-deadline realtime" & the "-tune zerolatency" parts seemed to help somewhat but not enough to get me streamin’.

  Here is some of the output of ffmpeg :

  FFmpeg STDERR: frame=   35 fps=3.1 q=23.0 size=     104kB time=00:00:08.44 bitrate= 100.4kbits/s dup=0 drop=3 speed=0.76x    
  
  FFmpeg STDERR: frame=   35 fps=3.0 q=23.0 size=     104kB time=00:00:08.44 bitrate= 100.4kbits/s dup=0 drop=3 speed=0.726x    
  
  FFmpeg STDERR: frame=   35 fps=2.9 q=23.0 size=     104kB time=00:00:08.44 bitrate= 100.4kbits/s dup=0 drop=3 speed=0.696x    
  
  FFmpeg STDERR: frame=   36 fps=2.8 q=23.0 size=     109kB time=00:00:09.45 bitrate=  94.6kbits/s dup=0 drop=3 speed=0.747x    
  
  FFmpeg STDERR: frame=   36 fps=2.7 q=23.0 size=     109kB time=00:00:09.45 bitrate=  94.6kbits/s dup=0 drop=3 speed=0.719x    
  
  FFmpeg STDERR: frame=   38 fps=2.8 q=23.0 size=     121kB time=00:00:11.45 bitrate=  86.7kbits/s dup=0 drop=3 speed=0.839x   

  This is extremely frustrating.

  Please, guys, any guidance is good. what is it that I should be maximizing or minimizing ? how do I do that ? I honestly do not care about everything else going to hell (for example the video freezing or being severely pixelated at times) I just care about being able to stream

  Thank you in advance for anything that might help me !

  UPDATE : I created a new broadcast, with variable bitrate, I broadcasted to it, it was at "status:optimal" for a few seconds then fps and speed went down and the stream went back to "status : incorrect"

• Compressing videos from a smartphone

  21 septembre 2019, par fejesjoco

  I have a Nexus 6p with the stock camera. It’s set to record at 1080p, 30fps. Here’s a 5 second sample (11 MB).

  Videos from this phone come out at about 17 Mbps on average. I tried to compress it with ffmpeg with -c:v libx264 -crf 23 -preset veryslow, the result comes out at about 5.5 MB, which is about 9 Mbps.

  I think this bitrate is a bit too much. When I look at torrent file listings, I can see high quality videos at 3 GB in size on average, and if such a movie is 90 minutes long on average, that is about 4-5 Mbps which sounds okay.

  I’m wondering, why the big difference ? I can notice that my video is noisy/grainy (which is expected from a phone), and that might reduce compressibility. I tried a few ffmpeg filters, like hqdn3d and atadenoise, but the noise mostly remained (maybe I didn’t play with it enough). Then I figured, the video is also shaky (which is also expected), and that might reduce compressibility too (and even makes temporal noise filtering less effective). I tried to stabilize it with the deshake filter, but that didn’t help either.

  I know I could just limit the bandwidth to whatever I like, but there must be a reason why ffmpeg thinks it needs a high bandwidth to maintain a certain quality, and a lower bandwidth would just decrease the quality.

  Why do these videos have such a high bitrate ? What’s the best way to compress them more while keeping or even increasing their quality ?