Recherche avancée

Sur d’autres sites (8794)

• 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

• 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 !

  


• Why SIGSEGV appears when trying to decode audio using libavcodec.57 and libopus-1.2 alpha2-1 ?

  10 août 2021, par Greg Joy

  I'm decoding audio using FFMPEG libavcodec's function avcodec_decode_audio4(). Everything works perfect on Windows and Ubuntu 18.04, but I receive segmentation fault when trying to run the same app on Debian 9. I've debugged my code with gdb, and it showed this result :

  


  Thread 24 "SDLAudioDev2" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fea700 (LWP 1657)]
0x00007fffecdd6eff in ?? () from /usr/lib/x86_64-linux-gnu/libopus.so.0
(gdb) bt
#0  0x00007fffecdd6eff in ?? ()
   from /usr/lib/x86_64-linux-gnu/libopus.so.0
#1  0x00007fffecde0b18 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libopus.so.0
#2  0x00007fffece04ac1 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libopus.so.0
#3  0x00007fffece05b5b in ?? ()
   from /usr/lib/x86_64-linux-gnu/libopus.so.0
#4  0x00007fffece0e87e in ?? ()
   from /usr/lib/x86_64-linux-gnu/libopus.so.0
#5  0x00007fffece0eba7 in opus_multistream_decode ()
   from /usr/lib/x86_64-linux-gnu/libopus.so.0
#6  0x00007ffff4f8a235 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libavcodec.so.57
#7  0x00007ffff51893fd in avcodec_decode_audio4 ()
   from /usr/lib/x86_64-linux-gnu/libavcodec.so.57
#8  0x00007ffff5189e78 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libavcodec.so.57
#9  0x00007ffff518f098 in avcodec_send_packet ()


  


  Seems that data race appears somewhere. I've tried to remove avcodec_decode_audio4() and use avcodec_send_packet() and avcodec_receive_frame() functions, however in libavcodec.57 of FFMPEG ver.3.2.10 function avcodec_send_packet() invokes avcodec_decode_audio4() and the problem occurs again.

  


  Could someone help me with what do I need to change to make it all be compatible with Debian 9 packages' versions, please ?

  


  On Windows I have libavcodec.58, on Ubuntu 18.04 libavcodec.57 ver.3.4.8

  


  On Debian 9 I have libavcodec.57 ver.3.2.15