Video Streaming over Home Network Peter van der stok

Transcription

1 Video Streaming over Home Network Peter van der stok Thanks to Michael van Hartskamp 22 June 2005 Universitat Politècnica of Catalunya Division, Content owner, Date(in numbers), ISO No 1

2 Home network example Internet Internet Internet in Ethernet switch 2

3 Management examples Load Source Destination source network server brake control 1 client Transport protocol Feedback 3

4 Contents 1. Video over home network 2. Transport driven video artifacts 3. Techniques to remove artifacts 4. QoS management 4

5 QoS chains Quality of video Size of video bit/s network Quality of network Bandwidth, delay Quality of renderer Processing power Quality of experience Perception by user 5

6 Network stream video transport frames Mbit/s 0.1 % loss 30 % loss link packets Ethernet switch 80 Mbit/s 5-24 Mbit/s 6

7 MPEG2 video Divide picture in 16*16 macroblocks Each macroblock is 4 blocks 8*8 block 7

8 Frame types I frames MPEG2 video P frames B frames Group of Pictures (GOP): Set of frames between two I frames IBBPBBPBBI or IPPPI, or II 8

9 Wireless video streaming Video frame contains packets With 30% loss no frame will ever be displayed Standard foresees retransmission from point to point 9

10 IEEE Protocol Interframe spacing in Courtesy of A. Tanenbaum 10

11 IEEE Link QoS Every received packet is immediately acknowledged Unacknowledged packet is repeated sending failed after n unacknowledged repetitions 0 < n < 256 Conclusion: under packet-loss, bandwidth decreases 11

12 Network stream video 3 Mbit/s transport frames Transport level Link level packets link stored Ethernet switch broadcast 1 Mbit/s 12

13 Contents 1. Video over home network 2. Transport driven video artifacts 3. Techniques to remove artifacts 4. QoS management 13

14 Two Internet Protocols Transmission Control Protocol, and Real-Time Transport Protocol TCP A receiver that accepted a packet, accepted all preceding packets in the sending order RTP All accepted packets return a production time with respect to the production time of the first produced packet 14

15 The Real-Time Transport Protocol (a) The position of RTP in the protocol stack. (b) Packet nesting. 15 Courtesy of A. Tanenbaum

16 The Real-Time Transport Protocol UDP header Source port UDP length 32 bits Destination port UDP checksum Control info Sequence number TimeStamp Synchronization source identifier Courtesy of A. Tanenbaum 32 bits 16

17 The Transmission Control Protocol TCP header 32 bits Source port Destination port Sequence number Acknowledgement number Header length Window size Checksum Urgent pointer Courtesy of A. Tanenbaum 17

18 TCP (2) Separation of acknowledgements and permission to send leads to variable sized windows Use of selective repeat (NAK) 18

19 TCP (3) sender Write 2K Write 2K blocked Write 1K Seq 0, data 2K Ack 2K, Win 2K Seq 2K, data 2K Ack 4K, Win 0 Ack 4K, Win 2K Seq 4K, data 1K receiver 0 4k empty 2k 4k Read 2K 2k Courtesy of A. Tanenbaum 1K 2k 19

20 TCP (4) Congestion control Assumption: packets are not lost over wires. Consequently, transmission time-outs are due to congestion Two windows maintained: 1. Receiver window 2. Congestion window And take minimum of both. 20

21 TCP (5) Congestion control Determine congestion window size: (slow start) Start with maximum segment After acknowledgement set window size to two Send n segments After acknowledgement set congestion window size to 2n Stop at 2n = treshold or no acknowledgement before time-out When treshold add one segment at the time 21

22 TCP (6) Congestion control When timeout Half treshold size And start slow algorithm 22

23 TCP (7) Courtesy of A. Tanenbaum 23

24 Single loss TCP RTP smooth Intermittent losses 24

25 TCP versus RTP behavior TCP Single loss A RTP

26 Bursty loss TCP RTP Intermittent delays Intermittent losses 26

27 TCP hick-up TCP Loss burst RTP

28 Bursty loss RTP-RTM Combines RTP and TCP properties 1. Allows the dropping of late packets 2. Allows retransmission of lost packets 28

29 TCP-RTM behavior Loss burst A TCP 2 1 TCP-RTM

30 Network stream 3 Mbit/s video TCP losses, artifacts + hiccups frames transport TCP hiccups RTP losses, artifacts packets link stored Ethernet switch broadcast 1 Mbit/s 30

31 Contents 1. Video over home network 2. Transport driven video artifacts 3. Techniques to remove artifacts 4. QoS management 31

32 Scalable video code Enhancement layer transmit Base layer 32

33 Perturbed wireless streaming Microwave on RTP unlayered RTP layered 33

34 Sending layers EL BL E1 E2 E3 E4 1 E1 E2 E3 2 E2 E1 3 E1 4 B1 B2 B3 B4 1 B1 B2 B3 2 B2 B1 3 B1 4 Layered video BL: Base layer EL: Enhancement layer B4 B3 B2 B1 E3 E4 E1 EL BL E4 1 E1 E3 2 E1 3 B2 B3 B1 B4 1 B2 B1 B3 2 B1 B

35 Group of Pictures (GOP) Visualization order for given GOP B1 B2 I1 B3 B4 P1 B5 B6 P2 B7 B8 P3 B9 B10 Transmission order for same GOP I2 I1 B1 B2 P1 B3 B4 P2 B5 B6 P3 B7 B8 I2 B9 B10 35

36 I-Frame Delay (IFD) I-frames lost I-frames delayed 36

37 IFD protocol Sufficient bandwidth B IP BP I PB I w S R 37

38 IFD protocol Insufficient bandwidth BP I B P P I PI w S R 38

39 Sender structure EL2 If S+W+EL1 empty: send (EL2) Choose queue EL1 If S+W empty: send (EL1) Packets Coming in BL IFD algorithm Remove Old packets SINK W buffer S buffer IF S filled: send (S) If S empty: (W) -> (S) 39

40 Control video transport Access control bandwidth frames Number of layers Layer size packets Slow feedback link stored Ethernet switch broadcast Fast feedback 40

41 Contents 1. Video over home network 2. Transport driven video artifacts 3. Techniques to remove artifacts 4. QoS management 41

42 IEEE e EDCF Priority is given through different interframe spacing. For priority i, the Arbitration Interframe Space is AIFS [i]. 42

43 Priorities according to 802.1p/q/D prio 7 NC 6 VO 5 VI 4 CL 3 EE 0 BE 2-1 BK name Network Control Voice (< 10ms) Video (< 100ms) Controlled Load Excellent Effort Best Effort default - Bulk 43

44 Prioritization Prioritization is based on IEEE 802.1p/q/D In MAC header add a tag with a user priority (so-called VLAN TAG) Any MAC (i.e., sender and bridges) that forwards this devices should implement multiple queues and give some kind of precedence to higher-priority queues 44

45 Typical Home Network Topology GW Wired backbone AP Server Renderer Renderer Wired backbone Wired and/or wireless renderers Wired and/or wireless servers Routers often only at the boundary of the network Renderer 45

46 Prioritization in practice So we now have a video stream going through, e.g., an access point Video Packets will queue up in AP; with the other packets. The AP will indiscriminately drop packets. Both streams are disturbed; the video user is unhappy Access Point 46

47 Prioritization in practice So we now have a video stream going through, e.g., an access point Video Packets will queue up in AP; with the other packets. The AP will indiscriminately drop packets. Both streams are disturbed; the video user is unhappy Now if priorities are assigned good chance that the video packets will get through and the other packets are dropped Access Point 47

48 Prioritization in practice So we now have a video stream going through, e.g., an access point Video Packets will queue up in AP; with the other packets. The AP will indiscriminately drop packets. Both streams are disturbed; the video user is unhappy Now if priorities are assigned good chance that the video packets will get through and the other packets are dropped But if both streams are video streams their priorities are the same and we are back were we started H H H H H H H H H H H H 48 H H H H H Access Point H H H H H = high

49 IEEE e MAC QoS extensions HCCA = Hybrid Coordinator Controlled Access QAP poll ack poll send ack send send QSTA QSTA STA Poll uses a short interframe space to grab the medium There is both a period of controlled access as a traditional contention period 49

50 IEEE e MAC QoS extensions HCCA = Hybrid Coordinator Controlled Access QAP poll ack poll send ack send QSTA QSTA Poll grants a transmit opportunity, there is no guarantee for success! send STA 50

51 IEEE e MAC QoS extensions Reservation Request QAP RR (Tspec) ack QSTA Parameters in Tspec are (amongst others) Mean Bandwidth, Peak Bandwidth, Delay Service Interval, Minimum Physical Rate Reservation request asks to poll such that STA can submit traffic according to the given specification (Tspec) The (manufacturer of the) QAP decides on the scheduler it uses. 51

52 What we achieved UPnP-QoS 1 finalized in January 2005 Goals (with hindsight) Support prioritized QoS at the link layer VLAN tagging In principle only needed to tag at Source But regeneration at hops is possible Create an extensible framework able to cover prioritized and parameterized QoS / scheduled access for IP traffic Non-goals Develop a new QoS mechanism Solve end-to-end QoS problem (Internet/access network) 52

53 The QosDevice service The QosDevice is a service (!) preferably running on every physical device in UPnP-devices such as MS/MR or Basic device MS QosDevice QosDevice QosDevice MR QosDevice QosDevice QosDevice Data flow Control flow 53

54 QosDevice actions Name Req. or Opt. 1 GetQosDeviceCapabilities R GetQosState R Static properties, e.g. type of interface (wireless, wired, ) Dynamic properties, e.g. ongoing streams SetupTrafficQos ReleaseTrafficQos R R This is what it is about GetPathInformation O GetQosDeviceInfo O 1 R = Required, O = Optional, X = Non-standard. Information on which devices are reachable from this devices To get additional QoSrelated information from devices up 54

55 QosManager and QosDevice The QosManager is the control point for the QosDevice service MS QosManager The QosManager also offers a UPnP service to the outside world QosDevice QosDevice QosDevice MR QosDevice QosDevice QosDevice Data flow Control flow 55

56 QosManager actions This is the action an AVCP could use to ask for QoS Name Req. or Opt. 1 RequestTrafficQos R UpdateTrafficQos R ReleaseTrafficQos R BrowseAllTrafficDescriptors R 1 R = Required, O = Optional, X = Non-standard. This makes it easy for an AV control point to change QoS, but it is not easy for the QosManager to realize as there is no equivalent action on a QosDevice! An AV control point can find out what streams are running and what QoS they asked for And this releases the QoS 56

57 QosPolicyHolder actions The overall QoS would benefit from applying a consistent policy throughout the network In UPnP-QoS we addressed this by the introduction of a QosPolicyHolder service. This service holds the policy. How it comes to policy is not defined Name Req. or Opt. 1 GetTrafficPolicy R 1 R = Required, O = Optional, X = Non-standard. Unfortunately there is no way to guarantee there is only one QosPolicyHolder service running in the network 57

58 The UPnP-QoS 1.0 high-level architecture Policy decisions are made by the QosPolicyHolder QosManager QPH MS QosDevice QosDevice QosDevice link MR QosDevice QosDevice QosDevice Data flow Control flow 58

59 The Traffic Descriptor structure: A_ARG_TYPE_TrafficDescriptor Most UPnP-QoS communication uses an XML structure called Traffic Descriptor which contains the following elements for the stream: TrafficHandle TrafficID SourceAddress DestinationAddress SourcePort DestinationPort IpProtocol QosBoundarySourceAddress QosBoundaryDestinationAddress AvailableOrderedTspecList / Tspec TspecIndex AVTransportURI AVTransportInstanceID TrafficClass ActiveTspecIndex OptionalPolicyParams UserName CpName VendorApplicationName PortName ServiceProviderServiceName TrafficImportanceNumber TrafficLeaseTime 59

60 Interaction UPnP A/V CDS CDS::Browse/Search() Control Point QoS Manager QoS Policy Holder QoS Device** This is the typical interaction for prioritized QoS Traffic Class/TSPEC QM::RequestTrafficQoS() QPH::GetTrafficPolicy() AdmissonPolicyEnabled TrafficImportanceNumber UserImportanceNumber QD::GetPathInformation()* PathInformation QD::GetQosDeviceInfo()* QosDeviceInfo QD::GetQosState() QosDeviceState QD::SetupTrafficQos() * Optional Actions of QoS Device Service **QoS Manager may call actions on multple QoS Device Service Instances on the LAN TrafficImportanceNumber to Layer-2 Packet Priority Mapping Tag Packets with Layer-2 Priority Value 60

61 Parameterized Qos & Admission Control We observed a need for Admission control to ensure that quality does not decrease indefinitely. We use parameters to specify streams. These parameters can be used in the admission control process (and of course in the scheduling) 61

62 Tspec Content Parameters (proposed) Parameters that describe the bandwidth requirements of the content Typical parameters: Mean Bandwidth, Token bucket Peak Bandwidth Minimum Required Bandwidth Typically known to the media server. The content parameters are relevant throughout the network continued 62

63 Background information: token bucket first token bucket second token bucket p tokens/sec r tokens/sec bucket holds up to 0 tokens bucket holds up to b tokens packets token wait remove token packets token wait remove token to network 63

64 Integration with UPnP-AV architecture There are AVCPs out on the market. They are unaware of QoS The intention is that the QosManager simplifies life for the AVCP implementer. I.e. AVCP does the work on AV, QosManager does the work on QoS. AVCP selects a program item. Based on User input it can select some <res>-resources from the set that is possible on the basis of supported format and protocols. It hands over those selected <res> stream and their QoS information to the QosManager. The QosManager goes out and finds & sets up the most-preferred stream 64

65 Browse/Search select content browse or search (get URL to content) - includes formats - includes Tspecs Control Point <item> <res protocolinfo= http-get:*:video/mpeg:* Media Server Media Server ContentDirectory ConnectionManager AVTransport tspec= <TrafficClass>AV</TrafficClas s><q:meandatarate> </q:meandatarate&gt ; > </res> <res protocolinfo= http-get:*:video/mpeg:* tspec= > </res> <res protocolinfo= http-get:*:video/mpeg:* tspec= <TrafficClass>AV</TrafficClas s><q:meandatarate> </q:meandatarate&gt ; > </res> </item> Media Media Renderer Renderer Rendering Control ConnectionManager AVTransport 65

66 Get supported protocols/formats getprotocolinfo() Get transfer protocols Get data formats Control Point getprotocolinfo() Get transfer protocols Get data formats Media Server Media Server ContentDirectory ConnectionManager AVTransport Media Media Renderer Renderer Rendering Control ConnectionManager AVTransport 66

67 Prepare for connection prepareforconnection() specify protocol+format returns ConnManagerID returns AVTransport Instance ID* Control Point prepareforconnection() specify protocol+format returns ConnManagerID returns AVTransport Instance ID* returns RenderControl ID Media Server Media Server ContentDirectory ConnectionManager AVTransport Media Media Renderer Renderer Rendering Control ConnectionManager AVTransport 67 * At least one of them returns the id

68 Invoke RequestTrafficQos RequestTrafficQoS In: TrafficDescriptor with ConnManagerId TrafficId List of Selected Tspecs and URIs Out: ActiveTspecIndex Control Point Media Server Media Server ContentDirectory ConnectionManager AVTransport QoSManager Media Media Renderer Renderer Rendering Control ConnectionManager AVTransport 68 * At least one of them returns the id

69 Set&start content with Transport ID Control Point For appropriate URI: SetTransPortURI() Play() Media Server Media Server ContentDirectory ConnectionManager AVTransport Media Media Renderer Renderer Rendering Control ConnectionManager AVTransport 69

70