Posts Tagged ‘Data’

Accel Leads $52.5M Round In Cloud-Based Data Storage And Backup Company Code 42

Code 42 Software , a Minnesota-based online backup company for consumers, businesses and the enterprise, has raised $52.5 million in funding led by Accel Partners with participation from Split Rock Partners. This is the first major investment from Accel’s recently announced Big Data Fund , which is dedicated to funding infrastructure and application companies in “Big Data.” This is the first round of institutional investing for Code 42. You may not have heard of Code 42, but the enterprise company should be on your radar. Founded by Brian Bispala, Mitch Coopet and Matthew Dornquast, Code 42 launched CrashPlan, a personal data protection and backup software, back in 2007. The intention of CrashPlan was to reinvent backup by developing an easy-to-use technology to protect data whenever and wherever it is created. After introducing CrashPlan to consumers, Code 42 decided to use this knowledge gained to develop and deliver a backup software that was enterprise-grade. Just five years after launching CrashPlan, Code 42 now manages and protects over 100 petabytes of data globally. In addition to CrashPlan for consumers, Code 42’s product lineup includes online backup solutions for the SMB, CrashPlan PRO, and private and public cloud solutions for the enterprise, CrashPlan PROe. All of the company’s data storage and backup products are cross-platform, and provide continuous protection onsite, offsite and online. The virtue of Code 42′s offering is that the software can be used for both public and private clouds. Dornquast explained to me in an interview that most large enterprises believe in a hybrid model, with four out of five of the company’s enterprise customers building their own private cloud as opposed to relying on an untrusted cloud. Dornquast says that Code 42′s ‘secret sauce’ is the company has engineered its own storage technology, that allows businesses to build their own private clouds. As he explains, Code 42 is “part software company, part cloud storage company, and part managed appliance hardware company.” Crashplan product has been deployed in over 4000 “big data” enterprise environments and customers include: Adobe, Google, Groupon, HP, Intuit, NASA, LinkedIn, Salesforce.com, and Stanford University. For example, Dornquast said Google has been is using Crashplan for internal data storage. While revenue was not disclosed, the company has seen 500 percent growth over the last three years, and is profitable. Accel partner Ping Li explains that managing data on multiple devices is a challenge for both consumers and the enterprise, and being able to move this data safely and securely is becoming more and more important. With this in mind, there needs to be real technology behind this issue, he says. Li (and Accel) believes that device and information data management in the cloud is an example of a big data application ripe for disruption. Code 42 provides a scalable and seamless multi-device “big data information management platform” to continuously protect and manage this growing data in real-time across any device. What struck Li has being particularly unique about Code 42 (besides the technology itself) is that although the startup provides major infrastructure and helps manage massive amounts of data, the UI is lightweight and resonates with the trend of the consumerization of IT. As Dornquast tells me, this clean, consumer product-like experience is one of the key reasons the company has been able to pull in customers like Google. The company has been able to back-up over 250 million files per day across multiple data centers  globally; and service customers from soccer moms to Fortune 100 companies. Code 42 faces competition from Carbonite , Box and others. The new funding will be will be used to accelerate multi-platform product development and increase sales and marketing efforts internationally.

Taking a look at Intel Anti Theft & Identity Protection Technologies

I wanted to start a new blog introducing myself in a new role at Intel. As part of my new role I will be explaining Intel’s Security, Manageability, and Virtualization features to a broad base of ISV’s through our scale enabling team and associated platform communities. In my new role, I have been learning about many of Intel’s security technologies and am excited about bringing these technologies to light in my blogs, and Intel Software Network TV. To see why I am excited, and a little daunted with my new tasks, take a look at a couple of clips of Mooly Eden at Intel’s recent Intel Developer Conference. These technologies are amazing ,…but there is so much ground that they span! The first clip showcases Intel’s Anti Theft technologies (starting at 31:10 mark and ending at 34:57). Here Mooly invited McAfee co president, Todd Gebhart, to the stage to discuss McAfee’s Anti Theft which allows a user to lock their laptop or even wipe their data by issuing a poison pill in the event that their laptop is stolen. Then Mooly introduced a new technology called Intel Identity Protection Technology (IPT) . To showcase this technology, Mooly had a hacker, garbed in a ninja costume, attempt to use a key logger and frame grabbing software to attempt to hack, demo presenter, Mark’s bank transaction. In this amazing clip, the hacker successfully grabs the username and password to Mark’s bank account, using a nefarious keylogger. BUT – the hacker cannot capture or generate a third authentication token which has been set up between Mark & his bank. The hacker is thwarted from any mischievous activity by IPT. Using this IPT technology, a random layout pin pad is generated and displayed to Mark, which allows Mark to send an additional credential to the bank in order to authenticate the transaction. Mark’s bank account is safe! See this part of the clip at 35:08 to 38:44 . If you want to learn even more, see Intel’s Ned Smith’s IPT foils at 2011 Kerberos conference. I plan to be interviewing experts from various corners of Intel to help describe these technologies in more detail. We will also be working to bring API’s to light with Software Developer Guides, tech briefs, and whitepapers, videos and more. I also hope to keep one eye on new developments in the security space in the rest of industry to help articulate security, virtualization and manageability trends that I see developing.

Doctor Fortran in "Lest Old Acquaintance Be Forgot"

In some of my earlier posts I’ve discussed new features in the Fortran language that might be unfamiliar to some.  But this time I’m going to go the other way and describe some really old language features – so old that many newer Fortran programmers are mystified when they see them – but these features are still supported by many current compilers, including Intel Fortran.  So let’s set the Wayback Machine to the 1960s and have a look around. Computed GO TO This feature remained in the standard through Fortran 95, not deleted until Fortran 2003. but you don’t see it very often.  The syntax is: GO TO (label-list), expr where expr is an integer expression.  If the expression is 1, control transfers to the first label in the list, if 2, the second label, etc.  If the value is less than 1 or greater than the number of labels, execution “falls through” to the next statement.  For example: GO TO (10,20,20,30), I Nowadays the SELECT CASE construct is a preferred replacement. Arithmetic IF This is the one I see popping up most often in comp.lang.fortran posts where the author has come across it and has no idea what it does. The syntax is: IF (expr) label1, label2, label3 Here, expr can be integer or real.  If the value is less than zero, control transfers to label1; if zero, label2; and if greater than zero, label 3. As with Computed GO TO, you can repeat labels if you wish.  Arithmetic IF was declared obsolescent in Fortran 90 and deleted in Fortran 95. The usual recommendation here is to use IF-THEN-ELSE (which was new in Fortran 77). ASSIGNed GO TO and FORMAT So let’s say you had some common piece of code that needed access to your local variables and that was used in several places in a routine. Nowadays we’d use internal procedures, but before that, there was ASSIGNed GO TO.  The way it would work is you’d declare some integer variable, we’ll call it IDEST here, and do something like this: ASSIGN 30 TO IDEST GO TO 900 30 CONTINUE … ASSIGN 40 TO IDEST GO TO 900 40 CONTINUE … 900 CONTINUE … Do common stuff GO TO IDEST The jump to 900 would occur, the common code would execute, and then control would transfer to the label that had been assigned to the IDEST variable.  You could use ASSIGNed variables in place of FORMAT labels too in an I/O statement. Back when I was working on VAX Fortran, I occasionally encountered programs written by customers who had cleverly noticed that the compiler implemented ASSIGNed GOTOs by simply storing the 32-bit address of the instruction at the assigned label into the variable.  They could then use this address in various ways, perhaps implementing some sort of array of pointers to statements.  (The compiler had to support 16-bit integer variables too, so what it stored there were offsets from the routine start address.)  This unraveled, though, when these applications were ported to the DEC Alpha processors, as the compiler there simply stored an index into a table rather than an instruction address. ASSIGNed GO TO and FORMAT was declared obsolescent in Fortran 90 and deleted in Fortran 95. Alternate Return Here’s one that actually stayed in the language through Fortran 95, though it had been named obsolescent in Fortran 90.  Let’s say you wanted to call a subroutine but wanted, on return, to branch to some other label if some condition was met, rather than continuing after the CALL. So you’d do something like this: CALL SUB (arg1, arg2, *10, *20) … SUBROUTINE SUB (arg1, arg2, *, *) In subroutine SUB, you could return normally if you wanted.  But if you wanted to instead return and branch to the first alternate return label, you’d do: RETURN 1 Similarly, if you wanted to return to the second alternate label, you’d write: RETURN 2 The value could be any numeric expression that got converted to an integer.  If the value was less than 1 or more than the number of alternate return labels, a normal RETURN would be done.  Some compilers, as an extension, accepted the use of & in the CALL instead of * (but not in the subroutine argument list.)  Intel Fortran also supports that. Hollerith Constants FORTRAN 66 didn’t have a character data type nor did it have character literals.  Instead, you could use Hollerith constants to assign values to numeric variables.  The form of a Hollerith constant is an integer specifying the number of characters, the letter H, and then however many characters were specified.  For example: 4HABCD Hollerith constants were odd in that they had no intrinsic data type – they assumed the numeric (remember, no character type!) type based on the context in which they were used.  You could assign Hollerith constants to integer and real variables and the bytes of the characters would be stored directly.  If the constant’s length were too short, it would be padded with blanks, and truncated if too long.  Many compilers had the extension of using apostrophe delimited strings as a substitute for Hollerith, so you might see something like: INTEGER I I = ‘WHAT’ and be perplexed that the compiler accepted it. Hollerith constants were not carried over from Fortran 66 to Fortran 77, though the 77 standard did have an appendix describing how they should work if a compiler chose to support them.  Note that there is also a Hollerith edit descriptor in formats, but those are treated like character strings and were still in the language through Fortran 90. Writable FORMAT This is the language feature that prompted me to write this post.  A user recently complained, in our user forum, that the output of his program was being corrupted by a READ.  In one part of a subroutine he had something like this: WRITE (6,100) MM,DD,YY 100 FORMAT (I2,’/',I2,’/',I2) and then later in this same routine: READ (5,100) I The first time through the routine, everything was fine, but on the second call, the WRITE had a blank in place of the first slash! What was going on here? If you’re familiar with the interaction between formats and I/O lists, you’ll know that once an I/O list item has been “consumed” by an edit descriptor, processing of the format continues until it reaches another data-consuming edit descriptor, a colon, or the end of the format is reached.  So on the READ, processing continues and the ‘/’ is seen.  What does this do on a READ? In Fortran 77, this is not legal – you are not allowed to have an “apostrophe edit descriptor” in a format used by a READ.  But Fortran 66 did allow this, sort of.  Remember what I wrote above that compilers would treat quoted literals the same as Hollerith constants, so the format was treated as if it had 1H/ instead of the ‘/’.  Ok, but so what? Here’s where the ancient magic comes in.  Fortran 66 allowed you to READ into a Hollerth edit descriptor, changing the characters for future uses of that FORMAT.  This was usually done to provide titles for reports – you’d read the title from the input card deck (remember cards?) and then the title would appear when the FORMAT was used on subsequent WRITEs.  So what happened here is that a character was read from the input record and it replaced the slash.  In this customer’s case, there were no more characters so the input record was padded with a blank.  The FORMAT effectively turned into: 100 FORMAT (I2,’ ‘,I2,’/',I2) for subsequent calls!  The fix I recommended was to use a separate FORMAT for the READ, rather than sharing the earlier one. Well, that’s enough for today.  Happy New Year, everyone!

DCT, or Down the Rabbit-Hole (Part I, Correlated)

Until now we have discussed only one aspect of video encoding, namely how to eliminate time redundancy. It’s time to talk about the space, or frequency redundancy, and to find out “just how deep the rabbit hole is”. The concept of time redundancy may appear rather vague, but it contains a simple but very important idea of strong correlation among adjacent pixels. In other words, if you pick a random pixel in the image, there is a high probability that its color will match or come very close to that of adjacent pixels. Such statistical relationship breeds information redundancy, as each next pixel contains information on its neighbors. In order to achieve compression, this redundancy has to be eliminated. Let us consider the idea of correlation using a simple example. Let’s take 8 subsequent luminance samples with the following values: This is a real example that provides a nice demonstration of how close the values of adjacent samples are. Let’s extract from each sample the value of the previous sample. In such easy way we have managed to capture the correlation between the values, and considerably reduced the number of bits required to encode them. Repeating the transformation clearly does not reduce the data values. This proves that decorrelation did take place indeed. Please note that all the information was concentrated in the first element. This leads us to the idea that the transform is compact, that is, most of the energy is concentrated in a small number of coefficients. Next time we will build a two dimensional transform that would be efficient, compact, and reversible.

Outbrain Raises $35M In Series D Funding For Content Discovery Platform

Today, content discovery platform Outbrain  is announcing it has secured $35 million in Series D funding in a round led by Index Ventures. Existing investors Carmel Ventures and Lightspeed Venture Partners also participated in the round. As a part of the deal, Dominique Vidal, partner at Index Ventures, will join the company’s Board of Directors. The New York-based startup helps online publishers recommend additional content to their site’s readers through a website widget technology. The system combines contextual analysis, collaborative filtering (people who like X, also like Y) and personalization to determine which links to show readers at a given time. The personalization of the links shown is based on cookies, but is not tied to any personally identifiable information, nor is the data collected by one publisher shared with another. You see Outbrain’s technology in action everywhere, but you probably don’t realize it. Its “recommended reading” widgets often show up at the bottom of a publisher’s page as sections titled “You might like:,” “We Recommend,” and “Elsewhere on the Web,” for example. The service suggests two types of links to readers: inbound links to the publisher’s own content, which are not paid for, and outbound links to content on other sites which are paid for by Outbrain’s buyers, and involve a revenue share. Currently, publishers using Outbrain’s technology include CNN, Fox News, Future Publishing, Hearst, Hachette Filipacchi Media, IPC, Mashable, MSNBC, Reuters UK, Sky News, Slate, Trinity Mirror and Ziff Davis. The company also works with brands and agencies like Digitas, Mindshare, P&G, Allstate and American Express. Outbrain’s recommendations are now viewed more than 3.5 billion times per month, generating over 200 million monthly clicks, the company reports. A growing number of those publishers are now using Outbrain’s newly launched mobile product, says Outbrain CEO Yaron Galai. Even though it’s only a few months old, mobile now accounts for 5%-10% of Outbrain’s business. With the Outbrain for Mobile widget, publishers can now add the same “recommended” sections to their mobile sites which link exclusively to other mobile-optimized content. Video is another newer focus for the company, based on publisher demands. For publishers, explains Galai, “content is content” and they want one system to recommend it all. The video recommendation technology has been soft-launched and is live now on some partner websites. A public announcement will follow shortly. Going forward, Outbrain wants to continue to expand to any platform where people are consuming content, says Galai, a statement which hints at the still untapped e-reader market. As a result of this additional funding, which brings Outbrain’s total raise to $64 million, the company will focus on investing in both business development and global expansion. Outbrain had already been working towards these goals through its acquisition of Surphace from AOL (disclosure: TechCrunch is owned by AOL) and the opening of new offices in London , Paris and Hamburg . Going forward, there will be further moves into Europe as well as Asia.

Life in Motion: Estimation Library (Part I, Served with a Clockwork Fish)

Can you admit that you like watching various TV series, Hollywood blockbusters and DVD or Blu-ray bestsellers? All those gruff doctors lost in sunny southern California among desperate housewives? To a certain degree, perhaps we are all addicted to television and the motion pictures! We should then thank ourselves for the blessings of civilization: multimegabit channels, multi-terabyte drives, multi-inch monitors, and multi-core processors. Today, a recording of a TV series might fit into 500MB of space; what a trifle! Although just 10 years ago a system administrator might have blown a whole office to bits for the space to fit a single file like that in. Life is getting better but progress is unable to keep up with consumption, as usual: Terabytes and Megabits still cost a lot. Let’s go back to our TV show season: 0.5GB per series, 40 minutes, 30 frames per second: and a DVDRip creates a cost of about 36GB of pure video (btw, could you validate or argue my calculations?) . That’s a lot of used storage space! You’ll hardly find free disk space for the video of even a couple of seasons – go ahead and check it right now. And that’s not considering the download time. Fortunately, video encoding comes to the rescue. Encoders can turn 36GB of video into 0.5GB. That is, they can compress the information about 72 times. How is it possible to do this? Let’s try to figure it out. The principles of video data compression are based on the human perception of video sequence (Human Visual Sense, or HVS). It’s not that hard to explain these principles in words: 1) Delete all “redundant” information, that is, the details of the image which aren’t ever going to be noticed anyway; and, 2) Find recurrent information in the video stream and minimize duplication. The second item involves the so-called “statistical redundancy.” The HVS standard is normally divided into both space and time redundancies. Space redundancy includes considerable areas of the image with virtually the same pixels, such as the sky. Such areas are compressed using the principles close to JPEG compression for photos. The situation with time redundancy is somewhat more complicated. Let us recall that the human eye can see about 25-30 frames every second. How close are these frames to each other? Unless the frames feature a complete change of scene, they are usually fairly close. Therefore, there’s no point in coding each frame separately. To minimize the volume of data stored (transmitted, processed, and so on) some block video encoding standards, MPEG4 in particular, code only the residual differences between a block and the next block in the keyframe. From the encoder internals point of view, there are two main functional units. The first is the Discrete Cosine Transformation (DCT), which allows the removal of the space redundancy of a static image. The second one is Motion Estimation (ME) which, as described above, reduces the time redundancy of subsequent video frames. When the encoder gets a video input, its motion estimation and motion compensation reduce the volume of information that is identical for two adjacent frames. Then the DCT and the quantization minimize identical information within the frame. The quantization ratios, the transformed data together with the motion vectors are all fed into the entropy encoder for final compression. The better the motion estimation is, the less work for the DCT. That is to say, better motion estimation facilitates better video compression. It looks simple, doesn’t it? However, there are some hidden barriers and reefs, which we will now try to deal with. Before the deep dive, can you guess how much redundant information is in this video (a cool movie, incidentally)? Let’s continue our theoretical digression. You can use various methods to do motion estimation. The so-called pixel-recursive methods allow calculation of motion vectors for each separate pixel. It’s also worth mentioning the Phase Plane Correlation technique, which generates motion vectors based on correlation of the current frame with the reference one. Yet the most popular algorithm is the Block Matching Algorithm (BMA). The BMA calculates the motion vector not for separate pixels, but for pixel blocks. Objects in a video are in fact pixel groups; therefore pixels within the block ultimately have the same motion vector. This helps to considerably reduce the amount of calculation and to get more accurate results. An illustration of the BMA algorithm is provided in picture above. The current frame is split into pixel blocks, and we’re going to estimate the motion of each block individually. The idea is to find the most similar block to a given block in the reference frame. Then we need to calculate a motion vector, a shift of the block with respect to its “original” location. Thus, motion vectors represent horizontal and vertical shift of the current pixel block by x and y: In this equation I is the intensity of the pixel in position x on frame n, and d is the shift (motion vector) with respect to the initial position on frame n+1. Various pixel block matching criteria (Displaced Frame Difference, or DFD) can minimize the function: The two most popular are: Sum of Square Error (SSE): Sum of Absolute Difference (SAD): The SSE function is known for accurate matching, but is more computationally intensive. The SAD function is not particularly good at matching, but requires less computation, so it is often used in BMA algorithms. The functions also deal with criteria such as cross correlation and maximum number of matching pixels. The functions select the reference pixel block from the so-called search area. The search area determines the boundaries for the motion vectors and limits the number of candidate reference blocks to review. The height and width of the search area depend on many factors, such as motion speed and computational complexity. A wider search area requires more computation due to greater number of candidate blocks. The general practice is to select a wider area since horizontal motion in video happens more frequently. Search area may be also adapted to the motion type. The Full Search (FS) algorithm is a BMA-type algorithm that processes every possible pixel block within the search area and finds the best possible motion vector. The method provides the best possible residual difference for video compression by the cost of extra computational workload. It is the best possible algorithm for matching blocks identification, and luckily, it fits very well with multithreaded GPU architecture. Now it is time to get down to practice! We’re going to develop a library for motion estimation that would be convenient to use and, would take into account the specifics of various video encoding standards. We’ve got to create an interface that would assume the existence of various algorithm implementations based on various technologies, such as software-based and GPU-based implementations. Well, that was complicated! Before we jump into the code, let me ask: when you look at the video above, can you see the handle knob? What do you think about its behavior from the motion estimation perspective? Will the motion vectors trace the handle knob movement trajectory, or do you think it is still too complicated for modern algorithms? The library interface should consider various aspects of the algorithm and the data. We know that modern video encoding standards are block-based, so that each frame is divided into macroblocks (that are also split into various powers of two). We also know that there are several types of motion estimation algorithms, and their implementations differ considerably. Standards determine the method for estimation of frames interpolated by a noninteger number of pixels. The input consists of a pure frame for motion estimate and reference frames to be used for estimating the source frame. The expected output consists of motion vectors with linked SAD values. We are going to create an interface considering all these details. Please note that we’re going to use the Intel® Integrated Performance Primitives library because it contains lots of useful and very fast functions, including, in particular, the interpolation function and SAD calculation function. #if !defined(__HARDWARE_ME_H) #define __HARDWARE_ME_H /* this implementation uses IPP defined types and structs */ #include #if defined(__cplusplus) extern “C” { #endif /* defined(__cplusplus) */ /* Declare the types used in the accelerated ME object */ typedef struct _HW_ME_HANDLE *hw_me_handle_t; enum { HW_ME_MAX_SAD = 0×7FFFFFFF, HW_ME_MAX_LENGTH = 0×7FFFFFFF, HW_ME_SLEEP_TIME = 5 }; typedef enum eHWMECodecStandard { HW_ME_MPEG2 = 0, HW_ME_MPEG4 = 1, HW_ME_VC1 = 2, HW_ME_H264 = 3 } eHWMECodecStandard; typedef enum eHWMEAlgorithm { HW_ME_RESIDUAL = 0, HW_ME_TRUE_MOTION = 1, } eHWMEAlgorithm; typedef enum eHWMEType { HW_ME_WHOLE_PIXEL = 0, HW_ME_HALF_PIXEL = 1, HW_ME_QUARTER_PIXEL = 2 } eHWMEType; typedef enum eHWMEImageStructure { HW_ME_FRAME = 0, HW_ME_TOP_FIELD = 1, HW_ME_BOTTOM_FIELD = 2, HW_ME_MIXED = 3 } eHWMEImageStructure; typedef enum eHWMEDivType { HW_ME_DIV_16X16 = 0, HW_ME_DIV_16X8 = 1, HW_ME_DIV_8X16 = 2, HW_ME_DIV_8X8 = 3, HW_ME_DIV_8X4 = 4, HW_ME_DIV_4X8 = 5, HW_ME_DIV_4X4 = 6 } eHWMEDivType; typedef enum eHWMEPredictionType { HW_ME_BACKWARD = 0, HW_ME_FORWARD = 1, HW_ME_INTRA = 2, HW_ME_BIDIRECT = 3 } eHWMEPredictionType; typedef struct HW_ME_RANGE { Ipp32s left; Ipp32s right; Ipp32s top; Ipp32s bottom; } eHWMERange; typedef struct HW_ME_PARAMETERS { Ipp32u structSize; /* (Ipp32u) size of the current struct */ IppiSize imageSize; /* (IppiSize) size of processed images */ Ipp32u maxNumRef; /* (Ipp32u) maximum number of available references */ IppiPoint maxVector; /* (IppiPoint) maximum allowed vector */ eHWMEDivType minSubblockSize; /* (eHWMEDivType) minimal subblock size */ IppiPoint maxSubBlockVectorDif; /* (IppiPoint) maximum vector difference between subblocks of macroblock */ eHWMECodecStandard codecStandard; /* (eHWMECodecStandard) interpixel interpolation standard */ eHWMEType meType; /* (eHWMEType) type of interpolation */ eHWMEAlgorithm algType; /* (eHWMEAlgorithm) algorithm type */ IppBool strictWithinFrame; /* (IppBool) is it allow to be outside frame or not */ } HW_ME_PARAMETERS; typedef struct HW_ME_IMAGE { eHWMEImageStructure imageStructure; /* (eHWMEImageStructure) current image structure */ Ipp8u *pPlanes[3]; /* (Ipp8u *([])) array of pointers to image’s planes */ Ipp32s imageStep; /* (Ipp32s) image step */ } HW_ME_IMAGE; typedef struct HW_ME_MB_INFO { eHWMEDivType mbDiv; /* (eHWEDivType) macro block fragmentation */ eHWMEDivType subblockDiv[4]; /* (eHWEDivType) sub macro block fragmentation */ eHWMEPredictionType predType[4]; /* (eHWMEPredictionType) macro block prediction types */ Ipp32s minSAD; /* (Ipp32s) minimal found SAD for the macroblock */ Ipp32u ref[2][4]; /* (Ipp32u [][]) reference list for macro block */ IppiPoint mv[2][16]; /* (IppiPoint [][]) motion vector list */ } HW_ME_MB_INFO; typedef struct HW_ME_INFO { HW_ME_MB_INFO *pMbInfo; /* (HW_ME_MB_INFO *) pointer to macroblock info store */ Ipp32u numFrameRefs[2]; /* (Ipp32u) number of references in reference array */ Ipp32u refFrameList[2][16]; /* (Ipp32u [][]) reference list for each direction */ Ipp32u numTopFieldRefs[2]; /* (Ipp32u) number of references in reference array */ Ipp32u refTopFieldList[2][32]; /* (Ipp32u [][]) reference list for each direction */ Ipp32u numBottomFieldRefs[2]; /* (Ipp32u) number of references in reference array */ Ipp32u refBottomFieldList[2][32]; /* (Ipp32u [][]) reference list for each direction */ } HW_ME_INFO; /* Initialize the accelerated ME object */ IppStatus InitializeHWME(const HW_ME_PARAMETERS *pHWMEParams, hw_me_handle_t *pHandle); /* Stop all ME operation and release the accelerated ME object */ IppStatus ReleaseHWME(hw_me_handle_t handle); /* Add a reference to the accelerated ME object */ IppStatus CopyHWMEReference(hw_me_handle_t handle, const Ipp32u refIdx, const HW_ME_IMAGE *pImage); /* Do a accelerated ME */ IppStatus DoHWME(hw_me_handle_t handle, HW_ME_INFO *pInfo, const HW_ME_IMAGE *pImage, void **ppEvent); IppStatus WaitHWMEDone(void *pEvent); #if defined(__cplusplus) } // extern “C” #endif /* defined(__cplusplus) */ #endif /* __HARDWARE_ME_H */

Tor for Windows 1.3.27

Tor is a toolset for organizations and people that want to improve their safety and security on the Internet. Using Tor can help you anonymize Web browsing and publishing, instant messaging, IRC, SSH, and other applications that use the TCP protocol. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features. Communications are bounced around a distributed network of servers, called onion routers. Instead of taking a direct route from source to destination, data packets on the Tor network take a random pathway through several servers that cover your tracks so no observer at any single point can tell where the data came from or where it´s going. This makes it hard for recipients, observers, and even the onion routers themselves to figure out who and where you are. Tor´s technology aims to provide Internet users with protection against “traffic analysis,” a form of network surveillance that threatens personal anonymity and privacy, confidential business activities and relationships, and state security. Homepage : https://www.torproject.org/ Download : tor-browser-1.3.27_en-US.exe File Size : 16.59MB Incoming search terms for the article: download tor tor-browser-1 3 27_en-US

DBeauty

DBeauty is a relationship-oriented Database Browser. Provides insight into both the data and the correlation between the rows. Features 1. See the contents of any SQL database 2. Navigate through the database by following foreign-key-based or user-defined relationships 3. Automatic detection…

ModemWatcher

ModemWatcher provides a front-end for ADSL Modems/Routers showing statistics like “Sync Speed” and “Downstream Noise” – the two key indicators for a good ADSL download experience. Because the data interface varies across models, only those shown are currently supported. To…

BAMStats

BAMStats is a utility for extracting coverage, and other data, from BAM format mapping files, and generating descriptive statistics of that data. 1. Installation Unpack zip archive to a convenient location. Zip archive contains two executables and a lib directory containing third-party jar files…