Recherche avancée

Sur d’autres sites (8748)

• In ffmpeg : Can't get peak bitrate values within 10% error tolerance for HLS playlist files

  5 octobre 2019, par ALS20394

  I’m using ffmpeg to produce several HLS variant playlists from an .mp4 file. When I check master.m3u8 file with mediastreamvalidator I get :

  Error : Measured peak bitrate compared to master playlist declared value exceeds error tolerance

  I understand that the error percentage needs to be less than 10%, and figured it out on 1 variant but not the three others. I’ve spent quite a bit of time adjusting the -maxrate and the -buffsize but the error percentage change is minimal. Beginning to wonder if I’m misunderstanding something ?

  This is the latest of what I enter :

  ffmpeg -i FHVid.mp4 \
  
  -b:v:0 5000k -maxrate 5250k -bufsize 5500k -profile:v main -c:v h264 -crf 20 -sc_threshold 0 -g 48 \
  
  -b:v:1 2800k -maxrate 2940k -bufsize 3100k -profile:v main -c:v h264 -crf 20 -sc_threshold 0 -g 48 \
  
  -b:v:2 1400k -maxrate 1540k -bufsize 1700k -profile:v main -c:v h264 -crf 20 -sc_threshold 0 -g 48 \
  
  -b:v:3 800k -maxrate 840k -bufsize 1050k -profile:v main -c:v h264 -crf 20 -sc_threshold 0 -g 48 \
  
  -b:a:0 192k \
  
  -b:a:1 128k \
  
  -b:a:2 128k \
  
  -b:a:3 96k \
  
  -c:a aac -ar 48000 -keyint_min 48 -map 0:v -map 0:a -map 0:v -map 0:a -map 0:v -map 0:a -map 0:v -map 0:a \
  
  -f hls -var_stream_map "v:0,a:0  v:1,a:1 v:2,a:2 v:3,a:3" \
  
  -master_pl_name FHVidmaster.m3u8 -hls_time 4 -hls_playlist_type vod \
  
  -hls_segment_filename 'file_%v_%03d.ts' out_%v.m3u8

  but I’ve also tried max rates that seem to be more standard

  -b:v:0 5000k -maxrate 5500k -bufsize 6500k
  
  -b:v:1 2800k -maxrate 3080k -bufsize 3200k
  
  -b:v:2 1400k -maxrate 1540k -bufsize 1900k
  
  -b:v:3 800k -maxrate 880k -bufsize 1050k

  The latest error message :

  Error: Measured peak bitrate compared to master playlist declared value exceeds error tolerance
  
  --> Detail:  Measured: 1111.54 kb/s, Master playlist: 1680.80 kb/s, Error: 33.87%
  
  --> Source:  /Users/Bun/Documents/CODING/CosmicPerspectiveAssets/01-FalconHeavy/HLS/FHVidmaster.m3u8
  
  --> Compare: out_2.m3u8
  
  
  
  --> Detail:  Measured: 1178.21 kb/s, Master playlist: 5711.20 kb/s, Error: 79.37%
  
  --> Source:  /Users/Bun/Documents/CODING/CosmicPerspectiveAssets/01-FalconHeavy/HLS/FHVidmaster.m3u8
  
  --> Compare: out_0.m3u8
  
  
  
  --> Detail:  Measured: 1109.03 kb/s, Master playlist: 3220.80 kb/s, Error: 65.57%
  
  --> Source:  /Users/Bun/Documents/CODING/CosmicPerspectiveAssets/01-FalconHeavy/HLS/FHVidmaster.m3u8
  
  --> Compare: out_1.m3u8

  Any help would be greatly appreciated on the -maxrate and -buffsize for variant playlists 0, 1, and 2. No adjustment I make seems to make any difference.

• lavu/tx : implement 32 bit fixed point FFT and MDCT

  9 février 2020, par Lynne

  lavu/tx : implement 32 bit fixed point FFT and MDCT
  Required minimal changes to the code so made sense to implement.
  
  FFT and MDCT tested, the output of both was properly rounded.
  
  Fun fact : the non-power-of-two fixed-point FFT and MDCT are the fastest ever
  
  non-power-of-two fixed-point FFT and MDCT written.
  
  This can replace the power of two integer MDCTs in aac and ac3 if the
  
  MIPS optimizations are ported across.
  
  Unfortunately the ac3 encoder uses a 16-bit fixed point forward transform,
  
  unlike the encoder which uses a 32bit inverse transform, so some modifications
  
  might be required there.
  The 3-point FFT is somewhat less accurate than it otherwise could be,
  
  having minor rounding errors with bigger transforms. However, this
  
  could be improved later, and the way its currently written is the way one
  
  would write assembly for it.
  
  Similar rounding errors can also be found throughout the power of two FFTs
  
  as well, though those are more difficult to correct.
  
  Despite this, the integer transforms are more than accurate enough.
  

  • [DH] doc/APIchanges
  • [DH] libavutil/Makefile
  • [DH] libavutil/tx.c
  • [DH] libavutil/tx.h
  • [DH] libavutil/tx_int32.c
  • [DH] libavutil/tx_priv.h
  • [DH] libavutil/tx_template.c
  • [DH] libavutil/version.h

• avfilter/scale* : add option reset_sar

  31 janvier, par Gyan Doshi

  avfilter/scale* : add option reset_sar
  For anamorphic videos, enabling this option leads to adjustment of
  
  output dimensions to obtain square pixels when the user requests
  
  proportional scaling through either of the w/h expressions or
  
  force_original_aspect_ratio.
  Output SAR is always reset to 1.
  Option added to scale, scale_cuda, scale_npp & scale_vaapi.
  libplacebo already has a similar option with different semantics,
  
  scale_vt and scale_vulkan don't implement force_oar, so for these
  
  three filters, I've made minimal changes needed to not break building
  
  or change output.
  

  • [DH] doc/filters.texi
  • [DH] libavfilter/scale_eval.c
  • [DH] libavfilter/scale_eval.h
  • [DH] libavfilter/vf_libplacebo.c
  • [DH] libavfilter/vf_scale.c
  • [DH] libavfilter/vf_scale_cuda.c
  • [DH] libavfilter/vf_scale_npp.c
  • [DH] libavfilter/vf_scale_vaapi.c
  • [DH] libavfilter/vf_scale_vt.c
  • [DH] libavfilter/vf_scale_vulkan.c