Recherche avancée

Sur d’autres sites (5624)

• Missing functions in new version of FFmpeg

  25 avril 2013, par Asik

  I am upgrading a wrapper around ffmpeg to the most recent version of the library. Some functions have been renamed or replaced. For the most part I've been able to found equivalents easily, but the following two are giving me trouble :

  av_abort_set_callback
  
  av_abort_default_callback

  I could not find these functions by searching online, so what happened to them and what should they be replaced with now ?

  Here is a copy of the header file "abort.h" where they were located :

  /* 
  
   * This file is part of FFmpeg. 
  
   * 
  
   * FFmpeg is free software; you can redistribute it and/or 
  
   * modify it under the terms of the GNU Lesser General Public 
  
   * License as published by the Free Software Foundation; either 
  
   * version 2.1 of the License, or (at your option) any later version. 
  
   * 
  
   * FFmpeg is distributed in the hope that it will be useful, 
  
   * but WITHOUT ANY WARRANTY; without even the implied warranty of 
  
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU 
  
   * Lesser General Public License for more details. 
  
   * 
  
   * You should have received a copy of the GNU Lesser General Public 
  
   * License along with FFmpeg; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA 
  
   */
  
  
  
  #ifndef AVUTIL_ABORT_H
  
  #define AVUTIL_ABORT_H
  
  
  
  /** 
  
   * Causes abnormal program termination. By default, av_abort_callback calls 
  
   * abort() from the stdlib. This behavior can be altered by setting a 
  
   * different av_abort callback function. 
  
   */
  
  
  
  void av_abort_internal(void);
  
  void av_abort_set_callback(void (*)(void));
  
  void av_abort_default_callback(void);
  
  
  
  #define av_abort()    do { av_log(NULL, AV_LOG_ERROR, "Abort at %s:%d\n", __FILE__, __LINE__); av_abort_internal(); } while(0)
  
  
  
  #endif /* AVUTIL_ABORT_H */

• Revision afd2f68dae : Revert "VP9_COPY_CONVOLVE_SSE2 optimization" This reverts commit a5e97d874b16ae

  5 août 2015, par James Zern

  Changed Paths :
   Modify /vpx_dsp/x86/vpx_convolve_copy_sse2.asm

  
  
  Revert "VP9_COPY_CONVOLVE_SSE2 optimization"

  This reverts commit a5e97d874b16ae5826b68515f1e35ffb44361cf8.

  Additionally :
  Revert "vpx_convolve_copy_sse2 : fix win64"

  This reverts commit 22a8474fe7ec30d96f746dc6e4b23771758c071e.

  This change performs poorly on various x86_64 devices affecting
  performance by 1-3% at 1080P. Performance on chromebook like devices was
  mixed neutral to slightly negative, so there should be minimal change
  there.

  Change-Id : I95831233b4b84ee96369baa192a2d4cc7639658c

• Fastest seek speed and decoding with ffmpeg and x265 ProRes

  17 mai 2018, par Christopher Jarvis

  I’m trying to optimize seek speed with x265. No matter what encoding settings I try, ProRes still seeks more quickly/gracefully. This makes sense since it was built for editing, but I’m sure there’s got to be something I’m missing to better improve x265.

  So far, -tune fastdecode, keyint=1, maxrate and -b (to remove B Frame calculations) yield the best results, but they’re still unsatisfactory. I’ve been pouring over the docs but there’s so much jargon I just don’t understand. Perhaps another codec like VP9 / WebM would be better for this purpose ?

  From what I can tell, there’s no bottleneck with CPU, read speed or RAM... or GPU for that matter. Monitoring these processes show minimal drain. Is there just an amount of decoding in a highly compressed format like x265 that can’t be circumvented ?

  Thank you in advance for your help.