Recherche avancée

Sur d’autres sites (9708)

• New proposed ePrivacy Regulation and why Piwik might not need tracking consent compared to Google Analytics & co

  11 janvier 2017, par InnoCraft — Community

  The EU is proposing new ePrivacy Regulations. The proposed Regulation on Privacy and Electronic Communications will increase the protection of people’s private life and open up new opportunities for business.

  

  The new ePrivacy Regulation proposal

  The proposal mentions several changes for example to the “Cookie Law” where no longer a cookie consent will be needed when the cookies improve the user’s internet experience, for example to remember the shopping cart history or when completing a form over several pages.

  However, consent to track a user’s behaviour may be needed in the future, unless the analytics data collection is hosted on the first-party website.

  From TheRegister : O’Neil noted a minor change in which visitors to a website for analytics purposes do not require consent, as long as any personal data collected is only processed by the first party.

  

  First party Analytics respecting privacy

  Piwik is an open-source analytics platform that is used on more than 1 million websites and apps in over 150 countries, and available in more than 50 languages. The difference with other analytics solutions is that you can download and install Piwik on your own infrastructure. Websites and mobile apps tracking users with their own Piwik very likely won’t require a consent from their users if these regulations become reality.

  We have regularly written about why privacy matters, or more recently 11 ways Piwik Analytics helps you to protect your visitors privacy.

  Besides the standard Piwik features, there are Premium Features that let businesses and organizations further maximize their success based on the tracked data. Need help in hosting Piwik on premise ? InnoCraft are THE Piwik experts and know it best as it is the company of the makers of Piwik. InnoCraft provides support subscriptions and enterprise packages to help you setting up, configuring and maintaining Piwik on your infrastructure as well as offer training and custom development.

  

  We’re excited to be building the best digital analytics platform which respects our privacy on the Internet.

  Thank you for being a valued member of the Piwik community !

• Does ffmpeg rtp_mpegts muxer support setting DVB triplet ?

  19 février 2021, par drake7

  It seems ffmpeg lets you set the DVB triplet with UDP but not with RTP.

  


  FYI : This is a followup on my findings about the rtp_mpegts muxer compared to the mpegts muxer : Question

  


  In my tests I was using ffmpeg version 4.3.1-2021-01-01-full_build-www.gyan.dev on windows.

  


  findings

  


  I analyzed my streams with dectec's "StreamXpert" :

  


  


  • With UDP and it's mpegts muxer, the DVB triplet can be set (1)

    


  


  • With RTP and it's rtp_mpegts muxer, the DVB triplet is ignored (3) (Note that 3a and 3b create very similar results in "StreamXpert".)

    


  


  • Using UDP with DVB triplet as input and output with RTP ignores the DVB triplet (2)

    


  



  


  Interestingly, leaving out the following options...

  


  -pcr_period 20 -pat_period 0.10 -sdt_period 0.25 -metadata:s:a:0 language=nya \
-mpegts_flags +pat_pmt_at_frames -mpegts_flags system_b


  


  ... the rtp_mpegts muxer (3b) creates a valid DVB transport stream, while the the mpegts muxer (4) does not.

  


  ffmpeg params :

  


  



  


  muxer : mpegts (udp)

  


  ffmpeg -f lavfi -i testsrc -r 25 -c:v libx264 -pix_fmt yuv420p -profile:v main -level 3.1 -preset veryfast -vf scale=1280:720,setdar=dar=16/9 -an -bsf:v h264_mp4toannexb -b:v 4M -muxrate 8M \
-pcr_period 20 -pat_period 0.10 -sdt_period 0.25 -metadata:s:a:0 language=nya -mpegts_flags +pat_pmt_at_frames \
-mpegts_transport_stream_id 0x005A \
-mpegts_original_network_id 0x005B \
-mpegts_service_id 0x005C \
-mpegts_pmt_start_pid 0x005D -mpegts_start_pid 0x005E -mpegts_service_type advanced_codec_digital_hdtv \
-metadata service_provider="Provider foo" \
-metadata service_name="Service bar" \
-mpegts_flags system_b -flush_packets 0 \
-f mpegts "udp://239.10.33.10:1234?pkt_size=1316"


  


  



  


  muxer : rtp_mpegts (rtp)

  


  ffmpeg -i "udp://239.10.33.10:1234" -map 0 -c copy \
-f rtp_mpegts "rtp://239.10.33.11:1234?pkt_size=1316"


  


  



  


  a) muxer : rtp_mpegts (rtp)

  


  ffmpeg -f lavfi -i testsrc -r 25 -c:v libx264 -pix_fmt yuv420p -profile:v main -level 3.1 -preset veryfast -vf scale=1280:720,setdar=dar=16/9 -an -bsf:v h264_mp4toannexb -b:v 4M -muxrate 8M \
-pcr_period 20 -pat_period 0.10 -sdt_period 0.25 -metadata:s:a:0 language=nya -mpegts_flags +pat_pmt_at_frames \
-mpegts_transport_stream_id 0x005A \
-mpegts_original_network_id 0x005B \
-mpegts_service_id 0x005C \
-mpegts_pmt_start_pid 0x005D -mpegts_start_pid 0x005E -mpegts_service_type advanced_codec_digital_hdtv \
-metadata service_provider="Provider foo" \
-metadata service_name="Service bar" \
-mpegts_flags system_b -flush_packets 0 \
-f rtp_mpegts "rtp://239.10.33.10:1234?pkt_size=1316"


  


  b) muxer : rtp_mpegts (rtp) (omitting some options)

  


  ffmpeg -f lavfi -i testsrc -r 25 -c:v libx264 -vf scale=1280:720,setdar=dar=16/9 -b:v 4M -muxrate 8M \
-mpegts_transport_stream_id 0x005A \
-mpegts_original_network_id 0x005B \
-mpegts_service_id 0x005C -mpegts_pmt_start_pid 0x005D -mpegts_start_pid 0x005E \
-mpegts_service_type advanced_codec_digital_hdtv \
-metadata service_provider="Provider foo" \
-metadata service_name="Service bar" \
-f rtp_mpegts "rtp://239.10.33.10:1234"


  


  



  


  muxer : mpegts (udp) (omitting some options)

  


  ffmpeg -f lavfi -i testsrc -r 25 -c:v libx264 -vf scale=1280:720,setdar=dar=16/9 -b:v 4M -muxrate 8M \
-mpegts_transport_stream_id 0x005A \
-mpegts_original_network_id 0x005B \
-mpegts_service_id 0x005C -mpegts_pmt_start_pid 0x005D -mpegts_start_pid 0x005E \
-mpegts_service_type advanced_codec_digital_hdtv \
-metadata service_provider="Provider foo" \
-metadata service_name="Service bar" \
-f mpegts "udp://239.10.33.10:1234"


  


  Analyzing the transport stream

  


  

  


• Revision 393a8ccef9 : Remove avoid_frame_with_high_error from RD loop The feature undergoes prior ass

  6 janvier 2014, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Remove avoid_frame_with_high_error from RD loop

  The feature undergoes prior assumption that the recursive partition
  size search from 4x4 to 64x64, hence utilizing information from small
  blocks to determine early termination in large block rate-distortion
  optimization search. The current codebase is now going from top down.
  The previous function might go with not properly initialized values,
  hence removed.

  Tested on pedestrian_area_1080p at 4000 kbps running under speed 2.
  No visible difference in runtime observed.

  Change-Id : I553df415c6191413762db7ae34e8790c71d8118e