Recherche avancée

Sur d’autres sites (11000)

• 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.

• avformat/mpc8 : fix hang with fuzzed file

  3 février 2015, par wm4

  avformat/mpc8 : fix hang with fuzzed file
  This can lead to an endless loop by seeking back a few bytes after each
  
  attempted chunk read. Assuming negative sizes are always invalid, this
  
  is easy to fix. Other code in this demuxer treats negative sizes as
  
  invalid as well.
  Fixes ticket #4262.
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/mpc8.c

• Revision 3b5a90bd86 : Enable adaptive pred filter type for sub8x8 This commit enables an adaptive pre

  13 décembre 2013, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Enable adaptive pred filter type for sub8x8

  This commit enables an adaptive prediction filter type selection
  for sub8x8 block sizes. In speed 1, it re-uses the filter type of
  collocated 8x8 block if it is tested in the rate-distortion optimization
  loop, for the sub8x8 blocks. Otherwise, it runs the normal test
  over all the three filter types. In speed 2, it re-uses the 8x8
  block's prediction filter type, if available. Otherwise, force it
  to be EIGHTTAP.

  Compression and speed performance wise :
  speed 1
  derf -0.266%
  yt -0.138%

  bus at 2000 kbps : 33766ms -> 30451ms (10% speed-up)
  football at 600 kbps : 48173ms -> 43786ms (9% speed-up)

  speed 2
  derf -0.026%
  yt +0.134%

  bus at 2000 kbps : 18973ms -> 17698ms (6% speed-up)
  football at 600 kbps : 26748ms -> 25096ms (6% speed-up)

  Change-Id : I77e097533b969fd3472147225fa79fc98095d342