Recherche avancée

Sur d’autres sites (5297)

• avformat/hlsenc : Don't segfault on uncommon names

  6 mai 2020, par Andreas Rheinhardt

  avformat/hlsenc : Don't segfault on uncommon names
  The parsing process of the AVOpt-enabled string controlling the mapping
  
  of input streams to variant streams is roughly as follows : Space and tab
  
  separate variant stream group maps while the entries in each variant
  
  stream group map are separated by ','.
  The parsing process of each variant stream group proceeded as follows :
  
  At first the number of occurences of "a :", "v :" and "s :" in each variant
  
  stream group is calculated so that one can can allocate an array of
  
  streams with this number of entries. Then the string is split along ','
  
  and each substring is parsed. If such a substring starts with "a :", "s :"
  
  or "v :" it is treated as stream specifier and (if there is a correct
  
  number after ' :') a stream of the variant stream is mapped to one of the
  
  actual input streams.
  Nothing actually guarantees that the number of streams allocated initially
  
  equals the number of streams that are mapped to an actual input stream.
  
  These numbers can differ if e.g. the name, the sgroup, agroup or ccgroup
  
  of the variant stream contain "a :", "s :" or "v :".
  The problem hereby is that the rest of the code presumes these numbers
  
  to be equal and segfaults if it isn't (because the corresponding input
  
  stream is NULL).
  This commit fixes this by modifying the initial counting process to only
  
  count occurences of "a :", "s :" or "v :" that are at the beginning or that
  
  immediately follow a ','.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/hlsenc.c

• avformat/hlsenc : Improve checks for invalid stream mappings

  5 mai 2020, par Andreas Rheinhardt

  avformat/hlsenc : Improve checks for invalid stream mappings
  The mapping of streams to the various variant streams to be created by
  
  the HLS muxer is roughly as follows : Space and tab separate variant
  
  stream group maps while the entries in each variant stream group map are
  
  separated by ','.
  The parsing process of each variant stream group proceeded as follows :
  
  At first the number of occurences of "a :", "v :" and "s :" in each variant
  
  stream group is calculated so that one can can allocate an array of
  
  streams with this number of entries. Then each entry is checked and the
  
  check for stream numbers was deficient : It did check that there is a
  
  number beginning after the " :", but it did not check that the number
  
  extends until the next "," (or until the end).
  This means that an invalid variant stream group like v:0_v:1 will not be
  
  rejected ; the problem is that the variant stream in this example is
  
  supposed to have two streams associated with it (because it contains two
  
  "v :"), yet only one stream is actually associated with it (because there
  
  is no ',' to start a second stream specifier). This discrepancy led to
  
  segfaults (null pointer dereferencing) in the rest of the code (when the
  
  nonexistent second stream associated to the variant stream was inspected).
  Furthermore, this commit also removes an instance of using atoi() whose
  
  behaviour on a range error is undefined.
  Fixes ticket #8652.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/hlsenc.c

• Enable QSV for FFmpeg with directshow input and JPEG image sequence output

  10 mars 2020, par clic

  I’m using FFmpeg with Directshow input. The output is a series of single JPEG images. FFmpeg itself maps the stream to mjpeg and uses image2 for the output.

  Is it possible to increase performance by using the Intel QuickSync Video (QSV) hardware acceleration for this process ? The FFmpeg QuickSync Wiki actually lists JPEG encoding since Braswell.

  This is what I tried so far :

  ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -f dshow -video_size 3840x2160 -framerate 25 -i "video=My Webcam" -vf hwupload=extra_hw_frames=64,format=qsv -vcodec mjpeg_qsv "C:\out\%d.jpg"

  The command works, images are generated - but the GPU load seems to be the same as without any qsv options..?

  Thanks !