Newest 'ffmpeg' Questions - Stack Overflow

Les articles publiés sur le site

• FFmpeg command in Windows to split audio file by silence

  28 janvier 2019, par ZhouW

  I have previously used ffmpeg to split audio files by silence in Linux, with the following command (taken from How to split video or audio by silent parts, which splits an audio file by silences of -40dB that last at least 0.35 seconds):

  ffmpeg -i testfile.wav -filter_complex "[0:a]silencedetect=n=-40dB:d=0.35[outa]" -map [outa] -f s16le -y /dev/null |& F='-aq 70 -v warning' perl -ne 'INIT { $ss=0; $se=0; } if (/silence_start: (\S+)/) { $ss=$1; $ctr+=1; printf "ffmpeg -nostdin -i testfile.wav -ss %f -t %f $ENV{F} -y %03d.wav\n", $se, ($ss-$se), $ctr; } if (/silence_end: (\S+)/) { $se=$1; } END { printf "ffmpeg -nostdin -i testfile.wav -ss %f $ENV{F} -y %03d.wav\n", $se, $ctr+1; }' | bash -x
  

  When trying to run this in Windows, I get the following error:

  & was unexpected at this time.

  The above command uses Linux-specific syntax and I'm unclear on how this should be written in a Windows environment. How should this be done?

• Does H.264 encoded video with BT.709 matrix include any gamma adjustment ?

  27 janvier 2019, par MoDJ

  I have read the BT.709 spec a number of times and the thing that is just not clear is should an encoded H.264 bitstream actually apply any gamma curve to the encoded data? Note the specific mention of a gamma like formula in the BT.709 spec. Apple provided examples of OpenGL or Metal shaders that read YUV data from CoreVideo provided buffers do not do any sort of gamma adjustment. YUV values are being read and processed as though they are simple linear values. I also examined the source code of ffmpeg and found no gamma adjustments being applied after the BT.709 scaling step. I then created a test video with just two linear grayscale colors 5 and 26 corresponding to 2% and 10% levels. When converted to H.264 with both ffmpeg and iMovie, the output BT.709 values are (YCbCr) (20 128 128) and (38 128 128) and these values exactly match the output of the BT.709 conversion matrix without any gamma adjustment.

  A great piece of background on this topic can be found at Quicktime Gamma Bug. It seems that some historical issues with Quicktime and Adobe encoders were improperly doing different gamma adjustments and the results made video streams look awful on different players. This is really confusing because if you compare to sRGB, it clearly indicates how to apply a gamma encoding and then decode it to convert between sRGB and linear. Why does BT.709 go into so much detail about the same sort of gamma adjustment curve if no gamma adjustment is applied after the matrix step when creating a h.264 data stream? Are all the color steps in a h.264 stream meant to be coded as straight linear (gamma 1.0) values?

  In case specific example input would make things more clear, I am attaching 3 color bar images, the exact values of different colors can be displayed in an image editor with these image files.

  This first image is in the sRGB colorspace and is tagged as sRGB.

  

  This second image has been converted to the linear RGB colorspace and is tagged with a linear RGB profile.

  

  This third image has been converted to REC.709 profile levels with Rec709-elle-V4-rec709.icc from elles_icc_profiles . This seems to be what one would need to do to simulate "camera" gamma as described in BT.709.

  

  Note how the sRGB value in the lower right corner (0x555555) becomes linear RGB (0x171717) and the BT.709 gamma encoded value becomes (0x464646). What is unclear is if I should be passing a linear RGB value into ffmpeg or if I should be passing an already BT.709 gamma encoded value which would then need to be decoded in the client before the linear conversion Matrix step to get back to RGB.

  Update:

  Based on the feedback, I have updated my C based implementation and Metal shader and uploaded to github as an iOS example project MetalBT709Decoder.

  Encoding a normalized linear RGB value is implemented like this:

  static inline
  int BT709_convertLinearRGBToYCbCr(
                              float Rn,
                              float Gn,
                              float Bn,
                              int *YPtr,
                              int *CbPtr,
                              int *CrPtr,
                              int applyGammaMap)
  {
    // Gamma adjustment to non-linear value
  
    if (applyGammaMap) {
      Rn = BT709_linearNormToNonLinear(Rn);
      Gn = BT709_linearNormToNonLinear(Gn);
      Bn = BT709_linearNormToNonLinear(Bn);
    }
  
    // https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
  
    float Ey = (Kr * Rn) + (Kg * Gn) + (Kb * Bn);
    float Eb = (Bn - Ey) / Eb_minus_Ey_Range;
    float Er = (Rn - Ey) / Er_minus_Ey_Range;
  
    // Quant Y to range [16, 235] (inclusive 219 values)
    // Quant Eb, Er to range [16, 240] (inclusive 224 values, centered at 128)
  
    float AdjEy = (Ey * (YMax-YMin)) + 16;
    float AdjEb = (Eb * (UVMax-UVMin)) + 128;
    float AdjEr = (Er * (UVMax-UVMin)) + 128;
  
    *YPtr = (int) round(AdjEy);
    *CbPtr = (int) round(AdjEb);
    *CrPtr = (int) round(AdjEr);
  
    return 0;
  }
  

  Decoding from YCbCr to linear RGB is implemented like so:

  static inline
  int BT709_convertYCbCrToLinearRGB(
                               int Y,
                               int Cb,
                               int Cr,
                               float *RPtr,
                               float *GPtr,
                               float *BPtr,
                               int applyGammaMap)
  {
    // https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.709_conversion
    // http://www.niwa.nu/2013/05/understanding-yuv-values/
  
    // Normalize Y to range [0 255]
    //
    // Note that the matrix multiply will adjust
    // this byte normalized range to account for
    // the limited range [16 235]
  
    float Yn = (Y - 16) * (1.0f / 255.0f);
  
    // Normalize Cb and CR with zero at 128 and range [0 255]
    // Note that matrix will adjust to limited range [16 240]
  
    float Cbn = (Cb - 128) * (1.0f / 255.0f);
    float Crn = (Cr - 128) * (1.0f / 255.0f);
  
    const float YScale = 255.0f / (YMax-YMin);
    const float UVScale = 255.0f / (UVMax-UVMin);
  
    const
    float BT709Mat[] = {
      YScale,   0.000f,  (UVScale * Er_minus_Ey_Range),
      YScale, (-1.0f * UVScale * Eb_minus_Ey_Range * Kb_over_Kg),  (-1.0f * UVScale * Er_minus_Ey_Range * Kr_over_Kg),
      YScale, (UVScale * Eb_minus_Ey_Range),  0.000f,
    };
  
    // Matrix multiply operation
    //
    // rgb = BT709Mat * YCbCr
  
    // Convert input Y, Cb, Cr to normalized float values
  
    float Rn = (Yn * BT709Mat[0]) + (Cbn * BT709Mat[1]) + (Crn * BT709Mat[2]);
    float Gn = (Yn * BT709Mat[3]) + (Cbn * BT709Mat[4]) + (Crn * BT709Mat[5]);
    float Bn = (Yn * BT709Mat[6]) + (Cbn * BT709Mat[7]) + (Crn * BT709Mat[8]);
  
    // Saturate normalzied linear (R G B) to range [0.0, 1.0]
  
    Rn = saturatef(Rn);
    Gn = saturatef(Gn);
    Bn = saturatef(Bn);
  
    // Gamma adjustment for RGB components after matrix transform
  
    if (applyGammaMap) {
      Rn = BT709_nonLinearNormToLinear(Rn);
      Gn = BT709_nonLinearNormToLinear(Gn);
      Bn = BT709_nonLinearNormToLinear(Bn);
    }
  
    *RPtr = Rn;
    *GPtr = Gn;
    *BPtr = Bn;
  
    return 0;
  }
  

  I believe this logic is implemented correctly, but I am having a very difficult time validating the results. When I generate a .m4v file that contains gamma adjusted color values (osxcolor_test_image_24bit_BT709.m4v), the result come out as expected. But a test case like (bars_709_Frame01.m4v) that I found here does not seem to work as the color bar values seem to be encoded as linear (no gamma adjustment).

  For a SMPTE test pattern, the 0.75 graylevel is linear RGB (191 191 191), should this RGB be encoded with no gamma adjustment as (Y Cb Cr) (180 128 128) or should the value in the bitstream appear as the gamma adjusted (Y Cb Cr) (206 128 128)?

  (follow up) After doing additional research into this gamma issue, it has become clear that what Apple is actually doing in AVFoundation is using a 1.961 gamma function. This is the case when encoding with AVAssetWriterInputPixelBufferAdaptor, when using vImage, or with CoreVideo APIs. This piecewise gamma function is defined as follows:

  #define APPLE_GAMMA_196 (1.960938f)
  
  static inline
  float Apple196_nonLinearNormToLinear(float normV) {
    const float xIntercept = 0.05583828f;
  
    if (normV < xIntercept) {
      normV *= (1.0f / 16.0f);
    } else {
      const float gamma = APPLE_GAMMA_196;
      normV = pow(normV, gamma);
    }
  
    return normV;
  }
  
  static inline
  float Apple196_linearNormToNonLinear(float normV) {
    const float yIntercept = 0.00349f;
  
    if (normV < yIntercept) {
      normV *= 16.0f;
    } else {
      const float gamma = 1.0f / APPLE_GAMMA_196;
      normV = pow(normV, gamma);
    }
  
    return normV;
  }
  

• ffmpeg use setdar in filter

  27 janvier 2019, par Marius Pricker

  As described already here ffpeg I get an error when using this command

  ffmpeg -i 234627426842_converted.mp4 -i 1548625936003_converted.mp4 -i 1548626656821_converted.mp4 -i 1548625467753_converted.mp4 -c:a aac -strict -2 -filter_complex [0:v:0][0:a:0][1:v:0][1:a:0][2:v:0][2:a:0][3:v:0][3:a:0]concat=n=4:v=1:a=1[v][a] -map [v] -map [a] ready.mp4
  

  in order to concentrate 4 different videos. However, I cant add setdar=16/9 to the filter as said in the accepted answer of the previously mentioned question because my filter looks like this:

  [0:v:0][0:a:0][1:v:0][1:a:0][2:v:0][2:a:0][3:v:0][3:a:0]concat=n=4:v=1:a=1[v][a]
  

  How can I add setdar=16/9 to every video stream using this layout? (Im new to ffmpeg)

• Transforming ffmpeg code to batch process files in linux

  27 janvier 2019, par Kururin

  I need help converting ffmpeg command to so I can batch process the files

  ffmpeg -i in.mkv -vf subtitles=in.mkv:si=0 -c:v libx264 -c:a copy -map 0:v -map 0:a:0 out.mp4
  

  Convert everything in the folder to same name as the .mkv file but to .mp4. The file name can have [ ] _ and spaces. So I will really appreciate if any one can help me and explain the process!

• Ffmpeg issue : At the time of convert from .webm to .mp4 it getting 0 MB size

  27 janvier 2019, par amit kumar

  At any time I get video file whereas video as .webm. So, files have different different size.

  Now the issue is: I have a pair of video files whose video size is 7 mb when they execute to create mp4, then it success whose mp4 size become 5.18 MB.

  At the same time again I have a files whose size is 4.65 MB of video as .webm then, when they execute then Mp4 files are create but size becomes 0 MB.

  So I need help why this becomes 0 MB.

  Note: whereas I am using this command:

   (-i  407118_agentPL27_2018-09-26T16-18-17.webm  407118_agentPL27_2018-     
    09- 26T16-18-17_in.mp4)
  

  I have many of files whose size lies between 1 MB to 1 GB, they also not create MP4. But, in between if give 7 MB to 9 MB file it creates with Proper size.

  I need the command as above which I send, from that command if I pass into ffmpeg between 1 MB to 1GB .webm file then the MP4 file should must be created.

  Note: I don't have console output because I am implementing this command with C#.