Recherche avancée

Sur d’autres sites (3400)

• ffmpeg : Using tee with segmenter

  30 avril 2017, par Lev

  I’m trying to use a tee to output my stream into 1min segments and into a file at the same time. Here’s my command :

  ffmpeg -i "rtsp://${cameraIp}:554/axis-media/media.amp?videocodec=h264&resolution=1280x720&fps=15" -c copy -map 0 \
  
  -f tee "[f=ssegment:segment_time=60:segment_format=mp4:reset_timestamps=1:r=15] ${rootPath}/${storeId}-${location}-%03d.mp4 \
  
  | /tmp/${cameraIp}.mkv"

  Individually (without tee) both outputs work fine. So I can either output into segmented files or into a non-segmented file. But with the tee I get this error :

  [stream_segment,ssegment @ 0x217ece0] Failed to open segment ’
  /etc/cida/diagnostics/vid/780801-99-000.mp4’ [tee @ 0x217d820] Slave
  ’[f=ssegment:segment_time=60:segment_format=mp4:reset_timestamps=1:r=15]
  /etc/cida/diagnostics/vid/780801-99-%03d.mp4’ : error writing header :
  No such file or directory

  See full command output below. Any suggestions ?

  ffmpeg version 3.3 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1 14.04.3) configuration :
  —extra-libs=-ldl —prefix=/opt/ffmpeg —mandir=/usr/share/man —enable-avresample —disable-debug —enable-nonfree —enable-gpl —enable-version3 —enable-libopencore-amrnb —enable-libopencore-amrwb —disable-decoder=amrnb —disable-decoder=amrwb —enable-libpulse —enable-libfreetype —enable-gnutls —enable-libx264 —enable-libx265 —enable-libfdk-aac —enable-libvorbis —enable-libmp3lame —enable-libopus —enable-libvpx —enable-libspeex —enable-libass —enable-avisynth —enable-libsoxr —enable-libxvid —enable-libvidstab —enable-libwavpack —enable-nvenc libavutil 55. 58.100 / 55. 58.100 libavcodec 57. 89.100 / 57. 89.100 libavformat 57. 71.100 / 57. 71.100 libavdevice 57. 6.100 / 57. 6.100 libavfilter 6. 82.100 / 6. 82.100 libavresample 3. 5. 0 /
  3. 5. 0 libswscale 4. 6.100 / 4. 6.100 libswresample 2. 7.100 / 2. 7.100 libpostproc 54. 5.100 / 54. 5.100 Input #0, rtsp, from ’rtsp ://10.83.245.7:554/axis-media/media.amp ?videocodec=h264&resolution=1280x720&fps=15’ :
  Metadata :
  title : Session streamed with GStreamer
  comment : rtsp-server Duration : N/A, start : 0.080011, bitrate : N/A
  Stream #0:0 : Video : h264 (Main), yuvj420p(pc, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 25 tbr, 90k tbn, 180k tbc
  [stream_segment,ssegment @ 0x217ece0] Failed to open segment ’
  /etc/cida/diagnostics/vid/780801-99-000.mp4’ [tee @ 0x217d820] Slave
  ’[f=ssegment:segment_time=60:segment_format=mp4:reset_timestamps=1:r=15]
  /etc/cida/diagnostics/vid/780801-99-%03d.mp4’ : error writing header :
  No such file or directory [tee @ 0x217d820] Slave muxer #0 failed,
  aborting. Could not write header for output file #0 (incorrect codec
  parameters ?) : No such file or directory Stream mapping : Stream #0:0
  -> #0:0 (copy)
  Last message repeated 1 times

• 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>
  

• 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