Recherche avancée

Sur d’autres sites (9785)

• hwcontext_vulkan : add support for allocating all planes in a single allocation

  7 décembre 2021, par Wenbin Chen

  hwcontext_vulkan : add support for allocating all planes in a single allocation
  VAAPI on Intel can import external frame, but the planes of the external
  
  frames should be in the same drm object. A new option "contiguous_planes"
  
  is added to device. This flag tells device to allocate places in one
  
  memory. When device is derived from vaapi this flag will be enabled.
  
  A new flag frame_flag is also added to AVVulkanFramesContext. User
  
  can use this flag to force enable or disable this behaviour.
  
  A new variable "offset "is added to AVVKFrame. It describe describe the
  
  offset from the memory currently bound to the VkImage.
  Signed-off-by : Wenbin Chen <wenbin.chen@intel.com>
  
  Further-modifications-by : Lynne <dev@lynne.ee>
  

  • [DH] libavutil/hwcontext_vulkan.c
  • [DH] libavutil/hwcontext_vulkan.h

• avformat/avc, mxfenc : Avoid allocation of H264 SPS structure, fix memleak

  24 juin 2020, par Andreas Rheinhardt

  avformat/avc, mxfenc : Avoid allocation of H264 SPS structure, fix memleak
  Up until now, ff_avc_decode_sps would parse a SPS and return some
  
  properties from it in a freshly allocated structure. Yet said structure
  
  is very small and completely internal to libavformat, so there is no
  
  reason to use the heap for it. This commit therefore changes the
  
  function to return an int and to modify a caller-provided structure.
  
  This will also allow ff_avc_decode_sps to return better error codes in
  
  the future.
  It also fixes a memleak in mxfenc : If a packet contained multiple SPS,
  
  only the SPS structure belonging to the last SPS would be freed, the
  
  other ones would leak when the pointer is overwritten to point to the
  
  new SPS structure. Of course, without allocations there are no leaks.
  
  This is Coverity issue #1445194.
  Furthermore, the SPS structure has been renamed from
  
  H264SequenceParameterSet to H264SPS in order to avoid overlong lines.
  Reviewed-by : Tomas Härdin <tjoppen@acc.umu.se>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/avc.c
  • [DH] libavformat/avc.h
  • [DH] libavformat/mxfenc.c

• avfilter/vf_overlay : Fix double-free of AVFilterFormats on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/vf_overlay : Fix double-free of AVFilterFormats on error
  The query_formats function of the overlay filter tries to allocate
  
  two lists (only one in a special case) of formats which on success
  
  are attached to more permanent objects (AVFilterLinks) for storage
  
  afterwards. If attaching a list to an AVFilterLink succeeds, it is
  
  in turn owned by the AVFilterLink (or more exactly, the AVFilterLink
  
  becomes one of the common owners of the list). Yet if attaching a list
  
  to one of its links succeeds and an error happens lateron, both lists
  
  were manually freed, whic is wrong if the list is already owned by one
  
  or more links ; these links' pointers to their lists will become dangling
  
  and there will be a double-free/use-after-free when these links are
  
  cleaned up automatically.
  This commit fixes this by removing the custom freeing code ; this will
  
  temporarily add a leaking codepath (if attaching a list not already
  
  owned by a link to a link fails, the list will leak), but this will
  
  be fixed soon by making sure that an AVFilterFormats without owner will
  
  be automatically freed when attaching it to an AVFilterLink fails.
  
  Notice that at most one list leaks because a new list is only allocated
  
  after the old list has been successfully attached to a link.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/vf_overlay.c