Streaming MPEG video over wireless link QoS in Digital In-home Networks PROGRESS project EES.5653 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Agenda I-frame delay (summary on the approach) Progress since May 2004 Future plans Demo 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Video over wireless link Typical scenario: video transmission from a set-top box to the (mutiple) screens wireless Between 5 and 13 seconds a microwave oven is on; Δt=50ms Wireless link: Low and highly variable throughput 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Sender/receiver communication (RTP-based) video source video sink Packets get lost here sender buffer receiver buffer MAC retransmission mechanism - Latency or playback delay. - What the jitter is. - Why do we need buffers? The bigger the buffers – the higher the latency, the less the jitter. If we want lower latency (par example conferencing), we want smaller buffers. (In case of RT video – conferencing) The bigger the buffers – the less probability of data loss - So, we have a dillema – we need to find how to minimize latency and still provide data delivery. - Explain why it’s not meaningful to use the sender buffer bigger than the receiver buffer. - Explain that the size of the receiver buffer is oftern limited and that for sake of lower latency we may want smaller buffers - With smaller buffers more data will get lost That’s why we need to consider sending first of all what is most important. If we need to drop data, then we drop pieces which influence our quality leas wireless interface (sender) wireless inerface (receiver) 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

I BBPBBPBB(I) MPEG encoding GOP (group-of-pictures): Frame types: I, P, B Typical GOP structure and dependences: I BBPBBPBB(I) So, losing B frames is less undesirable than P frames. Same with P and I accordingly. 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Importance of I and P frames Missing of I/P frames causes video artefacts A complete stream only missing B frames has no artefacts In worst case you only get 8.3fps from originally 25fps 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Cumulative weight of B-frames An example of a 5Mbps stream (LOTR) B-frames make up more than 50% of the whole bitrate 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Link layer approach Sender Application/ encoder OS network stack MAC-retransmissions Application/ encoder Selectively drop frames here video stream IP packets OS network stack Explain here what the MAC retries means, how it influences the fullness of the scheduler buffer, how the jitter occurs. Retries parameter lets us specify the trade-off between reliability of the wireless link and it’s throughput scheduler buffer 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

I-frame delay (IFD) Stream generated by application Transmitting under low and variable throughput: some frames take longer time Frames displayed at receiver – NN 1, 4, 5, 8 are skipped 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Pros and cons of link layer approach We only need to modify sending part it will work with any terminals supporting RTP reception and equiped with a general MPEG decoder due to RTP (UDP-based), it can be used for broadcasting It is very reactive against fast network fluctuations Requires access to wireless interface should be implemented at every sending device 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Deployment of IFD ASL, SC (Ewout Brandsma, Eric Persoon) CE: “Connected Planet” project (Tom Suters, Daniel Meirsman) SLx00 products (“Streamium”) CES at Las Vegas in June 2005 (with CE) CRE in June 2005 (with ASL) 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Progress since May 2004 A publication submitted to WoWMoM 2005 A demo set-up created a number of successful demonstrations given Deployment of IFD into real projects started (SC & CE) Future work made concrete (coming slides) Yesterday IFD proved to work with a Linksys AP IFD and “wired + wireless” network streaming to wireless CE devices (such as HotMan-2) new 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Simulator (based on ns2) Further work (I): Evaluation of IFD – models, simulations and optimizations Simulator (based on ns2) variations of network topologies variations of algorithms/buffer sizes for IFD variations of video stream (GOP pattern variations, bit-rates, coding standards etc) Optimal settings are the simulation goal 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Future work (II): IFD above transport layer we don’t have direct access to the wireless interface we don’t want to modify it we want to use it with both wired/wireless networks we want it over a reliable transport protocol ... Then we would like to look at the tranport layer implement the same idea in the application layer above TCP (master-student working on that) 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Future work (III): IFD + SNR scalability (together with Dmitry) The goal is to handle even higher variations in the link bandwidth KISS project at NatLab is implementing it 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653

Welcome to the demo! (given after the meeting) Questions? 1-Jan-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking PROGRESS project EES.5653