Monday, June 25, 2012

Linux - Yum "Cannot find a valid baseurl for repo" on CentOS 4

If you encounter this error and you are using CentOS 4, it means that you need to update your yum repository url.

CentOS 4 is obsolete and they changed the repo url. The following will help you to resolve it

1. From your CentOS machine, cd /etc/yum.repos.d

2. Back up your CentOS-Base.repo to CentOS-Base.repo.bak. Then, rm CentOS-Base.repo to remove it

3. Create a new CentOS-Base.repo with vi CentOS-Base.repo

4. Paste the following to CentOS-Base.repo and save it (actually file is at http://vault.centos.org/4.9/CentOS-Base.repo)

[base]
name=CentOS-$releasever - Base
baseurl=http://vault.centos.org/4.9/os/$basearch/
gpgcheck=1
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1
priority=1

#released updates 
[update]
name=CentOS-$releasever - Updates
baseurl=http://vault.centos.org/4.9/updates/$basearch/
gpgcheck=1
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1
priority=1

#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
baseurl=http://vault.centos.org/4.9/addons/$basearch/
gpgcheck=1
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1
priority=1

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
baseurl=http://vault.centos.org/4.9/extras/$basearch/
gpgcheck=1
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1
priority=1

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
baseurl=http://vault.centos.org/4.9/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1
priority=2

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
baseurl=http://vault.centos.org/4.9/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1 
priority=2

Sunday, June 10, 2012

RTP - Lip Sync Part 2, The Overview

In part 1, RTCP SR is discussed. In this part, I am going to talk about the overview of lip synchronization on receiver side. A streaming RTP server usually send you the following

1. RTCP SR
2. RTP video packets
3. RTP audio packets

The server will send these data in a synchronized way. In a synchronized way mean a video/audio should be sent in a constant interpacket interval. In perfect situation, the receiver can simply receive these constant time-spaced packets at receiver and playout directly. However, this is impossible. The are many factors that could cause a delay on these contant time-spaced packets. Some of the exmaples are

1. Network jitters - this will cause the packets to arrive in variable timing
2. Packets errors - error correction/missing packets
3. System delay - decompression/queuing/system latency

In general, you need to consider these when you are calculating the playout timing. Before I talk more about playout timing, let's list down the operation needed upon RTP packets received at the network interface

1. Received the packets in NIC card
2. Raw packet data will be read into the program
3. RTP packet processing such as depacketizing and group data into video/audio frame
4. Calculate the playout timing for each frame.
5. Insert these frame into a playout buffer, usually a linked list, and sorted by playout timing.
6. Calculate the playout delay with the consideration of operations such as system jitter, decoding, etc...
7. Playout the frame

For the first 3 steps, if you have a RTP client system, you shouldn't have any issue. The only thing you need to know is how to group RTP payload into packet frame. Usually, audio is self contained and only a single packet per frame. For video, usually it is fragmented into multiple packets. For packets that are being to the same frames, they will have then same RTP timestamp and the last packet will have a market bit on. So, all you need is to check the timestamp and group all packets that has same RTP timestamp together. Make sure their sequence number are in ascending order and the last packet has marker bit on.

For point 4, you need to use RTCP SR to calculate the playout time of the frames. For a generic example, in a 30FPS video, each frames should have a constant 33ms interval between each frames' playout time. How to calculate playout time will be shown in later part

For point 5, you should have a playout buffer to hold audio and video frame. A playout buffer usually is a time-sequenced linked list that is sorted by playout time in acending order.

For point 6, although you have a playout time, that will only tell you which frame should be playout in what specific time. However, we need to know the relative presentation timing from each frame. For example, if you have frame A and frame B and frame A is served, you want to know how long to wait before serving frame B. That wait is the playout delay. To determine playout delay, you have to take decoding, system jitter, etc.. into consideration.

For point 7, playout the frame. This can be sound simple. But, sometime, you may need to take graphic rendering, audio system buffer playout, etc... into consideration. Those variable may affect the accuracy on how you play out the frame.

Saturday, June 9, 2012

RTP - Lip Sync Part 1, RTCP Sender Report

This is a multi-series of RTP lip synchronization post. Lip synchronization is a very very tedious topic that requires you to understand multiple RTP concepts. So for part1, I will talk about RTCP sender report (SR)

The purpose of RTCP SR is to provide information on the media that had recently sent by the server.

See RFC 3550 6.4.1, it has a complete packet format for RTCP SR.



SR is identified by packet type of 200 in the PT field

The most important part of SR for lip sync is NTP timestamp field. The NTP timestamp is a 64 bits unsigned value that denote the time of the SR is sent. For the upper 32 bits (MSW), it denotes the seconds since Jan 1 1900. For the lower 32 bits (LSW), it denotes the fractions of a second. Although it is using NTP timestamp format, it does not necessarily need to be synchronized with Network Time Protocol server.

Since NTP timestamp field is second since Jan 1 1900, you need to add 2,208,988,800 to NTP time to make it to UNIX time (second since 1970).

Now talk more about fractions of a second. See NTP Timestamp will give you a better understand of NTP timestamp. So, fractions of second mean the decimal part of the seconds. For example, 2008-05-07T11:24:35.876-04:00, 876 is the fractional part of the second. In the later part of the series, I will tell how to get the fractional time of the NTP timestamp of SR.

The other important part of SR is the RTP timestamp. It is a RTP timestamp that represent this SR packet. When this SR is sent, some time must have elapsed, and thus, this RTP timestamp will not be the same as the previous RTP timestamp. This is important because SR RTP timestamp is used for inter-media synchronization.

See RTP - Lip Sync Part 2, The Overview