Recherche avancée

Sur d’autres sites (5639)

• Formula to get frame display number after seek in FFmpeg

  27 septembre 2021, par ZeroDefect

  For a given AV file, I need to be able to seek to a particular video frame number in the file. Because of how decoding works, I am seeking to the nearest I-Frame before the required frame (which may or may not be the requested frame) and then decoding the frames in the GOP until I get to where I need to be. As such, I need to know my current position after seeking.

  


  Having found some posts of a similar nature on SO, I've gone away and collected a few interesting samples to see if I can get a formula to work across many different files, but I'm having a hard time. What works or 1 file may not work for another :

  


  File #1 (Podbox)

  


  Requested to seek to fame #1500. First video frame reports :

  


  AVFrame::pts = 760320
AVFrame::pkt_duration = 512

AVStream::time_base = {1,12800}
AVStream::start_time = 0
AVStream::avg_frame_rate = {25,1}


  


  File #2 (HTE54959)

  


  Requested to seek to fame #1500. First video frame reports :

  


  AVFrame::pts = 1500
AVFrame::pkt_duration = 1

AVStream::time_base = {1,25}
AVStream::start_time = 0
AVStream::avg_frame_rate = {25,1}


  


  File #3 (BuckBunny)

  


  Requested to seek to fame #1800. First video frame reports :

  


  AVFrame::pts = 1563562
AVFrame::pkt_duration = 1001

AVStream::time_base = {1,30000}
AVStream::start_time = 0
AVStream::avg_frame_rate = {30000,1001}


  


  File #4 (HouseDance)

  


  Requested to seek to fame #1800. First video frame reports :

  


  AVFrame::pts = 1800
AVFrame::pkt_duration = 1

AVStream::time_base = {1001,30000}
AVStream::start_time = 0
AVStream::avg_frame_rate = {30000,1001}


  


  For the above files, the following members are always zero :

  


  AVFrame::coded_picture_number
AVFrame::display_picture_number


  


  I have thought about merely using AVFrame::pts / AVFrame::pkt_duration, but I'm not sure that is the right way of doing things. I know for some codecs, there can be a variable frame rate (VFR) which would mean that my method is erroneous ? I assume that the AVFrame::pkt_duration could change per AVFrame ?

  


  I want to emphasize that my issue is not being able to seek. I am seeking to the correct location - I have verified that visually using timecode. My issue is programmatically identifying the frame number of the seek position

  


  Using FFmpeg v4.2.4

  


• seek : Fix crashes in ff_seek_frame_binary if built with latest Clang 14

  18 octobre 2021, par Martin Storsjö

  seek : Fix crashes in ff_seek_frame_binary if built with latest Clang 14
  Passing an uninitialized variable as argument to a function is
  
  undefined behaviour (UB). The compiler can assume that UB does not
  
  happen.
  Hence, the compiler can assume that the variables are never
  
  uninitialized when passed as argument, which means that the codepaths
  
  that initializes them must be taken.
  In ff_seek_frame_binary, this means that the compiler can assume
  
  that the codepaths that initialize pos_min and pos_max are taken,
  
  which means that the conditions "if (sti->index_entries)" and
  
  "if (index >= 0)" can be optimized out.
  Current Clang git versions (upcoming Clang 14) enabled an optimization
  
  that does this, which broke the current version of this function
  
  (which intentionally left the variables uninitialized, but silencing
  
  warnings about being uninitialized). See [1] for discussion on
  
  the matter.
  [1] https://reviews.llvm.org/D105169#3069555
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/seek.c

• avdevice/dshow : set no-seek flags

  21 décembre 2021, par Diederick Niehorster

  avdevice/dshow : set no-seek flags
  avdevice/dshow is a realtime device and as such does not support
  
  seeking. Therefore, its demuxer format should define the
  
  AVFMT_NOBINSEARCH, AVFMT_NOGENSEARCH and AVFMT_NO_BYTE_SEEK flags.
  
  With these flags set, attempting to seek (with, e.g.,
  
  avformat_seek_file()) correctly yields -1 (operation not permitted)
  
  instead of -22 (invalid argument).
  This actually seems to apply to many other devices, at least the
  
  gdigrab, v4l2, vfwcap, x11grab, fbdev, kmsgrab and android_camera
  
  devices, from reading the source.
  Signed-off-by : Diederick Niehorster <dcnieho@gmail.com>
  
  Reviewed-by : Roger Pack <rogerdpack2@gmail.com>
  

  • [DH] libavdevice/dshow.c