Recherche avancée

Sur d’autres sites (10237)

• Revision 117703 : saisie explication : possibilité d’avoir un titre à l’explication + de ...

  1er septembre 2019, par maieul@… — Log

  saisie explication : possibilité d’avoir un titre à l’explication + de masquer/affiche le texte en JS. Exemple d’usage : pour proposer des conditions générales de ventes

• adaptive compression with ffmpeg

  3 février 2016, par paunescuionica

  I’m currently developing an application which will enable visualizing images from different sources (mostly IP cameras) in browser (in a HTML5 video element). The UI will allow for matrix view so, normally 16 or more cameras will be displayed at the same time.
  From cameras I get MJPEG streams or JPEG images (which I "convert" to MJPEG streams). So, for a camera, I have an MJPEG stream which I set as input for ffmpeg. I instruct ffmpeg to convert this to MP4 & H.264, and expose the output as a tcp stream, like this :

  ffmpeg -f mjpeg -i "http://localhost/video.mjpg" -f mp4 -vcodec libx264 "tcp ://127.0.0.1:5001 ?listen"

  This works just fine on localhost, I get the stream displayed in the web page, at best quality.

  But this has to work in various network conditions. I played a bit with chrome throttling settings, and noticed that if the network speed is just a bit below the required speed (given by the current compression settings I use in ffmpeg), the things start to go wrong : from stream start being delayed (so, no longer a live stream), up to complete freeze of ’live’ image in browser.

  What I need is an "adaptive" way to do the compression, in relation with current network speed.

  My questions are :

  • is ffmpeg able to handle this, to adapt to network conditions - automatically reduce compression quality when speed is low ; so the image in browser will be lower quality, but live (which is most important in my case)

  • if not, is there a way to workaround this ?

  • is there a way to detect the network bottleneck ? (and then restart ffmpeg with lower compression parameters ; this is not a dynamic adaptive streaming, but better than nothing)

  Thank you in advance !

• ffmpeg send intra and gop over a traditionnal tcp (or udp) server

  27 décembre 2015, par the-owner

  The Problem :
  I want to stream a continuous sequence of bitmaps (a video if stuck).
  I want to send the stream over a QTcpSocket/Server (or a QUdpServer why not, or a traditional tcp/udp server), and with the help of ffmpeg librarie.

  Context and Conditions :
  I code in C++, under msvc2013 win-32, QT-IDE, ffmpeg dev 2.8.3.
  We start with a bitmap which is a raw format, a result from GDI+ that I have gotten.
  For very low client connection, so I will use a light video format compression MPEG-1.
  I already have a TCP-Server (QTcpServer), so my goal is to not rebuild another Server for it ...

  Potential algorithm ? :
  I have thought more on the encoding question than the procole one, assume that the protocol could be good.
  It is the very first time that I do it, I don’t want to enroll into something impossible, and obviously I want your insight about this problem which I think since last month (which I have not found a good answer on internet). So, below the outlines of the algorithm that I have imagined :

  Server Side :

  1. I convert the first BMP to YUV format thanks to sws_scale (), we name it P in the following (ffmpeg - libswscale)
  2. I (MPEG1-)encode the picture P (with avcodec_encode_video2()) I get the datas encoded
  3. I serialize the AVFrame/AVpicture P (maybe we will do this step just once)
  4. In the same time I push the datas into a QByteArray (or a simple byte array ?)
  5. I compress P (maybe with QCompress why not)
  6. I send it to the clients.
  7. If the step 6 goes well : we return to number 1 if the next image is a modulus of k, it will be an Intra otherwise a GOP
  8. Otherwise, I wait ? Or I can take into account the lost frame within the code, and I could jump it ? (Inside these question there are questions of server protocols)

  Client Side (summarized)

  1. We get the datas (new Intra or GOP),
  2. We check the error function on the datas received with respect to the other datas received
  3. If the error function return :
  4. "The Error is OK with this new Intra/GOP received" we start decoding them with ffmpeg, and we display the next image of the livestream.
  5. Otherwise, error is not OK, we take the error into account ... (it is not my main problem here)

  Questions :

  It is a solution that I imagined, If the question of server/client protocol are solved, my algorithm is it viable in order to do a livestream ? Could it work ? Is there a better solution ? (another more simpler algorithm or another librarie than ffmpeg for example or something else ?) a link ? Of course critics on my server protocol are welcome.

  I remind, it is just the outlines.