Recherche avancée

Sur d’autres sites (9917)

• ffmpeg reconnect to rtmp output if error

  27 avril 2017, par boygiandi

  I’m trying to livestream to facebook, it’s fine but sometime it got error and stop the stream

  [ sh : 2017-04-27 10:31:34 ]size= 296042kB time=00:13:04.48 bitrate=3091.4kbits/s speed= 1x

  [ sh : 2017-04-27 10:31:35 ]size= 296605kB time=00:13:05.48 bitrate=3093.4kbits/s speed= 1x

  [ sh : 2017-04-27 10:31:36 ]size= 296928kB time=00:13:06.50 bitrate=3092.7kbits/s speed= 1x

  [ sh : 2017-04-27 10:31:37 ]size= 297259kB time=00:13:07.48 bitrate=3092.3kbits/s speed= 1x

  [flv @ 0x32c91e0] Failed to update header with correct duration.

  [flv @ 0x32c91e0] Failed to update header with correct filesize.
  frame=23623 fps= 30 q=13.0 Lsize= 297346kB time=00:13:07.52 bitrate=3093.0kbits/s speed= 1x

  video:284080kB audio:12242kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead : 0.345891%

  [libx264 @ 0x3294c80] frame I:394 Avg QP:10.66 size : 99956

  [libx264 @ 0x3294c80] frame P:23229 Avg QP:13.94 size : 10828

  [libx264 @ 0x3294c80] mb I I16..4 : 100.0% 0.0% 0.0%

  [libx264 @ 0x3294c80] mb P I16..4 : 2.8% 0.0% 0.0% P16..4 : 34.9% 0.0% 0.0% 0.0% 0.0% skip:62.2%

  [libx264 @ 0x3294c80] coded y,uvDC,uvAC intra : 64.8% 69.3% 44.6% inter : 20.5% 16.6% 4.2%

  [libx264 @ 0x3294c80] i16 v,h,dc,p : 27% 51% 12% 10%

  [libx264 @ 0x3294c80] i8c dc,h,v,p : 34% 40% 16% 10%

  [libx264 @ 0x3294c80] kb/s:2955.27

  [aac @ 0x33825e0] Qavg : 1929.185

  I have no idea why it stopped, but is there any option to ignore error and still livestream ? Or another way, re-stream again from beginning. When I tried to do that by run ffmpeg (after few seconds) command again. It said

  [rtmp @ 0x3c01420] Server error : Initialization failed (2 : Broadcast state is bad)

  rtmp ://rtmp-api.facebook.com:80/rtmp/1658103677537416 ?ds=1&s_l=1&a=ATjLWmaYE8qulMzm : Operation not permitted

  I can’t stream again to facebook rtmp url. Please help

• Performance optimizations you can apply today to load the Piwik JavaScript tracker faster

  20 avril 2017, par InnoCraft — Community, Development

  When you track your website with Piwik or any other analytics solution, you need to embed a JavaScript file in order to track page views, events, clicks, and more. At InnoCraft, it is our daily business to help Piwik users to make the most out of their Piwik. We often see similar problems of websites loading unnecessarily slower because the tracking file is not loaded as fast as it should be. There are many ways you can improve the performance but avoiding the most important mistakes will help you to not lose revenue and conversions because of this today. Below you find a few steps that will boost the loading of your Piwik JavaScript tracking file.

  Cache piwik.js

  The most important step is to make sure to configure your server in a way so the piwik.js JavaScript tracker file will be cached once it has been loaded and not requested again on subsequent page views. Learn more about browser caching.

  Enable GZIP

  We recommend enabling GZIP as it reduces the size the user needs to load when the piwik.js file is requested. For the standard Piwik tracker, this will reduce the size from about 60KB to 20KB.

  Preload DNS

  Often a Piwik is hosted on a different domain and when the browser loads the JavaScript tracker file, it needs to first perform a DNS lookup to find the IP address for this domain. By adding the below snipped for your Piwik domain, it can boost the performance of loading the tracker file by 10ms to 50ms.

  <link rel="dns-prefetch" href="//example.innocraft.cloud">

  Preload resource

  To boost the loading of the Piwik tracking file, you can add the following HTML into the header of your website :

  <link rel="preload" href="https://yourpiwikdomain.com/piwik.js" onload="embedTracker()" type="script" crossorigin>

  In Chrome, Opera, and soon in more browsers this will load the JavaScript tracker file without blocking the “onload” event. As a result, as soon as you embed the tracking code, the JavaScript tracker might be already loaded. How “preloading” affects your website always depends and maybe you rather want to preload more important resources than the tracking code, but it is an option to consider. If you load your JavaScript tracker file in the <head> of your website, this should not be needed.

  Advanced options

  If you want to go even further, you can think about serving the JavaScript tracking file via a CDN, merging the JavaScript tracker file content with your other JavaScript files, making use of service workers (and even track data offline), and more. Feel free to get in touch with us if you have any questions.

  More performance improvements

  Read our first blog in the series at Different ways of embedding the Piwik tracking code for faster website performance

• Merge commit 'e807491fc6a336e4becc0cbc981274a8fde18aba'

  29 avril 2017, par Clément Bœsch

  Merge commit 'e807491fc6a336e4becc0cbc981274a8fde18aba'
  * commit 'e807491fc6a336e4becc0cbc981274a8fde18aba' :
  
    mpeg12dec : avoid signed overflow in bitrate calculation
  
    mpegvideo_parser : avoid signed overflow in bitrate calculation
  This merge is a noop.
  2017-04-29 12:54:15     @ubitux michaelni : is 740959fdbfbf804ccd8a6e426b1b1ba321fe5cfb enough to fix the overflow fixed in 58405de0951a843765625159402870c1eea3c3b1 ?
  
  2017-04-29 12:55:53     @ubitux same question with e807491fc6a336e4becc0cbc981274a8fde18aba
  
  2017-04-29 13:21:45     michaelni       ubitux, the libav code refered to is wrong for us and i doubt the problem it fixes applies to us.
  
  2017-04-29 13:24:29     @ubitux michaelni : ok, for both commits ?
  
  2017-04-29 13:33:55     michaelni       yes, they do more or less the same thing
  Merged-by : Clément Bœsch <u@pkh.me>