There's a big difference between what Microsoft
is working on and Google Glass, though.
The most recent word out of Google is that
Google Glass isn't going to use "augmented reality" – where data and
illustrations overlay the actual world around you.
Google Glass is actually just a tiny screen you
have to look up and to the left to see.
Microsoft's glasses seem to utilize augmented
reality. In a patent illustration we've embedded below, you can see that the
glasses put data on top of a live action concert and a ballgame.
Both gadget concepts are very interesting.
Lots of people disagree with me, including other
BI writers, but I think something like Google Glass or whatever Microsoft is
working on could end up replacing the smartphone as the dominant way people
access the Internet and connect to each other.
First off: something has to. Disruption is
inevitable.
Secondly: The trend is obvious.
Computers have been getting smaller and closer
to our faces since their very beginning.
First they were in big rooms, then they sat on
desktops, then they sat on our laps, and now they're in our palms. Next they'll
be on our faces.
(Eventually they'll be in our brains.)
By the way, you can bet that if Microsoft and
Google are working on computerized glasses, so is Apple and
Jony Ive.
Motion-compensated prediction (MCP) is the key to the success of the modern video coding standards, as it removes the temporal redundancy in video signals and reduces the size of bitstreams significantly. With MCP, the pixels to be coded are predicted from the temporally neighboring ones, and only the prediction errors and the motion vectors (MV) are transmitted. However, due to the finite sampling rate, the actual position of the prediction in the neighboring frames may be out of the sampling grid, where the intensity is unknown, so the intensities of the positions in between the integer pixels, called sub-positions, must be interpolated and the resolution of MV is increased accordingly.
Interpolation in H.264/AVC
In H.264/AVC, for the resolution of MV is quarter-pixel, the reference frame is interpolated to be 16 times the size for MCP, 4 times both sides. As shown in Fig. 1(a), the interpolation defined in H.264 includes two stages, interpolating the half-pixel and quarter-pixel sub-positions, respectively. The interpolation in the first stage is separable, which means the sampling rate in one direction is doubled by inserting zero-valued samples followed by filtering using a 1-D filter h1, [1, 0, -5, 0, 20, 32, 20, 0, -5, 0, 1]/32, and then the process repeats for the other direction. The second stage, which is non-separable, uses bilinear filtering supported by the integer pixels and the interpolated half-pixel values. The impulse and frequency responses of the interpolation filter in H.264/AVC are shown in Fig. 2 (a) and (b), respectively. As can be seen, this interpolation filter is almost ideal, as it has a square passband with the cutoff frequencies π/4 in both horizontal and vertical directions and very small ripples in the stopband. To fit the general statistics of various video sources, the filter coefficients are fixed.
Fig. 1 Interpolation process of (a) the filter in H.264/AVC, (b) the optimal AIF, and (c) the separable AIF
Fig. 2 Impulse and frequency responses of the normative interpolation filter in H.264/AVC
Review of Adaptive Interpolation Filters (AIF)
Considering the time-varying statistics of video sources, some researchers propose using adaptive interpolation filter (AIF), which is one of the design elements making KTA significantly outperform JM. With AIF, the filter coefficients are optimized on a frame basis, such that for each frame the energy of the MCP error is minimized. The optimal coefficients are quantized, coded, and transmitted as the side information of the associated frame. Our previous post listed all the AIF techniques adopted in KTA. These AIF techniques all use the minimum mean squared error (MMSE) estimator to calculate the coefficients and achieve minimum MCP error, but provide different balances among performance, complexity, and size of the side information, by using different support regions and imposing different symmetry constraints.
2-D non-separable AIF, of which the interpolation process is shown in Fig. 1(b), increases the spatial sampling rate 16 times at one time by zero-insertion, and each sub-position is interpolated directly by filtering the surrounding 6×6 integer pixels. Fig. 3 (a) shows the support region of 2-D non-separable AIF. As the spatial statistics are assumed to be isotropic, the filter h is in circular symmetry and therefore 1/8 of the coefficients are coded, as shown in Fig. 3 (b). The assumption that the spatial statistics are isotropic may not hold for every frame in a video sequence. 2-D separable AIF is proposed, which considers the spatial statistics of horizontal and vertical directions different and reduces the complexity of 2-D non-separable AIF. The 1-D AIFs for the two directions are separately designed. As shown in Fig. 1(c), the horizontal sampling rate is increased four times by zero-insertion and a 1-D filter h1 calculated for the current frame is applied. Then, the process repeats for the vertical direction using h2.
(a) (b)
Fig. 3 2-D non-separable AIF’s (a) support region and (b) coded coefficients
Directional AIF (D-AIF) further reduces the complexity, although also following the process in Fig. 1(b). Each sub-position is supported by at most 12 surrounding pixels in a form of diagonal cross. Its support region is shown in Fig. 4 (a). By doing this, the correlation along the diagonal direction can be exploited for interpolation. As D-AIF also has circular symmetry, the coded coefficients are shown in Fig. 4 (b). D-AIF is enhanced by the authors, known as E-DAIF, of which the support region is adaptively switched between diagonal cross (see Fig. 4 (a)) and a radial support (see Fig. 5 (a)).
(a) (b)
Fig. 4 D-AIF’s (a) support region and (b) coded coefficients
The enhanced AIF (E-AIF) uses 12-tap filters with a radial support to interpolate sub-positions, as shown in Fig. 5 (a), and adds a 5×5 filter for integer pixels and a DC offset for each integer and sub-position. The horizontal and vertical statistical properties are thought different, so the filter is axisymmetric, of which the coded coefficients are shown in Fig. 5 (b).
(a) (b)
Fig. 5 E-AIF’s (a) support region and (b) coded coefficients
Instead of adaptively calculating the filter coefficients for each frame, switched interpolation filter with offset (SIFO) enables frame-level switching between fixed interpolation and sending DC offset for each sub-position. When not using any of the filters, the pixels in different sub-positions and the integer position will be added by their relevant DC offsets, in order to compensate the illumination changes.
Type man ls to read the manual for the ls command.
man {command} > {filename}
Redirect help to a file to download.
whatis {command}
Give short description of command. (Not on RAIN?)
apropos {keyword}
Search for all Unix commands that match keyword, eg apropos file. (Not on RAIN?)
List a directory
ls {path}
It's ok to combine attributes, eg ls -laF gets a long listing of all files with types.
ls {path_1} {path_2}
List both {path_1} and {path_2}.
ls -l {path}
Long listing, with date, size and permisions.
ls -a {path}
Show all files, including important .dot files that don't otherwise show.
ls -F {path}
Show type of each file. "/" = directory, "*" = executable.
ls -R {path}
Recursive listing, with all subdirs.
ls {path} > {filename}
Redirect directory to a file.
ls {path} | more
Show listing one screen at a time.
dir {path}
Useful alias for DOS people, or use with ncftp.
Change to directory
cd {dirname}
There must be a space between.
cd ~
Go back to home directory, useful if you're lost.
cd ..
Go back one directory.
cdup
Useful alias, like "cd ..", or use with ncftp.
Make a new directory
mkdir {dirname}
Remove a directory
rmdir {dirname}
Only works if {dirname} is empty.
rm -r {dirname}
Remove all files and subdirs. Careful!
Print working directory
pwd
Show where you are as full path. Useful if you're lost or exploring.
Copy a file or directory
cp {file1} {file2}
cp -r {dir1} {dir2}
Recursive, copy directory and all subdirs.
cat {newfile} >> {oldfile}
Append newfile to end of oldfile.
Move (or rename) a file
mv {oldfile} {newfile}
Moving a file and renaming it are the same thing.
mv {oldname} {newname}
Delete a file
rm {filespec}
? and * wildcards work like DOS should. "?" is any character; "*" is any string of characters.
ls {filespec} rm {filespec}
Good strategy: first list a group to make sure it's what's you think... ...then delete it all at once.
View a text file
more {filename}
View file one screen at a time.
less {filename}
Like more, with extra features.
cat {filename}
View file, but it scrolls.
cat {filename} | more
View file one screen at a time.
page {filename}
Very handy with ncftp.
pico {filename}
Use text editor and don't save.
Edit a text file.
pico {filename}
The same editor PINE uses, so you already know it. vi and emacs are also available.
Create a text file.
cat > {filename}
Enter your text (multiple lines with enter are ok) and press control-d to save.
pico {filename}
Create some text and save it.
Compare two files
diff {file1} {file2}
Show the differences.
sdiff {file1} {file2}
Show files side by side.
Other text commands
grep '{pattern}' {file}
Find regular expression in file.
sort {file1} > {file2}
Sort file1 and save as file2.
sort -o {file} {file}
Replace file with sorted version.
spell {file}
Display misspelled words.
wc {file}
Count words in file.
Find files on system
find {filespec}
Works with wildcards. Handy for snooping.
find {filespec} > {filename}
Redirect find list to file. Can be big!
Make an Alias
alias {name} '{command}'
Put the command in 'single quotes'. More useful in your .cshrc file.
Wildcards and Shortcuts
*
Match any string of characters, eg page* gets page1, page10, and page.txt.
?
Match any single character, eg page? gets page1 and page2, but not page10.
[...]
Match any characters in a range, eg page[1-3] gets page1, page2, and page3.
~
Short for your home directory, eg cd ~ will take you home, and rm -r ~ will destroy it.
.
The current directory.
..
One directory up the tree, eg ls ...
Pipes and Redirection
(You pipe a command to another command, and redirect it to a file.)
{command} > {file}
Redirect output to a file, eg ls > list.txt writes directory to file.
{command} >> {file}
Append output to an existing file, eg cat update >> archive adds update to end of archive.
{command} < {file}
Get input from a file, eg sort < file.txt
{command} < {file1} > {file2}
Get input from file1, and write to file2, eg sort < old.txt > new.txt sorts old.txt and saves as new.txt.
{command} | {command}
Pipe one command to another, eg ls | more gets directory and sends it to more to show it one page at a time.
Permissions, important and tricky!
Unix permissions concern who can read a file or directory, write to it, and execute it. Permissions are granted or withheld with a magic 3-digit number. The three digits correspond to the owner(you); the group (?); and the world (everyone else).Think of each digit as a sum:
execute permission
= 1
write permission
= 2
write and execute (1+2)
= 3
read permission
= 4
read and execute (4+1)
= 5
read and write (4+2)
= 6
read, write and execute (4+2+1)
= 7
Add the number value of the permissions you want to grant each group to make a three digit number, one digit each for the owner, the group, and the world. Here are some useful combinations. Try to figure them out!
chmod 600 {filespec}
You can read and write; the world can't. Good for files.
chmod 700 {filespec}
You can read, write, and execute; the world can't. Good for scripts.
chmod 644 {filespec}
You can read and write; the world can only read. Good for web pages.
chmod 755 {filespec}
You can read, write, and execute; the world can read and execute. Good for programs you want to share, and your public_html directory.
Permissions, another way
You can also change file permissions with letters:
u = user (yourself)
g = group
a = everyone
r = read
w = write
x = execute
chmod u+rw {filespec}
Give yourself read and write permission
chmod u+x {filespec}
Give yourself execute permission.
chmod a+rw {filespec}
Give read and write permission to everyone.
System info
date
Show date and time.
df
Check system disk capacity.
du
Check your disk usage and show bytes in each directory.
more /etc/motd
Read message of the day, "motd" is a useful alias..
printenv
Show all environmental variables (in C-shell% - use set in Korn shell$).
quota -v
Check your total disk use.
uptime
Find out system load.
w
Who's online and what are they doing?
Unix Directory Format
Long listings (ls -l) have this format:
- file
d directory, * executable
^ symbolic links (?) file size (bytes) file name / directory
^ ^ ^ ^ ^
drwxr-xr-x 11 mkummel 2560 Mar 7 23:25 public_html/
-rw-r--r-- 1 mkummel 10297 Mar 8 23:42 index.html
^
^^^ user permission (rwx) date and time last modified
^^^ group permission (rwx)
^^^ world permission (rwx)
How to Make an Alias
An alias lets you type something simple and do something complex. It's a shorthand for a command. If you want to type "dir" instead of "ls -l" then type alias dir 'ls -l'. The single quotes tell Unix that the enclosed text is one command.Aliases are more useful if they're permanent so you don't have to think about them. You can do this by adding the alias to your .cshrc file so they're automatically loaded when you start. Typepico .cshrc and look for the alias section and add what you want. It will be effective when you start. Just remember that if you make an alias with the name of a Unix command, that command will become unavailable.
Here are a few aliases from my .cshrc file:
# enter your aliases here in the form:
# alias this means this
alias h history
alias m more
alias q quota -v
alias bye exit
alias ls ls -F
alias dir ls
alias cdup cd ..
alias motd more /etc/motd
How to Make a Script
A Unix script is a text file of commands that can be executed, like a .bat file in DOS. Unix contains a powerful programming language with loops and variables that I don't really understand. Here's a useful example.Unix can't rename a bunch of files at once the way DOS can. This is a problem if you develop Web pages on a DOS machine and then upload them to your Unix Server. You might have a bunch of .htm files that you want to rename as .html files, but Unix makes you do it one by one. This is actually not a defect. (It's a feature!) Unix is just being more consistent than DOS. So make a script!
Make a text file (eg with pico) with the following lines. The first line is special. It tells Unix what program or shell should execute the script. Other # lines are comments.
#! /bin/csh
# htm2html converts *.htm files to *.html
foreach f ( *.htm )
set base=`basename $f .htm`
mv $f $base.html
end
Save this in your home directory as htm2html (or whatever). Then make it user-executable by typing chmod 700 htm2html. After this a * will appear by the file name when you ls -F, to show that it's executable. Change to a directory with .htm files and type ~/htm2html, and it will do its stuff.Think about scripts whenever you find yourself doing the same tedious thing over and over.
Dotfiles (aka Hidden Files)
Dotfile names begin with a "." These files and directories don't show up when you list a directory unless you use the -a option, so they are also called hidden files. Type ls -la in your home directory to see what you have.Some of these dotfiles are crucial. They initialize your shell and the programs you use, like autoexec.bat in DOS and .ini files in Windows. rc means "run commands". These are all text files that can be edited, but change them at your peril. Make backups first!
Here's some of what I get when I type ls -laF:
A codec is a method for encoding or decoding data--specifically,
compressed data. Though the word codec has become somewhat
generic, the term was originally a shortened form of compressor-decompressor.
That's what codecs do: they take digital media data and either compress them
(for transport and storage) or decompress them (for viewing or transcoding.)
Raw video and audio data consume vast
amounts of storage space. Uncompressed 1080i high-definition video recorded at
60 frames per second eats up 410 gigabytes per hour of video.
CD audio, which is pretty passé by modern standards, puts about 74 minutes of
audio on a 680MB CD. However, eight channels of audio encoded at 24-bit
resolution churns through 16 megabits per second, or a little over 7 gigabytes per
hour of audio. Even with high-speed broadband, that's too much data. That's why
video and audio needs to be compressed for storage.
Once the media data is compressed into
suitable formats and reasonable sizes, it needs to be packaged, transported,
and presented. That's the purpose of container formats--to be discrete
"black boxes" for holding a variety of media formats. Good container
formats can handle files compressed with a variety of different codecs.
Dozens of codecs exist, with specific use
models; most of them you may never encounter as a typical consumer. This
section focuses on codecs as compression/decompression schemes, not as specific
software that may encode or transcode video. That discussion comes later.
H.264 / MPEG-4 AVC: This is the most common codec used in modern camcorders and digital cameras that capture to file-based devices (hard drives, memory cards, and so on). Again, note that this is the codec, not the container format, which is typically AVCHD (see the container section on the next page.)
MJPEG (Motion JPEG): This is an older format used by some digital cameras and older devices to capture video. It was developed by the same group (Joint Picture Experts Group) that developed the JPEG photography compression codec, hence the name.
DV and HDV: DV was developed by a consortium of consumer electronics companies that manufacture and sell camcorders. DV is a tape-based standard and is common on camcorders that use mini-DV tape cartridges. (Some versions of DV are used in professional tape-based gear as well, like DVCPRO and DVCAM.) DV itself is limited to standard definition, so one version, called HDV, was created to allow capture of high-definition video to mini-DV tape cartridges.
Note that DV and HDV describe both the codec used and the container format.
Disc-Based Delivery Formats
Let's talk about the old-fashioned DVD or slightly more newfangled Blu-ray Discs for a bit. Despite the increasing popularity of streaming video, the capability to deliver disc-based media is still needed. I've created Blu-ray and DVD discs to hand out to parents of high school athletes, or to send to relatives, for example. Practically everyone has a DVD player, and you don't need an Internet connection to share a DVD.
MPEG-2: Again, we have to distinguish the codec (MPEG-2 Part 2, also known as H.262) from the MPEG-2 container format. MPEG-2 is used exclusively as the compression standard for DVD video. MPEG-2 was also used in the early days of Blu-ray Disc creation, though most of the newer Blu-ray movies no longer use MPEG-2. MPEG-2 is also used to compress video for over-the-air HDTV broadcast.
H.264 / MPEG-4 AVC: This is essentially the same codec used by modern camcorders for capturing video. It's also used for delivering Web video. H.264 offers robust image quality at relatively low bit rates and high compression ratios. It's very scalable, so you can also have high-bit-rate H.264 video that looks fabulous. This is what's typically used for Blu-ray playback.
Microsoft VC-1: VC-1 is one of three codecs used to encode Blu-ray content. It's also used in Microsoft's Silverlight alternative to Adobe Flash. Blu-ray movies using VC-1 mostly use VC-1 Advanced Profile, also known as Windows Media Video 9 Advanced Profile or WVC1.
Streaming From the Web
Delivering video over the Web necessarily means compromises, mostly trading off image quality for lower bit rates. Broadband bit rates vary depending on the ISP and transport technology. Most of what applies to Web content delivery also applies to video stored on mobile, handheld devices.
MPEG-1: MPEG-1 is the old warhorse for delivering video over the Web. While YouTube, Netflix, and other relatively sophisticated streaming video providers have moved away from MPEG-1, a ton of MPEG-1 standard-definition video is still available on other sites. I've included it mostly for completeness; if you're planning on using high definition at all, you'll want to avoid MPEG-1.
WMV (Windows Media Video): Once again, we're talking about the codec, not the Windows Media Video container format. While not as common as MPEG-1, there's still a lot of WMV content available. Again, it's probably best to avoid using this.
H.264 / MPEG-4 AVC: H.264, at lower bit rates, delivers fairly high-quality video. H.264 will likely become the most common codec used: Adobe supports it in Flash, HTML5 canvas can use H.264, YouTube is steadily moving to H.264, and Apple fully supports it. While creating a video compressed in H.264 might not play on older devices, it's a sure bet going forward.
The Right Container: Flexible and Usable
I'm only going to touch on commonly used container formats you'll encounter currently. Each serves different purposes and audiences, and which you choose depends on what you want to accomplish. Since container formats also carry audio along with them, we'll touch on audio codecs.
When you actually render your video in your video editing package, you'll be creating a container file, which will include the compressed video and audio, as well as the information needed by the rendering device's data format, so the actual video and audio can be decoded by the target hardware. This is why knowing the final destination for your video is critical to choosing the best container.
Unlike codecs, the usage models of container formats tend to overlap heavily. These are the most common ones in use.
Containers for Archiving and Capturing
As mentioned with codecs, you need to pick the highest quality archive medium. Most consumers may simply want to store video in a way that's easy to stream to other PCs on the network--or even over the Internet--but you don't want it to look like a pixilated mess. The right container will help you strike the right balance between quality and streamability for your particular needs.
Advanced Systems Format: ASF is a Microsoft-based container format. You'll see various file extensions for ASF files, including .asf, .wma, and .wmv. Note that a file with a .wmv extension is probably compressed with Microsoft's WMV (Windows Media Video) codec, but the file itself is an ASF container file.
ASF files can, in theory, contain video and audio files compressed with any codec. In practice, it's playback that can become a problem, particularly with video compressed with H.264 codecs. If you're planning on remaining within the Microsoft universe, ASF is fine, but you might have problems with non-Microsoft media.
Audio Video Interleave: AVI is an older Microsoft container format. It's still fairly common, but you probably won't want to use it with new projects.
QuickTime: QuickTime is Apple's own container format. QuickTime sometimes gets criticized because codec support (both audio and video) is limited to whatever Apple supports. This is true, but QuickTime supports a large array of codecs for audio and video. Apple is a strong proponent of H.264, so QuickTime files can contain H.264-encoded video.
MP4: People sometimes confuse MP4 files with QuickTime, but they're actually different standards. MP4 is another container format developed by the Motion Pictures Expert Group, and is more technically known as MPEG-4 Part 14. Video inside MP4 files are encoded with H.264, while audio is usually encoded with AAC, but other audio standards can also be used.
MPEG and BDAV MPEG-2 Transport Streams: These are the container formats used in DVDs and Blu-ray discs, respectively. The VOB (Video Objects) container file format is a subset of the MPEG transport stream, and is used specifically in DVD video creation. (VOBs can also hold other types of data, but that's beyond what we're discussing here.) MPEG-2 Transport Streams, as the name suggests, uses video compressed with MPEG-2 Part 2 encoders, but it's actually not limited to MPEG-2. MPEG-2 TS data can also be compressed with H.264 and VC-1, since those are also defined as part of the Blu-ray standard. Audio files can be Dolby Digital (AC3) files, Dolby Digital Plus, Dolby Lossless, DTS, DTS HD, and Linear PCM (uncompressed) multichannel audio data.
AVCHD: This is the standard container used by many camcorders. Video captured with these devices is compressed with the H.264 AVC codec. Audio is encoded as Dolby Digital (AC3) or uncompressed linear PCM.
Flash: Adobe's own container format is Flash, which supports a variety of codecs. More recent Flash video is encoded with H.264 video and AAC audio codecs, but don't expect all Flash sites to use only those codecs, particularly if the video was created and encoded in years past.
Others: A variety of other formats are widely used, particularly for delivering video over the Internet. These include Matroska (.mkv), OGG (and the related containers OGM and OGV), and DiVX.
How to Use Your Codecs and Containers
First, let's consider what amateur videographers who are creating and editing their own videos need to consider. One key thing you'll have to invest in is storage--lots of it.
My own video projects consist of mixed video and audio, plus photographs. I shoot video using digital HD camcorders that record AVCHD files, but I often get files delivered to me in QuickTime (.mov) and AVI formats. I have a few older files rendered in MJPEG, and someday I'll probably transcode those to a more modern format.
All these live on a combination of a 2TB RAID 1 array on my production PC, or on a 4TB home server attached to the network. So far, I haven't had to archive off any data, but if I do, I'll probably use external hard drives, rather than tape-based or optical-disc-based media.
Editing video in Adobe Premiere Elements 9.I tend to keep videos on my home server in their original formats, and to use Adobe Premiere Pro CS5 to create videos that are delivered via disc formats; my most recent projects involved Blu-ray delivery.
If you're more interested in playing other people's videos instead of making your own, your needs will be different--if you plan on ripping your personal collection of DVDs so you can stream them over your home network, most container formats should do fine. However, you might want to use the format that's best suited for your delivery vehicle. For example, if you're using the freely available VLC Media Player and all the client hardware in your home consists of PCs or Macs, ripping to MP4 containers is a good choice--you get a good mix of compression versus storage requirements.
On the other hand, if you're storing video on a home server, but delivering it to a set-top box or a portable media player, you'll need to know what that particular device supports. Right now, most networked CE devices support a mixed bag of standards, and you need to know which formats will play. You're almost always safe encoding in MPEG-2 in those cases, but high-quality MPEG-2--particularly high-definition video--can consume a lot of storage space.
Looking Forward
Right now, so many codecs and containers are available that it's hard to ensure your video can be watched by everyone out there. The good news is that the future seems to lie with variations on the H.264 codec and MP4 containers. If you store your video in those formats today, transcoding to other widely supported formats (QuickTime, Flash, ASF) becomes pretty simple.
I've really only scratched the surface on codecs and containers. It's enough to get you started, but if you want to dive deeper, here are a few online resources.
Wikipedia: Wikipedia offers a good starting point if you want to dip your toes a bit deeper. Check out the entries on Comparison of Video Codecs article and Comparison of Container Formats. The descriptions are terse, but these entries have lots of links to deeper articles.
Master New Media's Video Encoding Guide: Robin Goode's article on codecs and container formats is a great jumping-off place, with links to other great articles, plus good basic information.
·Multibitrate support — ability to shift quality
depending on bandwidth and computer power. HTTP progressive delivery consumes
more bandwidth because it's not intelligent enough to throttle the delivery
(for example, a 30-minute video will be fully downloaded whether the user
watches it or not).
·Seeking within the video — ability to move around within a
long-format video without downloading it first
·Bandwidth control — ability to manage download
bandwidth to not disrupt other applications
·Support for live streaming with DVR and real-time protection
using Adobe Access
To deliver a streaming experience over HTTP, media assets need to go through a
fragmentation process that can also apply content protection (called
fragmenting), and a special module installed in the HTTP server is required.
The player can be built using OSMF, just like progressive download.
·Reach — Flash Player is a cross-platform browser plug-in
that delivers breakthrough online experiences to over 99% of Internet users.
·Open standards — HTTP Dynamic Streaming is built
on standards and deployed using standard HTTP servers (Apache), standard media
format (MP4 fragment) using standard codecs (H.264/AAC), open APIs (Flash
Player), and an open source framework for building media players (OSMF). The
file format will also be published, enabling advanced use cases of the format.
·Live publishing options — HTTP Dynamic Streaming supports
a separate process for packaging and protecting live content — allowing any
RTMP stream to be easily converted to a file format that can be delivered
through HTTP.
·Interactivity — On the Flash Platform, media
delivery can be synchronized with real-time interactivity and robust logging,
all within the same application. Flash Player is also used by over 70% of web
games, making it easy to add even more social and interactive experiences to
media.
·Content protection — With Adobe Access support in
Flash Player 10.1, Adobe can offer a robust, protected solution for content
delivery and monetization.
HTTP Dynamic
Streaming (HDS) enables on-demand and live adaptive bitrate video delivery of
standards-based MP4 media over regular HTTP connections. HDS lets you leverage
existing cache infrastructures and provides tools for integration of content
preparation into existing encoding workflows.
HTTP Dynamic streaming enables high-quality (H.264 or VP6), network-efficient
HTTP streaming for media delivery that is tightly integrated with Adobe® Access
software for robust content protection in the Adobe Flash® Player 10.1 or later
and Adobe AIR® 2 or later runtimes. This open format solution allows online
publishers to leverage existing network and cache infrastructures to
efficiently deliver media content to the Adobe Flash Platform. Adobe Media
Server software will continue to be a great option for streaming, multiway
communication, as well as advanced interactive experiences such as quick start
times and quick seeking. Like Adobe Media Server, HTTP Dynamic streaming
supports quality of service (QoS) monitoring, adaptive bitrate streaming, and
DVR functionality. The HTTP Dynamic Streaming workflow includes content
preparation tools, fragmented MP4 files that are HTTP cache‐friendly, a
playback framework (Open Source Media Framework, or OSMF), and options for
protected streaming powered by Adobe Access, continuing to make the Flash Platform
the choice for reliable delivery of protected, high-quality playback
experiences.
HTTP Dynamic Streaming utilizes the same HTTP server technology used to
delivery progressive downloaded video. The new technology is different because
it adds:
HTTP Dynamic Streaming is designed for online publishers that deliver to large
audiences requiring high capacity and scalability to meet traffic peaks or
those customers with high-quality video leveraging the benefits and reach of
the Adobe Flash Platform.
Adobe provides a full-featured HTTP delivery solution with the greatest reach
of any media delivery platform.
Thursday, November 1, 2012
HLS (HTTP Live Streaming) Overview
HTTP Live Streaming is an HTTP-based media streaming communications protocol implemented by Apple Inc. as part of their QuickTime and iPhone software systems. The protocol is in the first stage of being submitted to the IETF as a proposed Internet Standard.
The “Live” in the name is a bit misleading. HLS has many advantages for on-demand video playback as well as for live events. Companies that use HLS can reduce bandwidth expense and improve user experience by optimizing video quality based on network conditions.
Is HLS the same as HTTP Progressive Download?
No. HTTP Progressive Download simply enables playback of a full video file to start prior to completing the full download of that file. This is done primarily by placing the video’s atom (e.g. “table of contents”) at the beginning of the file.
HTTP Progressive Download is a very common technique used to emulate a streaming experience today. However, in many ways it is inferior to true adaptive streaming.
The quality of the file is pre-determined. A user watching from a mobile connection on a 3 inch screen will have the same video as a user watching from a cable modem connection on a 1080p TV at home. The player is unable to dynamically adjust based on the user’s network and screen conditions. Furthermore, if a user starts in a high-bandwidth environment, then moves to a low-bandwidth environment, HTTP Progressive Download is completely unable to keep pace. HLS, however, handles this scenario gracefully with minimal rebuffering and lag.
Security is limited. If a user gets access to the URL, they can download and share the entire file. HLS can be instrumented to include dynamically changing security tokens with each 10-second clip.
Does your app support HTTP Live Streaming?
Yes! my Apps have optimized the delivery method to match each device's strengths. HTTP Live Streaming is the preferred video delivery method for iPhone, iPad.
(a) (b)
(a) (b)
(a) (b)
