Sur d’autres sites (7904)

• uploading video to ftp while transcoding with Xuggler

  27 novembre 2013, par Holly

  I'm trying to transcode a video on a client PC (Win, Linux, IOS - x32 or x64 - all 6) and write the output directly to a ftp server using Xuggler. With pure ffmpeg it would look like this :

  ffmpeg -i "local.mp4" -ftp-write-seekable 0 -c:v libx264 -crf 25 -f flv ftp://user:pass@server.net:1234/uploaded.flv

  I'm assuming that it must be possible since ffmpeg can do it and Xuggler is supposed to be a wrapper for ffmpeg. I got it working using exec("ffmeg") but it needs to work on all 6 OS mentioned above.

  I tried to addapt this example : https://groups.google.com/forum/# !msg/xuggler-users/QeFTxqgc8Bg/0j1ntsl3tI0J by just using a ftp://user:pass@server.net:1234/uploaded.flvas the url but that does not work. Xuggler is unable to create a container based on such an url.

  I guess I should be able to write into an OutputStream and have ftp4j read from that stream and write to ftp. What would I need to consider for that ?

  Failing all else I could write into a temp file and upload that, but I really don't like that as a solution.

  1. Can someone please provide me with a code example of how to make Xuggler write to ftp directly ?

  2. As a side question. I'm still looking into how to best capture data for displaying the progress in the GUI. So far I found : IMediaListener onWritePacket(IWritePacketEvent event) which I would register to the writer. However I'm not sure how to get the details ffmped reports (current compression, output size so far). The only useful info I found so far is the TimeStamp. Any help on that would also be most welcome.

• Anomalie #4033 (Nouveau) : Critère `{age #TRUC}` erroné en SQLite

  28 octobre 2017

  Découvert suite à https://forum.spip.net/fr_267686.html

  - Le critère {age<3} fonctionne bien en SQLite.
  - Le critère {age<#TRUC}, avec #TRUC valant 3 provoque une erreur de test en SQLite, qui renvoie toujours VRAI.

  La différence est minime entre les deux :
  - TIMESTAMPDIFF('HOUR',articles.date,NOW())/24 < 3
  - TIMESTAMPDIFF('HOUR',articles.date,NOW())/24 < '3' pour le second

  Mysql quand à lui a parfaitement l’air de s’en accomoder. Notons qu’il y a une petite différence en Mysql sur la sortie : TIMESTAMPDIFF(HOUR ... où HOUR est une variable interne
  alors que sous SQLite c’est un paramètre de la fonction TIMESTAMPDIFF que sqlite_fonctions.php déclare. Mais ça ne change rien au problème rencontré ici.

  Pour tester, sous SQLite on obtient 2 résultats différents.
  

  #CACHE0
  #SQUELETTE
      #ID_ARTICLE : #COMPTEUR_BOUCLE / #GRAND_TOTAL
  
  #SETage,100
      #ID_ARTICLE : #COMPTEUR_BOUCLE / #GRAND_TOTAL
  
  

• FFMPEG libavformat internal buffering

  4 octobre 2013, par Theodor

  I'm using FFMPEG for a C++ audio streaming and playback application.

  I use the avformat_open_input function to open an URL to an external compressed audio file and then I step through to stream using av_read_frame. Then for each packet i directly decode the data and queue it in the audio buffer using OpenAL.

  My question is if FFMPEG internally prebuffers compressed data from the external URL ?

  Does FFMPEG keep downloading data in the background even if I don't call av_read_frame ?

  Or is it my responsibility to maintain a intermediate buffer where I download as many packets as possible ahead of time to avoid starving the audio-playback ?

  If so, how much does it buffer/download internally ? Can I configure this ?

  I have been looking through the documentation but have not found any information on this.

  Thanks.

  Update :
  According to this thread http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=376 libav should by default prebuffer about 5MB depending on AVFormatContext::max_analyze_duration. However I haven't noticed this behavior and it doesn't seem to change if I alter max_analyze_duration.

  If I monitor the memory consumption of my process it doesn't increase after I call avformat_open_input and if I simulate slow-network, av_read_frame directly stops working like if it didn't have any packets buffered.