Recherche avancée

Sur d’autres sites (9530)

• avcodec/ituh263dec : Make the condition for the studio slice start code match between...

  14 septembre 2019, par Michael Niedermayer

  avcodec/ituh263dec : Make the condition for the studio slice start code match between ff_h263_resync() and ff_mpeg4_decode_studio_slice_header()
  If they mismatch an infinite loop can occur
  
  Fixes : Timeout (infinite loop)
  
  Fixes : 17043/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5695051748868096
  Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/ituh263dec.c

• lavu/pixdesc : favour formats where depth and subsampling exactly match

  8 septembre 2022, par Philip Langdale

  lavu/pixdesc : favour formats where depth and subsampling exactly match
  Since introducing the various packed formats used by VAAPI (and p012),
  
  we've noticed that there's actually a gap in how
  
  av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value
  
  to having the same bit depth as the source format, when comparing
  
  against formats with a higher bit depth. This usually doesn't matter,
  
  because av_get_padded_bits_per_pixel() will account for it.
  However, as many of these formats use padding internally, we find that
  
  av_get_padded_bits_per_pixel() actually returns the same value for the
  
  10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end
  
  up just picking the first of the two provided formats, even if the
  
  second one should be preferred because it matches the actual bit depth.
  This bug already existed if you tried to compare yuv420p10 against p016
  
  and p010, for example, but it simply hadn't come up before so we never
  
  noticed.
  But now, we actually got a situation in the VAAPI VP9 decoder where it
  
  offers both p010 and p012 because Profile 3 could be either depth and
  
  ends up picking p012 for 10 bit content due to the ordering of the
  
  testing.
  In addition, in the process of testing the fix, I realised we have the
  
  same gap when it comes to chroma subsampling - we do not favour a
  
  format that has exactly the same subsampling vs one with less
  
  subsampling when all else is equal.
  To fix this, I'm introducing a small score penalty if the bit depth or
  
  subsampling doesn't exactly match the source format. This will break
  
  the tie in favour of the format with the exact match, but not offset
  
  any of the other scoring penalties we already have.
  I have added a set of tests around these formats which will fail
  
  without this fix.
  

  • [DH] libavutil/pixdesc.c
  • [DH] libavutil/pixdesc.h
  • [DH] libavutil/tests/pixfmt_best.c
  • [DH] libavutil/version.h
  • [DH] tests/ref/fate/pixfmt_best

• Why does FFmpeg's xfade filter need the timebase and frame rate to match ? [closed]

  19 juin, par Hashim Aziz

  As I discovered not long ago, and recently had to rediscover after trying to use it again, xfade - the crossfade filter that FFmpeg introduced in 2019 - requires that both inputs have a matching timebase (TBN) and frame rate (FPS).

  


  This is "resolved" by explicitly making them the same, by adding settb=AVTB and a hardcoded FPS to both streams (there doesn't seem to be a constant equivalent to AVTB for FPS) prior to using xfade :

  


  -filter_complex \
[0:v]settb=AVTB,fps=29[v0];
[1:v]settb=AVTB,fps=29[v1];
[v0][v1]xfade=transition=fade:duration=$fadeduration:offset=$fadetime,format=yuv420p[faded]; 


  


  However, I'm confused as to why is this necessary in the first place. The concat filter works similarly in that it requires all its inputs to have matching parameters, but this makes sense because the whole point of concat is to avoid re-encoding. If the xfade filter is (presumably) re-encoding anyway, why do the timebase and frame rate still need to match ?

  


  Is there a reason the devs decided to enforce these limitations for the filter when they don't seem to be technically necessary ?