240 likes | 255 Views
A multi-view surveillance system that captures audio and video at a fixed rate, with active and passive modes for client interaction.
E N D
MP3: Multi-view Surveillance System Instructor: KlaraNahrstedt April 20, 2012 CS414
MP3: Multi-view Surveillance System Window for server 1 Window for server 2 • Server • Capture Audio and Video at a fixed rate • Video: 30 fps, Audio: 8000Hz • Client • Requests for Video and/or Audio • Works in Two modes: Active Mode and Passive Mode • Active Mode: • Media type: Audio, Video • Video Rate: 15 to 25 fps • Audio Rate: 8000Hz • Video Resolution: 640X480 • Passive Mode: • Media type: Video • Video Rate: 10 fps • Video Resolution: 320X240
Client Behavior • Client can request active mode from Server 1 and passive mode from Server 2 • Client can request active mode from Server 2 and passive mode from Server 1 • Client can request active mode from both Server 1 and Server 2 • Client can request passive mode from both Server 1 and Server 2
Client User Interface: Example Connect Edit Video window for Server 1 Video window for Server 2 SWITCH SWITCH Computation window for Server 2 Computation window for Server 1
Resource Admission at Client User • User defines streaming MODE: active or passive • Client performs resource admission Control Channel MODE Server 1 Client
Resource Admission at Client resource.txt • Client • Available Application Bandwidth ABN • Application Frame Size, MN = ? • Application Frame Rate, RN = ? • Audio Bandwidth = 8000 * 16 • Request Bandwidth • Active Mode: BN = (MN * RN) + 8000 * 16 • Passive Mode: BN = (MN * RN) = (MN * 10) Optimistic Allocation [fps:15-25] 8000Hz Audio Signal fps: 10 How to define RN for active mode?
Resource Admission at Client resource.txt • Client • Available Application Bandwidth ABN • Application Frame Size, MN = ? • Application Frame Rate, RN = ? • Request Bandwidth • Active Mode: BN = (MN * RN) + Audio Bandwidth ABN = (MN*RN) + Audio Bandwidth if RN > 25, RN = 25 if RN < 15, REJECT request else RN Show your computation on the Screen
Resource Negotiation with Server • Information sent to server includes • Requested Frame Rate (FPS) for video, • Video Resolution, and • Media type (audio, video) FPS, Resolution Media types MODE Server 1 Client
Resource Admission at Server resource.txt • Server • Available Application Bandwidth ABN • Application Frame Size, MN = ? • Application Frame Rate, RN = [received from client] • Audio Bandwidth = 8000 * 16 • Request Bandwidth • Active Mode: BN = (MN * RN) + 8000 * 16 • Passive Mode: BN = (MN * RN) = (MN * 10) • Admitted if BN <= ABN • Else Rejected Optimistic Allocation
Video Data Flow Architecture Video Source Video Filter Media Encoder Video Muxer App Sink RTP Packet Rate Control Server-Side Segment Network App Source Decode Bin2 Merge Video Sink RTP Packet Synchronization Client-Side ID Media Type Timestamp RTP header Payload UDP Packet Payload
Rate Control: QoS Enforcement • You can build leaky bucket • You can implement token bucket • You can use gstreamer rate control • You can implement your own method You can simply read using a loop While(true){ SendPacket(); Thread.sleep(100); } Sleep (100) => 10 fps
Resource Reservation: Client resource.txt • Available Application Bandwidth ABN • Used Bandwidth for Server 1 B1 • Available Bandwidth ABN = ABN –B1 • Admission is successful for B2 if B2 <= ABN Resource Table
Video Data Flow Architecture using RtpBin Video Source Video Filter Media Encoder Video Muxer App Sink RTP Packet Rate Control Server-Side Segment RtpBin UdpSink UdpSrc Network App Source Decode Bin2 Merge Video Sink RTP Packet Synchronization Client-Side
Implementation Using RtpBin@ Server Tee Video Scale Scale Filter Queue Video Source Video Filter Video Rate Video Encoder Rate Filter RTP Payload UDP Sink • RtpBin combines • RtpSession • RtpSsrcDemux • RtpPtDesmux • RtpJitterBuffer RTCP RTCP UDP Source RTP Bin UDP Sink
Implementation Using RtpBin@ Client RTP DePayload Video Decoder Video Sink UDP Source RTCP RTCP UDP Sink RTP Bin UDP Source rtpBin.connect(new Element.PAD_ADDED() { public void padAdded(Element element, Pad pad) { if (pad.getCaps().toString().contains("video")) { //LINK TO VIDEO SINK via VIDEO MONITOR } else if (pad.getCaps().toString().contains("audio")) { // LINK TO AUDIO SINK via AUDIO MONITOR } } });
Internals of RtpBin http://gstreamer.freedesktop.org/documentation/rtp.html
Evaluation Process for MP3 • Case I: • Server 1 is requested to send stream in ACTIVE mode • Server 2 is requested to send stream in PASSIVE mode • Client has resource to support 25 fps in ACTIVE mode • Case II: • Server 1 is requested to send stream in ACTIVE mode • Server 2 is requested to send stream in PASSIVE mode • SWITCH streaming mode of Server 1 and Server 2 • Client has resource to support 25 fps in ACTIVE mode
Evaluation Process for MP3 • Case III: • Server 1 is requested to send streams in PASSIVE mode • Server 2 is requested to send streams in ACTIVE mode • Modify resource.txt so that ACTIVE mode use 15fps • Low interference in streaming • Case IV: • Server 1 is requested to send streams in PASSIVE mode • Server 2 is requested to send streams in ACTIVE mode • SWITCH mode of Server 1 and Server 2 • Client has resources to support 15fps in ACTIVE mode
Evaluation Process for MP3 • Case V: • Server 1 is requested to send streams in ACTIVE mode • Server 2 is requested to send streams in PASSIVE mode • Modify resource.txt so that ACTIVE mode use 25fps • Low interference in streaming • Case VI: • Server 1 is requested to send streams in ACTIVE mode • Server 2 is requested to send streams in PASSIVE mode • Update resource.txt so that client has enough available bandwidth to support two ACTIVE modes • SWITCH mode of Server 2 into ACTIVE mode • By default, no audio playback from Server 2; however client should receive audio streams from Server 2
Evaluation Process for MP3 • Case VII: • Server 1 is requested to send streams in ACTIVE mode • Server 2 is requested to send streams in ACTIVE mode • MUTE Server 1 audio playback and UNMUTE Server 2 audio playback • No interference in streaming • Client has enough resource to support two ACTIVE mode • Case VIII: • Server 1 is requested to send streams in ACTIVE mode • Server 2 is requested to send streams in ACTIVE mode • SWITCH mode of Server 1 into PASSIVE mode
Evaluation Process for MP3 • Case IX: • Server 1 is requested to send streams in PASSIVE mode • Server 2 is requested to send streams in ACTIVE mode • Modify resource.txt so that admission for ACTIVE mode is not successful • Streaming from Server 2 turns off, no interference in Server 1 streaming • Case X: • Server 1 is requested to streams send in ACTIVE mode • Modify resource.txt so that Server 2 can be requested in ACTIVE mode with 15 fps • SWITCH between modes of Server 1 and Server 2
Evaluation Process of MP3 • For All Cases: • Cases are designed to run continuously one after another process without restarting the program or starting from the beginning • Maintain audio-visual synchronization in ACTIVE mode • Show the computation of resource admission • Show the current frame rate, bandwidth usage, and network jitter
Demonstration and Interview • You must use at least 3 PCs/ laptops for the demo • If you want to use wireless/ wired with only your laptops, please setup the demo in SC3401 • If you want to use wired demo with lab PCs, please setup your demo at SC0216 • Demo date: April 30th • Demo time: • SC3401 @ 5pm • SC0216 @ 6pm
Additional Features for MP3? • It is highly recommended that you build an additional feature in MP3 to SURPRISE US! • Bonus Point: 20 • Bonus point will be awarded based on the amount of surprise!