- From: <bugzilla@jessica.w3.org>
- Date: Sat, 22 Sep 2012 00:02:52 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18921 --- Comment #5 from Aaron Colwell <acolwell@chromium.org> 2012-09-22 00:02:50 UTC --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > This is an advanced media API and expects the web application to be able to > > identify where segment boundaries are. The expectation is that some sort of > > manifiest, like DASH or HLS have, will be available to the application so that > > it can determine where the segment boundaries are w/o having to implement > > format parsing in JavaScript > > One thing that can help, is to expose the JavaScript with the segments cue > points (like in Flash video), which should be available after the video is > parsed. This should help the developer to easily implement seeking. In > particular, SeekToMediaSegmentAt(video.currentTime) would be very easy. > > So what I'm suggesting is to expose parsed meta data about the video once its > initialization has finished. I think you are assuming that all the segments come from a single file. The intent of this API is not to tie itself to that restriction. I believe you are also assuming that the cues are always at the beginning of the file which is also not necessarily true with the supported formats. Something would need to parse parts of the file to properly fetch the cues from the end. This API deals with sequences of segments, not files. It intentionally breaks some of the restrictions imposed by files so that you can compose presentations from pieces of different files. Why don't you just do manifest creation on the backend? -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 22 September 2012 00:02:53 UTC