Recherche avancée

Sur d’autres sites (13426)

• On-premise analytics demand grows as Google Analytics GDPR uncertainties continue

  7 janvier 2020, par Jake Thornton — Privacy

  The Google Analytics GDPR relationship is a complicated one. Website owners in states like Berlin in Germany are now required to ask users for consent to collect their data. This doesn’t make for the friendliest user-experience and often the website visitor will simply click “no.”

  The problem Google Analytics now presents website owners in the EU is with more visitors clicking “no”, the less accurate your data will become.

  Why do you need to ask your visitors for consent ?

  At this stage it’s simply because Google Analytics collects data for its own purposes. An example of this is using your visitor’s personal data for retargeting purposes across their advertising platforms like Google Ads and YouTube. 

  Google’s Privacy & Terms states : “when you visit a website that uses advertising services like AdSense, including analytics tools like Google Analytics, or embeds video content from YouTube, your web browser automatically sends certain information to Google. This includes the URL of the page you’re visiting and your IP address. We may also set cookies on your browser or read cookies that are already there. Apps that use Google advertising services also share information with Google, such as the name of the app and a unique identifier for advertising.”

  

  The rise of hosting web analytics on-premise

  Managing Google Analytics and GDPR can quickly become complicated, so there’s been an increase in website owners switching from cloud-hosted web analytics platforms, like Google Analytics, to more GDPR compliant alternatives, where you can host web analytics software on your own servers. This is called hosting web analytics on-premise.

  Hosting web analytics on your own servers means :

  No third-parties are involved

  The visitor data your website collects is stored on your own internal infrastructure. This means no third-parties are involved and there’s no risk of personal data being used in the way Google Analytics uses it e.g. sending personal data to its advertising platforms. 

  When you sign up with Google Analytics you sign away control of your user’s personal data. With on-premise website analytics, you own your data and are in full control.

  NOTE : Though Google Analytics uses personal data for its own purposes, not all cloud hosted web analytics platforms do this. As an example, Matomo Analytics Cloud hosted solution states that all personal data collected is not used for its own purposes and that Matomo has no rights in accessing or using this personal data. 

  

  You control where in the world your personal data is stored

  Google Analytics servers are based out of USA, Europe and Asia, so where your personal data will end up is uncertain and you don’t have the option to choose which location it goes to when using free Google Analytics.

  Different countries have different laws when it comes to accessing personal data. When you choose to host your web analytics on-premise, you can choose the location of your servers and where the personal data is stored.

  More flexibility

  With self-hosted web analytics platforms like Matomo On-Premise, you can extend the platform to do anything you want without the restrictions that cloud hosted platforms impose.

  You can :

  • Get full access to the source code of open-source solutions, like Matomo
  • Extend the platform however you want for your business
  • Get access to APIs
  • Have no data limitations or restrictions
  • Get RAW data access
  • Have control over security

  >> Read more about on-premise flexibility for web analytics here

  

  So what does the future look like for Google Analytics and GDPR ?

  It’s difficult to assess this right now. How exactly GDPR is enforced is still quite unclear. 

  What is clear however, is now website owners in Berlin using Google Analytics are lawfully required to ask their visitors for consent to collect personal data. It has been reported that Google Analytics has already received 200,000 complaints in Germany alone and it appears this trend is likely to continue across much of the EU.

  When using Google Analytics in the EU you must also ensure your privacy policy is updated so website visitors are aware that data is being collected through Google Analytics for its own purposes.

  Moving to a web analytics on-premise platform

  Matomo Analytics is the #1 open-source web analytics platform in the world and has been rated as an exceptional alternative to Google Analytics. Check the reviews on Capterra.

  Choosing Matomo On-Premise means you can control exactly where your data is stored, you have full flexibility to customise the platform to do what you want and it’s FREE.

  Matomo’s mission is to give control back to website owners and the team has designed the platform so that moving away from Google Analytics is seamless. Matomo offers most of your favourite Google Analytics features, a leaner interface to navigate, and the option to add free and paid premium features that Google Analytics can’t even offer you.

  And now you can import your historical Google Analytics data directly into your Matomo with the Google Analytics Importer plugin.

  DOWNLOAD MATOMO (FREE)

  And if you can’t host web analytics on your own servers ...

  Hosting web analytics on-premise is not an option for all businesses as you do need the internal infrastructure and technical knowledge to host your own platform.

  If you can’t self-host, then Matomo has a Cloud hosted solution you can easily install and operate like Google Analytics, which is hosted on Matomo’s servers in the EU. 

  The GDPR advantages of choosing Matomo Cloud over Google Analytics are :

  • Servers are secure and based in the EU (strict laws forbid outside access)
  • 100% data ownership – we never use data for our own purposes
  • You can export your data anytime and switch to Matomo On-Premise whenever you like
  • User-privacy protection
  • Advanced GDPR Manager and data anonymisation features which GA doesn’t offer

  

  Interested to learn more ?

  If you are wanting to learn more about why users are making the move from Google Analytics to Matomo, check out our Matomo Analytics vs Google Analytics comparison page.

  >> Matomo Analytics vs Google Analytics

• send h264 video to nginx-rtmp server using ffmpeg API

  11 décembre 2019, par Glen

  I have C++ code that grabs frames from a GigE camera and writes them out to a file. I’m using the libx264 codec and ffmpeg version 4.0.

  Writing to the file works fine, however I would also like to send the video to nginx configured with the nginx-rtmp plug-in to make the video available live via HLS.

  I can use the ffmpeg command line program to stream one of my previously captured files to my nginx server and rebroadcast as HLS, however if I try to stream from my C++ code the nginx server closes the connection after one or two frames are sent.

  To test further, I used the ffmpeg command line program to receive a rtmp stream and write it out to a file. I am able to send video to ffmpeg from my C++ program with rtmp, however every frame generates a warning like this :

  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1771, current: 53; changing to 1772. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1772, current: 53; changing to 1773. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1773, current: 53; changing to 1774. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1774, current: 53; changing to 1775. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1775, current: 53; changing to 1776. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1776, current: 53; changing to 1777. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1777, current: 53; changing to 1778. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1778, current: 53; changing to 1779. This may result in incorrect timestamps in the output file.
  
  [avi @ 0x1b6b6f0] Non-monotonous DTS in output stream 0:0; previous: 1779, current: 53; changing to 1780. This may result in incorrect timestamps in the output file.

  I printed PTS and DTS for my packet before writing it, and the numbers were monotonous (for example, in this last frame the pts and dts printed from my code were 1780, not the ’current : 53’ that ffmpeg reports>

  also, unless I tell ffmpeg what the output framerate should be I end up with a file that plays 2x speed.

  After ffmpeg receives the rtmp stream and writes it to the file, I am then able to successfully send that file to my nginx server using ffmpeg.

  here is some relevant code :

  //configuring the codec context
  
  // make sure that config.codec is something we support
  
  // for now we are only supporting LIBX264
  
  if (config.codec() != codecs::LIBX264) {
  
      throw std::invalid_argument("currently only libx264 codec is supported");
  
  }
  
  
  
  // lookup specified codec
  
  ffcodec_ = avcodec_find_encoder_by_name(config.codec().c_str());
  
  if (!ffcodec_) {
  
      throw std::invalid_argument("unable to get codec " + config.codec());
  
  }
  
  
  
  // unique_ptr to manage the codec_context
  
  codec_context_ = av_pointer::codec_context(avcodec_alloc_context3(ffcodec_));
  
  
  
  if (!codec_context_) {
  
      throw std::runtime_error("unable to initialize AVCodecContext");
  
  }
  
  
  
  // setup codec_context_
  
  codec_context_->width = frame_width;
  
  codec_context_->height = frame_height;
  
  codec_context_->time_base = (AVRational){1, config.target_fps()};
  
  codec_context_->framerate = (AVRational){config.target_fps(), 1};
  
  codec_context_->global_quality = 0;
  
  codec_context_->compression_level = 0;
  
  codec_context_->bits_per_raw_sample = 8;
  
  codec_context_->gop_size = 1;
  
  codec_context_->max_b_frames = 1;
  
  codec_context_->pix_fmt = AV_PIX_FMT_YUV420P;
  
  
  
  // x264 only settings
  
  if (config.codec() == codecs::LIBX264) {
  
      av_opt_set(codec_context_->priv_data, "preset", config.compression_target().c_str(), 0);
  
      av_opt_set(codec_context_->priv_data, "crf", std::to_string(config.crf()).c_str(), 0);
  
  }
  
  
  
  // Open up the codec
  
  if (avcodec_open2(codec_context_.get(), ffcodec_, NULL) < 0) {
  
      throw std::runtime_error("unable to open ffmpeg codec");
  
  }
  
  
  
  // setup the output format context and stream for RTMP
  
  AVFormatContext *tmp_f_context;
  
  avformat_alloc_output_context2(&tmp_f_context, NULL, "flv", uri.c_str());
  
  rtmp_format_context_ = av_pointer::format_context(tmp_f_context);
  
  rtmp_stream_ = avformat_new_stream(rtmp_format_context_.get(), ffcodec_);
  
  avcodec_parameters_from_context(rtmp_stream_->codecpar, codec_context_.get());
  
  rtmp_stream_->time_base = codec_context_->time_base;
  
  rtmp_stream_->r_frame_rate = codec_context_->framerate;
  
  
  
  /* open the output file */
  
  if (!(rtmp_format_context_->flags & AVFMT_NOFILE)) {
  
      int r = avio_open(&rtmp_format_context_->pb, uri.c_str(), AVIO_FLAG_WRITE);
  
      if (r < 0) {
  
          throw std::runtime_error("unable to open " + uri + " : " + av_err2str(r));
  
      }
  
  }
  
  
  
  if (avformat_write_header(rtmp_format_context_.get(), NULL) < 0) {
  
      throw std::runtime_error("unable to write header");
  
  }
  
  
  
  av_dump_format(rtmp_format_context_.get(), 0,uri.c_str() , 1);

  at this point the av_dump_format produces this output :

  Output #0, flv, to 'rtmp://[MY URI]':
  
    Metadata:
  
      encoder         : Lavf58.12.100
  
      Stream #0:0, 0, 1/1000: Video: h264 (libx264), 1 reference frame ([7][0][0][0] / 0x0007), yuv420p, 800x800 (0x0), 0/1, q=-1--1, 30 tbr, 1k tbn

  encoding and writing the frame :

  // send the frame to the encoder, filtering first if necessary
  
  void VideoWriter::Encode(AVFrame *frame)
  
  {
  
      int rval;
  
      if (!apply_filter_) {
  
          //send frame to encoder
  
          rval = avcodec_send_frame(codec_context_.get(), frame);
  
          if (rval < 0) {
  
              throw std::runtime_error("error sending frame for encoding");
  
          }
  
      } else {
  
          // push frame to filter 
  
          // REMOVED, currently testing without filtering
  
      }
  
  
  
      // get packets from encoder
  
      while (rval >= 0) {
  
          // create smart pointer to allocated packet
  
          av_pointer::packet pkt(av_packet_alloc());
  
          if (!pkt) {
  
              throw std::runtime_error("unable to allocate packet");
  
          }
  
  
  
          rval = avcodec_receive_packet(codec_context_.get(), pkt.get());
  
          if (rval == AVERROR(EAGAIN) || rval == AVERROR_EOF) {
  
              return;
  
          } else if (rval < 0) {
  
              throw std::runtime_error("error during encoding");
  
          }
  
  
  
          // if I print pkt->pts and pkt->dts here, I see sequential numbers
  
  
  
          // write packet
  
          rval = av_interleaved_write_frame(rtmp_format_context_.get(), pkt.get());
  
          if (rval < 0 ) {
  
              std::cerr << av_err2str(rval) << std::endl;
  
          }
  
      }
  
  }

  Since I am able to send video from a previously recorded file to nginx with the ffmpeg command line program, I believe the problem is in my code and not my nginx configuration.

  EDIT : I think it may have to do with SPS/PPS as I see a bunch of these error messages in the nginx log before it closes the stream

  2019/12/11 11:11:31 [error] 10180#0: *4 hls: failed to read 5 byte(s), client: XXX, server: 0.0.0.0:1935
  
  2019/12/11 11:11:31 [error] 10180#0: *4 hls: error appenging SPS/PPS NALs, client: XXX, server: 0.0.0.0:1935

  As I mentioned, this code works fine if I set it up to write to an avi file rather stream to rtmp, and I can stream to ffmpeg listening for rtmp but with lots of warnings about the DTS but if I try to send to nginx, it closes the connection almost immediately. My first thought was that there was something wrong with the frame timestamps, but when I print pts and dts prior to writing the packet to the stream they look okay to me.

  My end goal is to capture video to a file, and also be able to turn on the rtmp stream on demand — but for now I’m just trying to get the rtmp stream working continuously (without writing to a file)

  Thanks for any insights.

• FFmpeg how to get the first drawtext's x,y value to the second drawtext, and change the fontsize every frame, how to create a var ?

  22 octobre 2019, par FFmpeg2019

  I have a ffmpeg code :

  ffmpeg -i input.mp4 -vf drawtext=text=hello:fontsize=18:x=rand(0,640):y=rand(0,480),drawtext=world:fontsize=fontsize+0.1:x=16+?:y=? output.mp4

  And have three questions :

  1. How to let the "fontsize+0.1" work ?
  2. The two " ?" how to get the first drawtext’s x,y values ? let the two strings become one string like this : hello world.
  3. how to create a var ?