Recherche avancée

Sur d’autres sites (4913)

• Revision 2ae3d4f266 : Add a new PREDICTION mode using NEARMV as ref mv This experiment, referred as N

  18 mars 2015, par Zoe Liu

  Changed Paths :
   Modify /configure

  
   Modify /vp9/common/vp9_blockd.h

  
   Modify /vp9/common/vp9_entropymode.c

  
   Modify /vp9/common/vp9_loopfilter.c

  
   Modify /vp9/common/vp9_mvref_common.c

  
   Modify /vp9/common/vp9_mvref_common.h

  
   Modify /vp9/decoder/vp9_decodemv.c

  
   Modify /vp9/encoder/vp9_bitstream.c

  
   Modify /vp9/encoder/vp9_denoiser.c

  
   Modify /vp9/encoder/vp9_encodemv.c

  
   Modify /vp9/encoder/vp9_pickmode.c

  
   Modify /vp9/encoder/vp9_rd.c

  
   Modify /vp9/encoder/vp9_rd.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
   Modify /vp9/encoder/vp9_speed_features.h

  
  
  Add a new PREDICTION mode using NEARMV as ref mv

  This experiment, referred as NEWMVREF, also merged with NEWMVREF_SUB8X8
  and the latter one has been removed. Runborgs results show that :

  (1) Turning on this experiment only, compared against the base :
  derflf : Average PSNR 0.40% ; Overall PSNR 0.40% ; SSIM 0.35%
  (2) Turning on all the experiments including this feature, compared against
  that without this feature, on the highbitdepth case using 12-bit :
  derflf : Average PSNR 0.33% ; Overall PSNR 0.32% ; SSIM 0.30%.

  Now for highbitdepth using 12-bit, compared against base :
  derflf : Average PSNR 11.12% ; Overall PSNR 11.07% ; SSIM 20.27%.

  Change-Id : Ie61dbfd5a19b8652920d2c602201a25a018a87a6

• Revision a0043c6d30 : Enhance the transform skipping decision-making in non-rd mode For large partiti

  25 mars 2015, par Yunqing Wang

  Changed Paths :
   Modify /vp9/encoder/vp9_pickmode.c

  
  
  Enhance the transform skipping decision-making in non-rd mode

  For large partition blocks(block_size > 32x32), the variance
  calculation is modified so that every 8x8 block’s variance
  is stored during the calculation, which is used in the
  following transform skipping test. Also, the variance for
  every tx block is calculated. The skipping test checks all tx
  blocks in the partition, and sets the skip flag only if all tx
  blocks are skippable. If the skip flag of Y plane is 1, a
  quick evaluation is done on UV planes. If the current partition
  block is skippable in YUV planes, the mode search checks fewer
  inter modes and doesn’t check intra modes.

  The rtc set borg test(at speed 6) showed that :
  Overall psnr : -0.527% ; Avg psnr : -0.510% ; ssim : -0.573%.
  Average single-thread speedup on rtc set was 3.5%.
  For 720p clips, more speedups were seen.
  gipsrecmotion : 13%
  gipsrestat : 12%
  vidyo : 5 - 9%
  dark : 15%
  niklas : 6%

  Change-Id : I8d8ebec0cb305f1de016516400bf007c3042666e

• How can ffmpeg be made as efficient as Android's built-in video viewer ?

  6 janvier 2016, par Nicholas

  I have a project based off of https://ikaruga2.wordpress.com/2011/06/15/video-live-wallpaper-part-1/, which uses an older copy of the ffmpeg libraries from http://bambuser.com/opensource. Within the C++ code in this project we have the following lines of code :

          unsigned long long current = GetCurrentTimeInNanoseconds();
  
          avcodec_decode_video(pCodecCtx, pFrame, &frameFinished, packet.data, packet.size);
  
          __android_log_print(ANDROID_LOG_DEBUG, "getFrame>>>>", "decode video time: %llu", (GetCurrentTimeInNanoseconds() - current)/1000000);

  This code continually reports between 60 and 90 ms to decode each frame on an Xperia Ion, using a 1280x720 h264 source video file. Other processing to get the frame out to the screen takes an average of 30ms more with very little variation. This leads to frame rates of 10-11fps.

  Ignoring that other processing, a decode that takes an average of 75ms would result in 13fps. However, when I browse my SD card and click on that mp4 file to open it in the native viewer, it shows at a full 30fps. Further, when I open a 1920x1080 version of the same mp4 in the native viewer it also runs at a full 30fps without stutter or lag. This implies (to my novice eye) that something is very very wrong, as the hardware is obviously capable of decoding many times faster.

  What flags or options can be passed to avcode_decode_video to optimize decode speed to match that of the native viewer ? Can optimizations be made elsewhere to optimize speed further ? Is there a reason that the native viewer can decode almost an order of magnitude faster (taking into account the 1920x1080 source results) ?

  EDIT

  The answer below is very helpful, but is not practical for me at this time. In the mean time I have managed to decrease decoding time by 70% with some optimal encoding flags found through many many hours of trial and error. Here are the ffmpeg arguments I’m using for encoding in case it helps anyone else who stumbles across this post :

          ffmpeg.exe -i "#inputFilePath#" -c:v libx264 -preset veryslow -g 2 -y -s 910x512 -b 5000k -minrate 2000k -maxrate 8000k -pix_fmt yuv420p -tune fastdecode -coder 0 -flags -loop -profile:v main -x264-params subme=5:ref=4 "#ouputFilePath#"

  With these settings ffmpeg is decoding frames in 20-25 seconds, though with the sws_scale and then writing out to the texture I’m still hovering at 22 FPS on an Xperia Ion at a lower resolution than I’d like.