Recherche avancée

Sur d’autres sites (7061)

• Working way to make video from images in C#

  29 août 2011, par Jim Mischel

  Does anybody have a known reliable way to create a video from a series of image files ? Before you mod me down for not searching for the answer before posting the question, and before you fire off a simple message like "use FFMPEG," read the rest of this message.

  I'm trying to create a video, it doesn't matter too much what format as long as it's widely supported, from a series of images (.jpg, .bmp, etc.). My platform is Windows Server 2008, 64-bit. If I can make the video from within my C# program, that's great, but I'm not averse to writing a series of image files to a directory and then firing off an external program to make a video from those images.

  The only constraints are : it must work on my Windows Server 2008 system, and be scriptable. That is, no GUI programs that require operator intervention.

  I found a number of similar questions on StackOverflow, and have tried several of the solutions, all with varying degrees of frustration and none with anything like success.

  FFMPEG looks like a great program. Maybe it is, on Linux. The two Windows builds I downloaded are broken. Given this command line :

    ffmpeg -r 1 -f image2 -i jpeg\*.jpg video.avi

  One of the builds reads the images and then crashes due to data execution prevention. The other reads the first file and then spits out an error message that says "cannot find suitable codec for file jpeg/image2.jpg". Helpful, that. In any case, FFMPEG looks like a non-starter under Windows.

  One answer to a previous posting recommended Splicer . It looks like pretty good code. I compiled the samples and tried to run, but got some cryptic error message about a file not found. It looks like a COM class isn't registered. I suppose I need to install something (DirectShow, maybe, although I thought that was already installed ?). Depending on what's required, I might have a difficult time justifying its installation on a server. ("What ? Why do you need that on a server ?")

  Another answer suggested the AviFile library from Code Project. That looks simple enough : a wrapper around the Windows AviFile subsystem. Except that the AVI files the package creates appear to have all of the frames, but only the first frame shows when I play the AVI in Windows Media Player. Well, that and if you try to create a compressed video, the program throws an exception.

  So, I'm left wondering if there is a good, reliable way to do what I want : on a Windows system, create an AVI or other common video file format from a series of images, either through a .NET API or using an external program. Any help ?

• ftp: probe seek capability

  7 juin 2013, par Lukasz Marek

  ftp: probe seek capability
  Make FTP streamed when server doesn’t accept REST command
  Signed-off-by : Lukasz Marek <lukasz.m.luki@gmail.com>
  

  • [DH] libavformat/ftp.c

• Tour of Part of the VP8 Process

  18 novembre 2010, par Multimedia Mike — VP8

  My toy VP8 encoder outputs a lot of textual data to illustrate exactly what it’s doing. For those who may not be exactly clear on how this or related algorithms operate, this may prove illuminating.

  Let’s look at subblock 0 of macroblock 0 of a luma plane :

   subblock 0 (original)
    92  91  89  86
    91  90  88  86
    89  89  89  88
    89  87  88  93
  

  Since it’s in the top-left corner of the image to be encoded, the phantom samples above and to the left are implicitly 128 for the purpose of intra prediction (in the VP8 algorithm).

   subblock 0 (original)
       128 128 128 128
   128  92  91  89  86
   128  91  90  88  86
   128  89  89  89  88
   128  89  87  88  93
  

  
  Using the 4×4 DC prediction mode means averaging the 4 top predictors and 4 left predictors. So, the predictor is 128. Subtract this from each element of the subblock :

   subblock 0, predictor removed
   -36 -37 -39 -42
   -37 -38 -40 -42
   -39 -39 -39 -40
   -39 -41 -40 -35
  

  Next, run the subblock through the forward transform :

   subblock 0, transformed
   -312   7   1   0
      1  12  -5   2
      2  -3   3  -1
      1   0  -2   1
  

  Quantize (integer divide) each element ; the DC (first element) and AC (rest of the elements) quantizers are both 4 :

   subblock 0, quantized
   -78   1   0   0
     0   3  -1   0
     0   0   0   0
     0   0   0   0
  

  The above block contains the coefficients that are actually transmitted (zigzagged and entropy-encoded) through the bitstream and decoded on the other end.

  The decoding process looks something like this– after the same coefficients are decoded and rearranged, they are dequantized (multiplied) by the original quantizers :

   subblock 0, dequantized
   -312   4   0   0
      0  12  -4   0
      0   0   0   0
      0   0   0   0
  

  Note that these coefficients are not exactly the same as the original, pre-quantized coefficients. This is a large part of where the “lossy” in “lossy video compression” comes from.

  Next, the decoder generates a base predictor subblock. In this case, it’s all 128 (DC prediction for top-left subblock) :

   subblock 0, predictor
    128 128 128 128
    128 128 128 128
    128 128 128 128
    128 128 128 128
  

  Finally, the dequantized coefficients are shoved through the inverse transform and added to the base predictor block :

   subblock 0, reconstructed
    91  91  89  85
    90  90  89  87
    89  88  89  90
    88  88  89  92
  

  Again, not exactly the same as the original block, but an incredible facsimile thereof.

  Note that this decoding-after-encoding demonstration is not merely pedagogical– the encoder has to decode the subblock because the encoding of successive subblocks may depend on this subblock. The encoder can’t rely on the original representation of the subblock because the decoder won’t have that– it will have the reconstructed block.

  For example, here’s the next subblock :

   subblock 1 (original)
    84  84  87  90
    85  85  86  93
    86  83  83  89
    91  85  84  87
  

  Let’s assume DC prediction once more. The 4 top predictors are still all 128 since this subblock lies along the top row. However, the 4 left predictors are the right edge of the subblock reconstructed in the previous example :

   subblock 1 (original)
      128 128 128 128
   85  84  84  87  90
   87  85  85  86  93
   90  86  83  83  89
   92  91  85  84  87
  

  The DC predictor is computed as (128 + 128 + 128 + 128 + 85 + 87 + 90 + 92 + 4) / 8 = 108 (the extra +4 is for rounding considerations). (Note that in this case, using the original subblock’s right edge would also have resulted in 108, but that’s beside the point.)

  Continuing through the same process as in subblock 0 :

   subblock 1, predictor removed
   -24 -24 -21 -18
   -23 -23 -22 -15
   -22 -25 -25 -19
   -17 -23 -24 -21
   subblock 1, transformed
  
   -173  -9  14  -1
  
      2 -11  -4   0
  
      1   6  -2   3
  
     -5   1   0   1
   subblock 1, quantized
  
   -43  -2   3   0
  
     0  -2  -1   0
  
     0   1   0   0
  
    -1   0   0   0
   subblock 1, dequantized
  
   -172  -8  12   0
  
      0  -8  -4   0
  
      0   4   0   0
  
     -4   0   0   0
   subblock 1, predictor
  
    108 108 108 108
  
    108 108 108 108
  
    108 108 108 108
  
    108 108 108 108
   subblock 1, reconstructed
  
    84  84  87  89
  
    86  85  87  91
  
    86  83  84  89
  
    90  85  84  88
  

  I hope this concrete example (straight from a working codec) clarifies this part of the VP8 process.