Showing posts from June, 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

[base] name=CentOS-$releasever - Base baseurl=$basearch/ gpgcheck=1 gpgkey= protect=1 priority=1 #released updates [update] name=CentOS-$releasever - Updates baseurl=$basearch/ gpgcheck=1 gpgkey= protect=1 priority=1 #packages used/produced in the build but not released [addons] name=CentOS-$releasever - Add…

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

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 - 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 t…