Recherche avancée

Médias (1)

Mot : - Tags -/iphone

Autres articles (53)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

Sur d’autres sites (9874)

  • compiling FFmpeg on AIX

    3 mars 2017, par epitaxial

    I’m a hardware guy that likes to play around with different architectures and operating systems. Anyhow I’m trying to compile FFmpeg on AIX 7.1 using gcc but having some issues. I grabbed the latest code from git and while it does compile with a few warnings FFmpeg does not work. From my limited understanding it looks like the code is using 64 bit integers but was compiled as 32 bit ? Maybe someone can shed some light on this. Here is what happens when executing FFmpeg

    ./ffmpeg -i rtsp://192.168.1.9:554 -an -c copy -t 1:00:00 test.mp4
    ffmpeg version 3.2.git Copyright (c) 2000-2017 the FFmpeg developers
    built with gcc 4.8.5 (GCC)
    configuration: --enable-nonfree
    libavutil      55. 47.100 / 55. 47.100
    libavcodec     57. 81.100 / 57. 81.100
    libavformat    57. 66.102 / 57. 66.102
    libavdevice    57.  2.100 / 57.  2.100
    libavfilter     6. 74.100 /  6. 74.100
    libswscale      4.  3.101 /  4.  3.101
    libswresample   2.  4.100 /  2.  4.100
    [NULL @ 20932ac0] Value 0.000000 for parameter 'avioflags' is not a valid    set of 32bit integer flags
    [NULL @ 20932ac0] Value 2097664.000000 for parameter 'fflags' is not a valid set of 32bit integer flags
    [NULL @ 20932ac0] Value 0.000000 for parameter 'fdebug' is not a valid set of 32bit integer flags
    [NULL @ 20932ac0] Value 1.000000 for parameter 'f_err_detect' is not a valid set of 32bit integer flags
    [NULL @ 20932ac0] Value 1.000000 for parameter 'err_detect' is not a valid set of 32bit integer flags
    [RTSP demuxer @ 20933220] Value 0.000000 for parameter 'rtpflags' is not a valid set of 32bit integer flags
    [RTSP demuxer @ 20933220] Value 0.000000 for parameter 'rtsp_transport' is not a valid set of 32bit integer flags
    [RTSP demuxer @ 20933220] Value 0.000000 for parameter 'rtsp_flags' is not a valid set of 32bit integer flags
    [RTSP demuxer @ 20933220] Value 15.000000 for parameter 'allowed_media_types' is not a valid set of 32bit integer flags
    [rtsp @ 20932ac0] Unable to open RTSP for listening
    rtsp://192.168.1.9:554: Can't assign requested address

    Is my reasoning correct ? Thanks.

  • thread_queue_size during Live Streaming from ffmpeg

    11 mars 2017, par user2967920

    I’m trying to stream a webcam stream froma RaspberryPi-B to Youtube. The webcam used is a Logitech C920. If I use the h264 stream from the camera itself, it works fine using

    ffmpeg -f alsa -i hw:1,0 -f v4l2 -vcodec h264 -video_size 854x480 -r 25 -i /dev/video0 -acodec aac -b:a 64000 -ar 48000 -bufsize 64k -b:v 1200k -bufsize 1024k  -maxrate 1800k -vcodec copy -g 60 -r 30 -f flv
    rtmp://a.rtmp.youtube.com/live2/stream_here

    So, for this to work with other non h264 cameras like the Pi Cam or any other cheaper webcam, it needs to work with the raw stream and get converted to h264 using libx264. This is the whole point of using the Pi. Hence the second command set.

    ffmpeg -f alsa -ac 2 -i hw:1,0 -f v4l2 -i /dev/video0 -framerate 25 -video_size 1280x720  -c:v libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/stream_name

    So this results in the following issue.

    ffmpeg version git-2017-03-03-68ee800 Copyright (c) 2000-2017 the FFmpeg developers
     built with gcc 4.9.2 (Raspbian 4.9.2-10)
     configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --extra-libs=-lasound --enable-pthreads
     libavutil      55. 47.101 / 55. 47.101
     libavcodec     57. 82.100 / 57. 82.100
     libavformat    57. 66.103 / 57. 66.103
     libavdevice    57.  3.100 / 57.  3.100
     libavfilter     6. 74.100 /  6. 74.100
     libswscale      4.  3.101 /  4.  3.101
     libswresample   2.  4.100 /  2.  4.100
     libpostproc    54.  2.100 / 54.  2.100
    Guessed Channel Layout for Input Stream #0.0 : stereo
    Input #0, alsa, from 'hw:1,0':
     Duration: N/A, start: 1488650966.446293, bitrate: 1024 kb/s
       Stream #0:0: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s
    Input #1, video4linux2,v4l2, from '/dev/video0':
     Duration: N/A, start: 2227.042654, bitrate: 159252 kb/s
       Stream #1:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 864x480, 159252 kb/s, 24 fps, 24 tbr, 1000k tbn, 1000k tbc
    Stream mapping:
     Stream #1:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
     Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
    Press [q] to stop, [?] for help
    [video4linux2,v4l2 @ 0x2e42310] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
    Illegal instruction
    pi@raspberrypi:~ $

    If I add

    thread_queue_size 512

    I end up with

    pi@raspberrypi:~ $ ffmpeg -f alsa -ac 2 -i hw:1,0 -f v4l2 -thread_queue_size 512 -i /dev/video0 -framerate 25 -video_size 1280x720  -c:v libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/zqg7-98wy-60b6-f2yx
    ffmpeg version git-2017-03-03-68ee800 Copyright (c) 2000-2017 the FFmpeg developers
     built with gcc 4.9.2 (Raspbian 4.9.2-10)
     configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --extra-libs=-lasound --enable-pthreads
     libavutil      55. 47.101 / 55. 47.101
     libavcodec     57. 82.100 / 57. 82.100
     libavformat    57. 66.103 / 57. 66.103
     libavdevice    57.  3.100 / 57.  3.100
     libavfilter     6. 74.100 /  6. 74.100
     libswscale      4.  3.101 /  4.  3.101
     libswresample   2.  4.100 /  2.  4.100
     libpostproc    54.  2.100 / 54.  2.100
    Guessed Channel Layout for Input Stream #0.0 : stereo
    Input #0, alsa, from 'hw:1,0':
     Duration: N/A, start: 1488651430.836193, bitrate: 1024 kb/s
       Stream #0:0: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s
    Input #1, video4linux2,v4l2, from '/dev/video0':
     Duration: N/A, start: 2691.407641, bitrate: 159252 kb/s
       Stream #1:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 864x480, 159252 kb/s, 24 fps, 24 tbr, 1000k tbn, 1000k tbc
    Stream mapping:
     Stream #1:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
     Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
    Press [q] to stop, [?] for help
    Illegal instruction
    pi@raspberrypi:~ $

    Where exactly does

    thread_queue_size

    Belong ?

    Notes :
    ffmpeg was built using this reference
    –extra-libs=-lasound & —enable=pthreads was used

  • How to not process any personal data with Matomo and what it means for you

    22 avril 2018, par InnoCraft

    Disclaimer : this blog post has been written by digital analysts, not lawyers. The purpose of this article is to explain how to not process any personal data with Matomo in order to avoid going through the GDPR compliance process with Matomo analytics. This work comes from our interpretation of different sources : the official GDPR text and the UK privacy commission : ICO resources. It cannot be considered as a professional legal advice. So as GDPR, this information is subject to change. GDPR may be also known as RGPD in French, Spanish, Portuguese, Datenschutz-Grundverordnung, DS-GVO in German, Algemene verordening gegevensbescherming in Dutch, Regolamento generale sulla protezione dei dati in Italian.

    Are you looking for a way to not process any personal data with Matomo ? If the answer is yes, you are at the right place. From our understanding, if you are not processing personal data, then you shouldn’t be concerned about GDPR. Our inspiration came from this official reference :

    “The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.“

    In this blog post we are going to see how you can configure Matomo in order to not process any personal data and what the consequences are.

    Which data is considered as personal according to GDPR ?

    From : eur-lex.europa.eu

    (1) “‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’) ; an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person ;”

    (30) “Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.”

    So according to your Matomo configuration, it may leave some traces within the following data :

    1. IP addresses
    2. Cookies identifiers
    3. Page URL or page titles
    4. User ID and Custom “personal” data
    5. Ecommerce order IDs
    6. Location
    7. Heatmaps & Session Recordings

    Let’s see each of them in more detail.

    1. IP addresses

    IP addresses can indirectly identify an individual. It can also give a good approximation of an individual’s location.

    IP addresses are therefore considered as personal data which means you need to anonymize them. To do so, a feature is available within Matomo, where you can anonymize the IP. We recommend you to anonymize at least the last two bytes :

    See our configuration guide for more information

    What are the consequences of using this feature ?

    When applying IP anonymization on two bytes, you will no longer be able to see the full IP in the UI.

    Moreover, there is a small chance that 2 different visitors with the same device and software configuration will be identified as the same visitor if the anonymised IP address is the same for both.

    2. Cookies

    It is not clear for us yet if all cookies are considered equal under GDPR. At this stage it is too early to make a definite decision.

    Did you know ? Matomo lets you optionally disable the creation of cookies by adding an extra line of code to your tracking code see below.

    See our configuration guide for more information

    What are the consequences of using this feature ?

    Matomo is using a few first party cookies, and the following cookies may hold personal data :

    • _pk_id : contains a visitor id used to identify unique visitors
    • _pk_ref : to identify from where they came from

    If Matomo cannot set cookies, it will use a technique called Fingerprint. It is based on several metadata such as the operating system, browser, browser plugins, IP address, browser language ; just to name a few to identify a unique visitor. As this feature is less accurate than the one using cookies, the number of visitors and visits will be affected.

    3. Page URLs and page titles

    URLs are not mentioned within the official GDPR text. However, we know that according to the different CMS you use, some of them may have URLs including personal identifiers.

    For example :

    As a result, you need to find a way to anonymize this data.

    There are several ways you can perform this action according to your website. If your website is adding the personal data through query parameters, you can define a rule to exclude them from Matomo.

    If the personal data are not included within query parameters, you can use the “setCustomURL” feature and write your code as follow :

    See our developer documentation for more information

    If you are also processing personal data within the title tag, you can use the following function : “setDocumentTitle”.

    What are the consequences of using this feature ?

    By anonymizing the URLs containing personal data, some of your  URLs will be grouped together.

    4. User ID and custom personal data

    User ID is a feature (a tracking code needs to be added) which allows you to identify the same user across different devices.

    A User ID needs a corresponding database in order to link a user across different devices, it can be an email, a username, a name, a random number… All those data are either direct or non direct online identifiers and are therefore under the scope of GDPR.

    It will be the same situation if you are using custom variables and/or custom dimensions in order to push personal data to the system.

    To continue using the User ID feature but not recording personal data, you can consider using a hash function which will anonymize/convert your actual User ID into something like “3jrj3j34434834urj33j3”.

    Alternatively, you can enable the feature “Anonymise User IDs”. This feature will be available starting in Matomo 3.5.0 :

    What are the consequences of using this feature ?

    Under GDPR, User ID is personal data. Anonymizing the User ID using a hash function or our built-in functionality make the User Id pseudo-anonymous, which means it can’t be easily identified to a specific user. As a result, you will still get accurate visits and unique visitors metrics, and the Visitor Profile, but without tracking the original User ID which is personal data.

    5. Ecommerce order IDs

    Order IDs are the reference number assigned to the products/services bought by your customers. As this information can be crossed with your internal database, it is considered as an online identifier and is therefore under the scope of GDPR. As for User ID, you can anonymize order IDs using our built-in functionality to Anonymise Order IDs (see section 4. about User Id).

    What are the consequences of anonymizing order ID ?

    It really depends on your former use of order IDs. If you were not using them in the past then you should not see any difference.

    6. Location

    Based on the IP address of a visitor, Matomo can detect the visitors location. Location data is problematic for privacy as this technology has become quite accurate and can detect not only the city a visitor is from, but sometimes an even more precise position of a visitor.

    In order to not leave any accurate traces, we strongly recommend you to enable the IP anonymization feature. Next, you need to enable the setting “Also use the anonymized IP address when enriching visits”. You find this setting directly below the IP anonymization. This is important as otherwise the full IP address will be used to geolocate a visitor.

    What are the consequences of anonymizing location data ?

    The more bytes you anonymize from the IP, the more anonymized your location will be. When you remove two bytes as suggested, the city and region location reports will not be as accurate. In some cases even the country may not be detected correctly anymore.

    7. Heatmaps & Session Recordings

    Heatmaps & Session Recording is a premium feature in Matomo allowing you to see where users click, hover, type and scroll. With session recordings you can then replay their actions in a video.

    Heatmaps & Session Recordings are under the scope of GDPR as they can disclose in some specific cases (for example : filling a contact form) personal data :

    To avoid this, Matomo will anonymize all keystrokes which a user enters into a form field unless you specifically whitelist a field. Many fields that could contain personal data, such as a credit card, phone number, email address, password, social security number, and more are always anonymized and not recorded.

    See our configuration guide for more information

    Note that a page may still show personal information within the page as part of regular content (not a form element). For example an address, or the profile page of a forum user. We have added a feature which allows you to set an HTML attribute “data-matomo-mask” to anonymize any personal content shown in the UI.

    What are the consequences of using this feature ?

    Mainly, you will not be able to see in plain text what people are entering into your forms.

    What should you do with past data ?

    Once more, we have to say that we are not lawyers. So do not take our answers as legal advice. From : ec.europa.eu/newsroom/article29/document.cfm ?doc_id=50053

    “For example, as the GDPR requires that a controller must be able to demonstrate that valid consent was obtained, all presumed consents of which no references are kept will automatically be below the consent standard of the GDPR and will need to be renewed.”

    Our interpretation is that, if you were previously relying on consent, unless you can demonstrate that valid consent was obtained, you need to get the consent back (which is almost impossible) or you need to anonymize or remove that data.

    To anonymize previously tracked data, we are actively working on a feature to do just that directly within Matomo. Alternatively, you may also set up the deletion of logs after a certain amount of time.

    We really hope you enjoyed reading this article. GDPR is still on the go and we are pretty sure you have a lot of questions about it. You probably would like to share our vision about it. So do not hesitate to ask us through our contact form to see how we are interpreting GDPR at Matomo and InnoCraft.

    The post How to not process any personal data with Matomo and what it means for you appeared first on Analytics Platform - Matomo.