Recherche avancée

Sur d’autres sites (6368)

• Fighting with the VP8 Spec

  4 juin 2010, par Multimedia Mike — VP8

  As stated in a previous blog post on the matter, FFmpeg’s policy is to reimplement codecs rather than adopt other codebases wholesale. And so it is with Google’s recently open sourced VP8 codec, the video portion of their Webm initiative. I happen to know that the new FFmpeg implementation is in the capable hands of several of my co-developers so I’m not even worrying about that angle.

  Instead, I thought of another of my characteristically useless exercises : Create an independent VP8 decoder implementation entirely in pure Python. Silly ? Perhaps. But it has one very practical application : By attempting to write a new decoder based on the official bitstream documentation, this could serve as a mechanism for validating said spec, something near and dear to my heart.

  What is the current state of the spec ? Let me reiterate that I’m glad it exists. As I stated during the initial open sourcing event, everything that Google produced for the initial event went well beyond my wildest expectations. Having said that, the documentation does fall short in a number of places. Fortunately, I am on the Webm mailing lists and am sending in corrections and ideas for general improvement. For the most part, I have been able to understand the general ideas behind the decoding flow based on the spec and am even able to implement certain pieces correctly. Then I usually instrument the libvpx source code with output statements in order to validate that I’m doing everything right.

  Token Blocker
  Unfortunately, I’m quite blocked right now on the chapter regarding token/DCT coefficient decoding (chapter 13 in the current document iteration). In his seminal critique of the codec, Dark Shikari complained that large segments of the spec are just C code fragments copy and pasted from the official production decoder. As annoying as that is, the biggest insult comes at the end of section 13.3 :

  While we have in fact completely described the coefficient decoding procedure, the reader will probably find it helpful to consult the reference implementation, which can be found in the file detokenize.c.

  The reader most certainly will not find it helpful to consult the file detokenize.c. The file in question implements the coefficient residual decoding with an unholy sequence of C macros that contain goto statements. Honestly, I thought I did understand the coefficient decoding procedure based on the spec’s description. But my numbers don’t match up with the official decoder. Instrumenting or tracing macro’d code is obviously painful and studying the same code is making me think I don’t understand the procedure after all. To be fair, entropy decoding often occupies a lot of CPU time for many video decoders and I have little doubt that the macro/goto approach is much faster than clearer, more readable methods. It’s just highly inappropriate to refer to it for pedagogical purposes.

  Aside : For comparison, check out the reference implementation for the VC-1 codec. It was written so clearly and naively that the implementors used an O(n) Huffman decoder. That’s commitment to clarity.

  I wonder if my FFmpeg cohorts are having better luck with the DCT residue decoding in their new libavcodec implementation ? Maybe if I can get this Python decoder working, it can serve as a more appropriate reference decoder.

  Update : Almost immediately after I posted this entry, I figured out a big problem that was holding me back, and then several more small ones, and finally decoded by first correct DCT coefficient from the stream (I’ve never been so happy to see the number -448). I might be back on track now. Even better was realizing that my original understanding of the spec was correct.

  Unrelated
  I found this image on the Doom9 forums. I ROFL’d :
  

  
  
  

  It’s probably unfair and inaccurate but you have to admit it’s funny. Luckily, quality nitpickings aren’t my department. I’m just interested in getting codecs working, tested, and documented so that more people can use them reliably.

• Php-ffmpeg “Unknown encoder libfaac” on Windows

  6 mars 2016, par Dev

  I am using laravel 4.2.

  I am working on a project in that user can upload a video and I need to transcode it that it can be played over all kind of devices.

  For transcoding I have added php-ffmpeg package from git hub in my project. According to the instructions I have downloaded ffmpeg package from http://ffmpeg.zeranoe.com/builds and set the ffmpeg.exe’s path into the environment variable Path.

  Now, I tried code below to transcode an uploaded video :

  $ffmpeg = FFMpeg\FFMpeg::create();
  
  $video = $ffmpeg->open($video_path);
  
  $format = new FFMpeg\Format\Video\X264();
  
  $format->setKiloBitrate(1000)
  
          ->setAudioChannels(2)
  
          ->setAudioKiloBitrate(256);
  
  $video->save($format, public_path().$path.$save_filename);

  But it gives error as below :

  [ERROR] ffmpeg version N-70767-gd24af70 Copyright (c) 2000-2015 the FFmpeg developers
  
  [ERROR]   built with gcc 4.9.2 (GCC)
  
  [ERROR]   configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib
  
  [ERROR]   libavutil      54. 20.100 / 54. 20.100
  
  [ERROR]   libavcodec     56. 28.100 / 56. 28.100
  
  [ERROR]   libavformat    56. 25.101 / 56. 25.101
  
  [ERROR]   libavdevice    56.  4.100 / 56.  4.100
  
  [ERROR]   libavfilter     5. 12.100 /  5. 12.100
  
  [ERROR]   libswscale      3.  1.101 /  3.  1.101
  
  [ERROR]   libswresample   1.  1.100 /  1.  1.100
  
  [ERROR]   libpostproc    53.  3.100 / 53.  3.100
  
  [ERROR] 
  
  [ERROR] Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'http://localhost/ohvideo-ftp/public/temp/5ZPlIuU1AIgz8RR4p0bs.mp4':
  
  [ERROR]   Metadata:
  
  [ERROR]     major_brand     : mp42
  
  [ERROR]     minor_version   : 0
  
  [ERROR]     compatible_brands: mp42mp41isomavc1
  
  [ERROR]     creation_time   : 2013-11-09 00:29:52
  
  [ERROR]   Duration: 00:00:30.12, start: 0.000000, bitrate: 417 kb/s
  
  [ERROR]     Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 381 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
  
  [ERROR]     Metadata:
  
  [ERROR]       creation_time   : 2013-11-09 00:29:52
  
  [ERROR]       handler_name    : L-SMASH Video Handler
  
  [ERROR]       encoder         : AVC Coding
  
  [ERROR]     Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 32 kb/s (default)
  
  [ERROR]     Metadata:
  
  [ERROR]       creation_time   : 2013-11-09 00:29:52
  
  [ERROR]       handler_name    : L-SMASH Audio Handler
  
  [ERROR] Unknown encoder 'libfaac'
  
  [ERROR] 
  
  {"error":{"type":"FFMpeg\\Exception\\RuntimeException","message":"Encoding failed","file":"F:\\wamp\\www\\ohvideo-ftp\\vendor\\php-ffmpeg\\php-ffmpeg\\src\\FFMpeg\\Media\\Video.php","line":168}}

  After searching alot, I found a link for the solution here, with note that

  Zeranoe’s ffmpeg does not contain libfaac support due to that encoder
  requiring —enable-nonfree which would result in a non-redistributable
  build.

  I don’t get the solution. Can anybody help me to overcome this ?

  Edit : (working code as below)

  I have created a CustomVideo class the same like class FFMpeg\Format\Video\X264() as below :

  class CustomVideo extends FFMpeg\Format\Video\DefaultVideo
  
  {
  
      /** @var boolean */
  
      private $bframesSupport = true;
  
  
  
      public function __construct($audioCodec = 'libmp3lame', $videoCodec = 'libx264')
  
      {
  
          $this
  
              ->setAudioCodec($audioCodec)
  
              ->setVideoCodec($videoCodec);
  
      }
  
  
  
      /**
  
       * {@inheritDoc}
  
       */
  
      public function supportBFrames()
  
      {
  
          return $this->bframesSupport;
  
      }
  
  
  
      /**
  
       * @param $support
  
       *
  
       * @return X264
  
       */
  
      public function setBFramesSupport($support)
  
      {
  
          $this->bframesSupport = $support;
  
  
  
          return $this;
  
      }
  
  
  
      /**
  
       * {@inheritDoc}
  
       */
  
      public function getAvailableAudioCodecs()
  
      {
  
          return array('libmp3lame');
  
      }
  
  
  
      /**
  
       * {@inheritDoc}
  
       */
  
      public function getAvailableVideoCodecs()
  
      {
  
          return array('libx264');
  
      }
  
  
  
      /**
  
       * {@inheritDoc}
  
       */
  
      public function getPasses()
  
      {
  
          return 2;
  
      }
  
  
  
      /**
  
       * @return int
  
       */
  
      public function getModulus()
  
      {
  
          return 2;
  
      }
  
  }

  and updated the code to transcode video as below :

  $ffmpeg = FFMpeg\FFMpeg::create();
  
  $video = $ffmpeg->open($video_path);
  
  $format = new CustomVideo();
  
  $format->setKiloBitrate(1000)
  
         ->setAudioChannels(2)
  
         ->setAudioKiloBitrate(256);
  
  
  
  $video->save($format, public_path().$path.$save_filename); 

  It has solved the Unknown encoder libfaac error.

• WebRTC predictions for 2016

  17 février 2016, par silvia

  I wrote these predictions in the first week of January and meant to publish them as encouragement to think about where WebRTC still needs some work. I’d like to be able to compare the state of WebRTC in the browser a year from now. Therefore, without further ado, here are my thoughts.

  WebRTC Browser support

  I’m quite optimistic when it comes to browser support for WebRTC. We have seen Edge bring in initial support last year and Apple looking to hire engineers to implement WebRTC. My prediction is that we will see the following developments in 2016 :

  • Edge will become interoperable with Chrome and Firefox, i.e. it will publish VP8/VP9 and H.264/H.265 support
  • Firefox of course continues to support both VP8/VP9 and H.264/H.265
  • Chrome will follow the spec and implement H.264/H.265 support (to add to their already existing VP8/VP9 support)
  • Safari will enter the WebRTC space but only with H.264/H.265 support

  Codec Observations

  With Edge and Safari entering the WebRTC space, there will be a larger focus on H.264/H.265. It will help with creating interoperability between the browsers.

  However, since there are so many flavours of H.264/H.265, I expect that when different browsers are used at different endpoints, we will get poor quality video calls because of having to negotiate a common denominator. Certainly, baseline will work interoperably, but better encoding quality and lower bandwidth will only be achieved if all endpoints use the same browser.

  Thus, we will get to the funny situation where we buy ourselves interoperability at the cost of video quality and bandwidth. I’d call that a “degree of interoperability” and not the best possible outcome.

  I’m going to go out on a limb and say that at this stage, Google is going to consider strongly to improve the case of VP8/VP9 by improving its bandwidth adaptability : I think they will buy themselves some SVC capability and make VP9 the best quality codec for live video conferencing. Thus, when Safari eventually follows the standard and also implements VP8/VP9 support, the interoperability win of H.264/H.265 will become only temporary overshadowed by a vastly better video quality when using VP9.

  The Enterprise Boundary

  Like all video conferencing technology, WebRTC is having a hard time dealing with the corporate boundary : firewalls and proxies get in the way of setting up video connections from within an enterprise to people outside.

  The telco world has come up with the concept of SBCs (session border controller). SBCs come packed with functionality to deal with security, signalling protocol translation, Quality of Service policing, regulatory requirements, statistics, billing, and even media service like transcoding.

  SBCs are a total overkill for a world where a large number of Web applications simply want to add a WebRTC feature – probably mostly to provide a video or audio customer support service, but it could be a live training session with call-in, or an interest group conference all.

  We cannot install a custom SBC solution for every WebRTC service provider in every enterprise. That’s like saying we need a custom Web proxy for every Web server. It doesn’t scale.

  Cloud services thrive on their ability to sell directly to an individual in an organisation on their credit card without that individual having to ask their IT department to put special rules in place. WebRTC will not make progress in the corporate environment unless this is fixed.

  We need a solution that allows all WebRTC services to get through an enterprise firewall and enterprise proxy. I think the WebRTC standards have done pretty well with firewalls and connecting to a TURN server on port 443 will do the trick most of the time. But enterprise proxies are the next frontier.

  What it takes is some kind of media packet forwarding service that sits on the firewall or in a proxy and allows WebRTC media packets through – maybe with some configuration that is necessary in the browsers or the Web app to add this service as another type of TURN server.

  I don’t have a full understanding of the problems involved, but I think such a solution is vital before WebRTC can go mainstream. I expect that this year we will see some clever people coming up with a solution for this and a new type of product will be born and rolled out to enterprises around the world.

  Summary

  So these are my predictions. In summary, they address the key areas where I think WebRTC still has to make progress : interoperability between browsers, video quality at low bitrates, and the enterprise boundary. I’m really curious to see where we stand with these a year from now.

  —

  It’s worth mentioning Philipp Hancke’s tweet reply to my post :

  https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ … — we saw some clever people come up with a solution already. Now it needs to be implemented

  The post WebRTC predictions for 2016 first appeared on ginger’s thoughts.