Sunday, February 5, 2012

Making your Video Content Indexable

Internet search engines provide end-users a quick and easy to use way to get access to information available on the Internet. As more and more Internet content is multimedia, you need to ensure that your content is properly indexed by the search engines so that users can discover it. This article will provide an overview of how to enable your video content to be SEO enabled and indexed by the various search engines (Google, Yahoo, Microsoft).
There is a standard document, called a sitemap, that search engine indexers look for when examining your site. This document concisely tells the search engines what content is exposed on your site, the metadata for that content, and where that content is located on your site. A sitemap is an XML file that follows a standard specification.
There are two different flavors of sitemaps that you can (and should) create:
  • Sitemap – A sitemap that will index your content in the standard text based search engines such as www.google.com or search.yahoo.com
  • Video Sitemap – A sitemap that will index your content in media-centric search engines such as video.google.com
Note that both of these sitemaps index the metadata about your video content and provide links to end-users. The difference is where the metadata that is indexed is obtained from and how the content is surfaced in search results.
A proper SEO strategy for your video content will include creating both a standard sitemaps as well as a video sitemap. From a priority perspective, you want to create a standard Sitemap first and then a Video Sitemap.

Standard Sitemaps

Sitemaps follow the sitemap specification that is defined here: www.sitemaps.org. The purpose of the sitemap file is to provide a list of URLs on your site to the search engines. The only other information associated with a URL is when the page was last modified and how frequently the page changes. Note, there is no metadata about your content in this index. Because the sitemap is page-centric, we need to create a model where each video in your library will have a unique page, or URL, associated with it. This can be accomplished by having a single page whose behavior and content can be dynamically changed by passing in different query parameters to the page. For example, if you have a URL like http://www.example.com/video.html?videoId=123, you would have the video.html page look for the videoId query parameter (videoId=123) and modify the contents of the page returned to the browser to contain information about the video with id 123. This would be done on the server-side of your application where the page would look for the ID and then use the Video Cloud Media APIs to fetch metadata about the video and write it into the page.

For the purposes of this article, we assume that there is a single landing page on your site which can be used to play back all video content for your site. Different query parameters will be passed to the page to tell the page what video to play back and what video to surface metadata for. For example, let's say you have a page that displays the contents of an entire playlist and queues up a specific video in a player. You tell the page what playlist to display metadata for via a bclid query parameter and what video to surface in a player via the bctid parameter. Thus, what we want to do is create a URL for every unique playlist and video id combination.
Here is an example of sitemap that will be created:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
      <loc>http://www.example.com/video?bclid=345&bctid=123</loc>
      <lastmod>2008-01-01</lastmod>
      <changefreq>weekly</changefreq>
   </url>
   <url>
      <loc>http://www.example.com/video?bclid=12&bctid=544</loc>
      <lastmod>2008-03-01</lastmod>
      <changefreq>weekly</changefreq>
   </url>
</urlset>

Google Video Sitemaps

A video sitemap is similar in concept to the standard sitemap file; there will be an entry in this sitemap file per video in your account. In fact, a video sitemap uses the sitemap schema as its base and adds additional tags specific to video metadata.
We won't go through the meaning of every element in the video sitemap file, but we do want to touch upon two elements: <video:content_loc> and <video:player_loc>. According to the video sitemap specification:
You must provide one of either the <video:content_loc> or <video:player_loc>
The video:content_loc element would be used to provide a reference to your video file (FLV or MP4) directly. We don't want to do this for several reasons:
  • If you use FMS for streaming, the video sitemap specification does not allow you to reference these files directly; you can only use HTTP.
  • If Google surfaces your content directly in the results page, you want to make sure it is played back through your player to keep all of your analytics, advertising, and branding with your content.
For these reasons, we want to use the video:player_loc element rather than video:content_loc. This will point to a Single Video Player from the Video Cloud system via the Player URL publishing code. We can pass different video IDs to this player to play, using the bctid query parameter. We don't restrict this player to a particular domain and thus will allow it to be directly embedded in the search results.

Here is an example of the video sitemap that will be created:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
<url> 
  <loc>http://www.example.com/videos/some_video_landing_page.html</loc>
    <video:video>     
      <video:content_loc>http://www.site.com/video123.flv</video:content_loc>
      <video:player_loc allow_embed="yes">http://www.site.com/videoplayer.swf?video=123</video:player_loc>
      <video:thumbnail_loc>http://www.example.com/thumbs/123.jpg</video:thumbnail_loc>
      <video:title>Grilling steaks for summer</video:title>  
      <video:description>Get perfectly done steaks every time</video:description>
      <video:publication_date>2007-11-05T19:20:30+08:00.</video:publication_date>
      <video:tag>steak</video:tag>
      <video:tag>meat</video:tag>
      <video:tag>summer</video:tag>
      <video:family_friendly>yes</video:family_friendly>
      <video:duration>600</video:duration>
    </video:video>
</url>
</urlset>
 
 
Conclusion
 
A complete SEO strategy for your video content should include creating both a standard sitemap as well as a video sitemap. This will ensure that your content is indexed across the widest swath of search engines. Additionally, your content will be surfaced in the most aesthetically pleasing manner for the point of discovery. This article has outlined an approach for providing a unique URL per video and samples for generating the sitemap files that the engines will index.

Mobile SEO Vs Desktop SEO

As  the rising importance of local search optimisation, hundreds of millions of people now own a smartphone and this number is expected to rise to one billion by 2013. With this in mind, there still seems to be a relatively untapped market for mobile search optimisation within the industry of internet marketing.

One of the reasons that this particular market is not being fully exploited is that it is not still fully understood by many search engine optimisation professionals. In fact, a key mistake that SEO’s often make is that search engine results appear the same on a computer and on a mobile device. This is not the case, and with the users of smartphones becoming increasingly savvy to their capabilities, perhaps it’s time that more businesses and SEO agencies tap into this potentially huge market.

A crucial example of how mobile search differs to desktop search is that it is inherently local and therefore Local listings feature more prominently. This could be a great area for an emerging local business to exploit. One way a company could do this is by ensuring that they are optimised for Google Places listings, and there is a possibility to combine this with a domain that focuses on geo-specific keywords. This may seem to argue against the Desktop SEO logic that it is better to consolidate all links in one canonical domain, however, creating an alternate domain focused intensely on local search could provide more traffic, both physically and digitally. Determining the best approach to this dilemma requires a keen marketing mind to determine which option has the potential to bring your business the most success.


Another opportunity that mobile search creates is to search without using a ‘search term’. The best example of this is the Google Goggles app that allows the user to take a picture of something and that will become the subject of the search. The app works for books, films, landmarks, businesses and logos. A company optimising for mobile search would ensure that there logo is clearly displayed and optimised, and attached to a mobile site allowing users to go straight to it after finding the company logo. In a broader context, not necessarily logo’s, this could have a huge impact. Pretty much everyone that has a smartphone has a built in camera, so if they take a picture of a product that relates to your company, it makes business and practical sense to ensure you have a mobile site optimised for those images.

Some other differences between mobile and desktop search include the fact that the vertical listings will often differ in mobile search, with images featuring higher in the SERPs. Smartphone results also produce different filters at the top of the SERPs; fewer filters can mean less distraction for the user and potentially a higher click through rate to your site.

There are many more differences between mobile search and desktop search, but I selected these few to illustrate the point that there is incredible potential within this market. With relatively few companies targeting this specific sector of digital marketing, there is a real opportunity for business owners willing to grasp it.

SEO for Video Content

Videos are some of the hottest content on the net. Everyone receives those periodic emails from a friend or business associate advising, ‘Check this out!’ Videos are the main form for viral content, add interest when embedded in a site, and draw traffic like a magnet.

Videos are easy to make, too. Anyone with any kind of camera can create one, and anyone with a computer can upload one. Popular videos don’t have to be high-quality, have good production values or even be well-edited to succeed. Skilled children can make them.

Why, then, isn’t everyone rushing to include video content on their site? There’s a reason SEO experts don’t push video content. Videos, like images, present problems when it comes to search engine crawlers. The search engines can’t see video content. This means that all the effort you put into getting a video onto your site is wasted, from a search engine optimisation point of view.

This doesn’t mean that you should avoid video content. Videos have proven attraction for internet users, and as time goes by they are being used increasingly as part of internet marketing strategies. The value of video content as an attention magnet can’t be ignored. The answer is to work around your video content to ensure that everything is done that can be done to explain its content to a search engine.

Optimise your videos

The search engines rely on extraneous information to determine what your video is all about. Much like they do when ranking your site, the search engines examine the on-page factors around the video, the links to the video and links from the page the video is on. On the whole, search engines are unable to view the content of the video, but it is thought they can detect some on-screen text. This makes it worth optimising any subtitles and titles.

Many people forget that the video file can be optimised. Use your keywords in the title and, if the platform your video is on allows it, map out an SEO-friendly description and tags. If you host the video on a site like YouTube, don’t forget to re-enter all of the meta data.
Format will also affect your video’s search engine friendliness. As time goes by, Google is developing techniques to work with Flash content. This may mean Flash videos will gain some SEO standing in the future.

How to maximise SEO techniques around videos

The content you put around your video is vital. Writing a brief description of the video will help users and search engines identify the content. Ensure you use the word ‘video’ as part of your keywords for that page. The very fact that you have a video can prove part of the attraction. Finally, include a link to a transcript of the video. This will ensure the content is used to maximum SEO effect.

Saturday, January 21, 2012

InnoDB plugin row format performance

InnoDB plugin row format performance

Here is a quick comparison of the new InnoDB plugin performance between different compression, row formats that is introduced recently.

The table is a pretty simple one:

CREATE TABLE `sbtest` (
`id` int(10) unsigned NOT NULL,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k` (`k`)
) ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

The table is populated with 10M rows with average row length being 224 bytes. The tests are performed for Compact, Dynamic and Compressed (8K and 4K) row formats using MySQL-5.1.24 with InnoDB plugin-1.0.0-5.1 on Dell PE2950 1x Xeon quad core with 16G RAM, RAID-10 with RHEL-4 64-bit.

Here are the four test scenarios:

1. No compression, ROW_FORMAT=Compact
2. ROW_FORMAT=Compressed with KEY_BLOCK_SIZE=8
3. ROW_FORMAT=Compressed with KEY_BLOCK_SIZE=4
4. ROW_FORMAT=Dynamic

All the above tests are repeated with innodb_buffer_pool_size=6G and 512M to make sure one fits everything in memory and another one overflows. The rest of the InnoDB settings are all default except that innodb_thread_concurrency=32.

Here is the summary of the test results:

Table Load:

Load time from a dump of SQL script having 10M rows (not batched)
Compact Compressed (8K) Compressed (4K) Dynamic
28m 18s 29m 46s 36m 43s 27m 55s

File Sizes:

Here is the size of the .ibd file after each data load
Compact Compressed (8K) Compressed (4K) Dynamic
2.3G 1.2G 592M 2.3G

Data and Index Size from Table Status:

Here is the Data and Index size in bytes from SHOW TABLE STATUS and you can see the original data size here rather than the compressed size
Compact Compressed (8K) Compressed (4K) Dynamic
Data 2247098368 2247098368 2249195520 2247098368
Index 137019392 137035776 160301056 137019392

Compression Stats:

Here is the compression stats after the table is populated from information_schema.InnoDB_cmp; and you notice that 4K takes more operations and time for both compression and un-compression
Page_size Compress_ops Compress_ops_ok Compress_time Uncompress_ops Uncompress_time
8K 8192 446198 445598 73 300 0
4K 4096 1091421 1012917 463 38801 13

Performance:

Here is the performance of various row formats with threads ranging from 1-512 for both 512M and 6G buffer pool size for both concurrent reads and writes.

compress512m

compress6g

Observations:

Few key observations from the performance tests that I performed without looking to any of the sources, as I could be wrong, someone can correct me here. Its hard to draw from these input scenarios, but helps to estimate what is what.

* The load time is almost same except that the 4K compression seems to take longer than the rest; and compression in general is hitting the INSERT/Load performance a little bit.
* Compact or Dynamic, there is no compression; so the data and index file sizes will be almost same
* The SHOW TABLE STATUS for compressed table will have its original Data_Length and Index_Length statistics rather than the compressed statistics (may be a bug or InnoDB needs to extend SHOW TABLE STATUS to show any compressed sizes or other means, right now only option is to view your files manually)
* 8K compression reduced the .ibd file by nearly 50% (1.2G out of 2.3G) and 4K compression reduced the size by 1/4th (592M out of 2.3G); and it could vary based on table types and data.
* 8K compression takes less ops and time for both compression and de-compression when compared to 4K (obvious)
* When there is enough Innodb buffer pool size to act data in memory, the compression is a bit overhead, but you will be saving space
* When there is a overflow from buffer pool (IO bound), compression seems to really help
* 4K compression in general seems to be slower when compared with 8K or any other row_format.

How To Obtain hierarchical data / Parent - Child relationship

IPv4 vs IPv6

I had compiled differences between IPv6 and IPv4 long back. 

Hope someone might find this useful.


IPv4
IPv6
Addresses are 32 bits (4 bytes) in length. Addresses are 128 bits (16 bytes) in length
Address (A) resource records in DNS to map host names to IPv4 addresses. Address (AAAA) resource records in DNS to map host names to IPv6 addresses.
Pointer (PTR) resource records in the IN-ADDR.ARPA DNS domain to map IPv4 addresses to host names. Pointer (PTR) resource records in the IP6.ARPA DNS domain to map IPv6 addresses to host names.
IPSec is optional and should be supported externally IPSec support is not optional
Header does not identify packet flow for QoS handling by routers Header contains Flow Label field, which Identifies packet flow for QoS handling by router.
Both routers and the sending host fragment packets. Routers do not support packet fragmentation. Sending host fragments packets
Header includes a checksum. Header does not include a checksum.
Header includes options. Optional data is supported as extension headers.
ARP uses broadcast ARP request to resolve IP to MAC/Hardware address. Multicast Neighbor Solicitation messages resolve IP addresses to MAC addresses.
Internet Group Management Protocol (IGMP) manages membership in local subnet groups. Multicast Listener Discovery (MLD) messages manage membership in local subnet groups.
Broadcast addresses are used to send traffic to all nodes on a subnet. IPv6 uses a link-local scope all-nodes multicast address.
Configured either manually or through DHCP. Does not require manual configuration or DHCP.
Must support a 576-byte packet size (possibly fragmented). Must support a 1280-byte packet size (without fragmentation).

Network Sorcery is a great place to find RFC(s). 

Refer to http://www.networksorcery.com/enp/protocol/ipv6.htm and http://www.networksorcery.com/enp/protocol/ip.htm links for related RFC(s) of IPv6 and IPv4 respectively. 

Also there is good reference for Understanding IPv6 @ http://technet.microsoft.com/en-us/library/cc786127.aspx

Thursday, October 25, 2007

ET:QuakeWars - Linux Client is now available


In case you missed the official announcement, ETQW Linux Client is now available to download. You do need the full retail DVD to complete the installation though. The client itself is really small at 18MB, so need to work out if they actually preloaded some OS compatilibty stuff on the DVD pre-release.

Another issue, it only runs in 32bit mode, so if you have a x86_64 install - you will need the compat libs along with their deps. My main gaming machine is i686, but my primary laptop is x86_64 ( the Acer Ferrari 4005 ) and I will at some point install the game there as well. So a list of rpms required on centos-5 to make it work will get posted here soon'ish :)

Tech Search