Recherche avancée

Sur d’autres sites (5355)

• H.264 and VP8 for still image coding : WebP ?

  
  1er octobre 2010, par Dark Shikari — google, H.264, psychovisual optimizations, VP8

  Update : post now contains a Theora comparison as well ; see below.

  JPEG is a very old lossy image format. By today’s standards, it’s awful compression-wise : practically every video format since the days of MPEG-2 has been able to tie or beat JPEG at its own game. The reasons people haven’t switched to something more modern practically always boil down to a simple one — it’s just not worth the hassle. Even if JPEG can be beaten by a factor of 2, convincing the entire world to change image formats after 20 years is nigh impossible. Furthermore, JPEG is fast, simple, and practically guaranteed to be free of any intellectual property worries. It’s been tried before : JPEG-2000 first, then Microsoft’s JPEG XR, both tried to unseat JPEG. Neither got much of anywhere.

  Now Google is trying to dump yet another image format on us, “WebP”. But really, it’s just a VP8 intra frame. There are some obvious practical problems with this new image format in comparison to JPEG ; it doesn’t even support all of JPEG’s features, let alone many of the much-wanted features JPEG was missing (alpha channel support, lossless support). It only supports 4:2:0 chroma subsampling, while JPEG can handle 4:2:2 and 4:4:4. Google doesn’t seem interested in adding any of these features either.

  But let’s get to the meat and see how these encoders stack up on compressing still images. As I explained in my original analysis, VP8 has the advantage of H.264′s intra prediction, which is one of the primary reasons why H.264 has such an advantage in intra compression. It only has i4x4 and i16x16 modes, not i8x8, so it’s not quite as fancy as H.264′s, but it comes close.

  The test files are all around 155KB ; download them for the exact filesizes. For all three, I did a binary search of quality levels to get the file sizes close. For x264, I encoded with --tune stillimage --preset placebo. For libvpx, I encoded with --best. For JPEG, I encoded with ffmpeg, then applied jpgcrush, a lossless jpeg compressor. I suspect there are better JPEG encoders out there than ffmpeg ; if you have one, feel free to test it and post the results. The source image is the 200th frame of Parkjoy, from derf’s page (fun fact : this video was shot here ! More info on the video here.).

  Files : (x264 [154KB], vp8 [155KB], jpg [156KB])

  Results (decoded to PNG) : (x264, vp8, jpg)

  This seems rather embarrassing for libvpx. Personally I think VP8 looks by far the worst of the bunch, despite JPEG’s blocking. What’s going on here ? VP8 certainly has better entropy coding than JPEG does (by far !). It has better intra prediction (JPEG has just DC prediction). How could VP8 look worse ? Let’s investigate.

  VP8 uses a 4×4 transform, which tends to blur and lose more detail than JPEG’s 8×8 transform. But that alone certainly isn’t enough to create such a dramatic difference. Let’s investigate a hypothesis — that the problem is that libvpx is optimizing for PSNR and ignoring psychovisual considerations when encoding the image… I’ll encode with --tune psnr --preset placebo in x264, turning off all psy optimizations. 

  Files : (x264, optimized for PSNR [154KB]) [Note for the technical people : because adaptive quantization is off, to get the filesize on target I had to use a CQM here.]

  Results (decoded to PNG) : (x264, optimized for PSNR)

  What a blur ! Only somewhat better than VP8, and still worse than JPEG. And that’s using the same encoder and the same level of analysis — the only thing done differently is dropping the psy optimizations. Thus we come back to the conclusion I’ve made over and over on this blog — the encoder matters more than the video format, and good psy optimizations are more important than anything else for compression. libvpx, a much more powerful encoder than ffmpeg’s jpeg encoder, loses because it tries too hard to optimize for PSNR.

  These results raise an obvious question — is Google nuts ? I could understand the push for “WebP” if it was better than JPEG. And sure, technically as a file format it is, and an encoder could be made for it that’s better than JPEG. But note the word “could”. Why announce it now when libvpx is still such an awful encoder ? You’d have to be nuts to try to replace JPEG with this blurry mess as-is. Now, I don’t expect libvpx to be able to compete with x264, the best encoder in the world — but surely it should be able to beat an image format released in 1992 ?

  Earth to Google : make the encoder good first, then promote it as better than the alternatives. The reverse doesn’t work quite as well.

  Addendum (added Oct. 2, 03:51) :

  maikmerten gave me a Theora-encoded image to compare as well. Here’s the PNG and the source (155KB). And yes, that’s Theora 1.2 (Ptalarbvorm) beating VP8 handily. Now that is embarassing. Guess what the main new feature of Ptalarbvorm is ? Psy optimizations…

  Addendum (added Apr. 20, 23:33) :

  There’s a new webp encoder out, written from scratch by skal (available in libwebp). It’s significantly better than libvpx — not like that says much — but it should probably beat JPEG much more readily now. The encoder design is rather unique — it basically uses K-means for a large part of the encoding process. It still loses to x264, but that was expected.

  [155KB]

• FFmpeg : undefined references to av_frame_alloc()

  6 août 2014, par dontrythisathome

  I want to get into FFmpeg developing and i started following these samples tutorial here : here

  I started with the first tutorial - tutorial01.c - but i run into this problem ’undefined references to av_frame_alloc()’.

  I’m on Ubuntu 12.04 LTS.

  This is my program :

  /* 
  
   * File:   main.c
  
   * Author: dontrythisathome
  
   *
  
   * Created on 3 giugno 2014, 23.02
  
   */
  
  
  
  #include 
  
  #include <libavcodec></libavcodec>avcodec.h>
  
  #include <libavformat></libavformat>avformat.h>
  
  #include <libavutil></libavutil>frame.h>
  
  #include <libswscale></libswscale>swscale.h>
  
  /*
  
   *
  
   */
  
  void SaveFrame(AVFrame *pFrame, int width, int height, int iFrame)
  
      {
  
          FILE   *pFile;
  
          char  szFilename[32];
  
          int       y;
  
  
  
          //Apre il file
  
          sprintf(szFilename, "frame%d.ppm", iFrame);
  
          pFile=fopen(szFilename, "wb");
  
          if(pFile==NULL)
  
          {return; }
  
  
  
          //Scrive l'intestazione del file ( Larghezza x Altezza su video)
  
          fprintf(pFile, "P6\n%d %d\n255\n", width, height);
  
  
  
          //Scrive i data pixel
  
          for(y=0; ydata[0]+y*pFrame->linesize[0], 1, width*3, pFile);
  
          }
  
  
  
          //Chiude il file
  
          fclose(pFile);
  
        }
  
  /*
  
   * 
  
   */
  
  /*Main Function*/
  
  int main(int argc, char *argv[])
  
  {
  
      AVFormatContext *pFormatCtx;
  
      int                                     i, videoStreamIdx;
  
      AVCodecContext   *pCodecCtx;
  
      AVCodec                      *pCodec;
  
      AVFrame                      *pFrame;
  
      AVFrame                      *pFrameRGB;
  
      AVPacket                     packet;
  
      int                                     frameFinished;
  
      int                                     numBytes;
  
      uint8_t                           *buffer;
  
      static struct SwsContext  *img_convert_ctx;
  
  
  
      if(argc &lt; 2){
  
          printf("Inserisci un file video\n");
  
          return -1;
  
      }
  
  
  
      //Registra tutti i formati e i codec
  
      av_register_all();
  
  
  
      //Apre il file video
  
      if(avformat_open_input(&amp;pFormatCtx, argv[1], NULL, NULL) != 0)
  
      {return -1;} //Impossibile aprire il file
  
  
  
      //Recupera le informazioni dello stream
  
      if(avformat_find_stream_info(pFormatCtx, NULL) &lt; 0)
  
      {return -1;} // Couldn't find stream information
  
  
  
      //Versa le informazioni del file sullo standard error
  
      av_dump_format(pFormatCtx, 0, argv[1], 0);
  
  
  
      //Trova il primo stream video
  
      videoStreamIdx=-1;
  
      for(i=0; inb_streams; i++)
  
      {
  
          if(pFormatCtx->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO)
  
          { videoStreamIdx=i;
  
              break;}
  
      }
  
  
  
      if(videoStreamIdx==-1)
  
          return -1; // Impossibile trovare lo stream video
  
  
  
      // Punta al contenuto del codec per lo stream video
  
      pCodecCtx = pFormatCtx->streams[videoStreamIdx]->codec;
  
  
  
      // Trova il decoder per lo stream video
  
      pCodec = avcodec_find_decoder(pCodecCtx->codec_id);
  
      if(pCodec==NULL)
  
      {
  
          fprintf(stderr, "Codec Non Supportato!\n");
  
          return -1; //Impossibile trovare il codec
  
      }
  
  
  
      //Apre il codec
  
      if(avcodec_open2(pCodecCtx, pCodec, NULL) &lt; 0)
  
      {return -1;} //Impossibile aprire il codec
  
  
  
      //Alloca il frame video
  
      pFrame = av_frame_alloc();
  
  
  
      //Alloca una struct AVFrame
  
      pFrameRGB = av_frame_alloc();
  
      if(pFrameRGB==NULL)
  
      {return -1;}
  
  
  
      //Determina la grandezza necessaria per il buffer e lo alloca
  
      numBytes = avpicture_get_size(PIX_FMT_RGB24,
  
                                                                              pCodecCtx->width,
  
                                                                              pCodecCtx->height);
  
  
  
      buffer = (uint8_t *) av_malloc(numBytes*sizeof(uint8_t));
  
  
  
      //Assegna le parti appropriate del buffer sulla superficie dell'immagine in pFrameRGB
  
      //Tenere presente che pFrameRGB è un AVFrame, ma AVFrame è una superset di AVPicture
  
      avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24, pCodecCtx->width, pCodecCtx->height);
  
  
  
      int w = pCodecCtx->width;
  
      int h = pCodecCtx->height;
  
      img_convert_ctx = sws_getContext(w, h, pCodecCtx->pix_fmt,
  
                                                                                         w, h, PIX_FMT_RGB24,
  
                                                                                          SWS_LANCZOS, NULL, NULL, NULL);
  
  
  
      //Legge i frame e salva i primi 5 frame su disco
  
     i=0;
  
     while((av_read_frame(pFormatCtx, &amp;packet)>=0) &amp;&amp; (i&lt;5))
  
     {
  
         //Questo è il packet dello stream video?
  
         if(packet.stream_index==videoStreamIdx)
  
         {
  
             //Decodifica il frame video
  
             avcodec_decode_video2(pCodecCtx, pFrame, &amp;frameFinished, &amp;packet);
  
  
  
             //Si è riusiciti ad ottenere il frame video?
  
             if(frameFinished)
  
             {
  
                 i++;
  
                 sws_scale(img_convert_ctx, (const uint8_t * const *)pFrame->data,
  
                                          pFrame->linesize, 0, pCodecCtx->height,
  
                                          pFrameRGB->data, pFrameRGB->linesize);
  
                 SaveFrame(pFrameRGB, pCodecCtx->width, pCodecCtx->height, i);
  
             }
  
         }
  
  
  
         //Libera il pacchetto che era allocato da av_read_frame
  
         av_free_packet(&amp;packet);
  
     }
  
  
  
     //Libera l'immagine RGB
  
     av_free(buffer);
  
     av_free(pFrameRGB);
  
  
  
     //Libera il frame YUV
  
     av_free(pFrame);
  
  
  
     //Chiude il codec
  
     avcodec_close(pCodecCtx);
  
  
  
     //Chiude il file video
  
     avformat_close_input(&amp;pFormatCtx);
  
  
  
     /*FINE PROGRAMMA*/ 
  
  
  
      return 0;
  
  }

  This is the build output :

  "/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
  
  make[1]: ingresso nella directory "/home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid"
  
  "/usr/bin/make"  -f nbproject/Makefile-Debug.mk dist/Debug/GNU-Linux-x86/simplemediaplayerforandroid
  
  make[2]: ingresso nella directory "/home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid"
  
  mkdir -p dist/Debug/GNU-Linux-x86
  
  gcc     -o dist/Debug/GNU-Linux-x86/simplemediaplayerforandroid build/Debug/GNU-Linux-x86/main.o -L/usr/lib/x86_64-linux-gnu -lavformat -lavcodec -lavutil -lswscale -lz -lbz2
  
  build/Debug/GNU-Linux-x86/main.o: In function `main':
  
  /home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid/main.c:105: undefined reference to `av_frame_alloc'
  
  /home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid/main.c:108: undefined reference to `av_frame_alloc'
  
  collect2: ld returned 1 exit status
  
  make[2]: *** [dist/Debug/GNU-Linux-x86/simplemediaplayerforandroid] Errore 1
  
  make[2]: uscita dalla directory "/home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid"
  
  make[1]: *** [.build-conf] Errore 2
  
  make[1]: uscita dalla directory "/home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid"
  
  make: *** [.build-impl] Errore 2
  
  
  
  BUILD FAILED (exit value 2, total time: 143ms)

  I also linked the correct library path and headers path because there is no error with that.

  But when i try to build the program from the terminal with these commands :

  gcc -o prog1 /home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid/main.c -lavformat -lavcodec -lavutil -lswscale -lz -lbz2

  And the output is different :

  /home/dontrythisathome/Programmazione/C-C++/SimpleMediaPlayerForAndroid/main.c:11:29: fatal error: libavutil/frame.h: File o directory non esistente
  
  compilation terminated.

  The output says that there is no file or directory existing.
  What is the problem ?

• VP8 Codec SDK "Aylesbury" Release

  28 octobre 2010, par noreply@blogger.com (John Luther)

  Today we’re making available "Aylesbury," our first named release of libvpx, the VP8 codec SDK. VP8 is the video codec used in WebM. Note that the VP8 specification has not changed, only the SDK.

  What’s an Aylesbury ? It’s a breed of duck. We like ducks, so we plan to use duck-related names for each major libvpx release, in alphabetical order. Our goal is to have one named release of libvpx per calendar quarter, each with a theme.

  You can download the Aylesbury libvpx release from our Downloads page or check it out of our Git repository and build it yourself. In the coming days Aylesbury will be integrated into all of the WebM project components (DirectShow filters, QuickTime plugins, etc.). We encourage anyone using our components to upgrade to the Aylesbury releases.

  For Aylesbury the theme was faster decoder, better encoder. We used our May 19, 2010 launch release of libvpx as the benchmark. We’re very happy with the results (see graphs below) :
  

  • 20-40% (average 28%) improvement in libvpx decoder speed
  • Over 7% overall PSNR improvement (6.3% SSIM) in VP8 "best" quality encoding mode, and up to 60% improvement on very noisy, still or slow moving source video.

  

  
  

  

  
  

  

  
  

  The main improvements to the decoder are :
  

  • Single-core assembly "hot spot" optimizations, including improved vp8_sixtap_predict() and SSE2 loopfilter functions
  • Threading improvements for more efficient use of multiple processor cores
  • Improved memory handling and reduced footprint
  • Combining IDCT and reconstruction steps
  • SSSE3 usage in functions where appropriate

  On the encoder front, we concentrated on clips in the 30-45 dB range and saw the biggest gains in higher-quality source clips (greater that 38 dB), low to medium-motion clips, and clips with noisy source material. Many code contributions made this possible, but a few of the highlights were :
  

  • Adaptive width and strength alternate reference frame noise suppression filter with optional motion compensation.
  • Transform improvements (improved accuracy and reduction in round trip error)
  • Trellis-based quantized coefficient optimization
  • Two-pass rate control and quantizer changes
  • Rate distortion changes
  • Zero bin and rounding changes
  • Work on MB-level quality control and bit allocation

  We’re targeting Q1 2011 for the next named libvpx release, which we’re calling Bali. The theme for that release will be faster encoder. We are constantly working on improvements to video quality in the encoder, so after Aylesbury we won’t tie that work to specific named releases.

  WebM at Streaming Media West

  Members of the WebM project will discuss Aylesbury during a session at the Streaming Media West conference on November 3rd (session C203 : WebM Open Video Project Update). For more information, visit www.streamingmedia.com/west.

  John Luther is Product Manager of the WebM Project.