
Recherche avancée
Médias (1)
-
Richard Stallman et le logiciel libre
19 octobre 2011, par
Mis à jour : Mai 2013
Langue : français
Type : Texte
Autres articles (37)
-
Keeping control of your media in your hands
13 avril 2011, parThe vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...) -
HTML5 audio and video support
13 avril 2011, parMediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
For older browsers the Flowplayer flash fallback is used.
MediaSPIP allows for media playback on major mobile platforms with the above (...) -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
Upload et récupération d’informations de la vidéo source
Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)
Sur d’autres sites (2068)
-
16 Website Metrics to Track If You Want to Grow Your Business
9 avril 2024, par Erin -
How Media Analytics for Piwik gives you the insights you need to measure how effective your video and audio marketing is – Part 2
2 février 2017, par InnoCraft — CommunityIn Part 1 we have covered some of the Media Analytics features and explained why you cannot afford to not measure the media usage on your website. Chances are, you are wasting or losing money and time by not making the most out of your marketing strategy this very second. In this part, we continue showing you some more insights you can expect to get from Media Analytics and how nicely it is integrated into Piwik.
Video, Audio and Media Player reports
Media Analytics adds several new reports around videos, audios and media players. They are all quite similar and give you similar insights so we will mainly focus on the Video Titles report.
Metrics
The above mentioned reports give you all the same insights and features so we will mainly focus on the “Video Titles” report. When you open such a report for the first time, you will see a report like this with the following metrics :
- “Impressions”, the number of times a visitor has viewed a page where this media was included.
- “Plays”, the number of times a visitor watched or listened to this media.
- “Play rate”, the percentage of visitors that watched or listened to a media after they have visited a page where this media was included.
- “Finishes”, the percentage of visitors who played a media and finished it.
- “Avg. time spent”, the average amount of time a visitor spent watching or listening to this media.
- “Avg. media length” the average length of a video or audio media file. This number may vary for example if the media is a stream.
- “Avg completion” the percentage of how much visitors have watched of a video.
If you are not sure what a certain metric means, simply hover the metric title in the UI and you will get a detailed explanation. By changing the visualization to the “All Columns Table” in the bottom of the report, you get to see even more metrics like “Plays by unique visitors”, “Impressions by unique visitors”, “Finish rate”, “Avg. time to play aka hesitation time”, “Fullscreen rate” and we are always adding more metrics.
These metrics are available for the following reports :
- “Video / Audio Titles” shows you all metrics aggregated by video or audio title
- “Video / Audio Resource URLs” shows you all metrics aggregated by the video or audio resource URL, for example “https://piwik.org/media.mp4”.
- “Video / Audio Resource URLs grouped” removes some information from the URLs like subdomain, file extensions and other information to get aggregated metrics when you provide the same media in different formats.
- “Videos per hour in website’s timezone” lets you find out how your media content is consumed depending on the hour of the day. You might realize that your media is consumed very differently in the morning vs at night.
- “Video Resolutions” lets you discover how your video is consumed depending on the resolution.
- “Media players” report is useful if you use different media players on your websites or apps and want to see how engagement with your media compares by media player.
Row evolution
At InnoCraft, we understand that static numbers are not so useful. When you see for example that yesterday 20 visitors played a certain media, would you know whether this is good or bad ? This is why we always give you the possibility to see the data in relation to the recorded data in the past. To see how a specific media performs over time, simply hover a media title or media resource URL and click on the “Row Evolution” icon.
Now you can see whether actually more or less visitors played your chosen video for the selected period. Simply click on any metric name and the chosen metrics will be plotted in the big evolution graph.
This feature is similar to the Media Overall evolution graph introduced in Part 1, but shows you a detailed evolution for an individual media title or resource.
Media details
Now that you know some of the most important media metrics, you might want to look a bit deeper into the user behaviour. For example we mentioned before the “Avg time spent on media” metric. Such an average number doesn’t let you know whether most visitors spent about the same time watching the video, or whether there were many more visitors that watched it only for a few seconds and a few that watched it for very long.
One of the ways to get this insight is by again hovering any media title or resource URL and clicking on the “Media details” icon. It will open a new popup showing you a new set of reports like these :
The “Time spent watching” and “How far visitors reached in the media” bar charts show you on the X-Axis how much time each visitor spent on watching a video and how far in the video they reached. On the Y-Axis you see the number of visitors. This lets you discover whether your users for example jump often to the middle or end of the video and which parts of your video was seen most often.
The “How often the media was watched in a certain hour” and “Which resolutions the media was watched” is similar to the reports introduced in Part 1 of the blog post. However, this time instead of showing aggregated video or audio content data, they display data for a specific media title or media resource URL.
Segmented audience log
In Part 1 we have already introduced the Audience Log and explained that it is useful to better understand the user behaviour. Just a quick recap : The Audience Log shows you chronologically every action a specific visitor has performed on your website : Which pages they viewed, how they interacted with your media, when they clicked somewhere, and much more.
By hovering a media title or a media resource and then selecting “Segmented audience log” you get to see the same log, but this time it will show only visitors that have interacted with the selected media. This will be useful for you for example when you notice an unusual value for a metric and then want to better understand why a metric is like that.
Applying segments
Media Analytics lets you apply any Piwik segment to the media reports allowing you to dice your visitors or personas multiplying the value that you get out of Media Analytics. For example you may want to apply a segment and analyze the media usage for visitors that have visited your website or mobile app for the first time vs. recurring visitors. Sometimes it may be interesting how visitors that converted a specific goal or purchased something consume your media, the possibilities are endless. We really recommend to take advantage of segments to understand your different target groups even better.
The plugin also adds a lot of new segments to your Piwik letting you segment any Piwik report by visitors that have viewed or interacted with your media. For example you could go to the “Visitors => Devices” report and apply a media segment to see which devices were used the most to view your media. You can also combine segments to see for example how often your goals were converted when a visitor viewed media for longer than 10 seconds after waiting for at least 20 seconds before playing your media and when they played at least 3 videos during their visit.
Widgets, Scheduled Reports, and more.
This is not where the fun ends. Media Analytics defines more than 15 new widgets that you can add to your dashboard or export it into a third party website. You can set up Scheduled Reports to receive the Media reports automatically via email or sms or download the report to share it with your colleagues. It works also very well with Custom Alerts and you can view the Media reports in the Piwik Mobile app for Android and iOS. Via the HTTP Reporting API you can fetch any report in various formats. The plugin is really nicely integrated into Piwik we would need some more blog posts to fully cover all the ways Media Analytics advances your Piwik experience and how you can use and dig into all the data to increase your conversions and sales.
How to get Media Analytics and related features
You can get Media Analytics on the Piwik Marketplace. If you want to learn more about this feature, you might be also interested in the Media Analytics User Guide and the Media Analytics FAQ.
-
Parsing The Clue Chronicles
30 décembre 2018, par Multimedia Mike — Game HackingA long time ago, I procured a 1999 game called Clue Chronicles : Fatal Illusion, based on the classic board game Clue, a.k.a. Cluedo. At the time, I was big into collecting old, unloved PC games so that I could research obscure multimedia formats.
Surveying the 3 CD-ROMs contained in the box packaging revealed only Smacker (SMK) videos for full motion video which was nothing new to me or the multimedia hacking community at the time. Studying the mix of data formats present on the discs, I found a selection of straightforward formats such as WAV for audio and BMP for still images. I generally find myself more fascinated by how computer games are constructed rather than by playing them, and this mix of files has always triggered a strong “I could implement a new engine for this !” feeling in me, perhaps as part of the ScummVM project which already provides the core infrastructure for reimplementing engines for 2D adventure games.
Tying all of the assets together is a custom high-level programming language. I have touched on this before in a blog post over a decade ago. The scripts are in a series of files bearing the extension .ini (usually reserved for configuration scripts, but we’ll let that slide). A representative sample of such a script can be found here :
What Is This Language ?
At the time I first analyzed this language, I was still primarily a C/C++-minded programmer, with a decent amount of Perl experience as a high level language, and had just started to explore Python. I assessed this language to be “mildly object oriented with C++-type comments (‘//’) and reliant upon a number of implicit library functions”. Other people saw other properties. When I look at it nowadays, it reminds me a bit more of JavaScript than C++. I think it’s sort of a Rorschach test for programming languages.Strangely, I sort of had this fear that I would put a lot of effort into figuring out how to parse out the language only for someone to come along and point out that it’s a well-known yet academic language that already has a great deal of supporting code and libraries available as open source. Google for “spanish dolphins far side comic” for an illustration of the feeling this would leave me with.
It doesn’t matter in the end. Even if such libraries exist, how easy would they be to integrate into something like ScummVM ? Time to focus on a workable approach to understanding and processing the format.
Problem Scope
So I set about to see if I can write a program to parse the language seen in these INI files. Some questions :- How large is the corpus of data that I need to be sure to support ?
- What parsing approach should I take ?
- What is the exact language format ?
- Other hidden challenges ?
To figure out how large the data corpus is, I counted all of the INI files on all of the discs. There are 138 unique INI files between the 3 discs. However, there are 146 unique INI files after installation. This leads to a hidden challenge described a bit later.
What parsing approach should I take ? I worried a bit too much that I might not be doing this the “right” way. I’m trying to ignore doubts like this, like how “SQL Shame” blocked me on a task for a little while a few years ago as I concerned myself that I might not be using the purest, most elegant approach to the problem. I know I covered language parsing a lot time ago in university computer science education and there is a lot of academic literature to the matter. But sometimes, you just have to charge in and experiment and prototype and see what falls out. In doing so, I expect to have a better understanding of the problems that need to solved and the right questions to ask, not unlike that time that I wrote a continuous integration system from scratch because I didn’t actually know that “continuous integration” was the keyword I needed.
Next, what is the exact language format ? I realized that parsing the language isn’t the first and foremost problem here– I need to know exactly what the language is. I need to know what the grammar are keywords are. In essence, I need to reverse engineer the language before I write a proper parser for it. I guess that fits in nicely with the historical aim of this blog (reverse engineering).
Now, about the hidden challenges– I mentioned that there are 8 more INI files after the game installs itself. Okay, so what’s the big deal ? For some reason, all of the INI files are in plaintext on the CD-ROM but get compressed (apparently, according to file size ratios) when installed to the hard drive. This includes those 8 extra INI files. I thought to look inside the CAB installation archive file on the CD-ROM and the files were there… but all in compressed form. I suspect that one of the files forms the “root” of the program and is the launching point for the game.
Parsing Approach
I took a stab at parsing an INI file. My approach was to first perform lexical analysis on the file and create a list of 4 types : symbols, numbers, strings, and language elements ([]{}()=., :). Apparently, this is the kind of thing that Lex/Flex are good at. This prototyping tool is written in Python, but when I port this to ScummVM, it might be useful to call upon the services of Lex/Flex, or another lexical analyzer, for there are many. I have a feeling it will be easier to use better tools when I understand the full structure of the language based on the data available.
The purpose of this tool is to explore all the possibilities of the existing corpus of INI files. To that end, I ran all 138 of the plaintext files through it, collected all of the symbols, and massaged the results, assuming that the symbols that occurred most frequently are probably core language features. These are all the symbols which occur more than 1000 times among all the scripts :6248 false 5734 looping 4390 scripts 3877 layer 3423 sequentialscript 3408 setactive 3360 file 3257 thescreen 3239 true 3008 autoplay 2914 offset 2599 transparent 2441 text 2361 caption 2276 add 2205 ge 2197 smackanimation 2196 graphicscript 2196 graphic 1977 setstate 1642 state 1611 skippable 1576 desc 1413 delayscript 1298 script 1267 seconds 1019 rect
About That Compression
I have sorted out at least these few details of the compression :bytes 0-3 "COMP" (a pretty strong sign that this is, in fact, compressed data) bytes 4-11 unknown bytes 12-15 size of uncompressed data bytes 16-19 size of compressed data (filesize - 20) bytes 20- compressed payload
The compression ratios are on the same order of gzip. I was hoping that it was stock zlib data. However, I have been unable to prove this. I wrote a Python script that scrubbed through the first 100 bytes of payload data and tried to get Python’s zlib.decompress to initialize– no luck. It’s frustrating to know that I’ll have to reverse engineer a compression algorithm that deals with just 8 total text files if I want to see this effort through to fruition.
Update, January 15, 2019
Some folks expressed interest in trying to sort out the details of the compression format. So I have posted a followup in which I post some samples and go into deeper details about things I have tried :Reverse Engineering Clue Chronicles Compression
The post Parsing The Clue Chronicles first appeared on Breaking Eggs And Making Omelettes.