Sur d’autres sites (7031)

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  10 février 2021

  Les grands principes de séparation entre la forme et le contenu, oui ok d’accord.

  Mais t’as bien vu que l’objet de cette proposition, c’est justement d’accepter de faire un compromis pour simplifier la vie de tout le monde : à la fois pour maintenir le truc et à la fois quand on veut les utiliser dans le core et les plugins.
  Le constat de départ je rappelle, c’est qu’actuellement c’est bien des classes sémantiques-tout-ça, mais au prix de circonvolutions hypers lourdes dans le css (t’as jeté un coup d’oeil à boutons.css ?).

  Si on est pas content des quelques icônes qui peuvent se ballader d’office dans certains formulaires ou bouts de squelettes, on règle ça en 1 ligne de CSS hein : .icone-spip { display: none }
  Ou même si on veut les garder et les surcharger : .icone-spip svg { display: none } et voilà.
  Ça me semble pas un très gros prix à payer.

• Berlin website owners need consent for using Google Analytics

  19 novembre 2019, par Joselyn Khor — Uncategorized

  Website owners in Berlin need consent for using Google Analytics

  According to the Berlin Data Protection Office, if you’re a website owner collecting and sending data to third-party services (like Google Analytics) who are also using that data “for own purpose uses” in Berlin, you are now required to ask for specific consent from visitors in order to collect that information. 

  This means you can only use Google Analytics or similar services once you’ve gotten consent from visitors. In contrast, Matomo does not use information from Cloud or On-Premise users for “own purpose uses”.

  Consent is also needed when keystrokes or mouse movements are recorded. That means you need users to consent to your usage of features like Heatmaps and Session Recordings.

  It’s advised that website owners in Berlin should check their websites for third-party content and tracking mechanisms. If you do use these third-party functions that require consent, you must either get consent or remove the functions. Consent is only effective if the visitor (whose data you’re collecting) is informed and agrees to their data being processed.

  Currently this applies to website owners in Berlin, and should likely be applied for the whole of Germany to be on the safe side.

  Further reading :

  • Learn more about Matomo’s Cloud Data Processing Agreement
  • Read about asking for consent in Matomo
  • To use Matomo Analytics and be compliant with the regulation we recommend you learn how to make Matomo GDPR compliant in 12 steps.

  And learn more about all the features in our GDPR user guide and privacy user guide. You can also learn more about GDPR through our blog posts.

• Live streaming : node-media-server + Dash.js configured for real-time low latency

  7 juillet 2021, par Maoration

  We're working on an app that enables live monitoring of your back yard.
Each client has a camera connected to the internet, streaming to our public node.js server.

  



  I'm trying to use node-media-server to publish an MPEG-DASH (or HLS) stream to be available for our app clients, on different networks, bandwidths and resolutions around the world.

  



  Our goal is to get as close as possible to live "real-time" so you can monitor what happens in your backyard instantly.

  



  The technical flow already accomplished is :

  



  


  1. ffmpeg process on our server processes the incoming camera stream (separate child process for each camera) and publishes the stream via RTSP on the local machine for node-media-server to use as an 'input' (we are also saving segmented files, generating thumbnails, etc.). the ffmpeg command responsible for that is :

     



     -c:v libx264 -preset ultrafast -tune zerolatency -b:v 900k -f flv rtmp://127.0.0.1:1935/live/office

  


  2. node-media-server is running with what I found as the default configuration for 'live-streaming'

     



     private NMS_CONFIG = {
server: {
  secret: 'thisisnotmyrealsecret',
},
rtmp_server: {
  rtmp: {
    port: 1935,
    chunk_size: 60000,
    gop_cache: false,
    ping: 60,
    ping_timeout: 30,
  },
  http: {
    port: 8888,
    mediaroot: './server/media',
    allow_origin: '*',
  },
  trans: {
    ffmpeg: '/usr/bin/ffmpeg',
    tasks: [
      {
        app: 'live',
        hls: true,
        hlsFlags: '[hls_time=2:hls_list_size=3:hls_flags=delete_segments]',
        dash: true,
        dashFlags: '[f=dash:window_size=3:extra_window_size=5]',
      },
    ],
  },
},


     



     } ;

  


  3. As I understand it, out of the box NMS (node-media-server) publishes the input stream it gets in multiple output formats : flv, mpeg-dash, hls.
with all sorts of online players for these formats I'm able to access and the stream using the url on localhost. with mpeg-dash and hls I'm getting anything between 10-15 seconds of delay, and more.

  


  



  ---

  



  My goal now is to implement a local client-side mpeg-dash player, using dash.js and configure it to be as close as possible to live.

  



  my code for that is :

  



  


  


  &#xD;&#xA;&#xD;&#xA;    &#xD;&#xA;        &#xD;&#xA;        &#xD;&#xA;    &#xD;&#xA;    &#xD;&#xA;        <div>&#xD;&#xA;            <video autoplay="" controls=""></video>&#xD;&#xA;        </div>&#xD;&#xA;        <code class="echappe-js">&lt;script src=&quot;https://cdnjs.cloudflare.com/ajax/libs/dashjs/3.0.2/dash.all.min.js&quot;&gt;&lt;/script&gt;&#xD;&#xA;&#xD;&#xA;        &lt;script&gt;&amp;#xD;&amp;#xA;            (function(){&amp;#xD;&amp;#xA;                // var url = &quot;https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd&quot;;&amp;#xD;&amp;#xA;                var url = &quot;http://localhost:8888/live/office/index.mpd&quot;;&amp;#xD;&amp;#xA;                var player = dashjs.MediaPlayer().create();&amp;#xD;&amp;#xA;                &amp;#xD;&amp;#xA;                &amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;                // config&amp;#xD;&amp;#xA;                targetLatency = 2.0;        // Lowering this value will lower latency but may decrease the player&amp;#x27;s ability to build a stable buffer.&amp;#xD;&amp;#xA;                minDrift = 0.05;            // Minimum latency deviation allowed before activating catch-up mechanism.&amp;#xD;&amp;#xA;                catchupPlaybackRate = 0.5;  // Maximum catch-up rate, as a percentage, for low latency live streams.&amp;#xD;&amp;#xA;                stableBuffer = 2;           // The time that the internal buffer target will be set to post startup/seeks (NOT top quality).&amp;#xD;&amp;#xA;                bufferAtTopQuality = 2;     // The time that the internal buffer target will be set to once playing the top quality.&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;                player.updateSettings({&amp;#xD;&amp;#xA;                    &amp;#x27;streaming&amp;#x27;: {&amp;#xD;&amp;#xA;                        &amp;#x27;liveDelay&amp;#x27;: 2,&amp;#xD;&amp;#xA;                        &amp;#x27;liveCatchUpMinDrift&amp;#x27;: 0.05,&amp;#xD;&amp;#xA;                        &amp;#x27;liveCatchUpPlaybackRate&amp;#x27;: 0.5,&amp;#xD;&amp;#xA;                        &amp;#x27;stableBufferTime&amp;#x27;: 2,&amp;#xD;&amp;#xA;                        &amp;#x27;bufferTimeAtTopQuality&amp;#x27;: 2,&amp;#xD;&amp;#xA;                        &amp;#x27;bufferTimeAtTopQualityLongForm&amp;#x27;: 2,&amp;#xD;&amp;#xA;                        &amp;#x27;bufferToKeep&amp;#x27;: 2,&amp;#xD;&amp;#xA;                        &amp;#x27;bufferAheadToKeep&amp;#x27;: 2,&amp;#xD;&amp;#xA;                        &amp;#x27;lowLatencyEnabled&amp;#x27;: true,&amp;#xD;&amp;#xA;                        &amp;#x27;fastSwitchEnabled&amp;#x27;: true,&amp;#xD;&amp;#xA;                        &amp;#x27;abr&amp;#x27;: {&amp;#xD;&amp;#xA;                            &amp;#x27;limitBitrateByPortal&amp;#x27;: true&amp;#xD;&amp;#xA;                        },&amp;#xD;&amp;#xA;                    }&amp;#xD;&amp;#xA;                });&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;                console.log(player.getSettings());&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;                setInterval(() =&gt; {&amp;#xD;&amp;#xA;                  console.log(&amp;#x27;Live latency= &amp;#x27;, player.getCurrentLiveLatency());&amp;#xD;&amp;#xA;                  console.log(&amp;#x27;Buffer length= &amp;#x27;, player.getBufferLength(&amp;#x27;video&amp;#x27;));&amp;#xD;&amp;#xA;                }, 3000);&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;                player.initialize(document.querySelector(&quot;#videoPlayer&quot;), url, true);&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;            })();&amp;#xD;&amp;#xA;&amp;#xD;&amp;#xA;        &lt;/script&gt;&#xD;&#xA;    &#xD;&#xA;

  


  


  




  with the online test video (https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd) I see that the live latency value is close to 2 secs (but I have no way to actually confirm it. it's a video file streamed. in my office I have a camera so I can actually compare latency between real-life and the stream I get).
however when working locally with my NMS, it seems this value does not want to go below 20-25 seconds.

  



  Am I doing something wrong ? any configuration on the player (client-side html) I'm forgetting ?
or is there a missing configuration I should add on the server side (NMS) ?