Recherche avancée

Sur d’autres sites (5079)

• Revision 92733 : fix supplementaire de r80391 (suite de r82954) : il ne faut pas ...

  7 novembre 2015, par cedric@… — Log

  fix supplementaire de r80391 (suite de r82954) : il ne faut pas exclure les articles dont aucun index ne match mais dont l’index d’un mot cle lie match (b_b). A valider

• problem compiling ffmpeg for iFrameExtractor

  11 septembre 2012, par Robin Rye

  I'm trying to compile the ffmpeg by using the make and build files in iFrameExtractor example. firstly i tried to follow the readme file on the github, which only says to run the ./build_universal in ffmpeg folder. it did not work

  i then tried to follow the info in INSTALL without success. i then tried doing the stuff in INSTALL followed by the ./build_universal which didn't work. All the *.a files that are imported to the project exists until the end of the build sequence. when the lipo commands in build_universal are run, which i guess concat the .a files for the different architectures(?). anyhow these leave the following errors :

  lipo: specifed architecture type (armv6) for file (armv6/libavcodec.a) does not match it's cputype (16777223) and cpusubtype (3) (should be cputype (12) and cpusubtype (6))
  
  lipo: specifed architecture type (armv6) for file (armv6/libavdevice.a) does not match it's cputype (16777223) and cpusubtype (3) (should be cputype (12) and cpusubtype (6))
  
  lipo: specifed architecture type (armv6) for file (armv6/libavformat.a) does not match it's cputype (16777223) and cpusubtype (3) (should be cputype (12) and cpusubtype (6))
  
  lipo: specifed architecture type (armv6) for file (armv6/libavutil.a) does not match it's cputype (16777223) and cpusubtype (3) (should be cputype (12) and cpusubtype (6))
  
  lipo: specifed architecture type (armv6) for file (armv6/libswscale.a) does not match it's cputype (16777223) and cpusubtype (3) (should be cputype (12) and cpusubtype (6))

  i can get the project to compile for simulator if i only use ./build_armv7 but if i run the universal the .a files are removed in the end. and only using doesn't work to build for iphone 4 .

• Increased File Size When Converting MP4 to WebM using FFmpeg

  23 décembre 2024, par kimgijeong

  I am using FFmpeg to convert MP4 to WebM with the following command :

  


  ffmpeg -y -hide_banner -nostats \
-f mov,mp4,m4a,3gp,3g2,mj2 -i "http://127.0.0.1:80/lotteon-low-bitrate.mp4" \
-threads auto -f webm -acodec libopus -b:a 96.059k -vcodec libsvtav1 -preset 11 -pix_fmt yuv420p \
-vf "scale='min(-1, iw)':'min(-1,ih)':force_original_aspect_ratio=decrease,crop=trunc(iw/2)*2:trunc(ih/2)*2" \
"/usr/local/m2/m2temp/xcdrtmp/2052_1.webm"


  


  However, the output webm file size is larger than the source MP4 file. For example :

  


  


  • Source MP4 : 4.6 MB (bit rate : 994,053 bps)

    


  


  • Output WebM : 16 MB (bit rate : 3,902,037 bps)

    


  


  


  I know SVT-AV1 encoder defaults to CRF mode. Due to not specifying the bitrate explicitly, the SVT-AV1 encoder automatically sets the bit_rate. It appears that the encoder is setting it to a much higher value (3,323,104 bps), causing the increase in file size compared to the source MP4 (994,053 bps). Here are the methods i tried to reduce the WebM file size compared to the source MP4 :

  


  

  1. -b:v 994k

  


  


  I tried to match the target bitrate with the source MP4's bitrate to reduce the output size, but encountered the following error :

  


  Svt[error]: Instance 1: Force key frames is not supported for VBR mode Last message r
epeated 2 times [libsvtav1 @ 0x239dd100] Error setting encoder parameters: bad parameter (0x80001005)


  


  Looking at the official documentation, this mode change (from CRF to VBR when setting a target bitrate) appears to be expected behavior. However, the error is puzzling since I haven't set any force keyframe parameters in the FFmpeg command.

  


  

  2. svtav1-params "mbr=994k"

  


  


  The second method i tried was using the svtav1-params "mbr=994k" option to set the maxrate while maintaining CRF mode This method showed some improvement, but the output file size was still larger than the source MP4.

  


  

  • Output WebM : 5MB (bit rate : 1,209,877 bps)

  


  


  The more critical reason why we can't adopt the second method (using svtav1-params "mbr=994k") is that even for the same MP4 source file, the output file size varies slightly with each encoding.

  


  

  3. -b:v 994k -svtav1-params “rc=2:pred-struct=1”(CBR, low delay)

  


  


  The final method I tried was setting the target bitrate while using CBR (Constant Bit Rate) and low-delay mode The default value for pred-structure is 2(random access), but I had to use low-delay mode due to the following error :

  


  Svt[error]: CBR Rate control is currently not supported for SVT_AV1_PRED_RANDOM_ACCESS, use VBR mode


  


  This way was the only approach among those i tried that successfully reduced the output size.

  


  

  • Output WebM : 4.3MB (bit rate : 1,032,373 bps)

  


  


  In summary, I have three questions about this MP4 to WebM conversion issue :

  


  


  1. When setting the target bitrate with -b:v 994k, the switch to VBR mode is expected behavior. However, why does the force keyframe error occur when we haven't explicitly set any force keyframe parameters ?

     


  


  2. Why does the output WebM file size fluctuate when setting maxrate either through -maxrate or svtav1-params "mbr=994k", even when using the same MP4 source file ?

     


  


  3. Besides using -b:v 994k -svtav1-params "rc=2:pred-struct=1" (CBR with low delay), are there any other methods that can guarantee a WebM output size smaller than the source MP4 when converting from MP4 to WebM ?

     


  


  


  I am using a recent version of the SVT-AV1 codec :

  


  Svt[info]: SVT [version]:       SVT-AV1 Encoder Lib 58146ca
Svt[info]: SVT [build]  :       GCC 11.5.0 20240719 (Red Hat 11.5.0-2)   64 bit
Svt[info]: LIB Build date: Oct 28 2024 07:40:59
ffmpeg video svt-av1