Recherche avancée

Sur d’autres sites (3730)

• 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

  

• Further SMC Encoding Work

  25 août 2011, par Multimedia Mike — General

  Sometimes, when I don’t feel like doing anything else, I look at that Apple SMC video encoder again.

  8-bit Encoding
  When I last worked on the encoder, I couldn’t get the 8-color mode working correctly, even though the similar 2- and 4-color modes were working fine. I chalked the problem up to the extreme weirdness in the packing method unique to the 8-color mode. Remarkably, I had that logic correct the first time around. The real problem turned out to be with the 8-color cache and it was due to the vagaries of 64-bit math in C. Bit shifting an unsigned 8-bit quantity implicitly results in a signed 32-bit quantity, or so I discovered.

  Anyway, the 8-color encoding works correctly, thus shaving a few more bytes off the encoding size.

  Encoding Scheme Oddities
  The next step is to encode runs of data. This is where I noticed some algorithmic oddities in the scheme that I never really noticed before. There are 1-, 2-, 4-, 8-, and 16-color modes. Each mode allows encoding from 1-256 blocks of that same encoding. For example, the byte sequence :

    0x62 0x45
  

  Specifies that the next 3 4×4 blocks are encoded with single-color mode (of byte 0×62, high nibble is encoding mode and low nibble is count-1 blocks) and the palette color to be used is 0×45. Further, opcode 0×70 is the same except the following byte allows for specifying more than 16 (i.e., up to 256) blocks shall be encoded in the same matter. In light of this repeat functionality being built into the rendering opcodes, I’m puzzled by the existence of the repeat block opcodes. There are opcodes to repeat the prior block up to 256 times, and there are opcodes to repeat the prior pair of blocks up to 256 times.

  So my quandary is : What would the repeat opcodes be used for ? I hacked the FFmpeg / Libav SMC decoder to output a histogram of which opcodes are used. The repeat pair opcodes are never seen. However, the single-repeat opcodes are used a few times.

  Puzzle Solved ?
  I’m glad I wrote this post. Just as I was about to hit “Publish”, I think I figured it out. I haven’t mentioned the skip opcodes yet– there are opcodes that specify that 1-256 4×4 blocks are unchanged from the previous frame. Conceivably, a block could be unchanged from the previous frame and then repeated 1-256 times from there.

  That’s something I hadn’t thought of up to this point for my proposed algorithm and will require a little more work.

  Further reading

  • My first entry regarding my toy SMC encoder

• Alternative to sws_scale

  19 décembre 2012, par Hrishikesh_Pardeshi

  I am performing encoding of the captured windows screen with x264 using libavcodec. Since, the input is RGB, i am converting it to YUV to make it compatible with x264. I am using the sws_scale function for the same.
  My question is if there is any alternate for this function since i don't need any scaling to be done in my case. Also, it would be useful if someone could throw light on the workflow of this function.

  P.S : I am assuming x264 operates only in YUV color space. If this assumption is incorrect, please inform me on the same.

  Thanks in advance.