Video Conferencing System EECS150 Spring 2008 Shah Bawany 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Checkpoint Overview (1) PIP Display Text Interface DCT (Blackboxed) Huffman Coder Packetizer/Depacketizer Transmission Protocol Extra Credit 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Checkpoint Overview (2) Transceiver Transmission Protocol FSM Packet Buffer Packet Buffer Huffman Coder Huffman Decoder DCT IDCT From CP2.5 To CP2.5 9/16/2018 EECS150 Spring 2008 - Shah Bawany

EECS150 Spring 2008 - Shah Bawany 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 9/16/2018 EECS150 Spring 2008 - Shah Bawany

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 9/16/2018 EECS150 Spring 2008 - Shah Bawany

EECS150 Spring 2008 - Shah Bawany Quantization Since the frequency component coefficients generated by the DCT span such a large range, relatively small changes to the lower order bits don’t 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 9/16/2018 EECS150 Spring 2008 - Shah Bawany

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 0’s, 1/8 1’s, 1/8 2’s and 5/8 3’s. 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 < 2… Success! Why those specific codewords? We want to make sure they’re prefix free 9/16/2018 EECS150 Spring 2008 - Shah Bawany

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 as:0 -> 3 0 -> 3 10 -> 2 111 -> 0 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/16/2018 EECS150 Spring 2008 - Shah Bawany

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 |, (N<0) ? 1’b1 : 1’b0} For example 5 would be 0001010, while -12 would be 000011001 Your coder will accept parallel inputs and output a bitstream serially 9/16/2018 EECS150 Spring 2008 - Shah Bawany

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 don’t 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 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Transmission Protocol Our protocol this semester will contain the following packet formats: SYN: Master’s request to establish a connection SYNACK: Slave’s 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 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Transmission Protocol (2) Transmitting fast increases the probability of error, so there’s 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)) - 1]Tretransmit + Ttransmit 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Transmission Protocol (3) Timeout Master Reset SYN SYNACK Clock Slave Reset DATA Timeout Slave Wait SYN SYN ACK DATA GET DATA DATA Timeout 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Transmission Protocol (4) Master Slave SYN SYNACK DATA0 DATA1 DATA 1[Lost] (wait for retransmit) DATA1 [re-TX] DATA2 (serves as ACK) DATA2 9/16/2018 EECS150 Spring 2008 - Shah Bawany

Transmission Protocol (5) MPDU Src Dst WL Payload Header Video Data 1-Byte header 31-Byte bistream Packet Type Seq ID 7:3 2:0 9/16/2018 EECS150 Spring 2008 - Shah Bawany

A Sample Scenario 9/16/2018 EECS150 Spring 2008 - Shah Bawany Subimage 31 25 10 9 30 20 18 23 4 2 1 98 97 22 5 3 DCT Original Image 99 -5 10 4 20 18 7 -9 2 12 1 2 -1 Quant. Output from the Huffman Coder: 00001100010101110010000100010111111101111111111111111111111111111111111111111111111111 146 bits from an original 448! (Note this is not a real DCT result, but it simulates actual behavior) 9/16/2018 EECS150 Spring 2008 - Shah Bawany