Recherche avancée

Sur d’autres sites (4349)

• AVI compression with ffmpeg while maintaining alpha channel, to use in Adobe Premiere

  12 décembre 2020, par Dsrts

  I am a novice when it comes to handling video conversion/encoding in general, but have spent a few days trying to figure out if ffmpeg, or any other method out there, is able to compress an .avi that has rgb+a. I have been able to get a few files that appear to work when played in VLC, but they wont load into Adobe Premiere to verify that alpha was maintained, and I assume it is a codec issue and/or a pixel format issue, but so far I haven't been able to pinpoint it.

  


  Also, I'm not sure if it's advisable to compress an .avi at all with alpha since it could lead to quality issues from compression. Some loss of quality is ok if it means reducing file size.

  


  My goal is to convert an avi file to a smaller video file, that isn't multiple GB in size. Currently I have 8 sec transparent lower thirds file that is about 2GB in size. Simply adjusting bitrate has not done it, as that seems to wipe out the alpha channel and I end up with RGB with a white background. I have tried using a PNG codec, with various different pixel formats. This yielded files that would open in VLC, but not Adobe Premiere. I suspect that this has something to do with the codec, though as to what it is, I have no idea.

  


  Right now, this seems like it may just not be possible. Here are some examples of what I have tried :

  


  ffmpeg -i "input.avi" -map 0 -c:v png -c:a copy "Compressed.avi"

  


  —this just creates a file that opens in vlc, but not premiere

  


  ffmpeg.exe -i "input.avi" -vcodec png -b:v 64k -pix_fmt rgb32 "Compressed.avi"

  


  —this does the same thing as above, I tried every pixel format on this list with no success.

  


  ffmpeg.exe -i "input.avi" -b:v 64k -pix_fmt bgr32 "Compressed.avi"

  


  —this just results in an avi with a white background, kills alpha.

  


  That is the closest I have come. The bitrate value is likely arbitrary, as I have also tried with and without bitrate modification. I don't know if there is a way to get Premiere to recognize the files that did open in VLC with the PNG codec, or if there is something I am missing, OR if this is just entirely impossible. The output doesn't need to be .avi either, so long as it will open in Premiere.

  


  —
Edit : Requested in the comments, output from ffmpeg -i input.avi

  


  ffmpeg version 4.3.1-2020-11-19-essentials_build-www.gyan.dev Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 10.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, avi, from 'input.avi':
  Metadata:
    date            : 2020-12-09T20:27:57.080928
  Duration: 00:00:10.00, start: 0.000000, bitrate: 1990700 kb/s
    Stream #0:0: Video: rawvideo, bgra, 1920x1080, 1997313 kb/s, 30 fps, 30 tbr, 30 tbn, 30 tbc
At least one output file must be specified


  


  — Edit 2 :
Tried this from the comment and it results in a .mov with preserved alpha but it picks up the white pixel values from text drop shadows, resulting in an outer glow effect instead :

  


  ffmpeg -i "input.avi" -map 0 -pix_fmt rgba -c:v png -c:a copy "compressed.mov"

  


  I also tried the following, and I get dropped frames in addition to similar transparency issues in the drop shadow :

  


  ffmpeg -i "input.avi" -map 0 -pix_fmt rgba -c:v qtrle -c:a copy "compressed.mov"

  


• Choose your favourite logo

  28 septembre 2018, par Matomo Core Team — Community

  We’ve been searching for a new logo and we are now down to the final three designs. We want you, the community, to help us choose our logo as we set the scene for a refreshed and vibrant new look for Matomo.

  Please choose your favourite Matomo logo from the three options below. Voting limited to once per person :)

  • Choose your favorite logo*
    • 
    • 
    • 

  
  
  
  
  

• 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;
  
  }