Recherche avancée

Sur d’autres sites (3873)

• Availability of WebM (VP8) Video Hardware IP Designs

  10 janvier 2011, par noreply@blogger.com (John Luther)

  Hello from the frigid city of Oulu, in the far north of Finland. Our WebM hardware development team, formerly part of On2 Technologies, is now up-to-speed and working hard on a number of video efforts for WebM.
  

  • VP8 (the video codec used in WebM) hardware decoder IP is available from Google for semiconductor companies who want to support high-quality WebM playback in their chipsets.
  • The Oulu team will release the first VP8 video hardware encoder IP in the first quarter of 2011. We have the IP running in an FPGA environment, and rigorous testing is underway. Once all features have been tested and implemented, the encoder will be launched as well.

  WebM video hardware IPs are implemented and delivered as RTL (VHDL/Verilog) source code, which is a register-level hardware description language for creating digital circuit designs. The code is based on the Hantro brand video IP from On2, which has been successfully deployed by numerous chipset companies around the world. Our designs support VP8 up to 1080p resolution and can run 30 or 60fps, depending on the foundry process and hardware clock frequency.

  The WebM/VP8 hardware decoder implementation has already been licensed to over twenty partners and is proven in silicon. We expect the first commercial chips to integrate our VP8 decoder IP to be available in the first quarter of 2011. For example, Chinese semiconductor maker Rockchip last week demonstrated full WebM hardware playback on their new RK29xx series processor at CES in Las Vegas (video below).
  

  
  Note : To view the video in WebM format, ensure that you’ve enrolled in the YouTube HTML5 trial and are using a WebM-compatible browser. You can also view the video on YouTube.

  Hardware implementations of the VP8 encoder also bring exciting possibilities for WebM in portable devices. Not only can hardware-accelerated devices play high-quality WebM content, but hardware encoding also enables high-resolution, real-time video communications apps on the same devices. For example, when VP8 video encoding is fully off-loaded to a hardware accelerator, you can run 720p or even 1080p video conferencing at full framerate on a portable device with minimal battery use.

  The WebM hardware video IP team will be focusing on further developing the VP8 hardware designs while also helping our semiconductor partners to implement WebM video compression in their chipsets. If you have any questions, please visit our Hardware page.

  Happy New Year to the WebM community !

  Jani Huoponen, Product Manager
  Aki Kuusela, Engineering Manager

  

• ffmpegthumbnailer error with carrierwave-video-thumbnailer

  30 janvier 2014, par scientiffic

  I am getting the error "No such file or directory" when I try to run ffmpegthumbnailer using the carrierwave-video-thumbnailer gem.

  I confirmed that ffmpegthumbnailer is working correctly on my computer since I can generate a thumbnail image from a video straight from the command line.

  From my logs, it looks like my app thinks that it has generated a thumbnail image. However, when I look in the directory, there is no file tmpfile.png, and my app fails with the error.

  Has anyone successfully used the carrierewave-video-thumbnailer gem to create thumbnails, and if so, what am I doing wrong ? Alternatively, if there is some way I can just run ffmpegthumbnailer within my model, I could do that too.

  Here are my logs :

  Running....ffmpegthumbnailer -i /Users/.../Website/public/uploads/tmp/1380315873-21590-2814/thumb_Untitled.mov -o /Users/.../Website/public/uploads/tmp/1380315873-21590-2814/tmpfile.png -c png -q 10 -s 192 -f
  
  Success!
  
  Errno::ENOENT: No such file or directory - (/Users/.../Website/public/uploads/tmp/1380315873-21590-2814/tmpfile.png, /Users/.../Website/public/uploads/tmp/1380315873-21590-2814/thumb_Untitled.mov)

  video_path_uploader.rb

  class VideoPathUploader < CarrierWave::Uploader::Base
  
    include CarrierWave::Video
  
    include CarrierWave::Video::Thumbnailer
  
  
  
    process encode_video: [:mp4]
  
  
  
    # Include RMagick or MiniMagick support:
  
    # include CarrierWave::RMagick
  
    include CarrierWave::MiniMagick
  
  
  
    # Choose what kind of storage to use for this uploader:
  
    # storage :file
  
    storage :fog
  
  
  
    # Override the directory where uploaded files will be stored.
  
    # This is a sensible default for uploaders that are meant to be mounted:
  
    def store_dir
  
      "#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}"
  
    end
  
  
  
     version :thumb do
  
        process thumbnail: [{format: 'png', quality: 10, size: 192, strip: true, logger: Rails.logger}]
  
        def full_filename for_file
  
          png_name for_file, version_name
  
        end
  
    end
  
  
  
      def png_name for_file, version_name
  
        %Q{#{version_name}_#{for_file.chomp(File.extname(for_file))}.png}
  
      end
  
  
  
  end

  Video.rb

  class Video < ActiveRecord::Base
  
    # maybe we should add a title attribute to the video?
  
    attr_accessible :position, :project_id, :step_id, :image_id, :saved, :embed_url, :thumbnail_url, :video_path
  
    mount_uploader :video_path, VideoPathUploader
  
  ...
  
  end

• FFMpeg sws_scale Static and Shared Huge Performance Difference

  6 novembre 2018, par Ali

  I used swscale in my code as a shared library then managed to compile FFMpeg (4.1) to static libraries with Visual Studio with this command just to get swscale :

  ./configure --toolchain=msvc --arch=x86_32 --disable-everything --disable-programs 

  I have nasm and yasm installed. this my config output :

  install prefix            /usr/local
  
  source path               .
  
  C compiler                cl
  
  C library                 msvcrt
  
  ARCH                      x86 (generic)
  
  big-endian                no
  
  runtime cpu detection     yes
  
  standalone assembly       yes
  
  x86 assembler             nasm
  
  MMX enabled               yes
  
  MMXEXT enabled            yes
  
  3DNow! enabled            yes
  
  3DNow! extended enabled   yes
  
  SSE enabled               yes
  
  SSSE3 enabled             yes
  
  AESNI enabled             yes
  
  AVX enabled               yes
  
  AVX2 enabled              yes
  
  AVX-512 enabled           yes
  
  XOP enabled               yes
  
  FMA3 enabled              yes
  
  FMA4 enabled              yes
  
  i686 features enabled     yes
  
  CMOV is fast              no
  
  EBX available             no
  
  EBP available             no
  
  debug symbols             yes
  
  strip symbols             no
  
  optimize for size         no
  
  optimizations             yes
  
  static                    yes
  
  shared                    no
  
  postprocessing support    no
  
  network support           yes
  
  threading support         w32threads
  
  safe bitstream reader     yes
  
  texi2html enabled         no
  
  perl enabled              no
  
  pod2man enabled           no
  
  makeinfo enabled          no
  
  makeinfo supports HTML    no
  
  
  
  External libraries:
  
  schannel
  
  
  
  External libraries providing hardware acceleration:
  
  d3d11va                    dxva2
  
  
  
  Libraries:
  
  avcodec                    avdevice                   avfilter                   avformat                   avutil                     swresample                 swscale
  
  
  
  Programs:
  
  Enabled decoders:
  
  Enabled encoders:
  
  Enabled hwaccels:
  
  Enabled parsers:
  
  Enabled demuxers:
  
  Enabled muxers:
  
  Enabled protocols:
  
  Enabled filters:
  
  Enabled bsfs:
  
  null
  
  Enabled indevs:
  
  Enabled outdevs:

  This compiled successfully and I replaced the lib files with .a file in QT :

  INCLUDEPATH += $$PWD/ffmpeg/inc/
  
  LIBS += $$files($$PWD/ffmpeg/lib/*.a, true)

  I didn’t change anything else. EXE works correctly without dependency but problem is static swscale is so much slower than the shared one. For 1080p share .DLL takes 2ms to shrink and convert yuv to rgb and static .A takes 6ms to

  I also tried removing --disable-everything --disable-programs but still the same. I want to know if it’s because of the cl compiler or I missed a library or a setting ?

  BTW this my system : Win10/i7 4820K/16GB/GTX970

  EDIT :

  I got this in app output :
  No accelerated colorspace conversion found from yuv420p to bgra.
  Although x86 folder in swscale is compiled, it seems it’s not linked in the output.