Recherche avancée

Sur d’autres sites (13003)

• 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.

• The RTSP stream provided by my camera is parsed properly by ffmpeg on windows but on Linux it shows：Invalid data found when processing input ? [closed]

  9 novembre 2023, par LvWei

  The RTSP stream provided by my camera is parsed properly by ffmpeg on windows but on Linux it shows：Invalid data found when processing input ?

  


  The execution logs for ffmpeg for both operating systems are as follows：

  


  Linux :

  


  Opening an input file: rtsp://admin:12345678wjc@10.11.12.143:8960/h264/ch1/sub/av_stream.
Probing rtsp score:100 size:0
[tcp @ 0x64c8480] No default whitelist set
[tcp @ 0x64c8480] Original list of addresses:
[tcp @ 0x64c8480] Address 10.11.12.143 port 8960
[tcp @ 0x64c8480] Interleaved list of addresses:
[tcp @ 0x64c8480] Address 10.11.12.143 port 8960
[tcp @ 0x64c8480] Starting connection attempt to 10.11.12.143 port 8960
[tcp @ 0x64c8480] Successfully connected to 10.11.12.143 port 8960
[rtsp @ 0x64c5840] Sending:
OPTIONS rtsp://10.11.12.143:8960/h264/ch1/sub/av_stream RTSP/1.0
CSeq: 1
User-Agent: Lavf60.3.100

--
[rtsp @ 0x64c5840] ret=-104 c=00 [rtsp://admin:password@10.11.12.143:8960/h264/ch1/sub/av_stream: Invalid data found when processing input


  


  Windows :

  


  [tcp @ 000001c07a8ddd00] No default whitelist set
[tcp @ 000001c07a8ddd00] Original list of addresses:
[tcp @ 000001c07a8ddd00] Address 10.11.12.143 port 8960
[tcp @ 000001c07a8ddd00] Interleaved list of addresses:
[tcp @ 000001c07a8ddd00] Address 10.11.12.143 port 8960
[tcp @ 000001c07a8ddd00] Starting connection attempt to 10.11.12.143 port 8960
[tcp @ 000001c07a8ddd00] Successfully connected to 10.11.12.143 port 8960
[rtsp @ 000001c07a8da480] Sending:
OPTIONS rtsp://10.11.12.143:8960/h264/ch1/sub/av_stream RTSP/1.0
CSeq: 1
User-Agent: Lavf60.15.100

--
[rtsp @ 000001c07a8da480] ret=1 c=52 [R]
[rtsp @ 000001c07a8da480] ret=1 c=54 [T]
[rtsp @ 000001c07a8da480] ret=1 c=53 [S]
[rtsp @ 000001c07a8da480] ret=1 c=50 [P]
[rtsp @ 000001c07a8da480] ret=1 c=2f [/]
[rtsp @ 000001c07a8da480] ret=1 c=31 [1]
[rtsp @ 000001c07a8da480] ret=1 c=2e [.]
[rtsp @ 000001c07a8da480] ret=1 c=30 [0]
[rtsp @ 000001c07a8da480] ret=1 c=20 [ ]
[rtsp @ 000001c07a8da480] ret=1 c=32 [2]
[rtsp @ 000001c07a8da480] ret=1 c=30 [0]
    Last message repeated 1 times
[rtsp @ 000001c07a8da480] ret=1 c=20 [ ]
[rtsp @ 000001c07a8da480] ret=1 c=4f [O]
[rtsp @ 000001c07a8da480] ret=1 c=4b [K]
[rtsp @ 000001c07a8da480] ret=1 c=0d [
]
[rtsp @ 000001c07a8da480] ret=1 c=0a [
]
[rtsp @ 000001c07a8da480] line='RTSP/1.0 200 OK'


  


  windows下完整执行日志链接：
https://cowtransfer.com/s/b69b55e743c244 点击链接查看 [ windows_log.txt ] ，或访问奶牛快传 cowtransfer.com 输入传输口令 bsp0fk 查看；

  


  Why is this happening ? What causes parsing failures on linux systems ?感谢各位大佬！！！