Recherche avancée

Sur d’autres sites (10959)

• fate/matroska : Add test for avoiding negative timestamps

  18 janvier 2022, par Andreas Rheinhardt

  fate/matroska : Add test for avoiding negative timestamps
  This tests the issue from tickets #4536, #5784 ;
  
  the output of this test is currently broken.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] tests/fate/matroska.mak
  • [DH] tests/ref/fate/matroska-avoid-negative-ts

• avformat/mux : Preserve sync even if later packet has negative ts

  18 janvier 2022, par Andreas Rheinhardt

  avformat/mux : Preserve sync even if later packet has negative ts
  write_packet() has code to shift the packets timestamps
  
  to make them nonnegative or even make them start at ts zero ;
  
  this code inspects every packet that is written and if a packet
  
  with negative timestamp (whether this is dts or pts depends upon
  
  another flag ; basically : Matroska uses pts, everyone else dts)
  
  is encountered, this is offset to make the timestamp zero.
  
  All further packets will be offset accordingly (with the offset
  
  converted according to the streams' timebases).
  This is based around an assumption, namely that the timestamps
  
  are indeed non-decreasing, so that the first packet with negative
  
  timestamps is the first packet with timestamps. This assumption
  
  is often fulfilled given that the default interleavement function
  
  by default interleaves per dts ; yet there are scenarios in which
  
  it may not be fulfilled :
  
  a) av_write_frame() instead of av_interleaved_write_frame() is used.
  
  b) The audio_preload option is used.
  
  c) When the timestamps that are made nonnegative/zero are pts
  
  (i.e. with Matroska), because the packet with the smallest dts
  
  is not necessarily the packet with the smallest pts.
  
  d) Possibly with custom interleavement functions.
  
  In these cases the relative sync of the first few packet(s) is offset
  
  relative to the later packets. This contradicts the documentation
  
  ("When shifting is enabled, all output timestamps are shifted by
  
  the same amount").
  Therefore this commit changes this : As soon as the first packet
  
  with valid timestamps is output, it is checked and recorded whether
  
  the timestamps need to be shifted. Further packets are no longer
  
  checked for needing to be offset ; instead they are simply offset.
  
  In the cases above this leads to packets with negative timestamps
  
  (and the appropriate warnings) instead of desync. This will mostly
  
  be fixed in the next commit.
  This commit also factors handling the avoid_negative_ts stuff out
  
  of write_packet() in order to be able to return immediately.
  Tickets #4536 and #5784 as well as the matroska-avoid-negative-ts-test
  
  are examples of c) ; as has been said, some timestamps are now negative,
  
  yet the ref file update does not show it because ffmpeg.c sanitizes
  
  the timestamps (-copyts disables it ; ffprobe and mkvinfo also show
  
  the original timestamps).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/internal.h
  • [DH] libavformat/mux.c
  • [DH] libavformat/options.c
  • [DH] tests/fate/matroska.mak
  • [DH] tests/ref/fate/matroska-avoid-negative-ts

• libswresample/swresamplec : Err num(negative-size) was used as a function parameter

  8 décembre 2021, par Yu Yang

  libswresample/swresamplec : Err num(negative-size) was used as a function parameter
  If memory allocation fails, ERROR(ENOMEM) '-12' will be returned.
  
  When resample() is done first, the negative size param would cause buffer-overflow and SEGV in swri_rematrix().
  
  When swri_rematrix() is run first, resample() would not cause an error but Err num as a wrong parameter passing.
  
  Err num should be returned immediately. And remove an unneeded term from an assert.
  coredump info :
  
      #0 0x499517 in posix_memalign (/home/r1/ffmpeg/ffmpeg_4.4.1+0x499517)
  
      #1 0x6c1f0b4 in av_malloc /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:86:9
  
      #2 0x6c208fe in av_mallocz /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:239:17
  
      #3 0x6c207ad in av_mallocz_array /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:195:12
  
      #4 0x654b2e5 in swri_realloc_audio /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:418:14
  
      #5 0x654f9a1 in swr_convert_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:601:17
  
      #6 0x654d2c0 in swr_convert /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:766:19
  
      #7 0x186cf56 in flush_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:251:13
  
      #8 0x186a454 in request_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:288:20
  
      #9 0x787d9c in ff_request_frame_to_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:459:15
  
      #10 0x7877f1 in forward_status_change /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1257:19
  
      #11 0x77ed7e in ff_filter_activate_default /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1288:20
  
      #12 0x77e4e1 in ff_filter_activate /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1441:11
  
      #13 0x793b3f in ff_filter_graph_run_once /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1403:12
  
      #14 0x7a7bee in get_frame_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:131:19
  
      #15 0x7a7287 in av_buffersink_get_frame_flags /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:142:12
  
      #16 0x792888 in avfilter_graph_request_oldest /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1356:17
  
      #17 0x5d07df in transcode_from_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4639:11
  
      #18 0x59e557 in transcode_step /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4729:20
  
      #19 0x593970 in transcode /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4805:15
  
      #20 0x58f7a4 in main /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:5010:9
  
      #21 0x7f6fd2dee0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
  SUMMARY : AddressSanitizer : negative-size-param (/home/r1/ffmpeg/ffmpeg_4.4.1+0x497e67) in __asan_memcpy
  Reported-by : TOTE Robot <oslab@tsinghua.edu.cn>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libswresample/swresample.c