1 / 20

VCR-oriented Video Broadcasting for Near Video-On-Demand Services

VCR-oriented Video Broadcasting for Near Video-On-Demand Services. Jin B. Kwon and Heon Y. Yeon. Appears in IEEE Transactions on Consumer Electronics, vol. 49, No. 4, Nov. 2003, pp. 1106 - 1113. Outline. Introduction Conditions for continuous VCR VCR-oriented periodic broadcasting (VPB)

hestia
Download Presentation

VCR-oriented Video Broadcasting for Near Video-On-Demand Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. VCR-oriented Video Broadcasting for Near Video-On-Demand Services Jin B. Kwon and Heon Y. Yeon Appears in IEEE Transactions on Consumer Electronics, vol. 49, No. 4, Nov. 2003, pp. 1106 - 1113

  2. Outline • Introduction • Conditions for continuous VCR • VCR-oriented periodic broadcasting (VPB) • Reception schedule for continuous VCR actions • Discontinuous VCR actions handling • Simulation results • Conclusion Presented by Ki (2004-02-04)

  3. Introduction • True VoD systems use dedicated channel for each user • Respond to users quickly • Server bandwidth runs out quickly • Expensive and not scalable Presented by Ki (2004-02-04)

  4. Introduction • Near VoD systems let multiple users share video streams • Scheduled multicast (Close-loop) • Transmission schedule adapt to users arrival pattern • Periodic broadcast (Open-loop) • Transmission schedule is fixed regardless of users arrival pattern • This paper proposes a novel architecture of a periodic broadcast system that guarantee to support VCR actions Presented by Ki (2004-02-04)

  5. Conditions for continuous VCR • VCR functions can be classified into continuous and discontinuous functions • Continuous function • Play Forward/Play Backward • Fast Forward/Fast Backward • Slow Forward/Slow Backward • Pause • Discontinuous • Jump Forward/Jump Backward Presented by Ki (2004-02-04)

  6. Channel 3 …… Channel 4 Channel K-2 Channel 5 Channel K-1 Conditions for continuous VCR d Channel 0 b Channel 1 Channel 2 Presented by Ki (2004-02-04)

  7. Conditions for continuous VCR • Define • ∆(k0, k) be the distance (in second) from play point k0 to a future frame k at a normal play rate γ • c(k) be the time remaining until frame k is consumed • Then, • Consumption time of frame k ≥ time taken to consume all frames between k0 and k Presented by Ki (2004-02-04)

  8. Conditions for continuous VCR • If B is a set of frames currently in buffer, continuous VCR functions can be provided if where b(k) is the next broadcast time of k • Minimal client buffer space required for a client to provide continuous VCR functions consistently is 2nm • must be in buffer before c(k) • Worst case: Presented by Ki (2004-02-04)

  9. VCR-oriented periodic broadcasting (VPB) • VPB uses K/n channels each with bandwidth nb • Si is broadcast over channel Presented by Ki (2004-02-04)

  10. VCR-oriented periodic broadcasting (VPB) • In VPB, the next broadcast time, b(k)≤ d • So if , continuous VCR functions can be provided • Frames with distance > nd do not have to be buffered as they can be obtained by next broadcast before consumption • If n = 3 and the current play point k0 is in Si, target segments containing required future frames are Si, Si+1, Si+2, Si+3 Presented by Ki (2004-02-04)

  11. Reception Schedule • When S1 is being broadcast, S4, S7, …, SK/3-2 are also being broadcast • The following show the required frames to be stored when the channels are transmitting the target segments Presented by Ki (2004-02-04)

  12. Reception Schedule • Since only the frames within the distance nd are considered, the total buffer requirement for forward and backward buffer is 2nm • Receive and store the currently broadcasting frame, kt, into buffer if • Continuous VCR actions are guaranteed Presented by Ki (2004-02-04)

  13. Reception Schedule Presented by Ki (2004-02-04)

  14. Discontinuous VCR Actions Handling • Discontinuous actions render the buffered content useless • Jump to the requested destination immediately maybe impossible due to buffer restrictions and the service latency in periodic broadcast • VPB provides VCR action guarantee as when the service start, except for backward action Presented by Ki (2004-02-04)

  15. Discontinuous VCR Actions Handling • For (a), as all essential frames are in buffer, the action is allowed • For (b), the action is allowed if the current broadcast point satisfy • For (c), destination shift introduced • Maximum destination shift is nd/2 while the average is nd/4 Presented by Ki (2004-02-04)

  16. Simulation Results • Parameters • Mean duration of cont. action = 10s • Mean jumping distance = 60s • Fast Forward/Backward rate, n = 3 • Segment length = 60s • No. of Segments = 32 • Normal playback bitrate, γ= 30fps Presented by Ki (2004-02-04)

  17. Simulation Results Presented by Ki (2004-02-04)

  18. proportion of not shifted actions Simulation Results • Proportion of shifted destinations increases with mean jump distance • The average shift distance increases with the mean jump distance • Long jump actions are probably not serviced by the buffered data Presented by Ki (2004-02-04)

  19. Conclusion • This paper • analyzes the necessary conditions to provide VCR functions • proposes a VCR-oriented broadcasting scheme (VPB) that guarantee to support all continuous actions consistently and discontinuous actions with destination shift • VPB utilizes minimal client buffer requirement • VPB clients bandwidth increases with n Presented by Ki (2004-02-04)

  20. Final Thoughts • VPB is a scheme that support VCR actions with the trade off of increased client bandwidth • It requires frame level synchronization, which may not be possible • Comparisons with other schemes should be provided Presented by Ki (2004-02-04)

More Related