Video Conferencing System

1
Video Conferencing System

• EECS150 Spring 2008
• Shah Bawany

2
Checkpoint Overview (1)

• Checkpoint 2.5
• PIP Display
• Text Interface
• DCT (Blackboxed)
• Huffman Coder
• Packetizer/Depacketizer
• Transmission Protocol
• Extra Credit

3
Checkpoint Overview (2)
Transceiver
Transmission Protocol FSM
Packet Buffer
Packet Buffer
Huffman Coder
Huffman Decoder
IDCT
DCT
From CP2.5
To CP2.5
4
Checkpoint 2.5

• Checkpoint 4 requires you to finish all the
  requirements for Checkpoint 2.5 including
• Text display at the bottom of the screen
• Picture-in-picture display
• Subsampled local and remote video stored in SDRAM
• Modified address counters for wireless video
  processors

5
Discrete Cosine Transform

• In general the DCT is a multi-dimensional
  transform much like the Fourier Transform
• We will be using a 2-D transform on 8 x 8
  subimages from our compressed frame
• It generates real-valued spatial frequencies in a
  new 8 x 8 matrix
• Why we do it?
• Images are generally low frequency, so many of
  the frequency components will zero out
• It concentrates much of the information into
  values clustered in to the upper left corner of
  each matrix
• This gives us a more tightly clustered
  distribution allowing us to exploit variable
  length coding as an added compression technique

6
Quantization

• Since the frequency component coefficients
  generated by the DCT span such a large range,
  relatively small changes to the lower order bits
  dont make much of a difference on the appearance
  of the resulting image
• We can take the real-valued (signed fixed point)
  DCT coefficients and simply truncate them to
  integer multiples of 8 to save some space
• Greater quantization means less space is used and
  more information is lost.
• We have determined a suitable threshold at which
  the appearance degrades significantly

7
Prefix-Free Variable Length Coding

• When we have a source where some symbols are more
  frequent than others, it can be beneficial to
  convert each of the symbols into a unique
  compressed codeword with length inversely
  proportional to its frequency of occurrence
• For instance if we have a collection of 2-bit
  values composed of 1/8 0s, 1/8 1s, 1/8 2s and
  5/8 3s.
• Uncompressed expected length 2 bits
• Compressed using the scheme
• 3 0
• 2 10
• 1 110
• 0 111
• 5/8 2(1/8) 3(1/4) 1 5/8 lt 2 Success!
• Why those specific codewords?
• We want to make sure theyre prefix free

8
Prefix-Free Variable Length Coding (2)

• Prefix free means that if we took the codewords
  as a bitstream, we would know when we have
  finished reading a single codeword
• For instance, using our previous coding scheme
  the bitstream 0010111010111101 will be decomposed
  as0 -gt 3
• 0 -gt 3
• 10 -gt 2
• 111 -gt 0
• 0 -gt 3
• 10 -gt 2
• etc
• You can see that there is no ambiguity because
  once we have looked at the first 0, there are no
  other codewords that start with 0

9
Prefix-Free Variable Length Coding (3)

• More formally, for all X in our code alphabet C,
  there exist no codewords Y in C such that Y is a
  prefix of X
• Luckily for you, we have provided a static coding
  scheme that is based on frequency of occurrence
  of values in our DCT coefficient matrices
• We will be using signed unary-binary code, which
  works as follows
• 0 maps to 1
• All other values N map to
• log2N b0, N , (Nlt0) ? 1b1 1b0
• For example 5 would be 0001010, while -12 would
  be 000011001
• Your coder will accept parallel inputs and output
  a bitstream serially

10
Packetizing / Depacketizing

• The output of the Huffman Coder is a bitstream
  and we wish to send packets containing 31 bytes
  of raw video data
• You should completely fill each data packet,
  ignoring where symbols start and end
• Assuming that you dont lose any packets, the
  bitstream can be completely recovered and since
  the code is prefix-free, there is no need for
  delimiters or special grouping
• You can accomplish this with shift registers and
  FIFOs

11
Transmission Protocol

• Our protocol this semester will contain the
  following packet formats
• SYN Masters request to establish a connection
• SYNACK Slaves acknowledgement / acceptance of
  connection attempt
• DATA compressed video stream data
• To ensure that the protocol is lossless we must
  retransmit if a packet is lost
• To simplify the protocol and reduce overhead, we
  simply send a packet and wait for receipt of any
  packet in response as an acknowledgement of the
  first packet
• In the event of failure, wait a specified amount
  of time and retransmit
• If successful, continue transmitting

12
Transmission Protocol (2)

• Transmitting fast increases the probability of
  error, so theres a tradeoff between decreasing
  retransmissions and increasing the rate of
  transmission
• For the sake of Checkpoint 4, you can find a
  reasonable transmission rate (once every 4ms like
  CP3 fast transmit)
• For extra credit you can have your solution speed
  up or slow down dynamically based on channel
  congestion by optimizing the equation
• (1/(1-p)) - 1Tretransmit Ttransmit

13
Transmission Protocol (3)
Timeout
Master Reset
SYN
SYNACK
Clock
Slave Reset
DATA
Timeout
Slave Wait
SYN
GET DATA
DATA
SYN ACK
DATA
Timeout
14
Transmission Protocol (4)
Slave
Master
SYN
SYN
SYN
SYNACK
DATA0
DATA0
DATA1
DATA 1Lost
(wait for retransmit)
DATA1 re-TX
DATA2 (serves as ACK)
DATA2
15
Transmission Protocol (5)
MPDU
Src Dst WL Payload
Video Data
Header
31-Byte bistream
1-Byte header
Packet Type
Seq ID
73 20
16
A Sample Scenario
Subimage
31 25 10 9 31 30 20 18
10 9 31 10 9 31 30 20
9 31 30 9 31 30 20 23
4 2 9 31 30 1 98 97
10 30 31 10 20 22 10 10
9 1 30 9 30 30 5 9
4 22 1 4 1 1 4 4
10 3 22 10 22 22 10 10
DCT
Original Image
99 -5 10 4 0 0 20 18
10 0 7 0 0 0 0 0
-9 0 2 0 0 0 0 0
4 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
12 0 1 0 0 0 2 2
1 0 0 0 0 0 0 0
-1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Quant.
Output from the Huffman Coder 0000110001010111001
00001000101111111011111111111111111111111111111111
11111111111111111
146 bits from an original 448! (Note this is not
a real DCT result, but it simulates actual
behavior)