Recherche avancée

Sur d’autres sites (6060)

• Replacing the standard Android H264 software encoder with an ffmpeg based one

  10 août 2012, par rubenvb

  In Android ICS and later, a new OpenMax IL API version is in use, making old binary blobs useless/unused. This leads to older devices that otherwise run ICS just fine and dandy to have broken video playback (YouTube HQ and IMBD, for example) because Androids fallback software decoder sucks when compared to what ffmpeg can do on the same device (I tested MXPlayer+arm6vfp ffmpeg and a 720p movie played back great).

  I am trying to dig through the Android source code to see where and what exactly I could add/replace code to allow the ffmpeg library's awesomeness to be used. The problem is I don't know exactly what code is being used in for example the YouTube app to decode video, or how that's decided.

  So I have two options as far as I can tell :

  1. Figure out the current software decoder being used, and try to wrap its external interface around ffmpeg, effectively replacing the slow software decoder currently used. The end result would be a single .so I could push to the device.

  2. Figure out how to trick Android into thinking an OMX library based on ffmpeg (I have built one succesfully for Android : limoa) and add this somewhere to the list of considered libraries (or better : replace the unusable hardware codec).

  As an extension, I'd like to also make camcorder video encoding work through this, so a true integrated solution would be very much wanted. The question is : how, and where, and what ? Searching the Android source tree gives numerous counts of "H264" and related stuff in many different places. I need the lowest and simplest possible, so I can simply wrap the hypothetical decode(buffer) function call to use ffmpeg (libavcodec).

• Low latency routing of rtp input to rtsp output with ffmpeg on a server

  29 mai 2020, par guillefix

  I want to be able to do some simple low-latency screen share. I know peer-to-peer would be the lowest latency, but it seems using an intermediate server is a lot easier to setup. I have found this awesome little library, which sets up an RTSP server, which I'm running on my digital ocean server. I then :

  



  

  1. Set up OBS to stream using RTP to the server on port 8558 with libx264 encoding.

  


  2. Run ffmpeg -re -stream_loop -1 -i rtp://127.0.0.1:8558 -c:v libx264 -c:a aac -f rtsp rtsp://localhost:8554/mystream on the server.

  


  3. Open rtsp://<server ip="ip">:8554/mystream</server> on VLC.

  


  



  However, the latency seems to be quite high. With my crappy internet it must have been like half a minute. A friend with better internet saw it fluctuating between 4-15 seconds. Furthermore, there seems to be a lot of artifacts on the video (problems with encoding ? I'm not sure why these happen ?)

  



  I attach below my OBS settings, and an example of artifacts.

  



  My question is : is there some settings on OBS and on ffmpeg that would allow this to have as low end-to-end latency as possible, while not having too many bad artifacts ? I'm not very well versed on video encoding and streaming, so this is all quite new to me. I'm willing to learn !

  



  

  



  

  


• Evolution #4429 : Ajouter « configurer » en toutes lettres à côté de l’icône dans la liste des plu...

  9 octobre 2020

  Les évolutions liées au ticket #4562 ont introduit un petit bug avec les boutons.
  Oh 3 fois rien : quand il n’y a pas de descriptif, les boutons empiètent sur le checkbox.

  Quitte à corriger ce truc, je proposais de commencer à implémenter une partie des de la maquette (la v1, celle-là : https://core.spip.net/attachments/download/1171/svp.html).
  En gros, pour l’instant ça ne touche pas aux onglets, mais ça change le layout en plaçant les boutons en bas, toujours visibles, et des messages plus clairs pour les mises à jour.
  Attention, pour les mises à jour ça ne montre toujours qu’une seule version : la plus récente, comme actuellement. Mais au moins il y a un message un peu plus clair selon le type de mise à jour (x, y ou z).

  Ça ferait une étape intermédiaire avant une version finale plus tard.
  Là c’est prêt à PRiser, mais j’attends des retours.