Intro

Media delivery technology has been changing radically over the past decade and with broadband getting broader and broader the shape of things to come in the future could be very interesting. Currently most broadcasting companies stream their TV or radio contents to a website or more recently to mobile and tablet devices.

This White paper discusses the issues faced with streaming and the way forward.

Since streaming video to mobile devices is a relatively new concept I have described the video streaming process – technology overview and best practices for video compression (encoding) and decompression (decoding), high and standard definition (HD and SD) video, progressive and interlaced video, analog and digital video, and common settings to encode video for live streaming using the ITU-T H.264 / MPEG-4 in detail. If you’re looking to just get started with the technology you can check out my other blog on the subject.

What is video streaming?

Video streaming is the act of transmitting compressed (typically) video across a private or public network (like the Internet, a LAN, satellite, or cable television) to be uncompressed and played on a computing device (such as a TV, smart phone or computer).

Why compress video?

Video is compressed in size to save transmission bandwidth and storage space. Compression reduces original video information and removes redundancies. Uncompressed video requires a tremendous amount of bandwidth to transmit across a network or space to store.

The table below illustrates the advantages of compression.

TABLE 1. UNCOMPRESSED VS COMPRESSED VIDEO

It compares the streaming bit-rate of uncompressed video with that of compressed video assuming a  YUV 4:2:0 color space for SD video and YUV 4:4:4 color space for HD video, both using a 8-bit color depth. An H.2641encoder can achieve a wide range of compression ratios depending on a number of factors, including the video itself and target bit rate. H.264 is a standard for video compression. The ITU-T (International Telecommunications Union) and ISO/IEC MPEG (Motion Picture Experts Group) standards bodies jointly defined and maintain the standard. It is occasionally referred to as MPEG-4 Part 10 or AVC (Advanced Video Coding).

What are the peculiarities of live streaming?

Streaming video can either be live or VoD. With live streaming, source video is captured and encoded in real-time. This requires more computer processing, network resources and efficiency (lower latency during capture, encoding and stream delivery) compared to VoD streaming. With VoD streaming, source video is previously encoded and then streamed removing the need to capture, preprocess, convert and encode the video in real-time.

VoD encoding should utilize better (but more time consuming) encoding techniques (such as two-pass Variable Bit Rate) that increase quality whenever possible. These encoding techniques are typically not used for live streaming since the extra encoding time increases overall latency (delay). Since the size and location of VoD files are known, delivery of VoD files across a computer network can be optimized to further reduce delivery latency.

What is the video streaming process and what resources are required to stream?

The video streaming process consists of a number of steps and requires

TABLE 2. VIDEO STREAMING PROCESS AND REQUIREMENTS

What are the network and bandwidth requirements for live streaming?

A customized streaming platform, well that is if you architecture one yourself, won’t require the reconfiguration of existing networking infrastructure devices (routers, switches and gateways) or for security controls to be changed or bypassed. Since software encoders use RTMP, the ports Flash uses (80, 1935, 443) must be open on infrastructure routers and gateways. In most corporate environments this is already the case since many software applications used by businesses include Flash. HTTP streaming (Apple HTTP D Streaming, Adobe Flash Dynamic Streaming, Microsoft Smooth Streaming with Silverlight) does not have this requirement unless firewall packet inspection inhibits smooth traffic flow of multimedia packets. That must be addressed.

Minimally, it is recommended that between 10 Mbps and 20 Mbps sustained upload network bandwidth be available at an encoding location to stream a single high quality 512×384 or 768×432 resolution video. More bandwidth is required to encode multiple streams of different quality to allow users with varying bandwidth conditions to watch a stream that best matches their local conditions.

At the receiving (or viewing) location, that same amount of sustained download bandwidth (650 Kbps to 1 Mbps) is required by viewers to avoid excessive buffering, choppiness, dropped frames, and freezing of the video stream. Viewers should minimize the number of running applications (such as virus checkers) on their devices so the maximum amount of computing resources (CPU cycles and memory) can be allocated to the timely decoding of the video stream. Play back devices must be powerful enough to decode the video stream at the broadcast bit rate. Extensive buffering and dropped frames can otherwise result.

When streaming over the Internet to viewers across the country or world, a Content Delivery Network (CDN) – such as Influxis, Primcast, LiveStream – should be used. A CDN allows scalable delivery to tens of thousands (even hundreds of thousands) of viewers with no intervention required at the encoding location.

What is a CODEC?

A CODEC(COder-DECoder or COmpressor-DECompressor) is hardware or software that compresses (encodes) digital data (like digital video or audio) and uncompresses (decodes) the data back to its original form. A CODEC collectively refers to two components – an encoder and decoder.

CODECs used for live streaming must be very efficient in order to complete the encoding and decoding process fast enough to keep up with the rate of input video, minimize the size of the compressed output video, minimize latency and play back decoded frames fluidly. Common video CODECs are H.264, VP 8 and VC-1.

Encoders can be lossy or lossless. A lossless encoder reduces, but does not loose, original audio or video information during the compression process. Uncompressed source video matches the original exactly but less space is used to transmit or store the compressed video. The reduction (and space savings) however is no where near as significant as that provided by lossy encoding. A lossy encoder destructively reduces original video and audio information during the compression process substantially. Modern lossy encoders, like H.264 or HE-AAC V2, can be implemented and configured so it is difficult for most people to observe a difference between source video and uncompressed video. The purpose of lossy encoders is to save considerable amounts of space while maintaining acceptable quality. Compression artifacts (jagged edges, moire patterns, motion blur, loss of detail) result when a lossy encoder destructively reduces video information so much so it becomes easily discernible to a viewer after the video is uncompressed.

The challenge is to configure a lossy encoder to provide an acceptable level of quality while using an acceptable level of bandwidth or space. This balance is not always easily attainable since lossy encoders aren’t aware when the reduction process starts to do more harm then good.

Encoders and decoders can be implemented in hardware (a chip or set of chips within a computing device) or software, such as an application running on a computing device, e.g. Adobe’s Flash Media Encoder Live or the open source x264.

To be accurate, H.264 is a decoding standard. Software or hardware encoders used in combination with H.264 compliant decoders must encode source video so that any H.264 compliant decoder can decode it without issue.

What is a video frame?

Digital video consists of a sequence of pictures (frames) of video images in a particular aspect ratio (width/height) representing the source video at a point in time. Each frame consists of a set of pixels. A pixel is also known as a “sample.”Each pixel contains information representing the color (e.g. red, green, blue or cyan, magenta, yellow and black) intensity of the video at a particular location in the frame. The number of pixels in a frame depends on the frame’s resolution. Image 1 is an example of a video frame divided into groups of 8×8 pixels.

What is Standard Definition video?

SD video is any video that is not HD. One of the most common SD video modes is:

• 480i – 720×480 resolution @ 4:3 aspect ratio @ 24 frames per second (fps); there are 480 vertical lines of resolution in each interlaced video frame.

DVDs and non-HD television use 480i.The highest resolution SD video frame has a height of 576 lines.

What is High Definition video?

HD video is any video that is not SD or any video with a frame height greater than 576 lines. Two of the most common HD video modes (and what is popularly considered HD) are:

• 720p – 1280×720 resolution @ 16:9 aspect ratio @ 25/30/60 frames per second (fps); there are 720 vertical lines of resolution in each video frame; and

• 1080i/p – 1920×1080 resolution @ 16:9 aspect ratio @ 25/30/60 frames per second (fps); there are 1080 vertical lines of resolution in each video frame.

It’s important to recognize that resolution alone determines if a video is HD or SD. Not quality. Not frame rate. Not bit rate.

What is progressive and interlaced video?

SD and HD video is either “progressive” or “interlaced.” Progressive HD video consists of frames with each and every pixel of a video image. It’s a complete picture of all lines in a video image. Someone looking at an individual progressive frame would see an entire video image.

The ‘p’ in “720p” standards for “progressive.” Interlaced HD video consists of fields with 1/2 the pixels of a video frame. It’s a picture of the video frame containing every other vertical line in the frame – the even lines or the odd lines. Someone looking at an individual interlaced field would see 1/2 a video frame. Two interlaced fields are combined (the even and odd lines) to form one complete video frame with all its pixels. The ‘i’ in “1080i” standards for “interlaced.”

If an interlaced video mode mode is followed by a number such as 1080i60, the number stands for the field rate. Dividing by two gives the frame rate. E.g. 1080i60 has a frame rate of 30. If a progressive video mode is followed by a number such as 720p30, the number stands for the frame rate. E.g. 720p30 has a frame rate of 30, 720p60 and 1080p60 have a frame rate of 60. Streamlane can encode and stream interlaced or progressive video.

What affects the quality of streaming video?

Bit rate, color depth, and production factors (such as proper lighting) affect video quality. Resolution (if the video is HD or SD) does not. An SD video stream may look better than an HD video stream.

HD resolution video can be very low quality for a number of reasons, one being insufficient bit rate to transmit enough information to “fill” HD video frames with enough detail at an acceptable rate.

Here are some key factors that affect the quality of streaming video:

Quality of Original Source Video. Source video should be digital (preferably SDI) at the highest frame rate and resolution possible.

Input video resolution. The aspect ratio of a video can positively or negatively influence the efficiency of an encoder. The video frame’s height and width should both be wholly divisible by 16 if possible, or wholly divisible by 8 if not.

Video aspect ratio. The input video aspect ratio should match the target output video aspect ratio. The most common aspect ratios are 16:9 and 4:3.

Content of the source video including the amount of motion and proper contrast. Motion requires more information to represent accurately thus an encoder has to use more bandwidth to compress motion. Less motion (changes between or within video frames) requires less information and thus less bandwidth. Therefore, do not include unnecessary motion in source video. The background and foreground subjects in the video should be lit and contrasted properly.

Compatibility of devices. The devices used to process and render final broadcast contents need to be compatible with the encoding hardware. Minor incompatibilities can lead to loss of quality or even complete loss of audio or video.

Configuration of the encoder. The number of I-frames, B-frames, Variable or Constant Bit Rate Encoding, CAVLAC or CABAC, etc.

Streaming bit rate. Streaming video is like water rushing through a pipe. The bigger the pipe, the more water that can flow through it. An encoder fills a pipe with compressed video. Therefore, the larger the bit rate the more video information an encoder can compress. This additional information allows the video to be higher quality. The quality difference between 320 Kbps and 650 Kbps video is quite evident. However, a diminishing point of return exists so adding more bandwidth to an already high quality 320×240 video stream may not increase perceptible quality.

An end user must have the ability to support the higher bit rates required with the higher resolution. Presently the encoders at the MCR are streaming contents between 500 Kbps and 1.5 Kbps.

What are CBR and VBR?

Most encoders offer Constant Bit Rate (CBR) or Variable Bit Rate (VBR) encoding. VBR compresses video to a variable bit rate after analyzing video content to optimize quality and bandwidth use. CBR compresses video to a constant bit rate regardless of content. CBR helps ensure smooth playback without interruption since the rendering player doesn’t have to deal with bit rate fluctuations. CBR by default prevents bandwidth spikes in compressed video while VBR can be configured to compress to no greater than a maximum bit rate which will also prevent bandwidth spikes.

If the source video has little or no movement or change over time, CBR can waste bandwidth encoding redundant or static information that is not needed to maintain quality. This is where VBR excels. VBR uses bandwidth for more detailed or complex aspects of the video or in areas with high motion content instead of wasting it on static or less detailed imagery. However, VBR takes longer to compress video compared to CBR.

Despite CBR not using bandwidth as efficiently as VBR, CBR should be used for all live streaming applications to minimize encode latency. VBR is (and should) be used when creating VoD since this work typically doesn’t have a time constraint. When using VBR, set an average and maximum bit rate to avoid extreme bandwidth peaks in compressed video. Bandwidth spikes can cause extensive buffering and dropped frames for end viewers.

What is multi-pass encoding?

An encoder needs at least one pass through source video to analyze and compress it. The quality of compressed video (and how efficiently bandwidth is used) can be improved by allowing an encoder to make additional passes through source video to perform a more detailed analysis. This technique, known as multi-pass encoding, can be applied to both CBR and VBR encoding.

But (of course) there is a tradeoff with multi-pass encoding: speed. Additional passes through the source video increases overall encoding time (two-pass encoding typically doubles it) which may not be problematic for VoD, but can be problematic for live streaming where low latency may be required. Therefore, multi-pass encoding is not usually used to encode live streaming.

Two-pass encoding typically produces a noticeable increase in quality with most source video at the expense of twice the encoding time. Adding additional passes usually does not cause a discernible increase in quality or more efficient use of bandwidth. Once again, a factor of diminishing encoding return exists.

How powerful of a device is required to play streamed video?

A computing device must decode compressed video fast enough for fluid video playback. High bit rate compressed video requires significant processing power and memory to decode and play. Therefore, if viewers have limited processing power, adjustments must be made to the encoding settings to compensate. This is partially addressed by dynamic bit rate streaming (described later).

The power required varies with the complexity of the compressed video. A high motion 720p60 stream encoded at 1.5 Mbps requires a much more powerful rendering device compared to a 320×240 24 fps encoded stream at 350 Kbps.

Due to the amount of computational power required to decode and play streaming video, battery consumption in mobile devices also increases. Thus, care should be taken when determining target bit rates, frame rates and resolution for mobile devices.

Why is frame rate important and what are macroblocks?

The frame rate must reasonably convey sense of movement in the video source content. If the content contains fast-moving video, use a higher frame rate. As frame rate is increased, the frame size of the video may need to be reduced to retain reasonable visual quality for a specific bit rate. 24 fps is the cinematic frame rate. 29.97 (30) fps is the television and DVD frame rate. ESPN uses a frame rate of 60 to convey motion in sporting events.

Most video encoders including H.264, define each video frame as a series of pixel (e.g. 16×16) blocks. Each block is called a macroblock. Encoders compress and encode video by operating on differences between macroblocks in each frame (intraframe) and between previous and successive frames (interframe). This is known as spatial and temporal encoding respectfully.

By using frame resolutions that evenly distribute a macroblock (and not subportions), the video encoder can more easily encode the video source (which is more easily decoded during playback). Video encoders such as H.264 and VP 8 perform best when the frame width and height use multiples of 16. This allows macroblocks to be easily and efficiently created from the source pixels. For the best image quality and playback, always use width and height dimensions that are each wholly divisible by 16 (best), 8 (better), or 4 (good).

The width and height of video destined for computer playback should be kept to a square pixel aspect ratio. Any non-square pixel aspect video should be adjusted for computer playback. For example, source with a 720 by 480 frame size can be resized during the encoding process to 640 by 480, 480 by 360, 320 by 240, 160 by 120, and so on. Similarly, content with a 1440 by 1080 native non-square pixel frame size should be resized to 1920 by 1080, 1024 by 576, 768 by 432, 512 by 288, 256 by 144, and so on.

What is a keyframe?

An encoder generates a sequence of video frames of different types, with each type having a specific purposes. For H.264, these frame types are:

• I-frames (intraframes, a.k.a. keyframes) are self-contained video frames that can be independently decoded without reference to other frames. They are the least compressible and contain the most information.

• P-frames (predictive frames) hold only the differences between the current frame and a previous frame. They are more compressible than I-frames but require I-frames to decode.

• B-frames (Bi-predictive frames) are a second level of prediction that hold differences between the current frame and both a preceding frame and subsequent frame. They are the most compressible and require I-frames to decode.

A keyframe (I-frame) is used as a starter frame, drawing the initial video. Subsequent P-frames and Bframes store only the changes in the video frame relative to the previous keyframe. A group of pictures (GOP) is the number of frames from one I-frame to another. In one GOP, there is a full I-frame and a number of frames predicting the motion associated with that full frame. Higher levels of compression (less bandwidth for a given clip of source video) are achieved through larger GOP sizes and deeper frame prediction (i.e., using an IBP compression sequence instead of an IP sequence). However, deeper frame compressions require more time to encode, resulting in higher latencies. Note that these parameters are typically established during system setup and not changeable during live encoding.

Performance tuning

Low bandwidth/high latency – If a tighter bandwidth budget exists, select a deep compression (IBBP) with a large GOP size (~40-200); latency will suffer to some extent.

High bandwidth/low latency – If 100% accuracy and immediacy is required, select low compression (Iframe only, or IP) and a very small GOP size (~10-40).

Keyframe interval

The frequency of keyframes (I-frames) in the video can be specified in the encoder. This is known as the keyframe interval.

Keyframes are best inserted in multiples (or fractions) of the compressed file’s frame rate. For example, if a frame rate of 15 fps is used, use a keyframe interval of 150 frames (one keyframe will be generated every 150 frames). Some encoders can be provisioned to select automatic or natural keyframes, which essentially tell the encoder to make a keyframe whenever enough of the video frame has changed. The keyframe interval can greatly affect the quality of the overall video clip. If the encoder creates too many keyframes for an allocated video bit rate, the visual quality degrades. If too few keyframes are created, one loses the ability to start the playback of the video or seek or scrub the video very smoothly or accurately.

Keyframes and Dynamic Bit Rate Streaming

The advent of Dynamic Bit Rate Streaming in Flash Media Server 4.5 (and Flash player 10), Microsoft’s Internet Information Service (IIS) Smooth Streaming (and Silverlight player) and Apple’s HTTP Streaming, allows the quality of an end user’s viewing experience to be adjusted continuously based on the end user’s bandwidth conditions.

An end user’s video player constantly evaluates available end user bandwidth and instructs the streaming server to stream at a bit rate that can be supported by the end user’s available bandwidth. A player autonomously switches between individually encoded higher and lower bit rate video streams based on the available bandwidth. There can be many available streams from which the player can choose—the number is dependent on the encoding system, media server and bandwidth availability at the source and destination.

In order to facilitate smooth switching between streams, two provisions must be made when encoding.

1. Keyframes must be encoded at a much higher ratio to P-frames compared with previous encoding recommendations (e.g. one every 150 frames). A 25% (one out of every four) ratio to P-frames is recommended. Some even advise a 50% (every other frame is a keyframe) ratio.

2. All streams must be encoded using the same keyframe ratio.Implementing these provisions will ensure stream switching is done quickly and smoothly with no noticeable delay and/or staggering.

What are encoding profiles and levels?

The H.264 standard defines seven profiles to serve different applications, categorized by quality verse computational cost. The most common are Baseline, Main and High.

Baseline requires the lowest amount of processing power but provides the least efficient compression. It is typically used for video conferencing, security cameras and mobile devices such as iPhones. Main provides a medium level of quality for a slightly higher computational cost. The High profile provides the best quality because the encoder can use the widest range of encoding techniques provided by the H.264 standard but requires the highest processing power to decode. Some devices don’t even support it (e.g. iPhone). It was originally intended for Blu-ray devices but is gaining in popularity as computing devices become ever more powerful. H.264 has 11 levels or degree of capability to limit performance, bandwidth and memory requirements. Each level defines the bit rate and encoding rate in macroblock per second for resolutions from SD to HD. The higher the resolution, the higher the level required.

What is CAVLC and CABAC in H.264?

The Main and High profiles of the H.264 codec support encoding parameters such as B-frames, reference frames, Context-Adaptive Variable-Length Coding (CAVLC) – the default – and Context-Adaptive Binary Arithmetic Coding (CABAC) entropy encoding. These parameters can greatly improve the visual quality of a given video clip at any bit rate.

CABAC is more processor intensive than CAVLC. However, one typically sees a marked improvement in the visual quality of H.264 content with CABAC.CABAC creates more latency in live video streams as opposed to CAVLC so use CAVLC when real-time delivery is a concern.

How to reduce streaming latency?

Minimizing H.264 encode latency. Some techniques we use to minimize latency introduced by H.264 encoding:

• Use CAVLC not CABAC

• Use a low GOP such as 3

• Don’t use B-frames or keep the B-frames very low

• Use CBR, not VBR

• Use the Constrained Baseline Profile

• Ensure all CPUs and all cores on each CPU are used by the H.264 encoder, use the most powerful hardware available to run a software encoder and allocate as much processing power to the encoding software as possible by minimizing the use of other software applications

• Use a hardware H.264 encoder (this can be costly)

• Reduce motion in the video source, subjects should wear clothes without brightness extremes and fine patterns; ensure the scene and subjects are well lit; see [7] for more information

• Use multi-bit rate streaming

Minimizing transmission latency. Some techniques that we adopt to minimize latency introduced by transmission:

• Ensure there is more than enough sustained bandwidth at the encode site

• Use a CDN or a peer-to-peer UDP based stream distribution technology

• Use a point to point dedicated network link between the encode and decode sites; this can be cost prohibitive and impractical if there are many viewers worldwide at unknown viewing locations

• Prioritize streaming traffic over other types of network traffic on a private LAN or VPN

• Ensure streaming ports are open on network infrastructure devices on a private LAN or VPN

• Separate streaming traffic onto a dedicated VLAN in a private LAN

• Do not stream over a wireless network since data transmission collisions can be more frequent, and more adverse, than over a wired network

Minimizing H.264 decode latency. Some techniques  we use to minimize latency introduced by decoding:

• Ensure all CPUs and all cores on each CPU are used by the H.264 decoder, use the most powerful hardware available to run a software decoder and allocate as much processing power to the decoding software as possible by minimizing the use of other software applications

• Reduce the frame rate (to 12 or 15); take care not to degrade quality with a low frame rate.

1. http://colorzilla.com/gradient-editor/

Using images to support gradients in your code is history, but writing your code manually can be a bit of work. So here’s the best GUI approach which gives you the complete code black as you visually adjust the gradient.

2. http://css3please.com

If gradients are not your only concern, this is the way to go.

3. https://browserlab.adobe.com/

A great place to compare how your CSS3 and HTMl 5 elements render on older browsers. It offers a two up view for comparison. This one’s particularly important for coders working on Mac. You can’t go live with your website without testing it on IE.

4. http://html5boilerplate.com/

Loads up modernizer, jQuery and other essential libraries and provides starting templates to render your site consistently across most browsers. A lighter version of the application would be -

http://html5reset.org/

And if you’re just looking to clean things up without the overhead of templates, I recommend you use this -

http://necolas.github.com/normalize.css/

Just download the file and link it to your project root.

 5.  http://kuler.adobe.com

If you’re running our of creativity with a color scheme for your website, this is the site to hit. You can weak one of the existing themes to get started.

 6. http://texturise.com/

A great place to morph images and generate patterns. They offer a bunch of gradients ready-to-use off the shelf.

7. http://repperpatterns.com/

Take a picture and combine it into a seamless pattern. This is a paid application though.

8. http://fontsqirrel.com/

If you’re picky about typography, well you should be, and still not using typekit.com, you need to rethink. However if you’re a control freak and don’t believe in calling remote fonts  check this site out. You can also check out -

     http://fontspring.com

You can use the CSS generator for multiple formats or just upload the format that you have and it will provide you all the other formats necessary. Remember though, online font usage requires a separate licence, even if you’ve purchased the font.

Goto Disk Utilities>Erase>Ex-Fat

And that’s all that is there to make a flash drive discoverable in both a mac and windows. Happy data transferring guys!!

Bearing in mind the fact, that the guys at Nokia House at Espoo, Finland are soon gonna be tenants in a property they once owned, the Nokia Lumia 920 is being hailed as the Armageddon for this Finnish giant. Also keep in mid the fact that Windows has already slashed down the production of its Surface Tablet.
The Lumia 920 packs Windows 8 and a 4.5 inch IPS display  and introduces PureView camera technology in a bid to compete with the Apple and Samsung.

The slick unibody design makes the Nokia Lumia 920 feel like a sturdy, luxurious slab of chocolate in the hand and is clearly one of the best designed phones from Nokia till date.  The curved body allows ample space for speakers, looks stylish and  brings to the table good spacing of control buttons and a decent speaker at the bottom.

Windows Phone 8 with its vertical scroll works interestingly well on mobiles and continues to make others look like a boring alternative to the flashing tiles and infinitely customisable home screen options found on the Nokia Lumia 920. The bigger screen helps showcase the impressive 8 megapixel camera which is, like everything else, ultra fast thanks to a Snapdragon S4 processor making apps move with zero lag.

The persistent lack of apps and major apps is still the biggest drawback despite Nokia going to great lengths to show Windows Phone 8 in the best way possible. 32GB of internal storage however doesn’t stall my crib for  the lack of a MicroSD socket.

The IPS display and deep blacks work well – there’s little glare or reflection from the 4.5 inch screen which, in pixel terms, clocks in at 1280 x 768 pixels per inch. For movies and photos it works brilliantly and though it doesn’t have the best resolution on show, the menus and OS are super clear and bold, designed to match the screen. The end result is that it’s an impressive display that can’t match the best, but offers great colour and depth for the screen size – it still manages a wow factor against 2012 smartphones.

The Nokia Lumia 920 is the fastest Lumia yet, not that any Lumia could be accused of being slow. The screen itself is responsive and the easy start up menus and integration of contacts and old numbers is as simple as it gets. The exclusive apps like Nokia Drive and SkyDrive options are good and, really, the on-board navigation and clever Local Scout services kick Apple maps into touch – the Nokia 920 makes the best of them.

Has to be said though, that the battery life is disappointing and inconsistent. It’s hard to see what actually uses power but I managed a day with moderate use. The fast wireless charging accessory (simply place your phone on the black plastic charge plate) works well but does get hot and it’s not really a slim bedside table companion.

Verdict

Ingenuously chunky with good specs and a brilliant take on Windows Phone 8, there’s lots to like about the Nokia Lumia 920. The battery life and the lack of microSD may be enough to disappoint potential buyers but they would miss out on the advantages of a super-powered Windows phone.

And the nice Nokia extras like Nokia Drive which are so slick, they set a real example of how to do home grown navigation apps. Overall, I still find the Nokia Lumia 920 immense fun and that’s not something I’ve said for a long time about Windows.

I’m not really a windows guy, so my best possible guess as to why this happens would be a startup profile corruption. “How” could be anybody’s guess!!!

A quick fix – after setting you preferences to make hidden files visible, navigate to the AppData folder.

C:\Users\Soumasish\AppData

Go to the roaming profile and navigate to the FMLE folder inside Adobe.

AppData\Roaming\Adobe\Flash Media Live Encoder 3.5

This folder contains XML data of the profiles that you’ve set in the Encoder. It also contains a default profile named start up. Just delete the start up folder and your encoder should get back to life.

Now click the right button icon to push the stack into the next frame.

Voila! there you go click the tab, select the image and send your mail. That easy.

Rounded corners

div {

-moz-border-radius: 10px;
 -webkit-border-radius: 10px;
 -khtml-border-radius: 10px;
 border-radius: 10px;

}

Just suit the radius to your liking and apply it on the suitable div.

Transparency

/* Theoretically for IE 8 & 9 (more valid) */ 
 /* ...but not required as filter works too */
 /* should come BEFORE filter */
 -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

 /* This works in IE 8 & 9 too */
 /* ... but also 5, 6, 7 */
 filter: alpha(opacity=50);

 /* Older than Firefox 0.9 */
 -moz-opacity:0.5;

 /* Safari 1.x (pre WebKit!) */
 -khtml-opacity: 0.5;

 /* Modern!
 /* Firefox 0.9+, Safari 2?, Chrome any?
 /* Opera 9+, IE 9+ */
 opacity: 0.5;

Again suit the opacity to your liking(instead of 0.5 -0.3) and you’re good to go.

CSS Gradient

For CSS gradient, I normally use this URL

http://www.colorzilla.com/gradient-editor/

Ideally, choose a preset tonality and change colours to suit your page contents. Copy the code and place it in the relevant div.

Border Collapse

Collapsing Divs

If you have a div nested inside a parent div, adding a float property to the child, leads to the parent div losing its height or collapsing and  your site breaks. A quick and easy fix is to add an empty div as the last semantic element before closing the parent div, with the following property.

.clear_float{
      clear:both;
 }

The iPhone 5 is the thinnest and lightest iPhone yet. 7.6mm thick, 18% thinner than before. It’s the world’s thinnest smartphone, and weighs 112 grams. 20% lighter than the 4S.

The iPhone 5 sports a 326ppi Retina display, 4-inches. 1136 x 640 resolution. Same width, but taller. It has five rows of icons, plus the four shortcuts on the bottom. The phone offers 44% better color saturation, full sRGB rendering. It supports GPRS, EDGE, EV-DO, HSPA, HSPA+, DC-HSDPA and LTE! HSPA+ is 21Mbps, DC-HSDPA is 42Mbps, and LTE is a max of 100. So that’s a major concern addressed.

Apple still refuses to tread the quad core route. A new chip surely, the A6! 2X faster CPU and 2x graphics compared to the A5 — is this compared to the A5 or A5X?
With the new processor Pages is said to launch 2.1X faster than before and Keynote attachments load 1.7X faster. The battery life is 8 hours of 3G or LTE talk time or browsing and 10 hours on WiFi browsing.

The Camera is the same as 4S, but offers panorama now.The front-facing camera though is now 720p, backside illuminated.
Finally the long discussed connector port. The new connector port is called lightning – it’s 80% smaller. Apple now owns both the Thunderbolt and Lightning.

Ofcourse it launches iOS 6. I caught up Apple updating its site for the new pricing and download. As per the keynote, the pricing remains the same as iPhone 4S on the contractual rates. But that’s not what we’re interested in, here in the Middle East. So have to wait a few more hours for the official unlocked pricing ot be launched.

What did we miss then?

No NFC, unfortunately, nor any talk about using Bluetooth 4.0 for near-field communications. No wireless charging, either. You’ll need to keep that Lightning cable handy and, no micro-USB compatibility. That port indeed doesn’t look to be compatible.

Pre-orders start on Friday the 14th. Shipping on September 21st in the US, Canada, UK, Germany, France, Australia, Japan, Hong Kong and Singapore. Seems like my brother has a busy week ahead in Atlanta - queuing up, buying and then shipping it all the way up here is a lot of work for sure.

Go back a few years into early 2000 and web video started with plugins like real player, quicktime and windows media player. There wasn’t a clearly dominant plugin at that time and web developers would often try to support all three to make sure video could reach as much of their audience as possible. Then Flash came along and dominated the scene for a few years and even today Flash continues to be the predominant standards for video delivery over the web. With the rise of Flash browser developers around the world started playing with the idea of including audio/video as a component of HTML much like image and text. Opera introduced a video tag in early 2007 and played using a native player. From this the HTML 5 video concept was born and browser developers around the world continued to refine the specifications for video delivery on the web.
The inertia of change would have delayed the natural course of development further had it not been Apple unceremoniously dropping Flash support on its mobiles and tablets. HTML 5 thus became the order of the day if you had to deliver contents on iOS devices.  With HTML 5 video delivery every browser uses its own player and thus one could be very different from the other as opposed to Flash, which being a plugin, basically runs the same code running across browsers.
Though browser developers have done a commendable job in supporting HTML 5 specification as to how the video tag should be parsed, yet the components and formats are vastly different.

So can we use HTML 5 video as of today?

Yes, but with a list of caveats. IE 9, Safari 3, Firefox 3.5, Chrome 3 and Opera 10.5 onwards all browsers support HTML 5 video, but to varying extents.
I often get asked, “Why should we use HTML 5 Video in any case?”
Aside from the fact that it supports iOS devices, one big reason, is that’s the future and we’ll all be there eventually. That’s not the best reason though as, if you wait, you’ll find working with HTML 5 easier after most kinks are worked out. Second, would be cleaner code – use of one simple video tag as opposed to a bulky script for a plugin. However at present times, with multiple fall back options the code might actually get bulkier than plain Flash. This leads us to the third reason – HTML 5 video is rendered natively by the browser and not through a plugin, the video playback is thus smoother and more responsive.  And this gets us to the meat of our discussion today – not all browsers support all video formats. So let’s take a deeper look into what formats are all about and who supports what?

Audio & Video Formats

A video/audio format is essentially made up of three pieces – the container format which essentially gives the file extension, inside which you have your video data which is compressed using a video codec and audio data compressed using an audio codec.

HTML 5 supports three principal video formats – mp4, Ogg Thora and WebM.
The mp4 container supports H.264 video and AAC audio compression.Mp 4 is avery popular format and if you have a handheld video device, you’re most likely storing video in that format. It’s a closed format and there are licensing issues involved. Safari 3, IE 9 and Flash 9 supports the format – thus this is the format to reach iOS devices which essentially sports a mobile Safari.

The Ogg Theora format is made up of the Ogg container with Theora video codec and Vorbis audio codec. The format is free and open source and is supported by Firefox 3.5, Chrome 3 and Opera 10.5 and above. The only issue with Ogg is that it requires bigger file sizes to render the same quality as with the other two formats.

The Web M format uses the webm container with the VP8 video codec and Vorbis audio codec. It is supported by Firefox 4, Chrome 6 and Opera 10.6 and above and is an open source format. Significant to mention here that web M technology was created after google bought On2 for VP8 video codecs. The format is comparable to H.264 in terms of quality and also completely free, thus it has the maximum likelihood of becoming a standard HTML 5 format if there is one in the future.

In case of audio, the formats are mostly the same containers with only audio data in them. In fact, in some cases, there isn’t even a container only compressed audio data. Mp3 files for example have not containers. Mp3 is supported by Safari, IE9 and Chrome. AAC is the same as H.264 without the video data and often has the extension .m4a, to distinguish from the video content and is supported by the same browsers as mp3. AAC is a successor to mp3 and renders a higher quality, however both are closed source, so if you’re charging for your audio, make sure you understand the licensing agreement. The Ogg audio files typically have the extension .oga and uses the same vorbis audio codec. Ogg Vorbis is supported by Firefox, Chrome and Opera. Finally comes the .wav format which doesn’t use any audio codec and stores data in an uncompressed pcm format, the same format used in CDs. Wav is supported by most HTML 5 browsers, but it’s unlikely to make the cut, primarily b’coz of file sizes.

Now that we know all that we need to know about HTML 5 audio and video formats, time to get our hands dirty with some code to get you up and running.
The video tag is a simple open and close tag which contains your video attributes and even fall back contents if your browser doesn’t support HTML 5.

<video>

<p> Update your browser, bummer!!! </p>

</video>

Now you can add the source -

<video src = "../myFolder/myVideo.ogv " >

At this stage if you open up your page in a browser it would show you the first frame without any controls to play the content. So we need to add a few controls.

<video src = "../myFolder/myVideo.ogv "  controls>

That simple, it’s a boolean attribute, so if its present it’s true, otherwise false. It’s exactly same with audio.

<audio src = "../myFolder/myAudio.oga "  controls>

<p> Fallback content</p>

</audio>

Ok this is all it would be, another five years down the line when all browsers support HTML 5. But in today’s date if you load this page up in IE 6,7 or 8 or iOS devices, you hav a peeved audience, one amongst more than half  of your audience. So clearly you need to cater to fall back contents. So, hate as much as you’d, but its time to get your hands dirty with alternate.

The video file  format I’ve used above wouldnt work on Safari or Chrome and to support multiple formats we use the source tag. The tag is self closing and all we need to do is remove the src attribute from the video tag. It also has a type def. The way it works is that the browser will look from top to the bottom to see the list of sources which it can play and would start playing the one it supports.

<video controls>

<source src = "../myFolder/myVideo.mp4" type = "video/mp4" />

<source src = "../myFolder/myVideo.ogv " type = "video/ogg" />

<source src = "../myFolder/myVideo.webm " type = "video/webm" />

<p> Fallback content</p>

</video>

Last time, I checked, a bug in the iPad prevents it from scanning through the entire list of sources, thus you’d do good to place your mp4 source on top of the list. To add a smoother rendering experience you can add the preload attribute which enumerates between none, auto and metadata. With none, even the first frame will nto be loaded, with auto once the page is loaded the browser continues to load the video in the background and waits for the user to push play and finally with metadata selected the browser loads the meta information, ie frame size, duration and first frame and not the video itself.

<video controls preload="metadata">

You can also add the autoplay boolean attribute to your video tag and make the video loop using the loop boolean tag.

<video controls preload="metadata" autoplay loop>

Finally if you feel the first frame of your video doesn’t adequately represent the content, you can add a poster frame as place holder before the video starts playing. just poing the poster attribute to the source image.

<video controls preload="metadata" poster = "../myImageFolder/myImage.png">

That’s it. Goes without saying, I would add flash to my fall back contents, as not doing that might still leave out 50% of my audience.