Recherche avancée

Sur d’autres sites (11117)

• movenc : Add an option for resilient, hybrid fragmented/non-fragmented muxing

  1er novembre 2014, par Martin Storsjö

  movenc : Add an option for resilient, hybrid fragmented/non-fragmented muxing
  This allows ending up with a normal, non-fragmented file when
  
  the file is finished, while keeping the file readable if writing
  
  is aborted abruptly at any point. (Normally when writing a
  
  mov/mp4 file, the unfinished file is completely useless unless it
  
  is finished properly.)
  This results in a file where the mdat atom contains (and hides)
  
  all the moof atoms that were part of the fragmented file structure
  
  initially.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] doc/muxers.texi
  • [DH] libavformat/movenc.c
  • [DH] libavformat/movenc.h
  • [DH] libavformat/version.h
  • [DH] tests/fate/lavf-container.mak
  • [DH] tests/ref/lavf/mov_hybrid_frag

• FFMPEG syntax clarification question for the "between" function [closed]

  31 octobre 2024, par user2571504

  I've been using a crop filter script to hold the crop in one place for the first 750 frames, then automate a moving crop to follow some action in the clip. It's working great for chunky moves (5 pixel jumps as shown below) :

  


  -filter_script:v:0 crop-filter-script.txt

crop='1500:1000:100:
if(between(n,0,750),100,
if(between(n,751,756),105,
if(between(n,757,762),110,
if(between(n,763,768),115,
if(between(n,769,774),120,
if(between(n,775,780),125,
if(between(n,781,786),130,etc


  


  My question is about how "between" is interpreted. Does "between(n,751,756)" mean "frames 751, 752, 753, 754, 755 & 756" ? or does it exclude the start and ending frames, so that it's "between" those two numbers ? Like : 752, 753, 754 & 755 only ?

  


  Thanks !

  


• avformat/demux : add duration_probesize AVOption

  29 mars 2024, par Nicolas Gaullier

  avformat/demux : add duration_probesize AVOption
  Yet another probesize used to get the durations when
  
  estimate_timings_from_pts is required. It is aimed at users interested
  
  in better durations probing for itself, or because using
  
  avformat_find_stream_info indirectly and requiring exact values : for
  
  concatdec for example, especially if streamcopying above it.
  
  The current code is a performance trade-off that can fail to get video
  
  stream durations in a scenario with high bitrates and buffering for
  
  files ending cleanly (as opposed to live captures) : the physical gap
  
  between the last video packet and the last audio packet is very high in
  
  such a case.
  Default behaviour is unchanged : 250k up to 250k << 6 (step by step).
  
  Setting this new option has two effects :
  
   override the maximum probesize (currently 250k << 6)
  
   reduce the number of steps to 1 instead of 6, this is to avoid
  
  detecting the audio "too early" and failing to reach a video packet.
  
  Even if a single audio stream duration is found but not the other
  
  audio/video stream durations, there will be a retry, so at the end the
  
  full user-overriden probesize will be used as expected by the user.
  Signed-off-by : Nicolas Gaullier <nicolas.gaullier@cji.paris>
  

  • [DH] doc/APIchanges
  • [DH] doc/formats.texi
  • [DH] libavformat/avformat.h
  • [DH] libavformat/demux.c
  • [DH] libavformat/options_table.h
  • [DH] libavformat/version.h