Recherche avancée

Sur d’autres sites (6117)

• Duration of short ogg files (Telegram Voice messages) not correct when loaded into Python

  4 août 2018, par Kromme

  I’m trying to read voice messages, sent by Telegram, using Python but for short voice clips (< 10 seconds), it doesn’t work. It shortens the duration for some reason. It looks like it has something to do with OGG codec, but I’m not really sure.

  See here’s my code, the voice clip is about six seconds, however pydub reads my 6 second voiceclip as 0.06 seconds.

  import telegram
  
  from pydub import AudioSegment
  
  
  
  AudioSegment.ffmpeg = "./dependencies/ffmpeg-20180802-c9118d4-win64-static/bin/ffmpeg"
  
  AudioSegment.converter = "./dependencies/ffmpeg-20180802-c9118d4-win64-static/bin/ffmpeg"
  
  
  
  
  
  bot = telegram.Bot(token=token)
  
  f = bot.get_file(file_id)
  
  f.download('output/voiceclips/{}.ogg'.format(file_id))
  
  
  
  myaudio = AudioSegment.from_ogg("output/voiceclips/{}.ogg".format(file_id))
  
  print('ID: {}, which is {} seconds'.format(file_id, myaudio.duration_seconds)) 
  
  
  
  >>> ID: ______, which is 0.06 seconds

  When I open the file in VLC-player, it also states that is has 0 seconds. When I try to convert it to WAV-files using FFmpeg it reads the ogg file as 6 seconds, but writes it as 0.05-second WAV file.

  ffmpeg -i infile.ogg outfile.wav
  
  ffmpeg version N-91549-gc9118d4d64 Copyright (c) 2000-2018 the FFmpeg developers
  
    built with gcc 7.3.1 (GCC) 20180722
  
    configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  
    libavutil      56. 18.102 / 56. 18.102
  
    libavcodec     58. 22.100 / 58. 22.100
  
    libavformat    58. 17.101 / 58. 17.101
  
    libavdevice    58.  4.101 / 58.  4.101
  
    libavfilter     7. 26.100 /  7. 26.100
  
    libswscale      5.  2.100 /  5.  2.100
  
    libswresample   3.  2.100 /  3.  2.100
  
    libpostproc    55.  2.100 / 55.  2.100
  
  [ogg @ 0000020dd375ad40] 727 bytes of comment header remain
  
  Input #0, ogg, from 'infile.ogg':
  
    Duration: 00:00:06.03, start: 0.000000, bitrate: 20 kb/s
  
      Stream #0:0: Audio: opus, 48000 Hz, mono, fltp
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (opus (native) -> pcm_s16le (native))
  
  Press [q] to stop, [?] for help
  
  Output #0, wav, to 'outfile.wav':
  
    Metadata:
  
      ISFT            : Lavf58.17.101
  
      Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, mono, s16, 768 kb/s
  
      Metadata:
  
        encoder         : Lavc58.22.100 pcm_s16le
  
  size=       6kB time=00:00:00.05 bitrate= 873.0kbits/s speed=4.12x
  
  video:0kB audio:6kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.354167%

  For larger files it does the work !

• Microsoft Smooth Streaming declares timescale of 10M by default

  21 décembre 2020, par Andrey Rikunov

  As far as I understand timescale should be completely dividable by fps to have exact timestamps.

  &#xA;&#xA;

  Microsoft Smooth Streaming uses timescale 10M by default which is leaked as hardcoded value in various smarttv clients and packaging tools thus limiting video fps to 25 and other dividers of 10M.

  &#xA;&#xA;

  How is it possible to package 24 fps video for mss clients which support 10M only ?

  &#xA;

• Anomalie #3630 : Logo d’auteur et fonction de recherche de logo

  30 décembre 2015, par Debondt Didier

  Hello,

  Juste une petite remarque : id_table_objet semble assez inoffensif, car si c’est déjà une clé primaire qui est envoyée, elle n’y touchera pas.

  Du coup, cela pourrait rendre quete_logo compatible avec les dénomination "objet" et non pas les clés primaire.
  Ce qui me semble plus logique, partout ailleurs (à ma connaissance) dans SPIP on utilise objet/id_objet.