Recherche avancée

Sur d’autres sites (11869)

• mmaldec : be more tolerant against MMAL not returning decoded output

  23 septembre 2015, par wm4

  mmaldec : be more tolerant against MMAL not returning decoded output
  In some situations, MMAL won’t return a decoded frame for certain input
  
  frames. This can happen if a frame fails to decode, or if a packet does
  
  not actually contain a complete frame. In these situations, we would
  
  deadlock (or actually timeout) waiting for an expected output frame,
  
  which is not ideal. On the other hand, there are situations where we
  
  definitely have to block to avoid deadlocks. (This mess is a
  
  consequence of trying to map MMAL’s asynchronous and flexible
  
  dataflow to libavcodec, which is more static and rigid.)
  Solve this by doing a blocking wait only if the amount of buffered data
  
  is too big. The whole purpose of the blocking wait is to avoid excessive
  
  buffering of input data, so we can skip it if it appears to be low. The
  
  consequence is that libavcodec can gracefully return no frame to the
  
  API user.
  We want to track the number of full packets to make our heuristic work.
  
  But MMAL buffers are fixed-size, requiring splitting large packets. This
  
  is why the previous commit is needed. We use the ..._FRAME_END flag to
  
  remember packet boundaries, but MMAL does not preserve these buffer
  
  flags when returning buffers to the user.
  Signed-off-by : Luca Barbato <lu_zero@gentoo.org>
  

  • [DBH] libavcodec/mmaldec.c

• ffmpeg/libav easy way to set options for muxer, codec, format, etc [closed]

  14 mars 2023, par Patrick

  Edit (shorter question) :

  


  In the ff tools (e.g. ffplay) I can set all kinds of options by simply providing a list of arguments in cmd. Id like to do that programmatically as well and without having to look up where it belongs and insert it in the different AVDictionary by hand every time. Is there a way to do this easily ?

  


  Long question :

  


  I recently messed around with ffplay code to see how it works and I noticed it uses a very straight forward way to parse and set all the command line options using the library internal cmdutils.h. I personally find the av_opt_set used in other examples of av wrappers quite confusing (Some args are explicitly stored in the struct, some in priv_data ? Im allowed/supposed to modify void*priv_data ? Which objects can I use av_opt_set on ? Which args go in which object and are they declared or in priv_data ? Where is this documented ?).
In ffplay all args are simply stored in an array and distributed to the right codec/muxer/format instance using cmdutil.
Id like to have exactly this functionality for my program (so that i can simply read a json config and don't need to care about it any further). Apparently the necessary OptionDef arrays are already defined in different implementation files.

  


  However my actual question : I noticed the OptionDef array definition in ffplay does not contain all options (only some from cmdutil included via macro). But other options e.g. fflags are not included anywhere (only defined somewhere else) and yet they work. So how does cmdutil set/parse them ?

  


  I hope someone can answer this, since simply adapting cmdutil would be a quite simple solution for me. Id also really appreciate some general guidance regarding my previous questions.

  


  Many Thanks in advance !

  


  I tried looking into the ffmpeg source and expected all OptionDef array definitions to be connected/collected inside a single array such that cmdutil can parse them easily. However this isn't the case and still some cmd options work. Therefore Im confused on how cmtutil is able to parse them

  


• Accuracy of trimming/concatenating parts of videos with ffmpeg

  10 mai 2020, par Circonflexe

  I am adjusting a video (with audio track) using ffmpeg, with the goal being to move the time position of some given points of the video as precisely as possible in time (ideally, with an accuracy of 1ms), by using a piecewise affine transform on the time of the video.
For this I use ffmpeg with a combination of trim, setpts, atrim, atempo, and concat filters, such as :

  



  ffmpeg -i input.mp4 -filter_complex \
'[0:v]trim=start=0:end=162.328554216868,setpts=1.194377385743*(PTS-STARTPTS)[v0];'\
'[0:a]atrim=start=0:end=162.328554216868,asetpts=PTS-STARTPTS,atempo=.837256307710[a0];'\
'[0:v]trim=start=162.328554216868:end=173.161445783132,setpts=1.135513218334*(PTS-STARTPTS)[v1];'\
'[0:a]atrim=start=162.328554216868:end=173.161445783132,asetpts=PTS-STARTPTS,atempo=.880659056939[a1];'\
'[0:v]trim=start=173.161445783132:end=197.842554216868,setpts=1.093796435691*(PTS-STARTPTS)[v2];'\
'[0:a]atrim=start=173.161445783132:end=197.842554216868,asetpts=PTS-STARTPTS,atempo=.914246899486[a2];'\
'[0:v]trim=start=197.842554216868:end=208.505445783132,setpts=1.145926645725*(PTS-STARTPTS)[v3];'\
'[0:a]atrim=start=197.842554216868:end=208.505445783132,asetpts=PTS-STARTPTS,atempo=.872656206861[a3];'\
'[0:v]trim=start=208.505445783132:end=212.61,setpts=PTS-STARTPTS[v4];'\
'[0:a]atrim=start=208.505445783132:end=212.61,asetpts=PTS-STARTPTS,atempo=1[a4];'\
'[v0][a0][v1][a1][v2][a2][v3][a3][v4][a4]concat=n=5:v=1:a=1[v][a]' \
-map '[v]' -map '[a]' output.mp4


  



  (the numeric values above are obviously generated by another script, not by hand !). However I find that the resulting audio track has some “whitespace” inserted wherever two parts are joined. For example, when joining a longer file (about 4 minutes with 31 parts in total), I found that the duration of the file had increased by about 0.3 second in total, which obviously defeats the “millisecond-accuracy” goal.

  



  How could I tell ffmpeg to make the transitions as exact as possible ?