Recherche avancée

Sur d’autres sites (8237)

• ffmpeg streaming slow on android

  10 juillet 2016, par gemisoft

  I am trying to forward HLS stream http://vevoplaylist-live.hls.adaptive.level3.net/vevo/ch1/06/prog_index.m3u8 to streaming server from my Android device.

  I am using https://github.com/WritingMinds/ffmpeg-android-java library to get ffmpeg working in my Android Studio project.

  The problem is that when I stream in 720p resolution with ffmpeg from my Android phone the server income rate is max 500kbps on 4G network what is not enough for 720p streaming and also 480p.

  I tried to troubleshoot this issue by streaming from the same network but using my PC and the server stream income rate was good - around 1200kbps for 720p streaming.

  Is it possible that Android device has too slow hardware for ffmpeg ? is there a way to use mentioned library with Android hardware acceleration ? Would hardware acceleration with MediaCodec API improve streaming speed ?

  Here is log from my application :
  https://1drv.ms/t/s !AtXVGSZVYflZhFwIhg1s1jq_6e7g

  Here is CPU usage on my Android device :
  https://1drv.ms/f/s !AtXVGSZVYflZhGFT2akG2tD2uelB

  Here is CPU usage on my PC :
  https://1drv.ms/f/s !AtXVGSZVYflZhGIPSwe5GHjHWFCG

  Thanks

• nvenc : De-compensate aspect ratio compensation of DVD-like content.

  28 janvier 2015, par Philip Langdale

  nvenc : De-compensate aspect ratio compensation of DVD-like content.
  For reasons we are not privy to, nvidia decided that the nvenc encoder
  
  should apply aspect ratio compensation to ’DVD like’ content, assuming that
  
  the content is not BT.601 compliant, but needs to be BT.601 compliant. In
  
  this context, that means that they make the following, questionable,
  
  assumptions :
  1) If the input dimensions are 720x480 or 720x576, assume the content has
  
  an active area of 704x480 or 704x576.
  2) Assume that whatever the input sample aspect ratio is, it does not account
  
  for the difference between ’physical’ and ’active’ dimensions.
  From these assumptions, they then conclude that they can ’help’, by adjusting
  
  the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
  
  display only the 704 wide active area with the same aspect ratio as the full
  
  720 wide image - this would be the correct adjustment factor, but what if you
  
  don’t ? And more importantly, what if you’re used to lavc not making this kind
  
  of adjustment at encode time - because none of the other encoders do this !
  And, what if you had already accounted for BT.601 and your input had the
  
  correct attributes ? Well, it’s going to apply the compensation anyway !
  
  So, if you take some content, and feed it through nvenc repeatedly, it
  
  will keep scaling the aspect ratio every time, stretching your video out
  
  more and more and more.
  So, clearly, regardless of whether you want to apply bt.601 aspect ratio
  
  adjustments or not, this is not the way to do it. With any other lavc
  
  encoder, you would do it as part of defining your input parameters or do
  
  the adjustment at playback time, and there’s no reason by nvenc should
  
  be any different.
  This change adds some logic to undo the compensation that nvenc would
  
  otherwise do.
  nvidia engineers have told us that they will work to make this
  
  compensation mechanism optional in a future release of the nvenc
  
  SDK. At that point, we can adapt accordingly.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  
  Reviewed-by : Timo Rothenpieler <timo@rothenpieler.org>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavcodec/nvenc.c

• Anomalie #3772 : Filtrage automatique par statut actif sur une boucle spip_articles depuis SPIP 3.x

  8 mai 2016, par jluc -

  Comme écrit sur la page liée, un critère optionnel est actif "uniquement si l’environnement contient la balise demandée". Dans l’environnement des boucles imbriquées, la balise est bien définie, et ce serait donc normal que le critère soit activé.

  Dans les exemples cités, le traitement ne semble pas malin car dans l’environnement de la boucle interne, cette balise est un champ de la table englobante, qui n’est pas l’une des tables sur lesquelles boucle la boucle interne, comme c’est souvent le cas pour les critères raccourcis.

  Les critères optionnels et raccourcis ont été mis en place pour les arguments d’url ou les arguments des appels d’INCLURE ou de modèles, et rien n’est pas prévu de désambiguiser les homonymes : quand il y a statut dans une url, ce n’est ni spécialement un statut de rubrique, ni spécialement un statut d’article. Donc par conception,

  statut, statut ?, id_rubrique

  n’en tiennent pas compte.

  On ne peut pas changer ça pour les critères raccourcis, sinon la transmission des #ID_RUBRIQUE ne pourrait pas se faire d’une boucle rubrique à une boucle article et les critères raccourcis n’auraient quasiment plus raison d’être.

  A priori je trouve assez sain (car simple) que les critères optionnels fonctionnent pareil que les critères raccourcis. Donc il faudrait une raison sérieuse pour que ça soit différent. Quelle serait elle ?