Recherche avancée

Sur d’autres sites (9132)

• aac_ac3_parser : Drop in-parser downmix functionality

  26 avril 2017, par Vittorio Giovara

  aac_ac3_parser : Drop in-parser downmix functionality
  request_channel_layout is a decoder option and it makes no sense
  
  to have it in a parser.
  This feature was needed in the past when the decoder was allowed
  
  to reuse the avctx from the demuxer. Nowadays the decoder receives
  
  only the parameters from it, already containing the real channel
  
  layout (and the correct request_channel_layout option).
  After initialization the decoder overwrites the channel layout
  
  with the downmixed one that is actually output, so there is no need
  
  to preserve this functionality in the parser.
  Signed-off-by : Vittorio Giovara <vittorio.giovara@gmail.com>
  

  • [DBH] libavcodec/aac_ac3_parser.c

• Getting very high latencies while syncing live folder data to cloud storage [closed]

  28 juillet 2024, par baloda

  I am working on custom HLS Live transcoding implementation in GCP with k8s pods. I have tried s3fs, rclone, GCS-FUSE with sidecar solutions to sync data into s3/GCS. But getter very high latency to sync data to respective storage origin. Can someone suggest how i can reduce this latency ?

  


  System info : K8s Pod in GCP
Transcoding Tools : FFmpeg
Storage Origin : GCS, S3
Feed Type : live rtmp
Output : HLS with .m3u8 manifest & 4 sec .ts chunks

  


  

  1. GCS-Fuse sidecar :
with this transcoding pipeline is not able to use full cpu and it limit ffmpeg cpu used to 0.4 core

  


  2. Temp output directory for ffmpeg output & rclone ffmpeg output with GCS-Fuse sidecar mounted folder :
This implantation allowed ffmpeg to consume cpu till 10 core but rclone does not work as intended. It syncs data randomly. Tried a couple rsync optimisation and checksum options. but did not got expected result.

  


  3. s3fs :
This takes admin privileges. did not able to excute it for now. But i am assuming it will give similar result to GCS-Fuse

  


  


• Revision 23ebacdb81 : Auto-adaptive encoder frame resizing logic Note : This feature is still in devel

  15 novembre 2014, par Adrian Grange

  Changed Paths :
   Modify /vp9/encoder/vp9_encoder.c

  
   Modify /vp9/encoder/vp9_encoder.h

  
   Modify /vp9/encoder/vp9_firstpass.c

  
   Modify /vp9/encoder/vp9_firstpass.h

  
   Modify /vp9/encoder/vp9_ratectrl.c

  
   Modify /vp9/encoder/vp9_ratectrl.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
   Modify /vp9/encoder/vp9_speed_features.c

  
  
  Auto-adaptive encoder frame resizing logic

  Note : This feature is still in development.

  Add an option for the encoder to decide the resolution
  at which to encode each frame.

  Each KF/GF/ARF goup is tested to see if it would be
  better encoded at a lower resolution. At present, each
  KF/GF/ARF is coded first at full-size and if the coded
  size exceeds a threshold (twice target data rate) at
  the maximum active Q then the entire group is encoded
  at lower resolution.

  This feature is enabled in vpxenc by setting :
  —resize-allowed=1

  In addition, if the vpxenc command line also specifies
  valid frame dimensions using :
  —resize-width=XXXX & —resize_height=YYYY
  then *all* frames will be encoded at this resolution.

  Change-Id : I13f341e0a82512f9e84e144e0f3b5aed8a65402b