Recherche avancée

Sur d’autres sites (7914)

• libavformat : Improve ff_configure_buffers_for_index for excessive deltas

  21 mars 2023, par Martin Storsjö

  libavformat : Improve ff_configure_buffers_for_index for excessive deltas
  Previously, the ff_configure_buffers_for_index function had
  
  upper sanity limits of 16 MB (1<<24) for buffer_size and
  
  8 MB (1<<23) for short_seek_threshold.
  However, if the index contained entries with a much larger
  
  delta, setting pos_delta to a value larger than the sanity
  
  limit, we would end up not increasing the buffer size at all.
  Instead, ignore the individual deltas that are excessive, but
  
  increase the buffer size based on the deltas that are below the
  
  sanity limit.
  Only count deltas that are below 1<<23, 8 MB ; pos_delta gets doubled
  
  before setting the buffer size - this matches the previous maximum
  
  buffer size of 1<<24, 16 MB.
  This can happen e.g. with a mov file with some tracks containing
  
  some samples that belong in the start of the file, at the end of
  
  the mdat, while the rest of the file is mostly reasonably interleaved ;
  
  previously those samples caused the maximum pos_delta to skyrocket,
  
  skipping any buffer size enlargement.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/seek.c

• lavf : Remove codec_tag from dashenc and smoothstreamingenc

  30 juin 2017, par Martin Storsjö

  lavf : Remove codec_tag from dashenc and smoothstreamingenc
  Currently, the tags enforced and set on the segmenter muxer level
  
  mismatch what the mp4/ismv muxer uses (since 713efb2c0d013).
  Skip the codec_tag altogether here, to let the user (try to) set
  
  whichever codec/tag is preferred ; the individual chained muxer will
  
  reject invalid codecs anyway.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/dashenc.c
  • [DBH] libavformat/smoothstreamingenc.c

• ffmpeg concat drops audio frames

  5 octobre 2017, par Shaun

  I have an mp4 file and I want to take two sequential sections of the video out and render them as individual files, later recombining them back into the original video. For instance, with my video video.mp4, I can run

  ffmpeg -i video.mp4 -ss 56 -t 4 out1.mp4
  
  ffmpeg -i video.mp4 -ss 60 -t 4 out2.mp4

  creating out1.mp4 which contains 00:00:56 to 00:01:00 of video.mp4, and out2.mp4 which contains 00:01:00 to 00:01:04. However, later I want to be able to recombine them again quickly (i.e., without reencoding), so I use the concat demuxer,

  ffmpeg -f concat -safe 0 -i files.txt -c copy concat.mp4

  where files.txt contains

  file out1.mp4
  
  file out2.mp4

  which theoretically should give me back 00:00:56 to 00:01:04 of video.mp4, however there are always dropped audio frames where the concatenation occurs, creating a very unpleasant sound artifact, an audio blip, if you will.

  

  I have tried using async and -af apad on initially creating the two sections of the video but I am still faced with the same problem, and have not found the solution elsewhere. I have experienced this issue in multiple different use cases, so hopefully this simple example will shed some light on the real problem.