Recherche avancée

Sur d’autres sites (4389)

• More Weird VP8 Encodings

  10 décembre 2010, par Multimedia Mike — VP8

  When I announced that I had transitioned my VP8 encoder’s status from "toy" to "working", Jim L. lamented the loss of humorous posts about oddly encoded images output from my encoder. Not so ! There are still plenty of features that I have yet to implement, each of which carries the possibility of bizarre images.

  For example, I dusted off my work-in-progress intra 4x4 encoding, fixed a few of the more obvious bugs, and told the encoder to encode the first block in 4x4 mode and the rest in the usual, working, debugged 16x16 mode. The results of the first pass surprised me :

  
  
  

  The reason this surprised me was that I intuitively expected one of 2 outcomes :

  • Perfect image right away since everything is correct (very unlikely but not outside the realm of possibility)
  • Total garbage with, at most, the first macroblock looking somewhat legible ; this would be due to having some of the first macroblock correct but completely desynchronizing the bitstream for the purpose of decoding the rest of the coefficients.

  I absolutely did not expect the first macroblock to look messed up but for the rest of the picture to look fine. For fun, I reversed the logic and encoded the first block as 16x16 and the rest with the experimental 4x4 mode :

  
  
  

  If you examine carefully, you will see that the color planes are correct (though faint). There just isn’t much going on in the luma plane. This made sense when I noticed the encoder was encoding a blank (undefined, actually) set of luma coefficients for 4x4 mode macroblocks due to a bug. This helps to rationalize the first image as well— the first macroblock was encoding nonsense for the first macroblock which messed up the macroblocks which immediately surrounded it. Eventually, macroblock decoding got back on track when the prediction modes weren’t relying on the errantly decoded macroblocks.

  After I fixed that bug, I let the 4x4 mode rip through the whole image. That’s when I got what I am terming the "dark and gritty reboot of Big Buck Bunny" :

  
  
  

  Fortunately, this also turned out to be traceable to a pretty obvious code bug.

  One day, this VP8 encoder might do the right thing while implementing all of the algorithm’s features. In the meantime, it’s at least entertaining to watch it make mistakes.

• error while compiling x264 in linux

  14 avril 2011, par kartul

  Hey all
  I'm trying to compile x264 under linux (x64). But it keeps throwing me an error. I've googled around but found nothing. Here's the commandline history :

  spin@around : /x264$ git clone git ://git.videolan.org/x264.git
  Cloning into x264...
  remote : Counting objects : 13539, done.
  remote : Compressing objects : 100% (4416/4416), done.
  remote : Total 13539 (delta 11005), reused 11225 (delta 9082)
  Receiving objects : 100% (13539/13539), 3.29 MiB | 2.79 MiB/s, done.
  Resolving deltas : 100% (11005/11005), done.
  spin@around : /x264/x264$ ./configure
  Found no assembler
  Minimum version is yasm-0.7.0
  If you really want to compile without asm, configure with —disable-asm.
  spin@around : /x264/x264$ ./configure —disable-asm
  Platform :   X86_64
  System :     LINUX
  asm :        no
  avs :        no
  lavf :       no
  ffms :       no
  gpac :       no
  gpl :        yes
  thread :     posix
  filters :    crop select_every
  debug :      no
  gprof :      no
  PIC :        no
  shared :     no
  visualize :  no
  bit depth :  8
  You can run 'make' or 'make fprofiled' now.
  
  spin@around : /x264/x264$ make
  
  gcc -Wshadow -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer -fno-tree-vectorize   -c -o x264.o x264.c
  
  In file included from common/common.h:864,
  
                   from x264.c:33 :
  
  common/rectangle.h : In function āx264_macroblock_cache_rectā :
  
  common/rectangle.h:84 : error : āv4siā undeclared (first use in this function)
  
  common/rectangle.h:84 : error : (Each undeclared identifier is reported only once
  
  common/rectangle.h:84 : error : for each function it appears in.)
  
  common/rectangle.h:84 : error : expected ā ;ā before āv16ā
  
  common/rectangle.h:86 : error : ā__m128ā undeclared (first use in this function)
  
  common/rectangle.h:86 : error : expected ā ;ā before āv16ā
  
  common/rectangle.h:87 : error : expected ā ;ā before āv16ā
  
  common/rectangle.h:89 : error : expected ā ;ā before āv16ā
  
  common/rectangle.h:90 : error : expected ā ;ā before āv16ā
  
  make : *** [x264.o] Error 1
  
  spin@around : /x264/x264$
  

  and here is the file, from line 83 to 91 :

  #if HAVE_VECTOREXT && defined(__SSE__)
          v4si v16 = v,v,v,v ;
          M128( d+s*0+0 ) = (__m128)v16 ;
  
          M128( d+s*1+0 ) = (__m128)v16 ;
  
          if( h == 2 ) return ;
  
          M128( d+s*2+0 ) = (__m128)v16 ;
  
          M128( d+s*3+0 ) = (__m128)v16 ;
  
  #else
  

• FFMpeg Image Capture - continous frames

  19 juillet 2012, par user1537351

  I would like to capture continuous frames from a mpeg video file starting from a specific time stamp. That means assume that I have a video which has total duration of 2 minutes. I need to capture all the frames which are continuous from time 00:01:00. I also want to limit the number of frames capturing to 20. How can I make ffmpeg executable to do this

  Thanks
  Faisal