Recherche avancée
Autres articles (111)
-
Script d’installation automatique de MediaSPIP
25 avril 2011, parAfin de palier aux difficultés d’installation dues principalement aux dépendances logicielles coté serveur, un script d’installation "tout en un" en bash a été créé afin de faciliter cette étape sur un serveur doté d’une distribution Linux compatible.
Vous devez bénéficier d’un accès SSH à votre serveur et d’un compte "root" afin de l’utiliser, ce qui permettra d’installer les dépendances. Contactez votre hébergeur si vous ne disposez pas de cela.
La documentation de l’utilisation du script d’installation (...) -
Automated installation script of MediaSPIP
25 avril 2011, parTo overcome the difficulties mainly due to the installation of server side software dependencies, an "all-in-one" installation script written in bash was created to facilitate this step on a server with a compatible Linux distribution.
You must have access to your server via SSH and a root account to use it, which will install the dependencies. Contact your provider if you do not have that.
The documentation of the use of this installation script is available here.
The code of this (...) -
Que fait exactement ce script ?
18 janvier 2011, parCe script est écrit en bash. Il est donc facilement utilisable sur n’importe quel serveur.
Il n’est compatible qu’avec une liste de distributions précises (voir Liste des distributions compatibles).
Installation de dépendances de MediaSPIP
Son rôle principal est d’installer l’ensemble des dépendances logicielles nécessaires coté serveur à savoir :
Les outils de base pour pouvoir installer le reste des dépendances Les outils de développements : build-essential (via APT depuis les dépôts officiels) ; (...)
Sur d’autres sites (9908)
-
Data Privacy Day 2021 : Five ways to embrace privacy into your business
Welcome to Data Privacy Day 2021 !
This year we are excited to announce that we are participating as a #PrivacyAware Champion for DPD21 through the National Cyber Security Alliance. This means that on this significant day we are in partnership with hundreds of other organisations and businesses to share a unified message that empowers individuals to “Own Your Privacy” and for organisations to “Respect Privacy.”
"Last year dawned a new era in the way many businesses operate from a traditional office work setting to a remote working from home environment for employees. This now means it’s more important than ever for your employees to understand how to take ownership of their privacy when working online."
As a Data Privacy Day #PrivacyAware Champion we would like to provide some practical tips and share examples of how the Matomo team helps employees be privacy aware.
Five ways to embrace privacy into your business
1. Create a privacy aware culture within your business
- Get leadership involved.
- Appoint privacy ambassadors within your team.
- Create a privacy awareness campaign where you educate employees on your company privacy policy.
- Share messages about privacy around the office/or in meetings online, on internal message boards, in company newsletters, or emails.
- Teach new employees their role in your privacy culture and reinforce throughout their career.
2. Organise privacy awareness training for your employees
- Invite outside speakers to talk to employees about why privacy matters.
- Engage staff by asking them to consider how privacy and data security applies to the work they do on a daily basis.
- Encourage employees to complete online courses to gain a better understanding of how to avoid privacy risks.
3. Help employees manage their individual privacy
- Better security and privacy behaviours at home will translate to better security and privacy practices at work.
- Teach employees how to update their privacy and security settings on personal accounts.
- Use NCSA’s privacy settings page to help them get started
4. Add privacy to the employee’s toolbox
- Give your employees actual tools they can use to improve their privacy, such as company-branded camera covers or privacy screens for their devices, or virtual private networks (VPNs) to secure their connections.
5. Join Matomo and we’ll be your web analytics experts
- At Matomo, ensuring our users and customers that their privacy is protected is not only a core component of the work we do, it’s why we do what we do ! Find out how.
Want to find out more about data privacy download your free DPD 2021 Champion Toolkit and read our post on “Why is privacy important”.
Team Matomo
-
FFMPEG/DASH-LL creates audio and video chunks at different rates ; player is confused (404 errors)
26 mai 2021, par DannyI'm trying to create a MPEG-DASH "live" stream from a static file to test various low latency modes. The DASH muxer in FFmpeg creates two AdaptationSets, one for video chunks and one for audio chunks.


However, the audio and video chunk files are not created at the same rate (should they be ?). ie, here
stream0are the video chunks andstream1are the audio chunks. After a few seconds of running, the webroot directory contains :

chunk-stream0-00001.m4s chunk-stream1-00001.m4s 
chunk-stream0-00002.m4s chunk-stream1-00002.m4s 
chunk-stream0-00003.m4s chunk-stream1-00003.m4s 
chunk-stream0-00004.m4s chunk-stream1-00004.m4s 
 chunk-stream1-00005.m4s 
 chunk-stream1-00006.m4s 
 chunk-stream1-00007.m4s 
 chunk-stream1-00008.m4s 
 chunk-stream1-00009.m4s 
master.mpd 
init-stream0.m4s 
init-stream1.m4s 


The stream doesn't load (or play) on either
dash.jsor shaka-player and there are lots of404 (Not Found)errors for the video chunks. The player is requesting chunks from both stream0 and stream1 in sequence, ie, stream0-001 + stream1-001, then stream0-002 + stream1-002 and so on.

But since stream0 only goes from 001 to 004, there are lots of 404 errors as it tries to load stream0-005 through 009.


The gap gets wider after letting FFmpeg run for a while. eg, stream0 is 62 to 75 but stream1 is 174 to 187. Reloading the player page at this point fails with
dash.all.debug.js:15615 [2055][FragmentController] No video bytes to push or stream is inactive.and shows 404 errors stream0 chunk 188 (which doesn't exist yet !)



The FFmpeg command was adopted from DASH streaming from the top-down :


ffmpeg -re -i /mnt/swdevel/TestStreams/H264/ThreeHourMovie.mp4 \
-c:v libx264 -x264-params keyint=120:scenecut=0 -b:v 1M -c:a copy \
-f dash -dash_segment_type mp4 \
 -seg_duration 2 \
 -target_latency 3 \
 -frag_type duration \
 -frag_duration 0.2 \
 -window_size 10 \
 -extra_window_size 3 \
 -streaming 1 \
 -ldash 1 \
 -use_template 1 \
 -use_timeline 0 \
 -write_prft 1 \
 -fflags +nobuffer+flush_packets \
 -format_options "movflags=+cmaf" \
 -utc_timing_url "/pelican/testPlayers/time.php" \
 master.mpd


And the
dash.jsplayer code is very simple :

const srcUrl = "../ottWebRoot/playerTest/master.mpd"; 

var player = dashjs.MediaPlayer().create();

let autoPlay = false;
player.initialize(document.querySelector("#videoTagId"), srcUrl, autoPlay);

player.updateSettings(
{
 streaming :
 {
 lowLatencyEnabled : true,
 liveDelay : 2,
 jumpGaps : true,
 jumpLargeGaps : true,
 smallGapLimit : 1.5,
 }
});


To provide the
UTCTimingelement in the manifest, the smalltime.phpURL returns a UTC time from the web server :

<?php
 print gmdate("Y-m-d\TH:i:s\Z");
?>


(It also shows 404 errors for the latest stream1/audio chunk, that's likely a different problem)


I'm not sure what to try next. Any and suggestions greatly appreciated.


EDIT I


The suggestion by @Anonymous Coward to change the key interval improved things a lot. The chunks for stream0 and stream1 are in lock-step and have identical sequence numbers.


However, there are still many 404 errors, both on initial page load (without pressing play) and during playback.


I ran
watch -n 1 ls -lt code> and compared side-by-side to the errors in the browser console. It's hard to compare but it <em>looks</em> like the browser is trying to fetch files "on the play edge" which haven't yet been created by FFmpeg. See the pic below.

How do I instruct the browser to wait just a bit more before fetching the edge chunks ?




EDIT II


Using
shaka-playerinstead ofdash.jsplays properly without 404 errors. Configured as :

player.configure(
 {
 streaming: 
 {
 lowLatencyMode: true,
 inaccurateManifestTolerance: 0,
 rebufferingGoal: 0.1,
 }
 
 });


Client


- 

- MacOS 10.12
- dash.js latest 3.2.2
- Chrome 79, Safari 12, FireFox v ?








Server


- 

- Apache 2.4.37
- PHP 7.2.4 (for time function only)
- Centos 8








(For reference, here is the mpd file generated by FFmpeg)


<?xml version="1.0" encoding="utf-8"?>
<mpd xmlns="urn:mpeg:dash:schema:mpd:2011" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" minimumupdateperiod="PT500S" availabilitystarttime="2021-05-24T14:50:00.263Z" publishtime="2021-05-24T15:22:45.335Z" timeshiftbufferdepth="PT50.0S" maxsegmentduration="PT2.0S" minbuffertime="PT5.0S">
 <programinformation>
 </programinformation>
 <servicedescription>
 <latency target="3000" referenceid="0"></latency>
 </servicedescription>
 <period start="PT0.0S">
 <adaptationset contenttype="video" startwithsap="1" segmentalignment="true" bitstreamswitching="true" framerate="24/1" maxwidth="1280" maxheight="682" par="15:8" lang="und">
 <resync dt="200000" type="0"></resync>
 <representation mimetype="video/mp4" codecs="avc1.64081f" bandwidth="1000000" width="1280" height="682" sar="1023:1024">
 <producerreferencetime inband="true" type="captured" wallclocktime="2021-05-24T14:50:00.263Z" presentationtime="0">
 <utctiming schemeiduri="urn:mpeg:dash:utc:http-xsdate:2014" value="/pelican/testPlayers/time.php"></utctiming>
 </producerreferencetime>
 <resync dt="5000000" type="1"></resync>
 <segmenttemplate timescale="1000000" duration="2000000" availabilitytimeoffset="1.800" availabilitytimecomplete="false" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number%05d$.m4s" startnumber="1">
 </segmenttemplate>
 </representation>
 </adaptationset>
 <adaptationset contenttype="audio" startwithsap="1" segmentalignment="true" bitstreamswitching="true" lang="und">
 <resync dt="200000" type="0"></resync>
 <representation mimetype="audio/mp4" codecs="mp4a.40.2" bandwidth="116317" audiosamplingrate="48000">
 <audiochannelconfiguration schemeiduri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"></audiochannelconfiguration>
 <producerreferencetime inband="true" type="captured" wallclocktime="2021-05-24T14:50:00.306Z" presentationtime="0">
 <utctiming schemeiduri="urn:mpeg:dash:utc:http-xsdate:2014" value="/pelican/testPlayers/time.php"></utctiming>
 </producerreferencetime>
 <resync dt="21333" type="1"></resync>
 <segmenttemplate timescale="1000000" duration="2000000" availabilitytimeoffset="1.800" availabilitytimecomplete="false" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number%05d$.m4s" startnumber="1">
 </segmenttemplate>
 </representation>
 </adaptationset>
 </period>
 <utctiming schemeiduri="urn:mpeg:dash:utc:http-xsdate:2014" value="/pelican/testPlayers/time.php"></utctiming>
</mpd>


-
Netflix neutrality
31 mai 2014, par Mans — Law and libertyIn the net neutrality debate, a rarely mentioned aspect is the widespread practice amongst ISPs of over-subscribing bandwidth. Before streaming video became readily available and popular, this was viable, even reasonable, since few users managed to actually saturate their links for extended periods of time. Now that customers are suddenly … Continue reading
Syndiquer tout le site
