Recherche avancée

Sur d’autres sites (9447)

• 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

• hwcontext_vaapi : remove duplicate formats from sw_format list

  24 juillet 2020, par Haihao Xiang

  hwcontext_vaapi : remove duplicate formats from sw_format list
  hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V
  
  plane swap cases, however duplicate formats are not expected in sw_format
  
  list when merging formats.
  For example :
  
  ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \
  
   f lavfi -i smptebars -vf \
  
  "hwupload=derive_device=vaapi,scale_vaapi,hwdownload,format=yuv420p" \
  
   vframes 1 -f null -
  Without this fix, an auto scaler is required for the above command
  
     Duplicate formats in ff_merge_formats detected
  
     [auto_scaler_0 @ 0x560df58f4550] Setting 'flags' to value 'bicubic'
  
     [auto_scaler_0 @ 0x560df58f4550] w:iw h:ih flags :'bicubic' interl:0
  
     [Parsed_hwupload_0 @ 0x560df58f0ec0] auto-inserting filter
  
     'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
  
     the filter 'Parsed_hwupload_0'
  Signed-off-by : Haihao Xiang <haihao.xiang@intel.com>
  

  • [DH] libavutil/hwcontext_vaapi.c

• slicing and seeking extremeley small sections of video in ffmpeg

  20 février 2021, par Zarc Rowden

  I am writing a program that maps midi data to timestamps in a video. The end result is a kind of automatic generation of audio visuals for beat making or techno heads. The program takes in midi, slices a video into chunks based on the midi events and mappings and finally joins the slices into a video with 1:1 timing of monophonic midi notes to sections of a video.

  


  When it is successful, the result is very cool and watching the video jump around and lock in to midi notes is very interesting

  


  However, I am affraid that the ffmpeg commands I use are not giving exact results.

  


  The code I feed to ffmpeg looks like this

  


  EVENTS : left is midinote number, right is time from start of recording in which note occurs.

  


    [{"note"=>"start", "timestamp"=>0.0},
   {"note"=>48, "timestamp"=>0.5700000037904829},
   {"note"=>51, "timestamp"=>383.7100000018836},
   {"note"=>45, "timestamp"=>884.3500000002678},
   {"note"=>48, "timestamp"=>999.0449999968405},
   {"note"=>51, "timestamp"=>1383.544999996957},
   {"note"=>45, "timestamp"=>1884.2599999989034},
   {"note"=>48, "timestamp"=>1998.890000002575},
   {"note"=>51, "timestamp"=>2383.4199999982957},
   {"note"=>45, "timestamp"=>2884.1000000029453},
   {"note"=>48, "timestamp"=>2998.7200000032317},
   {"note"=>51, "timestamp"=>3383.2800000018324},
   {"note"=>45, "timestamp"=>3883.894999999029},
   {"note"=>48, "timestamp"=>3998.6250000001746},
   {"note"=>51, "timestamp"=>4384.550000002491},
   {"note"=>45, "timestamp"=>4883.780000003753},
   {"note"=>48, "timestamp"=>4998.404999998456},
   {"note"=>51, "timestamp"=>5384.39500000095},
   {"note"=>45, "timestamp"=>5883.565000003728},
   {"note"=>48, "timestamp"=>5998.464999996941},
   {"note"=>51, "timestamp"=>6384.254999997211},
   {"note"=>45, "timestamp"=>6883.4550000028685},
   {"note"=>48, "timestamp"=>6998.585000001185},
   {"note"=>51, "timestamp"=>7384.055000002263},
   {"note"=>45, "timestamp"=>7883.249999998952},],


  


  MAPPINGS : left side is midi note, right is timestamp in seconds

  


  {
 48=>234.3489,
 45=>124.334489,
 51=>2789.34,
}


  


  That Events are a sequential array of midi notes and time taken from recordings or standard midi file. The number is in milliseconds but I convert for ffmpeg before feeding the arguments.

  


  The mappings are just in seconds and tell the program what to show when certain midi notes are encountered as we loop through the events and begin slicing the video.

  


  The command I send to ffmpeg is constructed like this :

  


  "ffmpeg -an -y -ss #{begin_at} -i #{project_tempfile_url} -t #{slice_duration} -c:v libx264 #{temp_url}"


  


  When I concatenate these slices, they only look exact when my notes are very consistent like a kickdrum doing 4/4 rythms. Anything too fast or varied creates unpleasant results.

  


  Is there a specific set of commands that will tell ffmpeg to cut down to the frame ? I think keyframe are not an ideal answer but not sure. I also think I can adjust by making sure that I only ever map the notes to keyframes, I can settle for it but it would be great if I could just cut almost anywhere between start and end like ANYWHERE like

  


    rand(0...video.length)
  # and then have
  332.3253613134


  


  But I may just be dreaming :P

  


  Do you think that I would be better off writing a custom c program to cut frames like this ? I understand that frame rates could be an issue and that there may actually not be any data at 7.34667898999 seconds and that it might be here instead : 7.356788722342 and that ffmpeg probably searches for the nearest frame from whatever timestamp you input, but I feel like there must be a way to get good results still despite these limitations.

  


  Thank you so much in advance for those who take the time to read this and understand this issue.