Recherche avancée

Sur d’autres sites (8542)

• FFMPEG Aligning Timestamps in m3u8 Stream

  16 septembre 2021, par maxwellray

  I'm receiving an m3u8 stream with the following structure

  


  #EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:YES
#EXT-X-MEDIA-SEQUENCE:1193
#EXT-X-PROGRAM-DATE-TIME:2021-09-15T22:57:30+00:00
#EXT-X-TARGETDURATION:11
#EXTINF:10.054589,
20210915220000/20210915225710.ts
#EXTINF:10.008855,
20210915220000/20210915225720.ts


  


  Every 10 seconds, the playlist is updated with a new media file path and the oldest media path is removed. Each media file path contains a clip that is approximately 10 seconds long (i.e., over a very long time, the average length of each clip should be 10 seconds). Each media path is timestamped, rounded to 10 seconds.

  


  I run a system where I record continuous 32-minute clips of this stream using ffmpeg, and I need to know the exact timestamp where I start to record and where I stop. I'm encountering a sort of race condition where ffmpeg will start recording at the beginning of the oldest clip in the playlist instead of when it actually gets kicked off. The problem is illustrated below

  


  Clip 1: |==========|
Clip 2:            |==========|
FFMPEG:    |==================| <= ffmpeg is kicked off at t=3
OUTPUT: |=====================| <= but video would actually start at t=0


  


  I'm wondering if there's a way to ensure that the clips I record actually start when ffmpeg is kicked off, not from the start of the earliest clip in the stream.

  


  Thanks !

  


• swscale/swscale : Fix races when using unaligned strides/data

  18 septembre 2021, par Andreas Rheinhardt

  swscale/swscale : Fix races when using unaligned strides/data
  In this case the current code tries to warn once ; to do so, it uses
  
  ordinary static ints to store whether the warning has already been
  
  emitted. This is both a data race (and therefore undefined behaviour)
  
  as well as a race condition, because it is really possible for multiple
  
  threads to be the one thread to emit the warning. This is actually
  
  common since the introduction of the new multithreaded scaling API.
  This commit fixes this by using atomic integers for the state ;
  
  furthermore, these are not static anymore, but rather contained
  
  in the user-facing SwsContext (i.e. the parent SwsContext in case
  
  of slice-threading).
  Given that these atomic variables are not intended for synchronization
  
  at all (but only for atomicity, i.e. only to output the warning once),
  
  the atomic operations use memory_order_relaxed.
  This affected the nv12, nv21, yuv420, yuv420p10, yuv422, yuv422p10 and
  
  yuv444 filter-overlay FATE-tests.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libswscale/swscale.c
  • [DH] libswscale/swscale_internal.h
  • [DH] libswscale/utils.c

• lavu/vulkan : add support for using libshaderc as a GLSL compiler

  19 novembre 2021, par Lynne

  lavu/vulkan : add support for using libshaderc as a GLSL compiler
  It's got a much better API that's actually maintained, it eliminates
  
  race conditions, it comes with a pkg-config file by default, and
  
  unfortunately isn't currently packaged by Debian or other large
  
  distributions.
  

  • [DH] configure
  • [DH] libavutil/vulkan.c
  • [DH] libavutil/vulkan_shaderc.c