Recherche avancée

Sur d’autres sites (10764)

• How to get accurate output video duration from ffmpeg ? [migrated]

  20 octobre 2024, par Roy Harper

  Is there a way to get ffmpeg.exe to give the duration of the OUTPUT video ?

  


  I know how to get a video duration from an input video from ffmpeg. Just look for "Duration : " and parse the HH:MM:SS:XX.

  


  Sample output:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'video.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf60.3.100
  Duration: 00:05:53.24, start: 0.000000, bitrate: 1102 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 854x480 [SAR 1:1 DAR 427:240], 937 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 159 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]


  


  Unfortunately, this is only accurate to hundredths of a second, and I need something more precise than that. And it's the duration of the input video, and I need the duration of the output video.

  


  I know how to get a video duration, in seconds, accurate to six decimal places, from a video by using ffprobe.exe.

  


  ffprobe -v error -select_streams v -of default=noprint_wrappers=1:nokey=1 -show_entries stream=duration video.mp4

Sample output:
353.227875


  


  I also have read that calls to the ffmpeg libraries return a floating point value that is the duration of the output video in seconds. So ffmpeg.exe knows the output video duration, and it knows it quite accurately.

  


  So, is there a way to get an accurate duration of the output video from ffmpeg.exe ? Or am I stuck making one call to ffmpeg.exe to do the video processing, then a separate call to ffprobe.exe to get the video duration ?

  


• Cleaning up after av_frame_get_buffer

  30 juillet 2022, par Jason C

  There are two aspects of my question. I'm using libav, ffmpeg, 3.1.

  



  ---

  



  First, how do you appropriately dispose of a frame whose buffer has been allocated with av_frame_get_buffer ? E.g. :

  



  AVFrame *frame = av_frame_alloc();
frame->width = ...;
frame->height = ...;
frame->format = ...;
av_frame_get_buffer(frame, ...);


  



  Do any buffers have to be freed manually, beyond the call to av_frame_free(frame) ? The documentation doesn't mention anything special, but in my experience the ffmpeg documentation often leaves out important details, or at least hides them in places far away from the obvious spots. I took a look at the code for av_frame_free and av_frame_unref but it branched out quite a bit and I couldn't quite determine if it covered everything.

  



  ---

  



  Second, if something beyond av_frame_free needs to be done, then is there any catch-all way to clean up a frame if you don't know how its data has been allocated ? For example, assuming someBuffer is already allocated with the appropriate size :

  



  AVFrame *frame2 = av_frame_alloc();
frame2->width = ...;
frame2->height = ...;
frame2->format = ...;
av_image_fill_arrays(frame2->data, frame2->linesize, someBuffer, 
                     frame2->format, frame2->width, frame2->height, 1);


  



  Is there a way to free both frame and frame2 in the above examples using the exact same code ? That is frame and its data should be freed, and frame2 should be freed, but not someBuffer, since libav did not allocate it.

  


• h264_mp4toannexb : Don't forget numOfPictureParameterSets

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Don't forget numOfPictureParameterSets
  The format of an AVCDecoderConfigurationRecord, the out-of-band
  
  extradata of H.264 in mp4, is as follows : First four bytes containing
  
  version, profile and level, one byte for the length size and one byte
  
  each for the number of SPS, followed by the SPS (each with its own size
  
  field), followed by a byte containing the number of PPS followed by the
  
  PPS with their size fields. While the number of SPS/PPS may be zero, the
  
  bytes containing these numbers are mandatory. Yet the byte containing
  
  the number of PPS has been ignored in two places :
  
  1. In the initial check for whether the extradata can contain an
  
  AVCDecoderConfigurationRecord. The minimum size is 7, not 6.
  
  2. No check is made for whether the extradata ended right after the last
  
  byte of the last SPS of the SPS array. Instead the first byte of the
  
  padding is read as if it were part of the extradata and contained the
  
  number of PPS (namely zero, given that the padding is zeroed). No error
  
  or warning was ever raised.
  
  This has been changed. Such truncated extradata is now considered
  
  invalid ; the check for 2. has been incorporated into the general size
  
  check.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c