Recherche avancée

Sur d’autres sites (5335)

• PHP and FFMPEG - Performing intelligent video conversion

  24 décembre 2012, par Andrew

  I have an oddly difficult task to perform. I thought it would be easy, but all my efforts have been fruitless.

  I'm converting videos uploaded to a php script from various formats (.avi, .mpg, .wmv, .mov, etc.) to a single .flv format. The conversion is working great but what I'm having trouble with is the resolution of the videos.

  This is the command I'm currently running (with PHP vars) :

  ffmpeg -i $original -ab 96k -b 700k -ar 44100 -s 640x480 -acodec mp3 $converted

  Both $original and $converted contain the full paths to those files. My problem is that this always converts to 640x480 (like I'm telling it to) even when the source is smaller. Obviously, this is a waste of disk space and bandwidth when the video is downloaded. Also, this doesn't account for input videos being in any aspect ratio other than 4:3, resulting in a "squished" conversion if I upload a 16:9 video.

  There are 3 things I need to do :

  1. Determine the aspect ratio of the original video.
  2. If not 4:3, pad top and bottom with black bars.
  3. Convert to 640x480 if either dimension of the original is larger or a 4:3 aspect ratio relating to the width/height of the original (whichever is closer to 640x480).

  I've run ffmpeg -i on a few videos, but I don't see a consistent format or location to find the original's resolution from. Once I'm able to figure that out, I know I can "do the math" to figure out the right size and specify padding to fix the aspect ratio with -padttop, -padbottom, etc.

• Why do we need a buffer while converting AVFrame from one format to another ?

  2 mars 2016, par jsp99

  I am referring to this source code . The code snippets provided here are from lines (114-138) in the code . This is using the ffmpeg library . Can anyone explain why is the following code required in the program ?

  // Determine required buffer size and allocate buffer
  
  numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
  
                pCodecCtx->height);
  
  buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t)); 

  In a sense I understand that the following function is associating the destination frame to the buffer . But what is the necessity ?

  avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24, pCodecCtx->width, pCodecCtx->height);  

  PS : I tried removing the buffer and compiling the program . It got compiled . But it is showing the following run time error .

  [swscaler @ 0xa06d0a0] bad dst image pointers
  Segmentation fault (core dumped)

• Do FFMPEG H264 compression presets affect the video quality ? [closed]

  14 novembre 2013, par angainor

  I am definitely not an FFMPEG expert, but according to this document :

  A preset is a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression (compression is quality per filesize). General usage is to use the slowest preset that you have patience for. Current presets in descending order of speed are : ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo.

  So as I understand it, the ffmpeg presets should not affect the quality of the output video, but should only determine the compression ratio / output file size. Consequently, assuming the same quality setting (I will use -crf 24), the files should be larger for e.g., faster preset than for the slower preset. That would be the only reason to use a slower preset - to get a smaller file size.

  This turns out not to be the case. I encode a HD stream from a handycam using different presets, everything else is the same :

  ffmpeg -y -i "$fname" -vf yadif=1,scale=-1:720 -acodec aac -ab 128k -ac 2 -strict experimental -vcodec libx264 -vpre slow -threads 2 -crf 24 "$outp"

  Surprisingly, I get the smallest file size for veryfast preset ! For example :

  • slower : output bitrate 3500kbps, encoding speed 17 fps, file size 29MB
  • veryfast : output bitrate 3050kbps, encoding speed 34 fps, file size 25MB

  Which I think is not as it should be. Now I wonder, is that due to a worse encoding quality for the veryfast preset ? Or in my case using slower does simply not make sense for some reason ?