Recherche avancée

Sur d’autres sites (8484)

• Cleaning up after av_frame_get_buffer

  4 novembre 2016, 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.

• FFMPEG h264 grey frame and artifacts at beginning

  28 novembre 2011, par marce002

  I'm splitting my "zi6 quicktime mov" hd videos, I have 250 clips of around 10 or 15 seconds each, from lot of places, locationes around the globe and want to combine them in a single big clip.

  I can merge them very good with "mkvmerge".

  The problem is that the first frames of all videos in the collection (splitted with ffmpeg), are gray or with artifacts at beggining, I do not know how to explain, maybe wrong ffmpeg commands, I'm doing this (with batch command line, which is great / fast for me) :

  =======begin of batch file

  ffmpeg -i jockey_club_fpv.mov -ss 00:00:17 -t 00:00:24 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3a.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:04:40 -t 00:00:20 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3b.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:05:35 -t 00:01:00 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3c.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:07:11 -t 00:00:10 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3d.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:07:45 -t 00:00:21 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3e.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:08:47 -t 00:00:05 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3f.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:09:18 -t 00:00:10 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3g.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:09:35 -t 00:00:09 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3h.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:10:07 -t 00:00:16 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3i.mov
  
  mkvmerge -o join4.mov partes3a.mov + partes3b.mov + partes3c.mov + partes3d.mov + partes3e.mov + partes3f.mov + partes3g.mov + partes3h.mov + partes3i.mov

  =======end of batch file

  Thanks a lot for any answer !!

• 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