Recherche avancée

Sur d’autres sites (5678)

• Anomalie #3271 (Nouveau) : tailles_en_octets : tenir compte des norme SI

  22 septembre 2014, par Maïeul Rouquette

  On va pas revenir sur l’historique des puissance de 2 comme unité de mesure, mais actuellement taille_en_octets fait comme si 1 ko = 1024 octets.

  Depuis la normalisation par l’iso, on distingue :
  - 1 ko = 1000 octets
  - 1kio = 1024 octets

  et de même pour les multiples au dessus. Cela n’a guère d’importance pour les petites unités, mais à partir du giga cela se fait sentir.

  Voir https://fr.wikipedia.org/wiki/Octet#Multiples_normalis.C3.A9s

  Proposition pour que SPIP soit conforme aux normes ISO :
  - changer les chaînes de langues pour utiliser le kibi au lieu du kilo
  - Utiliser les multiples de 10 dans la fonction taille_en_octets, en proposant une constante pour basculer vers l’ancien mode

• Transcode HLS Segments individually using FFMPEG

  27 mai 2013, par rayh

  I am recording a continuous, live stream to a high-bitrate HLS stream. I then want to asynchronously transcode this to different formats/bitrates. I have this working, mostly, except audio artefacts are appearing between each segment (gaps and pops).

  Here is an example ffmpeg command line :

  ffmpeg -threads 1 -nostdin -loglevel verbose \
  
     -nostdin -y -i input.ts -c:a libfdk_aac \
  
     -ac 2 -b:a 64k -y -metadata -vn output.ts

  Inspecting an example sound file shows that there is a gap at the end of the audio :

  

  And the start of the file looks suspiciously attenuated (although this may not be an issue) :

  

  My suspicion is that these artefacts are happening because transcoding are occurring without the context of the stream as a whole.

  Any ideas on how to convince FFMPEG to produce audio that will fit back into a HLS stream ?

  ** UPDATE 1 **

  Here are the start/end of the original segment. As you can see, the start still appears the same, but the end is cleanly ended at 30s. I expect some degree of padding with lossy encoding, but I there is some way that HLS manages to do gapless playback (is this related to iTunes method with custom metadata ?)

  
  

  ** UPDATED 2 **

  So, I converted both the original (128k aac in MPEG2 TS) and the transcoded (64k aac in aac/adts container) to WAV and put the two side-by-side. This is the result :

  
  

  I'm not sure if this is representative of how a client will play it back, but it seems a bit odd that decoding the transcoded one introduces a gap at the start and makes the segment longer. Given they are both lossy encoding, I would have expected padding to be equally present in both (if at all).

  ** UPDATE 3 **

  According to http://en.wikipedia.org/wiki/Gapless_playback - Only a handful of encoders support gapless - for MP3, I've switched to lame in ffmpeg, and the problem, so far, appears to have gone.

  For AAC (see http://en.wikipedia.org/wiki/FAAC), I have tried libfaac (as opposed to libfdk_aac) and it also seems to produce gapless audio. However, the quality of the latter isn't that great and I'd rather use libfdk_aac is possible.

• ffmpeg : do packet ts rescaling in write_packet()

  27 mai 2016, par Anton Khirnov

  ffmpeg : do packet ts rescaling in write_packet()
  This will be useful in the following commit, after which the muxer
  
  timebase is not always available when encoding.
  This merges Libav commit 3e265ca. It was previously skipped.
  There are some changes with how/when the mux_timebase field is set,
  
  because the Libav approach often causes a too imprecise time base
  
  to be set. This is hard, because the muxer’s write_header function
  
  can readjust the timebase, at which point we might already have
  
  encoded packets buffered. (It might be better to buffer them after
  
  the encoder, instead of after all the timestamp handling logic
  
  before muxing.)
  The two FATE tests change because the output time base is raised
  
  for subtitles. (Needed to avoid certain rounding issues in other
  
  cases.)
  Includes a minor merge fix by Mark Thompson, and
      avconv : Move rescale to stream timebase before monotonisation
  also by Mark Thompson <sw@jkqxz.net>.
  Signed-off-by : wm4 <nfxjfg@googlemail.com>
  

  • [DH] ffmpeg.c
  • [DH] ffmpeg.h
  • [DH] tests/ref/fate/binsub-movtextenc
  • [DH] tests/ref/fate/sub2video