Recherche avancée

Sur d’autres sites (2947)

• Rotating videos with FFmpeg

  19 février 2016, par jocull

  I have been trying to figure out how to rotate videos with FFmpeg. I am working with iPhone videos taken in portrait mode. I know how to determine the current degrees of rotation using MediaInfo (excellent library, btw) but I’m stuck on FFmpeg now.

  From what I’ve read, what you need to use is a vfilter option. According to what I see, it should look like this :

  ffmpeg -vfilters "rotate=90" -i input.mp4 output.mp4

  However, I can’t get this to work. First, -vfilters doesn’t exist anymore, it’s now just -vf. Second, I get this error :

  No such filter: 'rotate'
  
  Error opening filters!

  As far as I know, I have an all-options-on build of FFmpeg. Running ffmpeg -filters shows this :

  Filters:
  
  anull            Pass the source unchanged to the output.
  
  aspect           Set the frame aspect ratio.
  
  crop             Crop the input video to x:y:width:height.
  
  fifo             Buffer input images and send them when they are requested.
  
  format           Convert the input video to one of the specified pixel formats.
  
  hflip            Horizontally flip the input video.
  
  noformat         Force libavfilter not to use any of the specified pixel formats
  
   for the input to the next filter.
  
  null             Pass the source unchanged to the output.
  
  pad              Pad input image to width:height[:x:y[:color]] (default x and y:
  
   0, default color: black).
  
  pixdesctest      Test pixel format definitions.
  
  pixelaspect      Set the pixel aspect ratio.
  
  scale            Scale the input video to width:height size and/or convert the i
  
  mage format.
  
  slicify          Pass the images of input video on to next video filter as multi
  
  ple slices.
  
  unsharp          Sharpen or blur the input video.
  
  vflip            Flip the input video vertically.
  
  buffer           Buffer video frames, and make them accessible to the filterchai
  
  n.
  
  color            Provide an uniformly colored input, syntax is: [color[:size[:ra
  
  te]]]
  
  nullsrc          Null video source, never return images.
  
  nullsink         Do absolutely nothing with the input video.

  Having the options for vflip and hflip are great and all, but they just won’t get me where I need to go. I need to the ability to rotate videos 90 degrees at the very least. 270 degrees would be an excellent option to have as well. Where have the rotate options gone ?

• Gallery of VP8 Encoding Naivete

  15 octobre 2010, par Multimedia Mike — VP8

  I’ve been toiling away as a multimedia technology generalist for so long that it’s easy for me to forget that not everyone is as versed in the minutiae of the domain as I am. But I recently experienced what it’s like to be such an outsider when I posted about my toy VP8 encoder, expressing that it’s one of the hardest things I have ever tried to do. I heard of from number of people who do have extensive experience in video encoding, particularly with the H.264 and VP8 codecs. Their reactions were predictable : What’s so hard ? Look, you might be a little too immersed in the area to really understand a relative beginner’s perspective.

  And to all the people who suggested that I should get the encoder into FFmpeg ASAP : Are you crazy ?! Did you see what the first pass of the encoder produced ? Do you have lower standards than even I do ?

  
  
  

  Not Giving Up
  I worked a little more on the toy encoder. Remember that the above image is what I’m hoping to encode somewhat faithfully for this experiment. In my first pass, I attempted vertical prediction for all planes. For my next pass, I forced the chroma planes to mid-level (which results in a greyscale image) and played with the 16×16 luma prediction modes. When implementing an extremely naive algorithm to decide which 16×16 prediction mode would be the best for a particular block, this is what the program produced :

  
  
  

  For fun, here is what the image encodes to when forcing various prediction modes :
  

  I think the DC-only prediction mode actually looks a little better than the image that the naive algorithm produced :

  
  
  

  Vertical 16×16 prediction, similar to the image from the last post (just in black and white) :
  

  
  
  

  Horizontal 16×16 prediction :
  

  
  
  

  This is the 16×16 prediction mode unique to VP8, the TrueMotion mode (based on On2/Duck’s very first video codec) :
  

  
  
  

  Wow, these encodings really bring down the cheerful tone of the original image.

  Next Steps
  I have little reason to believe that I am encoding and subsequently reconstructing the image correctly (i.e., error is likely propagating through the entire encoding). If I have time, the next step is to validate my reconstruction against the encoder. Then I need to get the entropy considerations correct so that I actually get some compression out of this format.

• Understanding the VP8 Token Tree

  7 juin 2010, par Multimedia Mike — VP8

  I got tripped up on another part of the VP8 decoding process today. So I drew a picture to help myself understand it. Then I went back and read David Conrad’s comment on my last post regarding my difficulty understanding the VP8 spec and saw that he ran into the same problem. Since we both experienced the same hindrance in trying to sort out this matter, I thought I may as well publish the picture I drew.

  VP8 defines various trees for decoding different syntax elements. There is one tree for decoding the tokens and it is expressed in the VP8 spec as such :

  PLAIN TEXT

  C :

  1. const tree_index coef_tree [2 * (num_dct_tokens - 1)] =
  2. {
  3.  -dct_eob, 2,        /* eob = "0"  */
  4.   -DCT_0, 4,        /* 0  = "10" */
  5.   -DCT_1, 6,        /* 1  = "110" */
  6.    8, 12,
  7.    -DCT_2, 10,      /* 2  = "11100" */
  8.     -DCT_3, -DCT_4,    /* 3  = "111010", 4 = "111011" */
  9.    14, 16,
  10.     -dct_cat1, -dct_cat2, /* cat1 = "111100", cat2 = "111101" */
  11.    18, 20,
  12.     -dct_cat3, -dct_cat4, /* cat3 = "1111100", cat4 = "1111101" */
  13.     -dct_cat5, -dct_cat6 /* cat4 = "1111110", cat4 = "1111111" */
  14. } ;

  Here is what the table looks like when you make a tree out of it (click for full size image) :

  
  
  

  The catch is that it makes no sense for an end-of-block (EOB) token to follow a 0 token since EOB already indicates that the remainder of the coefficients should be 0 anyway. Thus, the spec states that, "decoding of certain DCT coefficients may skip the first branch, whose preceding coefficient is a DCT_0." I confess, I didn’t understand what "skip the first branch" meant until I drew the tree.

  
  
  

  For those wondering why it might be sub-optimal (clarity-wise) for a spec to simply regurgitate vast chunks of C code, this makes a decent case. As you can see, the spec makes certain assumptions about how a binary tree should be organized in a static array (node n points to elements n*2 and n*2+1 as its branches ; leaves are either negative or 0). This is the second method I have seen ; another piece of code (not the VP8 spec) had the nodes in the first half of the array and pointed to leaves in the second half. There must be other arrangements.