Recherche avancée

Sur d’autres sites (5414)

• New FATE Test Coverage System

  10 août 2010, par Multimedia Mike — FATE Server

  I’ve been feeling a bit scattered for the last week since I was fired from my volunteer position as the FFmpeg QA manager, wondering if there is anything I should attempt to do with the project. It can’t be denied that the new system is working well. But one area I’ve wondered about is test coverage.

  Under my old regime I tracked test coverage as a wiki page which was a highly flawed method— tedious and error-prone. There are those 2 adjectives again— tedious and error-prone ; whenever I see those, I search for automation methods. I think that might be more plausible thanks to the new FATE’s tighter integration with the FFmpeg build system.

  I don’t think anyone is working on this problem so I wanted to toss out a brainstorm :

  1. First, run ’ffmpeg -formats’, ’ffmpeg -codecs’, etc. and parse the output to collect a list of all the features (full list : -formats, -codecs, -bsfs, -protocols, -filters, -pix_fmts). Transform these lists into a standardized list of features, e.g., "DEVSD  ffvhuff         Huffyuv FFmpeg variant" represents features ’decode-video-ffvhuff’, ’encode-video-ffvhuff’, ’ffvhuff-horizband’, and ’ffvhuff-dr1’.
  2. Next, tag each individual test spec with the features that it exercises. E.g., test ’fate-vqa-cc’ exercises features ’demux-wsvqa’, ’decode-video-vqavideo’, and ’decode-audio-adpcm_ima_ws’.
  3. Finally, compare the data from parts 1 and 2. Print a list of all the features that are not exercised in FATE.

  I think a lot of this could be implemented at the GNU make level. Then again, I’m no expert on GNU make syntax so I may be overestimating its capabilities. Or there might be simpler ways to automatically track test coverage stats based on the improved testing infrastructure.

• huffyuvdec : implement trick

  3 juin 2014, par Christophe Gisquet

  huffyuvdec : implement trick
  When the joint table does not contain a valid entry, the decoding restarts
  
  from scratch. By implementing the trick of jumping to the 2nd level of the
  
  individual table (and inlining the whole), a speed improvement of 5-10%
  
  is possible.
  On a 1000-frames YUV4:2:0 video, before :
  
  362851 decicycles in 422, 262094 runs, 50 skips
  
  182488 decicycles in gray, 262087 runs, 57 skips
  
  Object size : 23584
  
  Overall time : 8.377
  After :
  
  346800 decicycles in 422, 262079 runs, 65 skips
  
  168197 decicycles in gray, 262077 runs, 67 skips
  
  Object size : 23188
  
  Overall time : 7.878
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/huffyuvdec.c

• Texai Remote Presence System Using VP8 Video

  19 novembre 2010, par noreply@blogger.com (John Luther)

  Guest blogger Josh Tyler is a member of the Texai team at Willow Garage.

  Willow Garage is busy building the next version of its Texai remote presence platform with VP8, the video codec used in WebM.

  In short, Texai is a two-way videoconferencing app on a tele-operated robotic platform (for more details, see the piece about Texai in the New York Times). Video and audio quality are critical to providing the best user experience on Texai. We’ve evaluated several video codecs and found VP8’s image quality, low latency and tolerance to packet loss far better than anything else we tested.

  The video below shows VP8 running on one of our systems.

  (If you have a WebM-enabled browser and are enrolled in the YouTube HTML5 beta the video will play in WebM HTML5, otherwise it will play in Flash Player.)

  We’re also looking for help ! If you’re interested in helping us create an incredible, high-fidelity user experience, either by joining our team, partnering on development, or by being added to our early customer interest list, please email us at texai-info@willowgarage.com.