Recherche avancée

Sur d’autres sites (6506)

• 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

• 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

• avcodec/startcode : Avoid unaligned accesses

  21 janvier 2020, par Andreas Rheinhardt

  avcodec/startcode : Avoid unaligned accesses
  Up until now, ff_startcode_find_candidate_c() simply casts
  
  an uint8_t* to uint64_t*/uint32_t* to read 64/32 bits at a time
  
  in case HAVE_FAST_UNALIGNED is true. Yet this ignores the
  
  alignment requirement of these types as well as effective type
  
  rules of the C standard. This commit therefore replaces these
  
  direct accesses with AV_RN64/32 ; this also improves
  
  readability.
  UBSan reported these unaligned accesses which happened in 233
  
  FATE-tests involving H.264 and VC-1 (this has also been reported
  
  in tickets #8138 and #8485) ; these tests are fixed by this commit.
  The output of GCC with -O3 is unchanged for aarch64, loongarch,
  
  ppc and x64 (as well as for arches like alpha for which
  
  HAVE_FAST_UNALIGNED is never true in the first place).
  
  There was only a slight difference for mips and arm.
  
  I don't know about the speed impact of them.
  Reviewed-by : Anton Khirnov <anton@khirnov.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/startcode.c