Recherche avancée

Sur d’autres sites (10327)

• Firefox audio tag doubles length of OGG Vorbis

  22 mai 2014, par tomysshadow

  So, here I have a demo file from my website

  http://members.shaw.ca/darolynk/breakup/html5game/snd_music.ogg

  I am running off of Firefox Beta 30.0 and this issue does not persist in Google Chrome. In Firefox, when I play the file back, the length is displayed at around twice of its actual length as 32:13 when it is only 12:52 in length. Even worse, the audio stutters, playing one second of noise, one second of silence. This issue is not persistent in Chrome nor Opera. It is not a streaming issue (the song is streamed by the time it is played back in fact).

  I am wondering if this is an issue with the codec or with Firefox’s intrepretation of the codec, but more importantly, I want to know how to fix it. Some information about the file : the file is in OGG Vorbis format, 44100 Hz, 32 kbps Mono (yes, I am running out of storage space). It was encoded with SUPER, which in turn uses FFMpeg and MEncoder as necessary.

  This does not apply to all files of this format, making the issue even stranger. Are OGG Vorbis files over a certain length not allowed or interpreted differently by Firefox ? This must be the case for someone else and not just me...

  Any help is appreciated, thanks in advance !

• 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