Recherche avancée

Sur d’autres sites (12832)

• Decoding VP8 On A Sega Dreamcast

  20 février 2011, par Multimedia Mike — Sega Dreamcast, VP8

  I got Google’s libvpx VP8 codec library to compile and run on the Sega Dreamcast with its Hitachi/Renesas SH-4 200 MHz CPU. So give Google/On2 their due credit for writing portable software. I’m not sure how best to illustrate this so please accept this still photo depicting my testbench Dreamcast console driving video to my monitor :

  
  
  

  Why ? Because I wanted to try my hand at porting some existing software to this console and because I tend to be most comfortable working with assorted multimedia software components. This seemed like it would be a good exercise.

  You may have observed that the video is blue. Shortest, simplest answer : Pure laziness. Short, technical answer : Path of least resistance for getting through this exercise. Longer answer follows.

  Update : I did eventually realize that the Dreamcast can work with YUV textures. Read more in my followup post.

  Process and Pitfalls
  libvpx comes with a number of little utilities including decode_to_md5.c. The first order of business was porting over enough source files to make the VP8 decoder compile along with the MD5 testbench utility.

  Again, I used the KallistiOS (KOS) console RTOS (aside : I’m still working to get modern Linux kernels compiled for the Dreamcast). I started by configuring and compiling libvpx on a regular desktop Linux system. From there, I was able to modify a number of configuration options to make the build more amenable to the embedded RTOS.
  
  I had to create a few shim header files that mapped various functions related to threading and synchronization to their KOS equivalents. For example, KOS has a threading library cleverly named kthreads which is mostly compatible with the more common pthread library functions. KOS apparently also predates stdint.h, so I had to contrive a file with those basic types.

  So I got everything compiled and then uploaded the binary along with a small VP8 IVF test vector. Imagine my surprise when an MD5 sum came out of the serial console. Further, visualize my utter speechlessness when I noticed that the MD5 sum matched what my desktop platform produced. It worked !

  Almost. When I tried to decode all frames in a test vector, the program would invariably crash. The problem was that the file that manages motion compensation (reconinter.c) needs to define MUST_BE_ALIGNED which compiles byte-wise block copy functions. This is necessary for CPUs like the SH-4 which can’t load unaligned data. Apparently, even ARM CPUs these days can handle unaligned memory accesses which is why this isn’t a configure-time option.

  Showing The Work
  I completed the first testbench application which ran the MD5 test on all 17 official IVF test vectors. The SH-4/Dreamcast version aces the whole suite.

  However, this is a video game console, so I had better be able to show the decoded video. The Dreamcast is strictly RGB— forget about displaying YUV data directly. I could take the performance hit to convert YUV -> RGB. Or, I could just display the intensity information (Y plane) rendered on a random color scale (I chose blue) on an RGB565 texture (the DC’s graphics hardware can also do paletted textures but those need to be rearranged/twiddled/swizzled).

  Results
  So, can the Dreamcast decode VP8 video in realtime ? Sure ! Well, I really need to qualify. In the test depicted in the picture, it seems to be realtime (though I wasn’t enforcing proper frame timings, just decoding and displaying as quickly as possible). Obviously, I wasn’t bothering to properly convert YUV -> RGB. Plus, that Big Buck Bunny test vector clip is only 176x144. Obviously, no audio decoding either.

  So, realtime playback, with a little fine print.

  On the plus side, it’s trivial to get the Dreamcast video hardware to upscale that little blue image to fullscreen.

  I was able to tally the total milliseconds’ worth of wall clock time required to decode the 17 VP8 test vectors. As you can probably work out from this list, when I try to play a 320x240 video, things start to break down.

  1. Processed 29 176x144 frames in 987 milliseconds.
  2. Processed 49 176x144 frames in 1809 milliseconds.
  3. Processed 49 176x144 frames in 704 milliseconds.
  4. Processed 29 176x144 frames in 255 milliseconds.
  5. Processed 49 176x144 frames in 339 milliseconds.
  6. Processed 48 175x143 frames in 2446 milliseconds.
  7. Processed 29 176x144 frames in 432 milliseconds.
  8. Processed 2 1432x888 frames in 2060 milliseconds.
  9. Processed 49 176x144 frames in 1884 milliseconds.
  10. Processed 57 320x240 frames in 5792 milliseconds.
  11. Processed 29 176x144 frames in 989 milliseconds.
  12. Processed 29 176x144 frames in 740 milliseconds.
  13. Processed 29 176x144 frames in 839 milliseconds.
  14. Processed 49 175x143 frames in 2849 milliseconds.
  15. Processed 260 320x240 frames in 29719 milliseconds.
  16. Processed 29 176x144 frames in 962 milliseconds.
  17. Processed 29 176x144 frames in 933 milliseconds.

• Encode Frames to Video with C Library

  31 juillet 2018, par NetherGranite

  For the sake of continuity, let us assume "RGB values" are the following :

  typedef struct RGB {
  
      uint8_t r, g, b;
  
  } rgb;

  However, if you feel that a different color space is more appropriate for this question, please use that instead.

  How might I go about writing 2D arrays of RGB values to a video in C given an output format and framerate ?

  Before I continue, I should specify that I wish to be able to do this all within one program. I am trying to add functionality to an application that would allow it to compile videos frame by frame without having to leave it.

  Additionally, my needs for this functionality are extremely basic ; I simply need to be able to set individual pixels to certain colors.

  The closest I have come to a solution so far is the C library FFmpeg. Allow me to describe what I was able to learn on my own :

  After looking through its documentation, I came across the function avcodec_send_frame(avctx, frame), whose parameters are of the types AVCodexContext* and const AVFrame* respectively. If these are not the right tools for what I am trying to do, please ignore the rest of the question and instead point me towards what I should be using.

  However, I do not know which fields of avctx and frame must be set manually and which do not. The reason I assume some do not is because both are extremely large structures, but correct me if I am wrong.

  Question 1 : What values of an AVCodecContext and AVFrame must be set ? Of these, what is/are the recommended value(s) for each of them ?

  Additionally, I was only able to find instructions on how to initialize an AVFrame (using av_frame_alloc() and av_frame_get_buffer()) but not for an AVCodexConstant.

  Question 2 : Is there a proper way to initialize an AVCodexConstant ? And just in case, is the method of initializing an AVFrame described above correct ? Do any of the fields of either have a proper method of initialization ?

  Also, I was not able to find official documentation on how to take this AVCodexConstant (which I assume contains the video information) and turn it into a video. I apologize if the documentation for this is easy to find and I just missed it.

  Question 3 : How do I turn an AVCodexConstant into a file of a given format ?

  And, given my limited knowledge :

  Question 4 : Are there any other parts to this process that I am missing, and do I have any of the above parts wrong ?

  ---

  Please keep in mind that I found out about FFmpeg for the first time very recently, and as a result, I am a complete beginner to this. Additionally, my experience with C is very limited, so I would greatly appreciate it if you could note which files need to be included with #include.

  Feel free to even go as far as recommending something other than FFmpeg, just as long as it is written in C. I do not need power-user options, but I would greatly prefer flexibility in what audio and video file types the library can handle.

  ---

  Addressing Potential Duplicates

  I appologize for how long this section is ; I just want to have my bases covered. I heavily apologize, however, if this is in fact a duplicate of a question that I was just unable to find.

  • ffmpeg C API documentation/tutorial [closed] — This question was too open-ended and received answers pointing the asker towards a tutorial at dranger.com, a tutorial that confusingly muddied the waters by focusing heavily on a graphics library of choice. Please do not take this as me saying it is bad ; I am just enough of a beginner that I could not wade through it all.
  • Encoding frames to video with ffmpeg — Although this question seems to have been asking the same thing, it is geared towards Unreal Engine 4, and the asker provided sample code, making it difficult for me to understand which of parts of the accepted answer were necessary for me and which were not.
  • How to write frames to a video file ? — While this also asked the same thing, the accepted answer simply provides a command instead of an explanation of code.
  • YUV Raw frames to video stream — While the accepted answer for this question is a command, the question states that it is looking for a way to encode frames generated by C++ code. Is there some way to run commands in code that I haven’t been able to find ?
  • Converting sequenced frames to video — Not only is the asker’s code written in Python, but it also seems to use already-existing image files as frames.
  • How to write bitmaps as frames to H.264 with x264 in C\C++ ? — The accepted answer seems to describe a process that would take multiple applications, but I could be wrong as I am enough of a beginner that I am not sure exactly what it means other than Step 3.
  • How to write bitmaps as frames to Ogg Theora in C\C++ ? — Although it isn’t a problem that the question specifies the ogg format, it is a problem that the accepted answer suggests libtheora, which appears to only work with ogg files.

• Piwik 2.1 — Massive Performance and Reliability Improvements

  4 mars 2014, par Benaka M. — Community, Development

  We are very excited to announce the immediate availability of Piwik v2.1.0 !

  • Download Link
  • How to update Piwik ?
  • List of all tickets closed : Changelog

  Piwik 2.1 is the first release after our 2.0 release and it reflects the new direction Piwik is moving in : better performance, more reliability and a better overall open platform ! We also released more plugins on the marketplace as well as helped developers build exciting new plugins for Piwik.

  This 2.1.0 release contains several performance and reliability improvements to the archiving process and to the new device detection process introduced in Piwik 2.0. It also includes a new email report format (CSV), a new marketplace plugin and overall more than 80 improvements (source).

  Massive Performance Improvements to Archiving

  The biggest improvement this release brings to Piwik are the various performance improvements made to the Archiving Process. These improvements include the following :

  • The amount of memory used has been reduced in some cases by 80% or more ! What used to require 8GB of memory will now only require 1GB. Piwik engineers analysed Profiler XHProf reports of Piwik under high load and implemented several improvements to archiving.
  • The cron script you can setup to automatically process your reports will now create new processes to perform asynchronous archiving instead issuing CURL http requests. This change results in increases to the performance and reliability of the Archiving Process.

  Bug Fixes and Performance Improvements to Device Detection

  In Piwik 1.12 we introduced a new device detection feature that could detect much more information than what we used before. Piwik 2.1 includes several bug fixes and improvements to this feature (such as detecting dozens of new devices, brands and models for smartphones, tablets and other devices). To use this feature, go to “Settings” then “Plugins” then activate the DevicesDetection plugin.

  New Default MySQL Database Type (InnoDB)

  This change doesn’t affect our existing Piwik users, but it does reflect our commitment to performance and reliability. We’ve changed the default MySQL database type to be InnoDB instead of Myisam. This will allow new users to immediately gain the benefits in reliability offered by InnoDB.

  New Marketplace Plugin – HTTP Authentication

  We’re releasing a new plugin on the marketplace that will allow you to use the HTTP authentication services provided by your webserver. Learn more about this plugin on the marketplace.

  New Email Format for Scheduled Reports

  The last big change in this release is a new email report format. You can now get your email reports as CSV files as well as HTML and PDF reports.

  Other Improvements

  In addition to performance improvements and new plugins, this release contains a few other smaller improvements described below.

  Changing segments in the Embedded Dashboard

  The embedded dashboard is the powerful feature that lets you include the Piwik Dashboard without the top menu and Piwik branding, directly within your application !

  This dashboard will now include the segment selector allowing you to change the current segment and create new segments, just as you would in the normal dashboard view :

  

  Multiple Super Users

  It’s now possible for your Piwik to have more than one Super User and for Super Users to have aliases :

  

  Learn more in the User guide : Managing Super Users in Piwik.

  Smart App Banners for our Mobile Apps

  Finally, in accord with our commitment to providing great User Experience, we’ve added a smart banner to Piwik so users that view Piwik from a mobile device will be informed of our amazing (and free !) mobile apps (for both iOS and Android).

  Participate in Piwik

  Are you a talented developer or an experienced User Interface designer ? If you have some free time and if you want to contribute to one of the most awesome open source projects around, please get in touch with the Piwik team, or read this page to learn more ?

  Summary

  For the full list of changes in Piwik 2.1 check out the Changelog.

  Thank you to the core developers, all the beta testers and users, our official supporters, the translators & everyone who reported bugs or feature requests. Also thank you to the software we use, and the libraries we use.

  Many of the improvements in this release come from the efforts of Piwik PRO experts. If you are looking for help to make the most of your analytics data, contact Piwik PRO. Learn more about us here.

  If you like what you read, please tell your friends and colleagues or write on your website, blog, forums, stackoverflow, etc.

  Enjoy !