Recherche avancée

Sur d’autres sites (8154)

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

  28 janvier 2015, par Philip Langdale

  avcodec/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 ffmpeg 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 ffmpeg
  
  encoder, you would do it as part of defining your input paramters 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 : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/nvenc.c

• How to fill/calculate motion_val in FFMPEG ?

  10 février 2015, par MenuItem42

  I’m trying to get motion vectors of a mpeg video via ffmpeg (in c++).
  The problem that I have is, that motion_val along with motion_subsample_log2 and mb_type of the AVFrame class remain empty and/or aren’t initialized (debugger says 0x0) and it seems that they are only available because of compatibility reasons
  I’ve read in the ffmpeg wiki, that you can debug the motion vectors of the video via command line with

  ffmpeg -vismv pf -i input.mp4 output.mp4

  The result is that the output.mp4 has motion vector arrows. So I searched for the –vismv parameter in the code and found in libavcodec\options.c a long list of options :

  {"vismv", "visualize motion vectors (MVs)", OFFSET(debug_mv), FF_OPT_TYPE_INT, DEFAULT, 0, INT_MAX, V|D, "debug_mv"},   

  I suppose that this line affects somehow debug_mv of AVCodecContext. With this assumption I searched for further information and I found some code snippets which I thought might help.

  pAVCodecContext->debug_mv =  FF_DEBUG_VIS_MV_P_FOR | FF_DEBUG_VIS_MV_B_FOR | FF_DEBUG_MB_TYPE | FF_DEBUG_MV;

  and

  pAVCodecContext->debug |= FF_DEBUG_MV;    

  But both didn’t trigger the calculation or filling of the motion_val array.
  By the way my code is based on the code by Victor Hsieh and Jiasi Chen and this code is basically the ffmpeg sourcecode (libavcodec\mpegvideo.c). I also tried to find (also with help of the documentation) the piece of code that triggers the calculation, but because of the complexity of the code I didn’t get any results.
  The question is now, if is there any possibility to fill this variables or start the calculation of the motion vector table or is there any other alternative way to get the motion vectors of every block of the mpeg-frames.

  Edit :

  I forgot to mention my ffmpeg version

  Zeranoe’s FFmpeg version : 2014-07-08 git-14e2406

  • libavutil 52. 91.100 / 52. 91.100
  • libavcodec 55. 68.102 / 55. 68.102
  • libavformat 55. 45.100 / 55. 45.100
  • libavdevice 55. 13.101 / 55. 13.101
  • libavfilter 4. 10.100 / 4. 10.100
  • libswscale 2. 6.100 / 2. 6.100
  • libswresample 0. 19.100 / 0. 19.100
  • libpostproc 52. 3.100 / 52. 3.100

  Changed to a newer version (2.5), but it didn’t change/solve the problem.

• aarch64/tx_float : fix compilation

  6 septembre 2022, par Lynne

  aarch64/tx_float : fix compilation
  Forgot to add the new function arguments.
  

  • [DH] libavutil/aarch64/tx_float_init.c