Nathan Stratton’s Homepage

Software

Reality of H.264 SVC

by on Feb.04, 2013, under Software, Telephony

I frequently get asked about H.264 SVC, so I decided to write this post to share my thoughts. My background is in the service provider space, so let me first say that what I am about to talk about relates to SVC used for real time two way communication.

Lets first start with some background. Scalable Video Coding, (SVC) is the Annex G extension of H.264 AVC approved in July 2007. As the name implies, the idea behind SVC was to create a bit stream that allows scalable subset of bit streams that represent different resolutions, quality, and frame rates. You can think of SVC as layered stream where the decoder is allowed to decode all, or just the base subset of the streams depending on the desired quality. If all that is needed is the base stream, the decoder simply discards the packets from the other layers.

If you do a search on H.264 SVC, you quickly are overwhelmed by the flood of pages singing the praises of SVC. The sad part is, most of them are authored by marketing guys rather then technologist who understand the technical differences between SVC and standard H.264 AVC.

Lets first take a look at some of the proclaimed benefits of SVC and the reality when it comes to service providers.

SVC allows up to 20% packet loss without effecting quality.

A number of vendors use SVC layers to provide redundancy information to a bit stream. Providing redundancy is nothing new, a 8 disk RAID 5 array can lose 1 disk without any information lost. A RAID 6 array is able to lose 2 disks without losing any data. This redundancy however comes at a cost, depending on the desired level of redundancy extra data is sent making the total bit stream 10 – 30% larger. Many times this increase in bandwidth may itself lead to quality issue, however lets for right now pretend that it is worth sending the extra data. I have seen many tests showing how great using SVC layers to provide redundancy is. They show lots of loss and you can clearly see that quality is far superior to standard AVC. However, if you dig deeper you start to see the flaw of this approach. If you run a IP network, you know that most of your packet loss is not random, it is burst mode. A routers queue gets full and a bunch of packets are dumped on the floor. In cases like that, the most common packet loss on the internet, redundancy information does not do a thing because the base stream AND and the redundant information are both lost!

SVC allows a single encoder to provide different resolution, quality, or frame rates.

Yes, this is very true, in fact, it is what SVC was designed for. The issue becomes how relevant this is in two way real time video communication on the internet. The problem is that ALL of this data is in the full bit stream. As I mentioned before, if a decoder does not need the more advanced levels, it simply discards the packets, they are still sent! Many vendors have a solution to this, you simply buy their boxes and put them all over your network and your customers networks. The devices then drop the unneeded layers. While I find this approach great from the guys selling more boxes, from a network engineering side there are many drawbacks.

SVC is a standard, just like H.264 AVC

Again, this is correct, however just because there is a standard for SVC it does NOT mean that vendors who are deploying SVC are able to inter operate. Lets face it, in our industry most of our “standards” are know as RFCs out of the IETF. I am a big fan of the IETF and I love the process. It has HUGE some advantages over other standards bodies such as the ITU where standards become inch thing documents and the process is sometimes more political then technical. At the same time, lets not forget that RFC stands for “Request For Comment”, many times they are only a dozen or so pages in length where much of the implementation is left to the reader. Some “standards” are only internet-drafts that are published by only 1 or 2 people that never turn into a RFC from a company who just wants to say they are following a “standard”. We are still today working out issues with H.264 AVC over the public internet, SVC with a much smaller following in my opinion will never be “standardized” by the market, something that is much more crucial then the technical standard.

SVC provides a totally new way of offering low cost conferencing

One interesting approach to SVC is the idea of an application router that simply routes SVC layers between users rather then a typical MCU approach that decodes and then encodes the video stream. While I like this is interesting, I don’t think it is more then a niche play. First let me point out that this idea is far from new. Skype and others who do not have centralized MCUs have been routing streams between users for years with H.264 AVC and other CODECs. A big problem with this approach is that it shifts the burden from a centerlized MCU to in many respects the client. If 8 people are in the conference, it is forced to decode 7 video streams rather then just one. The bandwidth that is required to receive and send video to / from 7 other users is far greater then a single flow to a MCU. To make matters worse it goes in the opposite direction that the industry has been trying to move. We have been working on technologies like rtcp-mux and bundle to allow voice, video, + the 2 RTCP flows to all be on one flow rather then 4. With the application router approach, even if rtcp-mux and bundle are used, you still require port bindings for each of the other participants audio, video and signaling streams.

SVC and quality based on users bandwidth.

While closely related to encoder being able to provide different resolutions, quality or frame rates, this is more focused on the end device. The issues of last mile bandwidth has always been a real issue when it comes to two way video services. The idea here is that the device can somehow request just the layers it has bandwidth for rather then everything. However if we look at last mile bandwidth closer, this is trying to fix the wrong direction! The problem lies in that fact that most last mile bandwidth is asymmetrical, I wont bore you with the reasons, but upload speed is normally a fraction of download. If a device could back off on what is is receive (the big direction), it does nothing for what it is sending. Does the device simply send AVC, or does it try to send base plus high quality layers using SVC up the small bandwidth side of the pipe? If one wants to be smarter about this, a better approach would be to use standard AVC on both ends and allow both encoders to be adjusted in real time rather then at the start of the call.

SVC encoding speed

The SVC guys like to say its faster, but I am sorry, in the real world it is not. Yes, encoding 1080p + 720p + VGA + QVGA with H.264 is generally slower then SVC with QVGA + the other layers, however why would we be sending ALL of that to one device? You are much better off encoding just the required video feed for each endpoint rather then trying to encode everything. The SVC guy will then say, but if you do it once with SVC you can send that same feed to everyone. While I think their are applications where the exact same content can be sent to every user, in the real world this is rarely the case. Different users want different layouts, options, etc, the world of pushing the same static thing to everyone is going away, people want it their way! If you add to this the issue of CPU and especially DSP optimization for AVC over SVC, it becomes even more clear.

 

Is SVC good for anything? Yes, believe it is, SVC is great for the content storage industry allowing them to store one video file with many different option levels. It’s great for the security industry, allowing video feeds to be processed by systems at a base level and then expanded in quality if something needs to be analyzed further. However, I think most of the people making noise about SVC today are just looking for marketing spin, rather then real technical advantages.

 

Leave a Comment :, , , more...

Dracut PXE Boot with bonded interfaces

by on Mar.07, 2012, under Software

It’s taken me a while to get dracut PXE Boot working with bonded interfaces, so I wanted to take a moment and share.

My setup is as follows, 20 servers with dual gig ethernets connected to two Cisco 3750 switches connected togeter in a ring. The first ethernet, eth1 from each server are all connected to swich 1 with the 2nd ethernet, eth2 all connected to the 2nd switch. The ring configuration allows the switches to look like one larger switch, providing redundancy while still allowing for things like trunks spanning more then one switch.

Switch Configuration

The cisco 3750 is configured as follows:

interface Port-channel1
 description virt1
 switchport trunk encapsulation dot1q

interface GigabitEthernet1/0/1
 switchport trunk encapsulation dot1q
 speed 1000
 duplex full
 spanning-tree portfast
 channel-protocol lacp
 channel-group 1 mode passive

interface GigabitEthernet2/0/1
 switchport trunk encapsulation dot1q
 speed 1000
 duplex full
 spanning-tree portfast
 channel-protocol lacp
 channel-group 1 mode passive

The above config first sets up a port-channel, a bonded interface and sets the encapsulation to dot1q, the standard that allows VLAN tagging. Two interfaces are then configured I set the speed, duplex, and spanning-tree portfast to help speed up port setup time. The ports are both configured to used standared lacp and are both made part of the port-channel interface with the channel-group 1 mode passive command. The mode passive is important it does not setup the ports into the trunk group until the other end (our server) brings up the LACP trunk. This allows the server to do standard PXE Boot with DHCP and TFTP on the standard interface rather then failing because it was in trunk mode.

Dracut Configuration

Dracut allows you to boot a server with as little as possible hard-coded into the initramfs. To make the image I typed:

dracut dracut.img 3.2.7-1.fc16.x86_64
dracut –add-drivers bonding -f dracut.img

The first line builds the image and the 2nd line adds bonding support to the image, note that the kernel name is important, you can pull that with uname -r. The Dracut configuration lives on the tftpserver in the pxelinux.cfg/default file. Mine looks like:

prompt 1
default Fedora-16_3.2.7-1.fc16.x86_64
timeout 10
serial 0 115200
console 0

label Fedora-16_3.2.7-1.fc16.x86_64
kernel vmlinuz-3.2.7-1.fc16.x86_64
append initrd=dracut.img root=10.10.0.4:/diskless/Fedora16_020303 console=ttyS0,115200 biosdevname=0 bond=bond0:eth0,eth1:mode=4 bridge=ovirtmgmt:bond0 ip=ovirtmgmt:dhcp

This file configures a serial console on the first serial port as a speed of 115,200, it passes to the tftpserver the kernel file with the dracut configuration. A breakdown of the dracut line is as follows:

initrd=dracut.img                                                                         This is the name of my dracut image.
root=10.10.0.4:/diskless/Fedora16_020303                         
NFS IP and path for the root image.
console=ttys0,115200                                                                Sets the serial device and speed.
biosdevname=0                                                                           Keeps the old eth naming scheem.
bond=bond0:eth0,eth1:mode=4                                               Bonds eth0 and eth1 using mode4.
bridge=ovirtmgmt:bond0
                                                           Creates bridge ovirtmgmt attached to bond0.
ip=ovirtmgmt:dhcp                                                                       Run DHCP on ovirtmgmt interface.

Now the problme….

So far we have a setup that will correctly DHCP and PXE Boot, the server will have access to Vlan 1, but not the other VLANs, this is because the switch LACP port is not yet running as a trunk. Cisco can do this automatically if there is a cisco on the other end via cisco proprietary protocol, but the Linux box does not support this. To get around this problem and still PXE Boot boot we have a script that adds “switchport mode trunk” to the interface Port-Channel. Once this is done you will be able to talk on all the VLANs you have setup. This is an ugly hack, but so far is the only way I have found to have a cisco work in this setup.

3 Comments more...

Hello World, the current temp is:

by on May.02, 2010, under Hardware, Software

I have wanted to start playing with micro controllers for a while now, I ended up selecting the Parallax Propeller chip because of its ease of use and I liked it’s COG design with 8 32 big cores working together.

My first test was connecting a 4×20 line LCD and a few DS18S20 1-wire temp sensors to the propeller chip. Everything was very easy to learn the LCD was interfaced with no external components and the 1-wire bus only required a 4.7K pull up resistor.

Propeller PDB with LCD and 1-wire bus

Leave a Comment : more...

Converting Citrix .xva to Xen.org .img

by on Jun.06, 2009, under Software

Xen is one of the coolest virtualization technologies out there. It comes in may flavors, the two largest being the bleeding edge xen.org open source project and the commercial (Citrix) version. There are things I love about the commercial version, but they lost me only supporting windows in their XenCenter administration interface.

The file formats of the commercial and open source Xenare totall different. The open source is a standard image file, you can mount it, fdisk it, whatever you would like. The Citrix Xen Virtual Appliance .XVA file is quite different. It is actually a tar file with ova.xml meta data and directories starting with Ref full of 1M files that make up the drive volumes of the virtual image.

To convert .xva to an xen .img file you first untar the image:

tar -xvf {image}.xva

Then grab this handy utility and run it on your untared data, as an example:

python xenmigrate.py –convert=Ref:3 {image}.img

This will paste all of those files back together, starting at 00000000. Note I have had problems running this script on Centos 5.x.

10 Comments : more...

Looking for something?

Use the form below to search the site:

Cool Links!

A few highly recommended links...