locked
HTML5 Audio and Video "onwaiting" Event

Answers

  • James, 

    Thanks for reporting this issue. I can confirm that the onWaiting event does not get called as the documentation suggests. I believe this is due to the fact that we are using the HTTP 1.1 protocol and byte range offset. However it still makes sense that we would call onWaiting even if we don’t create a new HTTP session. I will go ahead and report this issue. Can you please give me a strong business case for why you need this event to be called?

    Thanks,

    James
    James Windows Media SDK Technologies Microsoft Developer Services http://blogs.msdn.com/mediasdkstuff/
    Friday, January 27, 2012 1:27 AM
    Moderator

All replies

  • Hello James,

     

    Let me take a look at this and I will get back to you tomorrow.

     

    Thanks,

     

    James


    James Windows Media SDK Technologies Microsoft Developer Services http://blogs.msdn.com/mediasdkstuff/
    Thursday, January 26, 2012 1:50 AM
    Moderator
  • James, 

    Thanks for reporting this issue. I can confirm that the onWaiting event does not get called as the documentation suggests. I believe this is due to the fact that we are using the HTTP 1.1 protocol and byte range offset. However it still makes sense that we would call onWaiting even if we don’t create a new HTTP session. I will go ahead and report this issue. Can you please give me a strong business case for why you need this event to be called?

    Thanks,

    James
    James Windows Media SDK Technologies Microsoft Developer Services http://blogs.msdn.com/mediasdkstuff/
    Friday, January 27, 2012 1:27 AM
    Moderator
  • Thanks James. The business case for needing this event to be called is to inform the user that playback has halted because buffering is occurring. We can inform the user by displaying a throbber (progress control) in the UI for the media element. If we cannot listen for this event, then playback will simply appear to have halted with no indication to the user that it will continue at some point.

    Thanks,

    James

    Monday, January 30, 2012 8:16 PM
  • Thanks James,

     

    Just out of curiosity how long of a wait are you seeing between the "seek" and playback to restart? Do you know if it is equal to the buffer window specified in the file? Testing an internal content source the delay was only about a second.

     

    Thanks,

     

    James


    James Windows Media SDK Technologies Microsoft Developer Services http://blogs.msdn.com/mediasdkstuff/
    Monday, January 30, 2012 11:38 PM
    Moderator
  • I'm seeing about one second for a 30-second clip loaded externally from Azure, but for large videos (e.g. http://video.ch9.ms/build/2011/key01/BUILD2011KeynoteDay1_low_ch9.mp4) I'm seeing two seconds plus from seek to resuming of playback.

    Tuesday, January 31, 2012 10:57 PM
  • Hey James,

     

    I just wanted to let you know that I reported this as a bug and it is currently under reveiw.

    Thanks,

    James


    James Windows Media SDK Technologies Microsoft Developer Services http://blogs.msdn.com/mediasdkstuff/
    Monday, February 06, 2012 6:25 PM
    Moderator