Recherche avancée

Sur d’autres sites (8697)

• lavu/hwcontext_qsv : add loader field to AVQSVDeviceContext

  5 juillet 2022, par Haihao Xiang

  lavu/hwcontext_qsv : add loader field to AVQSVDeviceContext
  In oneVPL, a valid mfxLoader handle is needed when creating mfx session
  
  for decoding, encoding and processing[1], so add loader field to
  
  AVQSVDeviceContext. User should fill this field before calling
  
  av_hwdevice_ctx_init() if using oneVPL
  This is in preparation for oneVPL support
  [1]https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html#onevpl-dispatcher
  

  • [DH] doc/APIchanges
  • [DH] libavutil/hwcontext_qsv.h
  • [DH] libavutil/version.h

• vulkan_av1 : add workaround for NVIDIA drivers tested on broken CTS

  14 avril 2024, par Lynne

  vulkan_av1 : add workaround for NVIDIA drivers tested on broken CTS
  The first release of the CTS for AV1 decoding had incorrect
  
  offsets for the OrderHints values.
  
  The CTS will be fixed, and eventually, the drivers will be
  
  updated to the proper spec-conforming behaviour, but we still
  
  need to add a workaround as this will take months.
  Only NVIDIA use these values at all, so limit the workaround
  
  to only NVIDIA. Also, other vendors don't tend to provide accurate
  
  CTS information.
  

  • [DH] libavcodec/vulkan_av1.c
  • [DH] libavcodec/vulkan_decode.c
  • [DH] libavcodec/vulkan_decode.h

• Is it possible to generate a keyframe to start a spliced H.264 video segment ?

  3 janvier 2015, par Ethan T

  When segmenting files with ffmpeg, I am currently only able to splice on keyframe boundaries if I don’t want to reencode. This presents issues if I want to control timing down to a specific frame. To my knowledge, you can only start on a keyframe if you’re performing a stream copy. If you want to start on an arbitrary frame, you must reencode.

  However, for codecs that ffmpeg understands (like H.264), it seems like it would be technically possible to replace the desired first frame with a newly created keyframe without reencoding the rest of the video. This would represent a "smart copy" sort of behavior. For example, say my video consists of these frames and types :

  Frame number:  0         1         2         3
  
                 0123456789012345678901234567890123
  
  Frame type:    IppbppbppbppbIppbppbppbppbIppbppbp
  
  Keyframes:     ^            ^            ^

  (I frames are keyframes while p and b frames are not)

  Currently, if I want to remove the first few frames and start on exactly frame 20, I must reencode the entire stream beginning with that input frame. This would cause an undesired degradation in quality. Instead, if I perform a copy, ffmpeg would begin at the most recent keyframe :

  Frame number:  0         1         2         3
  
                 0123456789012345678901234567890123
  
  Frame type:    IppbppbppbppbIppbppbppbppbIppbppbp
  
  Desired start:                     ^
  
  Actual start:               ^

  Why can’t ffmpeg seek to frame 13 (the last complete keyframe prior to the cut point), fully calculate frame 20, and recreate frame 20 as an I frame ? It would then copy the remaining frames as before. Like this :

  Frame number:  0         1         2         3
  
                 0123456789012345678901234567890123
  
  Input type:    IppbppbppbppbIppbppbppbppbIppbppbp
  
  Output type:                       IpbppbIppbppbp

  It seems like this would be a very useful feature for splicing videos without losing quality. Is there any technical barrier (e.g. the H.264 spec or any other common codec) that prevents this approach ?