Recherche avancée

Sur d’autres sites (6877)

• FFMPEG Motion Compensation and Search

  20 juin 2016, par Tina Jasmin

  I’m trying to modify the motion detection part of FFMPEG. What I want to do is to extend the search space, so that whenever the macroblock hit the right most edge of the frame, I need it to still move the block towards the left-most as if they are connected (in my example videos, the right edge is actually a continue of the left edge). Can someone help me to point where exactly I can modify it within FFMPEG source code or x265, or x264 ?

  

  I took H265 as an example from here. It has a motion.cpp file which nicely specifies the possible block sizes as below. But I can’t find the specific loop that traverses the frame. A help is highly appreciated.

  #define SETUP_SCALE(W, H) \
  
      sizeScale[LUMA_ ## W ## x ## H] = (H * H) >> 4;
  
      SETUP_SCALE(4, 4);
  
      SETUP_SCALE(8, 8);
  
      SETUP_SCALE(8, 4);
  
      SETUP_SCALE(4, 8);
  
      SETUP_SCALE(16, 16);
  
      SETUP_SCALE(16, 8);
  
      SETUP_SCALE(8, 16);
  
      SETUP_SCALE(16, 12);
  
      SETUP_SCALE(12, 16);
  
      SETUP_SCALE(4, 16);
  
      SETUP_SCALE(16, 4);
  
      SETUP_SCALE(32, 32);
  
      SETUP_SCALE(32, 16);
  
      SETUP_SCALE(16, 32);
  
      SETUP_SCALE(32, 24);
  
      SETUP_SCALE(24, 32);
  
      SETUP_SCALE(32, 8);
  
      SETUP_SCALE(8, 32);
  
      SETUP_SCALE(64, 64);
  
      SETUP_SCALE(64, 32);
  
      SETUP_SCALE(32, 64);
  
      SETUP_SCALE(64, 48);
  
      SETUP_SCALE(48, 64);
  
      SETUP_SCALE(64, 16);
  
      SETUP_SCALE(16, 64);
  
  #undef SETUP_SCALE

  UPDATE :

  One way to do that (in x265) is to modify the edge extension area (which is already in the code, in the frameFilter.cpp), and do that for rightmost and fill blocks with leftmost pixels. I identified the piece of code here. Can someone help me to add this feature for right-to-left extension ?

  if ((col == 0) | (col == m_frameFilter->m_numCols - 1))
  
      {
  
          // TODO: improve by process on Left or Right only
  
          primitives.extendRowBorder(reconPic->getLumaAddr(m_rowAddr), stride, reconPic->m_picWidth, realH, reconPic->m_lumaMarginX);
  
  
  
          if (m_frameFilter->m_param->internalCsp != X265_CSP_I400)
  
          {
  
              primitives.extendRowBorder(reconPic->getCbAddr(m_rowAddr), strideC, reconPic->m_picWidth >> hChromaShift, realH >> vChromaShift, reconPic->m_chromaMarginX);
  
              primitives.extendRowBorder(reconPic->getCrAddr(m_rowAddr), strideC, reconPic->m_picWidth >> hChromaShift, realH >> vChromaShift, reconPic->m_chromaMarginX);
  
          }
  
      }
  
  
  
      // Extra Left and Right border on first and last CU
  
      if ((col == 0) | (col == m_frameFilter->m_numCols - 1))
  
      {
  
          copySizeY += lumaMarginX;
  
          copySizeC += chromaMarginX;
  
      }
  
  
  
      // First column need extension left padding area and first CU
  
      if (col == 0)
  
      {
  
          pixY -= lumaMarginX;
  
          pixU -= chromaMarginX;
  
          pixV -= chromaMarginX;
  
      }

• nvenc : De-compensate aspect ratio compensation of DVD-like content.

  28 janvier 2015, par Philip Langdale

  nvenc : De-compensate aspect ratio compensation of DVD-like content.
  For reasons we are not privy to, nvidia decided that the nvenc encoder
  
  should apply aspect ratio compensation to ’DVD like’ content, assuming that
  
  the content is not BT.601 compliant, but needs to be BT.601 compliant. In
  
  this context, that means that they make the following, questionable,
  
  assumptions :
  1) If the input dimensions are 720x480 or 720x576, assume the content has
  
  an active area of 704x480 or 704x576.
  2) Assume that whatever the input sample aspect ratio is, it does not account
  
  for the difference between ’physical’ and ’active’ dimensions.
  From these assumptions, they then conclude that they can ’help’, by adjusting
  
  the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
  
  display only the 704 wide active area with the same aspect ratio as the full
  
  720 wide image - this would be the correct adjustment factor, but what if you
  
  don’t ? And more importantly, what if you’re used to lavc not making this kind
  
  of adjustment at encode time - because none of the other encoders do this !
  And, what if you had already accounted for BT.601 and your input had the
  
  correct attributes ? Well, it’s going to apply the compensation anyway !
  
  So, if you take some content, and feed it through nvenc repeatedly, it
  
  will keep scaling the aspect ratio every time, stretching your video out
  
  more and more and more.
  So, clearly, regardless of whether you want to apply bt.601 aspect ratio
  
  adjustments or not, this is not the way to do it. With any other lavc
  
  encoder, you would do it as part of defining your input parameters or do
  
  the adjustment at playback time, and there’s no reason by nvenc should
  
  be any different.
  This change adds some logic to undo the compensation that nvenc would
  
  otherwise do.
  nvidia engineers have told us that they will work to make this
  
  compensation mechanism optional in a future release of the nvenc
  
  SDK. At that point, we can adapt accordingly.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  
  Reviewed-by : Timo Rothenpieler <timo@rothenpieler.org>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavcodec/nvenc.c

• Per macroblock encoding in libx264

  12 janvier, par Wei.M

  I know that in x264 encoding, the process is going on with the unit of macroblock. However, is that possible to set the parameters for each macroblocks ? For example, if I want to let the QP of some specific area to be smaller than others. Is that possible ? If I need to modify the functions and Apis in libx264, where should I begin ?