Recherche avancée

Sur d’autres sites (7124)

• VP8 Codec Optimization Update

  15 juin 2010, par noreply@blogger.com (John Luther) — inside webm

  Since WebM launched in May, the team has been working hard to make the VP8 video codec faster. Our community members have contributed improvements, but there’s more work to be done in some interesting areas related to performance (more on those below).

  
  

  Encoder

  
  The VP8 encoder is ripe for speed optimizations. Scott LaVarnway’s efforts in writing an x86 assembly version of the quantizer will help in this goal significantly as the quantizer is called many times while the encoder makes decisions about how much detail from the image will be transmitted.

  For those of you eager to get involved, one piece of low-hanging fruit is writing a SIMD version of the ARNR temporal filtering code. Also, much of the assembly code only makes use of the SSE2 instruction set, and there surely are newer extensions that could be made use of. There are also redundant code removal and other general cleanup to be done ; (Yaowu Xu has submitted some changes for these).
  
  At a higher level, someone can explore some alternative motion search strategies in the encoder. Eventually the motion search can be decoupled entirely to allow motion fields to be calculated elsewhere (for example, on a graphics processor).
  

  Decoder

  
  Decoder optimizations can bring higher resolutions and smoother playback to less powerful hardware.

  Jeff Muizelaar has submitted some changes which combine the IDCT and summation with the predicted block into a single function, helping us avoid storing the intermediate result, thus reducing memory transfers and avoiding cache pollution. This changes the assembly code in a fundamental way, so we will need to sync the other platforms up or switch them to a generic C implementation and accept the performance regression. Johann Koenig is working on implementing this change for ARM processors, and we’ll merge these changes into the mainline soon.

  In addition, Tim Terriberry is attacking a different method of bounds checking on the "bool decoder." The bool decoder is performance-critical, as it is called several times for each bit in the input stream. The current code handles this check with a simple clamp in the innermost loops and a less-frequent copy into a circular buffer. This can be expensive at higher data rates. Tim’s patch removes the circular buffer, but uses a more complex clamp in the innermost loops. These inner loops have historically been troublesome on embedded platforms.
  
  To contribute in these efforts, I’ve started working on rewriting higher-level parts of the decoder. I believe there is an opportunity to improve performance by paying better attention to data locality and cache layout, and reducing memory bus traffic in general. Another area I plan to explore is improving utilization in the multi-threaded decoder by separating the bitstream decoding from the rest of the image reconstruction, using work units larger than a single macroblock, and not tying functionality to a specific thread. To get involved in these areas, subscribe to the codec-devel mailing list and provide feedback on the code as it’s written.
  

  Embedded Processors

  
  We want to optimize multiple platforms, not just desktops. Fritz Koenig has already started looking at the performance of VP8 on the Intel Atom platform. This platform need some attention as we wrote our current x86 assembly code with an out-of-order processor in mind. Since Atom is an in-order processor (much like the original Pentium), the instruction scheduling of all of the x86 assembly code needs to be reexamined. One option we’re looking at is scheduling the code for the Atom processor and seeing if that impacts the performance on other x86 platforms such as the Via C3 and AMD Geode. This is shaping up to be a lot of work, but doing it would provide us with an opportunity to tighten up our assembly code.
  
  These issues, along with wanting to make better use of the larger register file on x86_64, may reignite every assembly programmer’s (least ?) favorite debate : whether or not to use intrinsics. Yunqing Wang has been experimenting with this a bit, but initial results aren’t promising. If you have experience in dealing with a lot of assembly code across several similar-but-kinda-different platforms, these maintainability issues might be familiar to you. I hope you’ll share your thoughts and experiences on the codec-devel mailing list.
  
  Optimizing codecs is an iterative (some would say never-ending) process, so stay tuned for more posts on the progress we’re making, and by all means, start hacking yourself.
  
  It’s exciting to see that we’re starting to get substantial code contributions from developers outside of Google, and I look forward to more as WebM grows into a strong community effort.
  
  John Koleszar is a software engineer at Google.

  

• Piwik 3 Development Update #1 – New UI design, API changes & release date

  1er septembre 2016, par Thomas Steur — Community, Development

  Over the last months, we have been actively working on the Piwik 3 release and we want to introduce you to the changes that we have done so far. They include a new and modern UI redesign, new widgets for your dashboard, and technical improvements under the hood.

  New Piwik 3 UI

  Based on Material Design we have revamped the user interface which is now more responsive, more usable and faster. While the UI is not yet finished, we invite you to check it out already and to let us know what you think.

  

  This new Piwik material design is a visual language that synthesizes classic principles of good design with the innovation and possibility of technology and science.

  More responsive

  Piwik 3 will look and feel much better on your mobile phone and tablet. Many elements have been improved : the menus, the segment editor and dashboard selector, the widgets, the settings pages and most other pages so you can fully experience and enjoy Piwik on any device !

  

  Improved usability

  We have updated the menu structure, the dashboard selector as well as the footer in reports to make your life easier when using Piwik. We love to keep these complicated things simple. There are also many other tiny improvements that you will appreciate.

  

  The Zen Mode lets you view in full screen your analytics reports and dashboards. Users love this feature and it can now be accessed by pressing “z” key.

  

  Faster

  To make the Piwik interface faster, we have refactored most of our CSS, HTML and JavaScript and moved more and more of our code into the client. As a result, Piwik now needs to reload the page much less often ! For example when you change the date or change the segment, Piwik will now load the reports instantly. To improve performance even further, Piwik will now load multiple reports on a single page in parallel.

  Native fonts

  Over the last months more and more web services have started using system fonts, and so will Piwik 3. System fonts look better, improve language support and give you a more native, familiar feeling.

  For more details and screenshots have a look at the pull request for the Piwik 3 UI update.

  New widgets

  With the “Latest Piwik Plugin Updates” widget you won’t miss any newly added or updated plugin anymore. This will help you learn about and discover the useful plugins and themes available on the Marketplace.

  

  Super users can now see at a glance the current state of the Piwik system, thanks to the new “System Check” and “System Summary” widgets.

  

  API Changes

  Piwik is the leading open analytics platform, highly customisable and extensible thanks to a flexible plugins architecture and a design based on APIs. In this new major Piwik 3 release, we significantly improve the foundation of our open platform and several of its core APIs.

  The new Widgets and Reporting API makes it possible to add reports and widgets to any existing reporting page. In the past, reporting pages had to be created manually which was time consuming and it was hard to maintain a consistent look across different reporting pages. Now reporting pages are generated automatically by the Piwik platform.

  The Plugin Settings API was changed to improve performance and to let plugin developers customize the Websites Manager. This is one step towards our goal to let users not only manage websites but also mobile apps, cars, coffee machines or any other thing.

  To see a full list of changes in the Piwik 3 analytics platform, have a look at the developer changelog.

  Developer docs

  The Piwik Developer Zone is full of guides and API references to help developers understand, integrate and extend Piwik. As some APIs have changed in the Piwik 3 release it is now possible to select the Piwik version in the top right corner of the developer zone.

  

  We are updating guides for Piwik 3 and added a Piwik 2 -> Piwik 3 Migration Guide for plugin developers. Many other guides were updated such as Menus, Custom Report and Widgets.

  Release date

  The first Piwik 3 beta release will be available in the next four weeks. Beta testers automatically receive the update if they are subscribed to the “Latest Beta” release channel. The final Piwik 3 release will be ready before the end of the year. If you want to give it a try, you can either use Piwik from Git and check out the “3.x-dev” branch, or download Piwik 3 from GitHub.

  Closing thoughts

  With faster & more beautiful reports, better APIs and more stability, Piwik 3 is a big step forward for all Piwik users. As our mission is to create, as a community, the leading international open source web analytics platform that gives every user full control of their data, we are very excited to introduce you to this upcoming release.

  We now offer Custom Development services if you like to sponsor a new feature or bug fix, or if you have any custom requirements. And if you use Piwik Analytics to grow your business and need quality help, contact the Piwik analytics experts to get started.

  Until our next Piwik 3 dev update, Happy analysis !

• Server Move For multimedia.cx

  1er août 2014, par Multimedia Mike — General

  I made a big change to multimedia.cx last week : I moved hosting from a shared web hosting plan that I had been using for 10 years to a dedicated virtual private server (VPS). In short, I now have no one to blame but myself for any server problems I experience from here on out.

  The tipping point occurred a few months ago when my game music search engine kept breaking regardless of what technology I was using. First, I had an admittedly odd C-based CGI solution which broke due to mysterious binary compatibility issues, the sort that are bound to occur when trying to make a Linux binary run on heterogeneous distributions. The second solution was an SQLite-based solution. Like the first solution, this worked great until it didn’t work anymore. Something else mysteriously broke vis-à-vis PHP and SQLite on my server. I started investigating a MySQL-based full text search solution but couldn’t make it work, and decided that I shouldn’t have to either.

  Ironically, just before I finished this entire move operation, I noticed that my SQLite-based FTS solution was working again on the old shared host. I’m not sure when that problem went away. No matter, I had already thrown the switch.

  How Hard Could It Be ?
  We all have thresholds for the type of chores we’re willing to put up with and which we’d rather pay someone else to perform. For the past 10 years, I felt that administering a website’s underlying software is something that I would rather pay someone else to worry about. To be fair, 10 years ago, I don’t think VPSs were a thing, or at least a viable thing in the consumer space, and I wouldn’t have been competent enough to properly administer one. Though I would have been a full-time Linux user for 5 years at that point, I was still the type to build all of my own packages from source (I may have still been running Linux From Scratch 10 years ago) which might not be the most tractable solution for server stability.

  These days, VPSs are a much more affordable option (easily competitive with shared web hosting). I also realized I know exactly how to install and configure all the software that runs the main components of the various multimedia.cx sites, having done it on local setups just to ensure that my automated backups would actually be useful in the event of catastrophe.

  All I needed was the will to do it.

  The Switchover Process
  Here’s the rough plan :

  • Investigate options for both VPS providers and mail hosts– I might be willing to run a web server but NOT a mail server
  • Start plotting several months in advance of my yearly shared hosting renewal date
  • Screw around for several months, playing video games and generally finding reasons to put off the move
  • Panic when realizing there are only a few days left before the yearly renewal comes due

  So that’s the planning phase. BTW, I chose Digital Ocean for VPS and Zoho for email hosting. Here’s the execution phase I did last week :

  • Register with Digital Ocean and set up DNS entries to point to the old shared host for the time being
  • Once the D-O DNS servers respond correctly using a manual ‘dig’ command, use their servers as the authoritative ones for multimedia.cx
  • Create a new Droplet (D-O VPS), install all the right software, move the databases, upload the files ; and exhaustively document each step, gotcha, and pitfall ; treat a VPS as necessarily disposable and have an eye towards iterating the process with a new VPS
  • Use /etc/hosts on a local machine to point DNS to the new server and verify that each site is working correctly
  • After everything looks all right, update the DNS records to point to the new server

  Finally, flip the switch on the MX record by pointing it to the new email provider.

  Improvements and Problems
  Hosting on Digital Ocean is quite amazing so far. Maybe it’s the SSDs. Whatever it is, all the sites are performing far better than on the old shared web host. People who edit the MultimediaWiki report that changes get saved in less than the 10 or so seconds required on the old server.

  Again, all problems are now my problems. A sore spot with the shared web host was general poor performance. The hosting company would sometimes complain that my sites were using too much CPU. I would have loved to try to optimize things. However, the cPanel interface found on many shared hosts don’t give you a great deal of data for debugging performance problems. However, same sites, same software, same load on the VPS is considerably more performant.

  Problem : I’ve already had the MySQL database die due to a spike in usage. I had to manually restart it. I was considering a cron-based solution to check if the server is running and restart it if not. In response to my analysis that my databases are mostly read and not often modified, so db crashes shouldn’t be too disastrous, a friend helpfully reminded me that, “You would not make a good sysadmin with attitudes like ‘an occasional crash is okay’.”

  To this end, I am planning to migrate the database server to a separate VPS. This is a strategy that even Digital Ocean recommends. I’m hoping that the MySQL server isn’t subject to such memory spikes, but I’ll continue to monitor it after I set it up.

  Overall, the server continues to get modest amounts of traffic. I predict it will remain that way unless Dark Shikari resurrects the x264dev blog. The biggest spike that multimedia.cx ever saw was when Steve Jobs linked to this WebM post.

  Dropped Sites
  There are a bunch of subdomains I dropped because I hadn’t done anything with them for years and I doubt anyone will notice they’re gone. One notable section that I decided to drop is the samples.mplayerhq.hu archive. It will live on, but it will be hosted by samples.ffmpeg.org, which had a full mirror anyway. The lower-end VPS instances don’t have the 53 GB necessary.

  Going Forward
  Here’s to another 10 years of multimedia.cx, even if multimedia isn’t as exciting as it was 10 years ago (personal opinion ; I’ll have another post on this later). But at least I can get working on some other projects now that this is done. For the past 4 months or so, whenever I think of doing some other project, I always remembered that this server move took priority over everything else.