Recherche avancée

Sur d’autres sites (6551)

• ffmpeg udp/tcp stream receive frame not same as sent

  21 novembre 2013, par vivienlwt

  I am streaming a video on raspberrypi using command :

  ffmpeg -re -threads 2 -i sample_video.m2v -f mpegts - | \
  
  ffmpeg -f mpegts -i - -c copy -f mpegts udp://192.168.1.100:12345

  The remote PC with 192.168.1.100 uses ffmpeg library to listen to the input stream. For example :

  informat = ffmpeg::av_find_input_format("mpegts");
  
  avformat_open_input(&pFormatCtx, "udp://192.168.1.100:12345", informat, options);

  However, when I compute the hash value of each decoded frame on two sides (i.e. raspberrypi and PC), they DON'T MATCH at all. A weird thing is, among 2000 frames, there are in total 10 frames whose hash value are the same on the sender and receiver side. The match result look like this :

  00000....00011000...00011110000...000

  where 0 indicates non-match and 1 indicates match. The matched frame appeared 2 6 in sequence and appeared rarely while most of the other frames has different hash value.

  The hash is computed on the frame data buffer extracted using avpicture_layout(). On the Pi side, I just stream the video to a local port and there's a local process using the same code to decode and hash the frames :

  ffmpeg -re -threads 2 -i sample_video.m2v -f mpegts - | \
  
  ffmpeg -f mpegts -i - -c copy -f mpegts udp://localhost:12345
  
  ...

  The streaming source raspberry pi, is connected directly to the PC using cable. I don't think it is a packet loss problem. Because, first, I rerun the same process several times and the hash value of the received frames are the same (otherwise the result should be different because packet loss is probabilistic). Secondly, I even try to stream on tcp ://192.168.1.100:12345 (and "tcp ://192.168.1.100:12345 ?listen" on PC), and the received frame hash are still the same - different than the hash result on the Pi.

  So, does anyone know why the streaming to a remote address will yield different decoded frames ? Maybe I am missing some details.

  Thanks in advance !!

• Is it possible to capture audio from an ASIO device with ffmpeg ?

  26 mai 2016, par Amfasis

  We have a setup with a Windows 7 machine where we installed Dante Virtual Soundcard and start that soundcard with ASIO capabilities. The soundcard will receive audio over the network from a Tesira server. We want to capture the audio to files (highly preferring each channel to a separate file). The files will be played back on a later moment. There will likely be 6 channels or more.

  In the same setup we use ffmpeg to capture some video which is working fine, with Direct Show. So for audio we wanted to use the same setup, since ffmpeg is able to record audio as well. However, there seems to be no option to select the ASIO devices which the virtual soundcard probably creates. So the question is what command line to use for ffmpeg, or what to install ? Or which other program can record ASIO from command line ?

  I already tried installing :

  • Asio4all (actually wrong way around)
  • sox (don’t know why actually)
  • HiFi Cable Asio Bridge (from VB-audio, not enough channels even with donate version)
  • Voicemeeter (from VB-Audio, not enough channels and actually mixes down)
  • O Deus Asio link, this might be an interesting option but it did not let me configure any route, any suggestions ?

  One thing I noticed is that the virtual soundcard can also be set to use WDM. Then I can see the devices with ffmpeg -list_devices true -f dshow -i duymmy, but recording does not yield any result, I have to ctrl-c to make it stop instead of q, and the file is zero bytes. Supposedly this is because the data over the network is all ASIO formatted and the Tesira Server cannot send "WDM data". FFmpeg stops at selecting the capture pin for audio only

  EDIT :

  I ran ffmpeg with high verbosity and when selecting the WDM soundcard it stops at Selecting pin Capture on audio only. Also when requesting the options it gives the same line for 22 times : min ch=1 bits=8 rate= 11025 max ch=2 bits=16 rate= 44100

• Evolution #4468 : Unification des CSS pour les boutons et les icônes

  15 septembre 2020

  @b_b : Super, merci

  @jluc : Ah je pensais qu’on pouvait au moins éditer ses propres tickets sur trac, même sans être admin. Je viens de voir que j’aurais pu le faire moi-même d’ailleurs, mais je me suis encore fait avoir par l’UX : faut d’abord cliquer sur modifier, et ensuite sur la petite icône « changer la description ». Mon cerveau refuse de retenir ce truc.

  Alors en fin de compte j’ai fait en sorte de ranger un minimum, mais en essayant de pas toucher à trop de choses non plus :

  • Tout ce qui a trait aux boutons est dans un nouveau module boutons.css : les boutons de formulaires, les boutons d’action, et la nouvelle classe lambda .bouton.
  • Je n’ai pas touché au bando rapide, donc pour les nouveaux boutons le sélecteur CSS inclus le tag : a.bouton. Je disais que c’est sale parcequ’en dehors des règles de base (reset, typo…), la règle générale c’est d’éviter de cibler un tag en particulier.

  En parlant de rangement, le module icons.css contient aussi les onglets (barre + onglets simples). À mon avis le composant .icone.horizontale|verticale ça rentre dans la famille des boutons, donc à déplacer dans le module boutons.css, et le module icons pourrait ensuite être renommé en onglets.css.
  Mais bon, j’y touche pas, ça pourra faire l’objet d’un autre ticket spécifiquement pour le découpage et le rangement des modules.

  Je vais essayer de boucler ça demain, y a moyen de faire un PR pour tenter de squeezer ça dans l’alpha de la 3.3 amha.
  J’y mettrai un description complète de la prop incluant les derniers correctifs.